implement-feature

Implement Feature

Implement an approved feature plan with fresh-context slices, TDD, evidence, and PR-ready output.

Input: $ARGUMENTS

Optional args: slug=, ticket=<id/url>, mode=interactive|autonomous|channel, channel=, auto_continue=true|false, profile=business|hybrid|technical.

Instructions

Execute the following steps for $ARGUMENTS.

Implement Feature Workflow

Goal: Build an approved feature through TDD slices and route completed work to verification.

Steps

1. Load plan:
   • Search docs/prd/ and docs/srs/ for a matching [slug]; if absent, use the newest matching artifact.
   • If multiple candidates exist, ask the user to choose or input the target slug.
   • PRD or ticket
   • SRS/FRS technical design if present
   • Implementation plan
   • Matched framework and common skills
   • If stable REQ-*, AC-*, trace, or required SRS/test lanes are missing, stop and route to plan-feature, design-solution, or implementation-readiness.
2. Prepare workspace:
   • Confirm clean or intentionally dirty git state.
   • Create branch or worktree only when project workflow expects it.
   • Provision dependencies BEFORE tests (npm ci/pnpm i/yarn, flutter pub get, ./gradlew dependencies, or pip install -e . from the lockfile); isolated worktrees lack ignored toolchains.
   • If install fails from network, auth, or time budget, report verification_infra_failed with the exact command/error; never claim tests passed or silently skip verification.
   • Initialize or update docs/srs/srs-task-list.md with small vertical slices.
3. Implement slices:
   • For each slice, write or update the failing test first.
   • Before the test, record its observable contract, distinct fault, smallest layer, minimal cases, and exact focused command (the Test Intent Record).
   • Consume the named REQ-* and AC-* for each slice; do not invent scope from code inspection.
   • For new behavior, do not keep pre-test implementation code as a reference: observe the expected RED first.
   • For legacy or bug-fix slices, characterize only when needed, then make the intended change RED while preserving unrelated existing code.
   • Implement the smallest passing code.
   • Refactor without expanding scope.
   • Run the focused target in foreground, single-run, sequential mode; classify invalid RED, unexpected GREEN, timeout, and cleanup instead of retrying blindly.
   • Keep slice evidence near the task item.
   • Use sub-agents only when the runtime supports them and ownership is disjoint.
   • If a fix path is unclear, stop and apply root-cause debugging before more code changes.
4. Maintain context hygiene:
   • Start fresh context for large independent slices when possible.
   • Preserve decisions in docs/srs/srs-task-list.md or docs/prd/prd-plan-[slug].md.
   • If behavior or scope changes, update docs/prd/prd-[slug].md and docs/srs/srs-[slug].md before closing the slice.
   • Avoid carrying raw logs; summarize failures and fixes.
5. Prepare handoff:
   • Run fresh local automated checks before claiming success.
   • Update requirement trace notes for changed AC coverage.
   • Capture evidence in docs/srs/srs-walkthrough.md.
   • For autonomous/channel mode, delegate only with disjoint files, owner, AC IDs, expected artifact, and verification command.
   • Route next step to verify-work.