What problem does it solve?
Build and extend brownfield features in an existing codebase. Always explore
the codebase first, then decide from the user's requested change whether
specs (spec.md/tasks.md/checklist.md) are required before coding. When
specs are required, depend on generate-spec for the shared planning,
clarification, approval, and backfill workflow. Even when specs are not
required, still add and run related tests for
unit/property-based/user-critical integration chain/E2E coverage. Tests must
not stop at happy-path validation: for business-logic changes require
property-based testing unless explicitly N/A with reason, design
adversarial/regression/authorization/idempotency/concurrency coverage where
relevant, use mocks for external services in logic chains, and verify
meaningful business outcomes rather than smoke-only success.
Core Features & Use Cases
- Explore the existing codebase to identify entrypoints, data flow, dependencies, and user-critical logic.
- Decide whether specs are required based on change scope; trigger generate-spec if needed to create or update docs.
- Implement changes with minimal scope, preserving existing behavior unless required.
- Add risk-based tests including unit, property-based, regression, integration, and E2E coverage; ensure explicit approval when planning docs are generated.
- Backfill planning artifacts and keep artifacts traceable and aligned with completion results.
Quick Start
Map the affected codebase, decide whether specs are required, trigger the generate-spec workflow when needed, and implement with minimal, well-tested changes.