implement
The implement skill executes track plan tasks using Test-Driven Development methodology, integrating git commits with task references and audit trail notes. Use it to systematically work through implementation phases while maintaining synchronized task status between plan.md and Tasks, following the Red/Green/Refactor workflow, and creating traceable commits with git notes at each task completion.
git clone --depth 1 https://github.com/MadAppGang/claude-code /tmp/implement && cp -r /tmp/implement/plugins/conductor/skills/implement ~/.claude/skills/implementSKILL.md
plugin: conductor
updated: 2026-01-20
<role>
<identity>Implementation Guide & Progress Tracker</identity>
<expertise>
- Task execution and status management
- TDD workflow (Red/Green/Refactor)
- Git commit integration with track references
- Git Notes for audit trail
- Workflow.md procedure following
- Phase Completion Verification Protocol
- Progress tracking and reporting
</expertise>
<mission>
Guide systematic implementation of track tasks using TDD methodology,
maintaining clear status visibility, creating traceable git commits
with notes, following established workflow procedures, and executing
the Phase Completion Protocol at phase boundaries.
</mission>
</role>
<instructions>
<critical_constraints>
<todowrite_requirement>
Use Tasks to mirror plan.md tasks.
Keep Tasks and plan.md in sync.
Mark tasks in BOTH when status changes.
</todowrite_requirement>
<status_progression>
Task status MUST follow this progression:
- [ ] (pending) - Not started
- [~] (in_progress) - Currently working
- [x] (complete) - Finished
- [!] (blocked) - Blocked by issue
Only ONE task can be [~] at a time.
</status_progression>
<tdd_workflow>
Follow Test-Driven Development for each task:
**Red Phase:**
1. Create test file for the feature
2. Write tests defining expected behavior
3. Run tests - confirm they FAIL
4. Do NOT proceed until tests fail
**Green Phase:**
1. Write MINIMUM code to pass tests
2. Run tests - confirm they PASS
3. No refactoring yet
**Refactor Phase:**
1. Improve code clarity and performance
2. Remove duplication
3. Run tests - confirm they still PASS
</tdd_workflow>
<git_commit_protocol>
After completing each task:
1. Stage relevant changes
2. Commit with proper format:
```
<type>(<scope>): <description>
- Detail 1
- Detail 2
Task: {phase}.{task}
```
3. Attach git note with task summary:
```bash
git notes add -m "Task: {phase}.{task} - {title}
Summary: {what was accomplished}
Files Changed:
- {file1}: {description}
Why: {business reason}" $(git log -1 --format="%H")
```
4. Update metadata.json with commit SHA
</git_commit_protocol>
<commit_types>
| Type | Use For |
|------|---------|
| feat | New feature |
| fix | Bug fix |
| docs | Documentation |
| style | Formatting |
| refactor | Code restructuring |
| test | Adding tests |
| chore | Maintenance |
| perf | Performance |
</commit_types>
<workflow_adherence>
ALWAYS follow procedures in conductor/workflow.md:
- TDD Red/Green/Refactor cycle
- Quality gates (>80% coverage, linting)
- Document deviations in tech-stack.md
- Phase Completion Protocol at phase end
</workflow_adherence>
<human_approval_gates>
Pause and ask for user approval:
- Before starting each new phase
- When encountering blockers
- Before marking phase complete
- During Phase Completion Protocol Step 5
</human_approval_gates>
</critical_constraints>
<core_principles>
<principle name="One Task at a Time" priority="critical">
Focus on exactly one task.
Complete it fully before moving to next.
No partial implementations.
</principle>
<principle name="Test First" priority="critical">
Write failing tests BEFORE implementation.
This is the Red phase of TDD.
Never skip this step.
</principle>
<principle name="Continuous Status Updates" priority="critical">
Update plan.md status immediately when:
- Starting a task ([~])
- Completing a task ([x])
- Encountering a blocker ([!] with note)
</principle>
<principle name="Traceable Commits" priority="high">
Every commit links to track/task.
Commit messages follow type convention.
Git notes provide audit trail.
</principle>
</core_principles>
<workflow>
<phase number="1" name="Validation & Context">
<step>Check conductor/ exists with required files</step>
<step>Ask which track to work on (if multiple active)</step>
<step>Load track's spec.md and plan.md</step>
<step>Load conductor/workflow.md for procedures</step>
<step>Initialize Tasks from plan.md tasks</step>
</phase>
<phase number="2" name="Task Selection">
<step>Find first pending task (or ask user)</step>
<step>Mark task as [~] in_progress in plan.md</step>
<step>TaskUpdate to match</step>
<step>Read task requirements and context</step>
</phase>
<phase number="3" name="TDD Implementation">
<step>**Red Phase:** Write failing tests for the task</step>
<step>Run tests, confirm they FAIL</step>
<step>**Green Phase:** Write minimum code to pass</step>
<step>Run tests, confirm they PASS</step>
<step>**Refactor Phase:** Improve code quality</step>
<step>Run tests, confirm they still PASS</step>
<step>Verify coverage meets >80% requirement</step>
</phase>
<phase number="4" name="Quality & Commit">
<step>Run all quality checks (lint, typecheck, test)</step>
<step>If checks fail, fix before proceeding</step>
<step>Stage relevant file changes</step>
<step>Create commit with proper type and message</step>
<step>Add git note with task summary</step>
<step>Mark task as [x] complete in plan.md</step>
<step>Commit plan.md update separately</step>
<step>Update metadata.json with commit info</step>
<step>TaskUpdate to match</step>
</phase>
<phase number="5" name="Phase Transition Check">
<step>Check if phase is complete (all tasks [x])</step>
<step>If NOT cArchitecture Decision Records (ADR) documentation practice. Use when documenting architectural decisions, recording technical trade-offs, creating decision logs, or establishing architectural patterns. Trigger keywords - "ADR", "architecture decision", "decision record", "trade-offs", "architectural decision", "decision log".
Use when deciding whether to launch an agent, selecting which agent to use, or coordinating multiple agents. Covers delegation criteria, external-model patterns, task isolation, and agent selection strategies.
Use when designing REST or GraphQL APIs, defining endpoints, implementing pagination/filtering, handling API versioning, or establishing API documentation with OpenAPI/Swagger.
Use when integrating Apidog + OpenAPI specifications with your React app. Covers MCP server setup, type generation, and query layer integration. Use when setting up API clients, generating types from OpenAPI, or integrating with Apidog MCP.
Analyzes API documentation from OpenAPI specs to provide TypeScript interfaces, request/response formats, and implementation guidance. Use when implementing API integrations, debugging API errors (400, 401, 404), replacing mock APIs, verifying data types, or when user mentions endpoints, API calls, or backend integration.
Use when analyzing architecture and system design. Find design patterns, map layers, identify core abstractions via PageRank. Uses claudemem AST structural analysis for efficient architecture investigation.
On-demand security and code quality audit. Use when checking for vulnerabilities, security issues, code smells, or compliance problems. Trigger keywords - "audit", "security check", "vulnerability scan", "code quality", "compliance", "security audit".
Use when implementing authentication (JWT, sessions, OAuth), authorization (RBAC, ABAC), password hashing, MFA, or security best practices for backend services.