gps-denied-onboard/.claude/commands/implement/SKILL.md

name, description, category, tags, disable-model-invocation

name	description	category	tags	disable-model-invocation
implement	Implement tasks sequentially with dependency-aware batching and integrated code review. Reads flat task files and _dependencies_table.md from TASKS_DIR, computes execution batches via topological sort, implements tasks one at a time in dependency order, runs code-review skill after each batch, and loops until done. Use after /decompose has produced task files. Trigger phrases: - "implement", "start implementation", "implement tasks" - "execute tasks"	build	implementation batching code-review	true

Implementation Runner

Implement all tasks produced by the /decompose skill. This skill reads task specs, computes execution order, writes the code and tests for each task sequentially (no subagents, no parallel execution), validates results via the /code-review skill, and escalates issues.

For each task the main agent reads the task spec, analyzes the codebase, implements the feature, writes tests, and verifies acceptance criteria — then moves on to the next task.

Core Principles

• Sequential execution: implement one task at a time. Do NOT spawn subagents and do NOT run tasks in parallel.
• Dependency-aware ordering: tasks run only when all their dependencies are satisfied
• Batching for review, not parallelism: tasks are grouped into batches so /code-review and commits operate on a coherent unit of work — all tasks inside a batch are still implemented one after the other
• Integrated review: /code-review skill runs automatically after each batch
• Auto-start: batches start immediately — no user confirmation before a batch
• Gate on failure: user confirmation is required only when code review returns FAIL
• Commit and push per batch: after each batch is confirmed, commit and push to remote

Context Resolution

• TASKS_DIR: _docs/02_tasks/
• Task files: all *.md files in TASKS_DIR (excluding files starting with _)
• Dependency table: TASKS_DIR/_dependencies_table.md

Prerequisite Checks (BLOCKING)

1. TASKS_DIR exists and contains at least one task file — STOP if missing
2. _dependencies_table.md exists — STOP if missing
3. At least one task is not yet completed — STOP if all done

Algorithm

1. Parse

• Read all task *.md files from TASKS_DIR (excluding files starting with _)
• Read _dependencies_table.md — parse into a dependency graph (DAG)
• Validate: no circular dependencies, all referenced dependencies exist

2. Detect Progress

• Scan the codebase to determine which tasks are already completed
• Match implemented code against task acceptance criteria
• Mark completed tasks as done in the DAG
• Report progress to user: "X of Y tasks completed"

3. Compute Next Batch

• Topological sort remaining tasks
• Select tasks whose dependencies are ALL satisfied (completed)
• A batch is simply a coherent group of tasks for review + commit. Within the batch, tasks are implemented sequentially in topological order.
• Cap the batch size at a reasonable review scope (default: 4 tasks)
• If the batch would exceed 20 total complexity points, suggest splitting and let the user decide

4. Assign File Ownership

For each task in the batch:

