Skill: fullstackdev (version 1.0.0)

--- name: FullStackDev description: Master-level fullstack development standards for FastAPI/Starlette/Uvicorn backend, SQLAlchemy 2.x + SQLite data layer, Jinja2 + Vanilla JS frontend, auth/security hardening, Windows-aware automation, and production packaging. Use when designing features, fixing bugs, refactoring, hardening security, preparing releases, or reviewing architecture in this technology stack. --- # FullStackDev Apply professional engineering standards across backend, data, frontend, security, and operations. ## Core Execution Flow (mandatory) For every non-trivial task, follow this order: 1. Analyze current behavior and constraints 2. Propose minimal safe patch 3. Evaluate risks (security, compatibility, data integrity) 4. Define and run test checklist 5. Provide rollback plan 6. Record the change in `history.md` Never skip risk/test/rollback/history sections in substantial changes. ## Scope - FastAPI + Starlette + Uvicorn service architecture - Pydantic settings + environment config discipline - SQLAlchemy 2.x patterns + SQLite operational safety - Jinja2 server-rendered UI + Vanilla JS enhancement - JWT/auth/password hashing/crypto-safe changes - Windows-aware integrations (including COM-dependent flows) - Packaging and runtime operations (logging, release readiness) ## Required Output Contract Always return: - **Change summary** - **Files touched** - **Risk assessment** - **Test checklist** - **Rollback steps** - **History entry** (what was appended to `history.md`) For sensitive changes (auth/crypto/data migrations), include explicit blast-radius notes. ## Reference Map Read only what is needed: - Architecture decisions -> `references/architecture.md` - Backend implementation rules -> `references/backend-fastapi.md` - Data layer rules -> `references/data-sqlalchemy-sqlite.md` - Frontend patterns -> `references/frontend-jinja-vanillajs.md` - Security/auth/crypto -> `references/security-auth-crypto.md` - Windows-specific behavior -> `references/windows-office-automation.md` - Packaging & ops -> `references/packaging-ops.md` - Quality gates -> `references/testing-quality-gates.md` - Incident/debug playbook -> `references/troubleshooting.md` ## Hard Guardrails - Do not introduce unnecessary frameworks. - Do not replace architecture style unless explicitly requested. - Do not weaken auth, password, token, or crypto controls. - Do not make cross-platform assumptions for Windows-specific integrations. - Do not perform destructive data operations without rollback strategy. ## Change History Rule This rule is for day-to-day development work done **with this skill**. It is **not** related to ClawHub publishing metadata. Maintain `history.md` in the active work area (default: skill root). If the user provides a custom path, write there instead. Append one entry per completed task using this template: ``` ## YYYY-MM-DD HH:MM UTC - <short title> - Request: <one-line request summary> - Changes: <files/areas changed> - Risks: <top risk or "none significant"> - Tests: <what was validated> - Rollback: <how to revert> ``` Keep entries concise and factual. Minimum logging behavior (mandatory): - Add exactly one history entry for each completed implementation task. - If no code/config file changed, still log decision-only work as "analysis-only". - In the final response, include the exact history block that was appended. ## Templates Use templates from `templates/` for consistency: - Task intake -> `templates/codex-task-template.md` - Feature/PR notes -> `templates/pr-template.md` - Bugfix execution -> `templates/bugfix-template.md` - Refactor safety plan -> `templates/refactor-template.md` - History entry -> `templates/history-entry-template.md`

path: references/architecture.md
content: # Architecture Standards

- Keep modular monolith boundaries clear: router -> service -> data access.
- Keep side effects isolated behind service functions.
- Prefer explicit interfaces and predictable contracts.
- Keep background-heavy jobs isolated from request thread where possible.
- Avoid hidden coupling between UI templates and backend internals.


path: references/backend-fastapi.md
content: # Backend (FastAPI/Starlette/Uvicorn)

- Keep routers thin; business logic belongs in service layer.
- Use dependency injection for auth, db session, and settings.
- Validate request/response models strictly.
- Return stable error shapes; avoid leaking internals.
- Add structured logging around critical paths.


path: references/data-sqlalchemy-sqlite.md
content: # Data Layer (SQLAlchemy 2.x + SQLite)

- Use SQLAlchemy 2.x style consistently.
- Keep transaction boundaries explicit.
- For SQLite, preserve durability/performance pragmas (including WAL-oriented operation where configured).
- Never apply schema/data changes without rollback notes.
- Validate query performance impact for frequent paths.


path: references/frontend-jinja-vanillajs.md
content: # Frontend (Jinja2 + Vanilla JS)

- Keep templates readable and component-like by partialization.
- Prefer progressive enhancement over JS-heavy rewrites.
- Keep DOM hooks stable and minimal.
- Maintain CSS consistency and naming hygiene.
- Avoid introducing SPA frameworks unless explicitly requested.


path: references/packaging-ops.md
content: # Packaging & Operations

- Keep packaging reproducible and documented.
- Preserve logging rotation and operational visibility.
- Validate runtime config loading paths.
- Verify release artifact behavior against expected startup mode.


path: references/security-auth-crypto.md
content: # Security / Auth / Crypto

- Treat auth and crypto changes as high-risk.
- Preserve secure password hashing practices.
- Validate JWT creation/verification paths end-to-end.
- Do not downgrade key sizes, signature checks, or verification rigor.
- Include explicit threat/risk note for every security-touching patch.


path: references/testing-quality-gates.md
content: # Testing & Quality Gates

For every meaningful change, define checks for:

- Functional correctness
- Regression risk
- Security impact (if relevant)
- Performance sanity (critical paths)
- Operational sanity (startup/logging/config)

No "done" without a concrete test list.


path: references/troubleshooting.md
content: # Troubleshooting Playbook

- Reproduce issue with minimal deterministic steps.
- Isolate layer (UI / API / service / data / integration).
- Capture logs and error context before patching.
- Prefer minimal fix over broad refactor.
- Document root cause + prevention note.


path: references/windows-office-automation.md
content: # Windows-Aware Integrations

- Assume COM-dependent flows require Windows runtime.
- Gate platform-specific code paths clearly.
- Add graceful failure behavior for unsupported environments.
- Document operational prerequisites for automation-dependent features.


path: templates/bugfix-template.md
content: # Bugfix Plan

## Symptom
## Root cause hypothesis
## Minimal fix
## Validation steps
## Rollback steps


path: templates/codex-task-template.md
content: # Task Intake

## Goal
## Constraints
## Affected Layers
## Non-Goals
## Risk Level (Low/Med/High)
## Expected Output
## history.md Path (default: ./history.md)
## History Entry Title


path: templates/history-entry-template.md
content: ## YYYY-MM-DD HH:MM UTC - <short title>
- Request: <one-line request summary>
- Changes: <files/areas changed>
- Risks: <top risk or "none significant">
- Tests: <what was validated>
- Rollback: <how to revert>


path: templates/pr-template.md
content: # PR Summary

## What changed
## Why
## Risks
## Tests performed
## Rollback plan


path: templates/refactor-template.md
content: # Refactor Safety Plan

## Refactor target
## Invariants to preserve
## Compatibility risks
## Test matrix
## Revert strategy


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)