| name | add-feature |
| description | Plan and implement a complete feature end-to-end across all layers |
| disable-model-invocation | true |
Implement the following feature: $ARGUMENTS
This is a full-feature workflow that touches every layer. Follow the team's standards at each step.
Phase 1 — Plan (Sofia Nakamura)
- Define the user story: who needs this, what it does, why it matters
- Read existing code to understand where the feature fits in the architecture
- Identify every file that needs to change or be created
- List acceptance criteria — what "done" looks like
- Present the plan before writing any code
Phase 2 — Schema & Config (Daniel Okoye + Marcus Chen)
- Add any new typed schemas (see stack concepts) to the models/schemas file
- Explicit types on every field — no untyped/any fields
- Validation constraints where applicable (see stack concepts)
- Add any new settings to the config file with the project's env prefix
- Document new settings in the env example file with description and default
Phase 3 — Core Layer (Alex Rivera)
Skip if the feature doesn't touch the core/device layer.
- If new behavior is needed, extend the primary protocol/interface
- Implement in both the real and mock implementations — both must stay in sync
- Use typed exceptions from the exception hierarchy
- Document any protocol-specific commands with clear comments
Phase 4 — Service Logic (Alex Rivera + Janet Moore)
- Add business logic to the service layer
- Thread-safe: wrap external resource access in the lock mechanism
- Rollback on partial failure for multi-entity operations
- Audit log via the project's audit logger for any state changes
- Typed exceptions for error conditions
Phase 5 — API Endpoints (Daniel Okoye)
- Add routes to the appropriate router (see project config)
- Thin handlers — delegate to the service class
- Auth-protected DI dependency for protected endpoints
- Public DI dependency for unauthenticated endpoints
- Full OpenAPI metadata: response schema, summary, description, responses (see stack concepts)
- Static routes before parameterized routes
- Map domain exceptions to HTTP status codes per project config
Phase 6 — Security (Janet Moore)
- Verify new endpoints respect auth when API key is configured
- Verify error responses use the error response model — no stack traces or internals
- Verify input validation via typed schemas (see stack concepts) — no raw input trusted
- If handling secrets: use timing-safe comparison (see stack concepts), never equality operator
Phase 7 — Tests (Priya Sharma)
- Write tests for each new endpoint: success, validation error, device/service error
- Write tests for new service methods: happy path, edge cases, error conditions
- If state changes: test audit log output via log capture mechanism (see stack concepts)
- If multi-entity operations: test rollback on partial failure
- Add to corresponding test file (see test file mapping in project config)
Phase 8 — Verify (All)
Run the test command and the type-check command (see project config).
Both MUST pass with zero errors.
Phase 9 — Documentation (Sofia Nakamura)
- Update project documentation — API endpoints table, configuration table, examples
- Update app factory description if the feature changes API capabilities
- Verify OpenAPI docs reflect all new endpoints