• Parse the task spec's Component field and Scope section
• Map the component to directories/files in the project
• Determine: files OWNED (exclusive write), files READ-ONLY (shared interfaces, types), files FORBIDDEN (other components' owned files)

Since execution is sequential, there is no parallel-write conflict to resolve; ownership here is a scope discipline check — it stops a task from drifting into unrelated components even when alone.

5. Update Tracker Status → In Progress

For each task in the batch, transition its ticket status to In Progress via the configured work item tracker (Jira MCP — see protocols.md for detection) before starting work. If tracker: local, skip this step.

6. Implement Tasks Sequentially

For each task in the batch in topological order, one at a time:

1. Read the task spec file.
2. Respect the file-ownership envelope computed in Step 4 (OWNED / READ-ONLY / FORBIDDEN).
3. Implement the feature and write/update tests for every acceptance criterion in the spec.
4. Run the relevant tests locally before moving on to the next task in the batch. If tests fail, fix in-place — do not defer.
5. Capture a short per-task status line (files changed, tests pass/fail, any blockers) for the batch report.

Do NOT spawn subagents and do NOT attempt to implement two tasks simultaneously, even if they touch disjoint files.

7. Collect Status

• After all tasks in the batch are finished, aggregate the per-task status lines into a structured batch status.
• If any task reported "Blocked", log the blocker with the failing task's ID and continue — the batch report will surface it.

Stuck detection — while implementing a task, watch for these signals in your own progress:

• The same file has been rewritten 3+ times without tests going green → stop, mark the task Blocked, and move to the next task in the batch.
• You have tried 3+ distinct approaches without evidence-driven progress → stop, mark Blocked, move on.
• Do NOT loop indefinitely on a single task. Record the blocker and proceed.

8. Code Review

• Run /code-review skill on the batch's changed files + corresponding task specs
• The code-review skill produces a verdict: PASS, PASS_WITH_WARNINGS, or FAIL

9. Auto-Fix Gate

Auto-fix loop with bounded retries (max 2 attempts) before escalating to user:

1. If verdict is PASS or PASS_WITH_WARNINGS: show findings as info, continue automatically to step 10
2. If verdict is FAIL (attempt 1 or 2):
   • Parse the code review findings (Critical and High severity items)
   • For each finding, attempt an automated fix using the finding's location, description, and suggestion
   • Re-run /code-review on the modified files
   • If now PASS or PASS_WITH_WARNINGS → continue to step 10
   • If still FAIL → increment retry counter, repeat from (2) up to max 2 attempts
3. If still FAIL after 2 auto-fix attempts: present all findings to user (BLOCKING). User must confirm fixes or accept before proceeding.

Track auto_fix_attempts count in the batch report for retrospective analysis.

10. Test

• Run the full test suite
• If failures: report to user with details

11. Commit and Push

• After user confirms the batch (explicitly for FAIL, implicitly for PASS/PASS_WITH_WARNINGS):
  • git add all changed files from the batch
  • git commit with a message that includes ALL task IDs (Jira IDs, ADO IDs, or numeric prefixes) of tasks implemented in the batch, followed by a summary of what was implemented. Format: [TASK-ID-1] [TASK-ID-2] ... Summary of changes
  • git push to the remote branch

12. Update Tracker Status → In Testing

After the batch is committed and pushed, transition the ticket status of each task in the batch to In Testing via the configured work item tracker. If tracker: local, skip this step.

13. Loop

• Go back to step 2 until all tasks are done
• When all tasks are complete, report final summary

Batch Report Persistence

After each batch completes, save the batch report to _docs/03_implementation/batch_[NN]_report.md. Create the directory if it doesn't exist. When all tasks are complete, produce _docs/03_implementation/FINAL_implementation_report.md with a summary of all batches.

Batch Report

After each batch, produce a structured report:

# Batch Report

**Batch**: [N]
**Tasks**: [list]
**Date**: [YYYY-MM-DD]

## Task Results

| Task | Status | Files Modified | Tests | Issues |
|------|--------|---------------|-------|--------|
| [JIRA-ID]_[name] | Done | [count] files | [pass/fail] | [count or None] |

## Code Review Verdict: [PASS/FAIL/PASS_WITH_WARNINGS]
## Auto-Fix Attempts: [0/1/2]
## Blocked Tasks: [count or None]

## Next Batch: [task list] or "All tasks complete"

Stop Conditions and Escalation

Situation	Action
Same task rewritten 3+ times without green tests	Mark Blocked, continue batch, escalate at batch end
Task blocked on external dependency (not in task list)	Report and skip
File ownership violated (task wrote outside OWNED)	ASK user
Test failures exceed 50% of suite after a batch	Stop and escalate
All tasks complete	Report final summary, suggest final commit
_dependencies_table.md missing	STOP — run /decompose first

Recovery

Each batch commit serves as a rollback checkpoint. If recovery is needed:

• Tests fail after a batch commit: git revert <batch-commit-hash> using the hash from the batch report in _docs/03_implementation/
• Resuming after interruption: Read _docs/03_implementation/batch_*_report.md files to determine which batches completed, then continue from the next batch
• Multiple consecutive batches fail: Stop and escalate to user with links to batch reports and commit hashes

Safety Rules

• Never start a task whose dependencies are not yet completed
• Never run tasks in parallel and never spawn subagents
• If a task is flagged as stuck, stop working on it and report — do not let it loop indefinitely
• Always run tests after each batch completes