Task

Input

$ARGUMENTS - Task number or name (e.g., "002" or "bento-grid")

If empty, ask user which task to work on.

Steps

1. Find task file:

   .context/tasks/*$ARGUMENTS*.md
   

   Note: Only search in tasks/, not tasks-done/. Done tasks are archived and shouldn't be reopened.

2. Read context:

   • Task file
   • .context/patterns-architecture.md (if exists)
   • .context/domain.md (if exists) — read domain rules referenced by task acceptance criteria
   • Check task status and dependencies

3. Load specialized skill (if referenced):

   Check ## Technical Notes for a **Specialized Skill:** line.

   If found:

   • Read ONLY the sections listed in **Key sections to read:** from the referenced SKILL.md
   • Do NOT read the entire skill file — only the relevant sections, to keep context lean
   • Follow the skill's guidelines for the ACs in this task alongside patterns-architecture.md
   • Note in progress log: - [date] Using [skill-name] for [what]

   If not found:

   • Proceed normally with patterns-architecture.md guidance only

   Fallback discovery (only if no skill reference in task, AND AC clearly needs specialized work):

   • If an AC mentions writing spec/test files, migrations, or other specialized artifacts but no skill was referenced (e.g., task was created by /ctx:create-task, not breakdown):
   • Quick glob: .claude/skills/*/SKILL.md and ~/.claude/skills/*/SKILL.md
   • Read frontmatter only (name + description) — match against AC
   • If match found, ask user: "Found skill [name] for this work. Use it? (yes/no)"
   • If yes: read relevant sections, add **Specialized Skill:** to Technical Notes for future reference
   • If no: proceed normally

4. Verify ready:

   • Status should be pending or in-progress
   • Dependencies should be done
   • If blocked, report why

5. Begin work:

   • Update status to in-progress if pending
   • Add progress log entry: - [date] Started
   • Work through acceptance criteria in order

6. During work:

   • Follow patterns from patterns-architecture.md
   • If a specialized skill is loaded, follow its guidelines for relevant ACs
   • Update progress log with significant milestones
   • If blocked, update status and note blocker
   • AC tracking (MANDATORY): After completing work for an acceptance criterion, immediately edit the task file to change - [ ] to - [x] for that item. Do NOT defer this — update the checkbox as soon as the criterion is satisfied.

7. On completion (MANDATORY): After all acceptance criteria are checked [x]:

   • Change ## Status: in-progress to ## Status: done in the task file
   • Add progress log entry: - [date] Done — all ACs satisfied
   • Do NOT leave status as in-progress when all ACs are done

8. Verification on completion: Read the task's ## Verification: field (none / test / full). If config verification.carefulMode is true → treat as full regardless.

   • none: Skip verification entirely.
   • test: Check if a test-runner agent exists (glob ~/.claude/agents/test-runner*).
     • If found → suggest: "Run tests for affected code? (yes/no)"
     • If not found → suggest: "Consider running tests manually before marking complete."
   • full: Check for both test-runner and build-validator agents.
     • If found → suggest: "Run tests and build validation? (yes/no)"
     • If not found → suggest: "Consider running tests and build manually."
   • NEVER auto-run — always ask user first.

9. Suggest commit (discovery-based): After task completion, if a commit-related skill is available:

   • Quick glob: ~/.claude/skills/*/SKILL.md — scan frontmatter for "commit" or "push" in description
   • If found → suggest: "Task complete. Use [skill-name] to commit with task ID in scope? e.g., feat(task-NNN): [goal]"
   • If not found → suggest: "Task complete. Consider committing with task reference: feat(task-NNN): [goal]"

10. Domain check on completion: If the task references domain rule IDs (e.g., ORD-001, PAY-002) in its acceptance criteria:

• Ask: "This task referenced domain rules [list IDs]. Did the implementation match these rules exactly, or did business logic change?"
• If user says logic changed → generate proposed domain updates using Domain Impact Protocol format → show to user → require confirmation → update domain.md
• If user says matched exactly → no action needed

If during implementation you discover code behavior contradicts a domain rule:

• STOP — report the conflict: "[Rule ID] says X, but code does Y. Is this a bug or a stale rule?"
• Wait for user decision before proceeding

Output

Confirm task loaded and show:

• Goal
• Acceptance criteria (with current status)
• Next action to take

Gotchas

• Only search tasks/, never tasks-done/: Done tasks are archived and read-only. If user asks for a completed task, inform them it's in tasks-done/ but do not re-open it.
• AC checkbox updates are MANDATORY and immediate: Update - [ ] to - [x] the moment an acceptance criterion is satisfied. Do not batch updates at the end.
• Code vs domain conflict = STOP: If implementation contradicts a domain rule (referenced by Rule ID in ACs), stop work immediately. Report the conflict and wait for user decision.
• Blocked tasks need a reason: If a task cannot proceed, update status to blocked and document why. Do not silently skip to another task.
• Verification field controls post-completion behavior: Check the task's Verification: field. Only suggest test/build runs when the level warrants it (see config-convention).

Final Step — Execution Log

If ${CLAUDE_PLUGIN_DATA} is set and config logging.enabled is true:

• Append one JSONL line to ${CLAUDE_PLUGIN_DATA}/ctx-logs/execution.jsonl
• Fields: ts (ISO-8601), skill ("ctx:<name>"), project (cwd basename), args, outcome ("success"|"failure"|"partial"|"corrected"), failure_type, failure_detail
• See shared/conventions/logging-convention.md for schema