Wtf.implement Task

Implement Task

Start an existing Task as a developer.

Read the full spec (Task + Feature + Epic). Map it to the actual codebase. Propose a concrete technical approach. Drive implementation test-first against each Gherkin scenario.

The expected Task issue body structure is defined in @.github/ISSUE_TEMPLATE/TASK.md.

Process

0. GitHub CLI setup

Run steps 1–2 of ../references/gh-setup.md (install check and auth check). If gh is not installed or not authenticated, stop. Extensions are not required for this skill.

If this skill was invoked from wtf.verify-task or another skill that already ran gh-setup this session, skip this step.

1. Identify the Task

Call AskUserQuestion (per ../references/questioning-style.md):

• question: "Which Task are you implementing?"
• header: "Task"
• options: from recent open issues labeled task

Walk Task → Feature → Epic per ../references/spec-hierarchy.md to extract Gherkin, Contracts, Impacted Areas (Task) and ACs / Goal / constraints (Feature, Epic).

2. Lifecycle check

Apply the absent-label gate from ../references/lifecycle-labels.md for the designed label on the Task.

Recommended skill: wtf.design-task. Header: Design check.

On Design it first → follow wtf.design-task and pass the Task number as context. On Skip design → continue. If the label is present, continue silently.

3. Load the technical steering document

Load docs/steering/TECH.md per the strict consumer-side load in ../references/steering-doc-process.md (recommended skill: wtf.steer-tech). Apply its stack, architecture patterns, key constraints, commands, and ADRs silently throughout this session.

4. Set up the branch

Set up the feature branch and task branch per ../references/branch-setup.md (slug generation, feature-branch create-or-checkout, task-branch create-or-resume). Resolve any conflicts before you continue.

5. Explore the codebase

Before you explore, identify the test framework setup. Read a sample of existing test files. Record the following in a working scratchpad before you continue. These govern every test written in step 8:

Use the Agent tool with these concrete searches (run in parallel):

• Grep for the domain nouns and verbs from the Task's Functional Description across *.{ts,tsx,js,jsx,py,go,rb} files — finds files and modules this task will touch
• Glob matching the file patterns for each Impacted Area listed in the Task (e.g. src/api/**/*, src/features/<feature-slug>/**/*) — surfaces integration points and existing patterns
• Grep for interface or type names from the Task's Contracts section — finds current interface definitions to implement against
• Glob matching the test file pattern from the scratchpad (e.g. **/*.test.ts) near the integration points found above — surfaces existing tests covering adjacent behavior
• Grep for any import of the domain objects or services this task depends on — identifies dependencies that must exist first

Also fetch any relevant wiki pages or in-repo glossary docs for this task's Bounded Context. Use these so the implementation and test naming align with the team's Ubiquitous Language.

6. Draft the Technical Approach

Apply strict STE per ../references/ste-writing.md before you write any durable body (Technical Approach prose and later issue updates). Commit subject/body prose follows STE via ../references/commit-conventions.md.

Produce a concrete Technical Approach with actual file paths (not generic layer names):

• Architecture decisions: which layer owns what, which patterns to follow
• Data flow: how data moves from input to output
• Trade-offs: what alternatives were considered and why this approach was chosen
• Impacted Areas: concrete file paths for Backend, Frontend, Database, APIs

7. Review approach with user

Show the Technical Approach. Then call AskUserQuestion (per ../references/questioning-style.md):

• question: "Does this align with how you'd approach it?"
• header: "Approach review"
• options:
  • Yes — looks good, proceed → continue with implementation
  • I have constraints to share → adjust the approach first
  • Suggest an alternative → describe a different approach

Apply changes. Then update the Task issue with the Technical Approach and Impacted Areas.

See references/issue-body-update-pattern.md for the read-merge-write pattern (it goes through the gh body helper).

python3 .wtf/gh-body.py read <task_number>        # prints a temp path; Read it, merge in Technical Approach + Impacted Areas
python3 .wtf/gh-body.py edit <task_number> --body-file "<path-from-read>"

8. Drive the TDD cycle

For each Gherkin scenario in the Task, process them in order. Match the project's established test patterns discovered in step 5. Reference the Contracts & Interfaces section for exact request/response shapes.

1. Write the failing test for the scenario.

2. Implement the minimum code to make it pass.

3. Refactor if needed. Keep functions under 40 lines. Avoid deep nesting.

4. Commit — atomic semantic commit per ../references/commit-conventions.md. Use the Scenario: and Task: trailers:

   git add <changed files>
   git commit -m "<type>(<scope>): <short description>
   
   Scenario: <scenario name>
   Task: #<task_number>"
   

5. Do not skip ahead. Each scenario is a checkpoint.

Once all scenarios are green, run the full lint and type-check gate once across all changes. Check package.json for lint, typecheck, type-check, or check script keys. Run whichever exist:

# e.g. npm run lint && npm run typecheck

Fix any issues before you continue to coverage.

9. Verify coverage

Once all scenarios pass, confirm unit test coverage meets the minimum threshold for all new and modified code.

Use the threshold specified in docs/steering/QA.md if it exists. Default to 80% if the document is absent or does not define a threshold:

# Run the project's coverage command (check package.json scripts)

If coverage is below 80% on any new or modified file, add targeted tests before you continue. Every public function must have at least one happy-path and one error-path test.

10. Update Test Mapping

Fill the Test Mapping table in the Task issue with concrete file paths:

See references/issue-body-update-pattern.md for the read-merge-write pattern. Re-read the body (do not reuse the temp file from step 6).

python3 .wtf/gh-body.py read <task_number>        # re-fetch; prints a fresh temp path; Read it, update the Test Mapping table
python3 .wtf/gh-body.py edit <task_number> --body-file "<path-from-read>"

Print the updated Task issue URL.

11. Mark implemented and offer to continue

Add the implemented lifecycle label. This is mandatory regardless of invocation mode:

gh issue edit <task_number> --add-label "implemented"

If invoked from the loop (non-interactive mode), skip the ask below and return control to the loop.

Call AskUserQuestion (per ../references/questioning-style.md):

• question: "What's next?"
• header: "Next step"
• options:
  • Verify this Task → follow wtf.verify-task, passing the Task number in as context (recommended)
  • Open a pull request → follow wtf.create-pr, passing the Task number and branch in as context
  • Implement another Task → restart this skill from step 1