Implement Task

Process

0. GitHub CLI setup

../references/gh-setup.md

gh

verify-task

1. Identify the Task

gh issue view <task_number>    # Gherkin, Contracts, Impacted Areas — also yields feature and epic numbers
# Extract feature and epic numbers, then in parallel:
gh issue view <feature_number> # ACs, user stories
gh issue view <epic_number>    # Goal, context, constraints

2. Lifecycle check

gh issue view <task_number> --json labels --jq '.labels[].name'

designed

AskUserQuestion

• question

  : "This task doesn't have a

  designed

  label yet. How would you like to proceed?"

• header

  : "Design check"

• options

  :

  [{label: "Design it first", description: "Go back and run 

  design-task

   (default)"}, {label: "Skip design", description: "Proceed to implementation anyway"}]

• Design it first → follow the

  design-task

  process, passing the Task number in as context.
• Skip design → proceed.

designed

3. Load the technical steering document

docs/steering/TECH.md

AskUserQuestion

• question

  : "docs/steering/TECH.md doesn't exist yet. This document captures your stack, architecture patterns, and technical constraints. Would you like to create it now?"

• header

  : "Tech steering doc missing"

• options

  :

  [{label: "Create it now", description: "Run 

  steer-tech

   before continuing (recommended)"}, {label: "Skip for this session", description: "Continue without it — technical decisions won't reference project standards"}]

• Create it now → follow the

  steer-tech

  process, then return to this skill and continue from step 4.
• Skip for this session → continue without it.

4. Set up the branch

main
└── feature/<feature-number>-<feature-slug>   (merges → main)
    └── task/<task-number>-<task-slug>         (merges → feature branch)

claude-haiku-4-5

[a-z0-9-]

date-range-filter

git fetch origin
git checkout feature/<feature-number>-<feature-slug> 2>/dev/null || {
  git checkout main
  git pull --rebase origin main
  git checkout -b feature/<feature-number>-<feature-slug>
  git push -u origin feature/<feature-number>-<feature-slug>
}
git pull --rebase origin feature/<feature-number>-<feature-slug>

# Fresh work:
git checkout -b task/<task-number>-<task-slug>

# Resumed work (branch already exists):
git checkout task/<task-number>-<task-slug>
git rebase origin/feature/<feature-number>-<feature-slug>

5. Explore the codebase

**/*.test.ts

tests/test_*.py

import { describe, it } from 'vitest'

npm test

pytest

npm run coverage

pytest --cov

• 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

6. Draft the Technical Approach

• 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

AskUserQuestion

question: "Does this align with how you'd approach it?"

header: "Approach review"

options: [{label: "Yes — looks good, proceed", description: "Continue with implementation"}, {label: "I have constraints to share", description: "I want to adjust the approach first"}, {label: "Suggest an alternative", description: "Let me describe a different approach"}]

See

references/issue-body-update-pattern.md

for the read-merge-write pattern. Use

/tmp/wtf-implement-task-approach.md

as the temp file.

gh issue edit <task_number> --body-file /tmp/wtf-implement-task-approach.md

8. Drive the TDD cycle

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, no deep nesting.
4. Commit — create an atomic semantic commit:
   bash

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

   Commit type:

   feat

   for new behavior,

   fix

   for bug fixes,

   test

   for test-only changes,

   refactor

   for refactors,

   chore

   for config/build changes.
5. Do not skip ahead — each scenario is a checkpoint.

package.json

lint

typecheck

type-check

check

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

9. Verify coverage

docs/steering/QA.md

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

10. Update Test Mapping

<scenario name>

<test file path:line>

See

references/issue-body-update-pattern.md

for the read-merge-write pattern. Re-fetch the body (do not reuse the temp file from step 6). Use

/tmp/wtf-implement-task-test-mapping.md

as the temp file.

gh issue edit <task_number> --body-file /tmp/wtf-implement-task-test-mapping.md

11. Mark implemented and offer to continue

implemented

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

AskUserQuestion

• question

  : "What's next?"

• header

  : "Next step"

• options

  :

  [{label: "Verify this Task", description: "Run QA against the Gherkin scenarios (recommended next step, default)"}, {label: "Open a pull request", description: "Create a PR for this branch"}, {label: "Implement another Task", description: "Implement another Task for the same Feature"}]

• Verify this Task → follow the

  verify-task

  process, passing the Task number in as context so the user is not asked for it again.
• Open a pull request → follow the

  create-pr

  process, passing the Task number and branch in as context.
• Implement another Task → restart this skill from step 1.