feature-dev

Use this skill to coordinate non-trivial feature work from discovery through implementation, review, validation, and summary. ## Read Next Before running this workflow, read: - `references/phase-workflow.md` Use the sub-skills in this directory only when their phase applies: - `code-explorer`: deep codebase tracing and implementation analysis - `code-architect`: architecture design and implementation blueprinting - `code-reviewer`: high-signal review for correctness and project fit ## Role This parent skill is the orchestration layer. Keep it focused on routing, phase selection, and handoff between sub-skills. Concrete execution details belong in the phase workflow reference or in the smallest applicable sub-skill. ## Core Principles - Understand the codebase before changing it. - Ask concrete clarifying questions when behavior, scope, compatibility, or integration points are underspecified. - Read files surfaced by exploration or design passes before making architectural claims. - Prefer simple, maintainable designs grounded in repository patterns. - Track progress with a todo list when the work spans multiple steps. - Compress the workflow for trivial tasks, but preserve the same reasoning discipline. ## Workflow Summary The detailed actions, examples, and review rules live in `references/phase-workflow.md`. The phase order is: 1. Discovery: understand the request and constraints. 2. Codebase exploration: map relevant implementation patterns. 3. Clarifying questions: resolve material ambiguity before designing. 4. Architecture design: compare viable approaches and choose one. 5. Implementation: build the approved or obvious approach. 6. Quality review: run risk-appropriate review, validation, and Cleanup Gate. 7. Summary: report decisions, changed files, validation, and residual risks. ## Delegation Rules - Use `code-explorer` for broad or unfamiliar areas before designing. - Use `code-architect` when multiple credible architecture choices exist. - Use `code-reviewer` for non-trivial implementation review or explicit review loops. - Default to at most one active delegated reviewer per review round. Treat architecture, correctness, simplicity, and project conventions as review dimensions that one reviewer can cover together. - In a review loop, keep the current reviewer only long enough to verify fixes for its own findings, then start the next full-scope round with a fresh reviewer. - Use parallel reviewers within one round only when the user explicitly requests them or a concrete high-risk scope justifies independent review. - After delegated review, the main agent still owns consolidation, validation, and final handoff quality. ## When Not To Use This workflow is usually overkill for: - one-line bug fixes - trivial refactors - clearly scoped edits in a single file - urgent hotfixes where architecture comparison adds no value