skills/implement-plan/SKILL.md
Orchestrate the execution of complete implementation plans, delegating each phase to implement-phase skill. This skill manages the full plan lifecycle including phase sequencing, user confirmation between phases, and overall progress tracking. Triggers on "implement the plan", "execute the implementation plan", or when given a path to a plan file.
npx skillsauth add mhylle/claude-skills-collection implement-planInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Orchestrate the execution of complete implementation plans by delegating each phase to the implement-phase skill. This skill manages the full plan lifecycle.
THIS SESSION IS AN ORCHESTRATOR. YOU MUST NEVER IMPLEMENT CODE DIRECTLY.
implement-plan (this session - ORCHESTRATOR)
│
│ ⛔ NEVER writes code
│ ⛔ NEVER uses Write/Edit tools
│ ⛔ NEVER creates files
│
└── implement-phase (ORCHESTRATOR for phase)
│
│ ⛔ NEVER writes code
│ ⛔ NEVER uses Write/Edit tools
│ ⛔ NEVER creates files
│
└── Subagents (DO the actual work)
│
✅ Write code
✅ Create files
✅ Run tests
✅ Fix issues
| DO | DO NOT | |----|--------| | Read plan and prompts | Write code | | Discover phase prompts | Create files | | Invoke implement-phase skill | Use Write/Edit tools | | Track plan-level progress | Implement directly | | Present results to user | Fix issues directly | | Handle user confirmation | Run implementation commands |
If you find yourself about to use Write, Edit, or NotebookEdit tools in this session:
⛔ STOP - You are violating the orchestrator pattern
✅ INSTEAD - Delegate to implement-phase which will spawn subagents
implement-plan (this skill - plan orchestrator)
│
├── Phase 1 → implement-phase → [implementation, verification, review, ADR, sync]
│ ↓
│ [user confirmation]
│ ↓
├── Phase 2 → implement-phase → [implementation, verification, review, ADR, sync]
│ ↓
│ [user confirmation]
│ ↓
├── Phase N → implement-phase → [...]
│ ↓
└── Final Verification & Summary
implement-phaseEach phase requires user confirmation before proceeding to the next. This is the default, safe mode.
Phase 1 → implement-phase → ✅ Complete → [USER CONFIRMS] → Phase 2 → ...
Note: This mode is planned but not yet implemented. When enabled, the entire plan will execute without pauses between phases.
Phase 1 → Phase 2 → Phase 3 → ... → Final Report
Autonomous mode will require:
When given a plan path or asked to implement a plan:
1. Find the plan file (docs/plans/, thoughts/plans/, or specified path)
2. Read the ENTIRE plan - full context is essential
3. Identify total number of phases
4. Extract task_list_id from plan metadata (for multi-session support)
5. Check for existing Tasks (TaskList shows progress from previous sessions)
Multi-Session Support:
If the plan has a task_list_id in its metadata, ensure you're using the same task list:
CLAUDE_CODE_TASK_LIST_ID=plan-2026-01-24-feature-name claude
This enables multiple sessions to share progress on the same plan.
Check for pre-generated prompts from the prompt-generator skill:
# Check common prompt locations
1. Glob("docs/prompts/phase-*.md") # Standard location
2. Glob("prompts/phase-*.md") # Alternative location
# Match prompts to phases by number
phase-1-*.md → Phase 1
phase-2-*.md → Phase 2
...
Prompt Discovery Output:
● Prompt Discovery:
Found: docs/prompts/phase-1-foundation.md → Phase 1
Found: docs/prompts/phase-2-data-pipeline.md → Phase 2
Found: docs/prompts/phase-3-agent-system.md → Phase 3
Missing: Phase 4 (no prompt found)
Note: Phases with prompts will use pre-generated instructions.
Phases without prompts will use plan file directly.
# Tiered ADR reading (context conservation)
1. Read("docs/decisions/INDEX.md") # Scan all ADRs first
2. Read("docs/decisions/ADR-NNNN.md", limit=10) # Quick Reference of relevant ones
3. Read full ADR only if needed for implementation details
# Read files referenced in plan
4. Load all files mentioned in the plan
# Check for existing tasks for this plan
TaskList: Check for tasks matching "Phase N:" pattern
If tasks exist:
- Resume from first non-completed task
- Skip already-completed phases
- Display current progress
If no tasks exist:
- Tasks should have been created by create-plan
- If missing, create them now (see create-plan Phase 7)
Task Status Display:
Tasks (2 done, 3 open):
✓ #1 Phase 1: Setup
✓ #2 Phase 2: Core Logic
◻ #3 Phase 3: Integration › blocked by #2
◻ #4 Phase 4: Testing › blocked by #3
◻ #5 Phase 5: Documentation › blocked by #4
For each phase:
TaskUpdate(task_id, status: "in_progress")implement-phaseTaskUpdate(task_id, status: "completed")Skill(skill="implement-phase"): Execute Phase [N] of the implementation plan.
Context:
- Plan: [plan file path]
- Phase: [N] ([Phase Name])
- Task ID: [task_id from TaskList]
- Prompt: [prompt file path, if discovered]
- Previous Phase Status: [Complete/N/A]
Execute all quality gates and return structured result.
With Prompt (preferred):
Skill(skill="implement-phase"): Execute Phase 2.
Context:
- Plan: docs/plans/trading-platform.md
- Phase: 2 (Data Pipeline)
- Task ID: 2
- Prompt: docs/prompts/phase-2-data-pipeline.md
- Previous Phase Status: Complete
The prompt contains detailed orchestration instructions.
Execute all quality gates and archive prompt on completion.
Without Prompt (fallback):
Skill(skill="implement-phase"): Execute Phase 4.
Context:
- Plan: docs/plans/trading-platform.md
- Phase: 4 (Integration)
- Task ID: 4
- Prompt: None (use plan directly)
- Previous Phase Status: Complete
No pre-generated prompt. Use plan file for phase details.
═══════════════════════════════════════════════════════════════
● STARTING PHASE 2: Authentication Service
═══════════════════════════════════════════════════════════════
Objectives:
- Implement login/logout logic
- JWT token generation and validation
Dependencies:
- Phase 1 (Database Schema) must be complete ✅
Delegating to implement-phase...
The implement-phase skill handles all details:
code-review skillReceive structured result from implement-phase:
PHASE_RESULT:
status: COMPLETE | FAILED | BLOCKED
steps:
implementation: PASS
exit_conditions: PASS
code_review: PASS_WITH_NOTES
adr_compliance: PASS
plan_sync: PASS
manual_verification:
- "Check login flow in browser"
ready_for_next: true
After each phase completes, pause for user confirmation:
═══════════════════════════════════════════════════════════════
● PHASE 2 COMPLETE: Authentication Service
═══════════════════════════════════════════════════════════════
Results:
✅ Implementation: 3 files created, 2 modified
✅ Exit Conditions: All passed
✅ Code Review: Passed with 2 recommendations
✅ ADR Compliance: Passed
✅ Plan Updated: 8 tasks marked complete
Manual Verification Required:
- [ ] POST /auth/login returns token with expected claims
- [ ] POST /auth/logout invalidates session
Recommendations (non-blocking):
1. Consider using project's CustomLogger
2. Add ADR-0012 reference to plan
───────────────────────────────────────────────────────────────
Please confirm manual verification steps, then respond to
proceed to Phase 3: API Endpoints
═══════════════════════════════════════════════════════════════
When implement-phase returns a blocker:
PHASE_RESULT:
status: BLOCKED
blocker: "Existing JWT implementation found in src/legacy/auth.js"
options:
- "Proceed with new implementation"
- "Refactor legacy code"
- "Abort and revise plan"
⛔ PHASE 2 BLOCKED
Issue: Existing JWT implementation found in src/legacy/auth.js.
The plan specifies creating new jwt.strategy.ts but doesn't
mention legacy code.
Options:
A) Proceed with new implementation, mark legacy for removal
B) Refactor legacy code instead of creating new file
C) Abort and revise the plan
Recommendation: Option A - cleaner separation
How should I proceed?
Tasks persist across sessions, enabling seamless resume:
● Plan Status: Resuming interrupted work
Task Status (from TaskList):
✓ #1 Phase 1: Database Schema - completed
✓ #2 Phase 2: Authentication Service - completed
◻ #3 Phase 3: API Endpoints - in_progress ← Resume here
◻ #4 Phase 4: Testing - pending (blocked by #3)
Resume Point: Phase 3 (API Endpoints)
Continuing from Phase 3...
Multi-Session Resume:
# Start new session with same task list
CLAUDE_CODE_TASK_LIST_ID=plan-2026-01-24-user-auth claude
# Tasks automatically show current progress
# Resume from where any session left off
Benefits of Task-based resume:
After all phases complete:
═══════════════════════════════════════════════════════════════
● PLAN COMPLETE: User Authentication Implementation
═══════════════════════════════════════════════════════════════
Summary:
Phases Completed: 3/3
Files Created: 12
Files Modified: 5
Tests Added: 47
ADRs Created: 1 (ADR-0015)
Quality Gates (all phases):
✅ All exit conditions passed
✅ All code reviews passed
✅ All ADR compliance checks passed
✅ Plan fully synchronized
Final Verification:
- [ ] E2E tests pass: `npm run test:e2e`
- [ ] API documentation updated
- [ ] Security review checklist complete
═══════════════════════════════════════════════════════════════
Implementation complete. Ready for final review.
═══════════════════════════════════════════════════════════════
Progress is tracked via Task tools with cross-session persistence. See ADR-0001.
| Tracking Method | Scope | Purpose | |-----------------|-------|---------| | TaskList/TaskUpdate | Persistent | Track phase-level progress across sessions | | Plan File | Persistent | Specification document (updated with ✅ on completion) | | Status Updates | User | Communicate current state |
Task Lifecycle:
create-plan → TaskCreate (all phases with dependencies)
↓
implement-plan → TaskUpdate(in_progress) → implement-phase → TaskUpdate(completed)
↓
Resume (any session) → TaskList (find first pending task)
Multi-Session Workflow:
# Session 1: Start implementation
CLAUDE_CODE_TASK_LIST_ID=plan-my-feature claude
> /implement-plan docs/plans/my-feature.md
# ... complete Phase 1, 2 ...
# Session 2: Resume from another terminal
CLAUDE_CODE_TASK_LIST_ID=plan-my-feature claude
> /implement-plan docs/plans/my-feature.md
# Automatically resumes from Phase 3
Phase-level tracking is handled by implement-phase using Task tools.
See references/plan-format.md for:
implement-phase for all phase workimplement-plan
└── implement-phase (required)
├── code-review (required)
└── adr (required for compliance)
tools
--- name: tt-workflow-build description: Tasktracker-native trigger for a PARALLEL build via the Claude Code Workflow tool. Thin by design — it does two things, then drives to done: (1) ensure a tasktracker project exists (use the existing one, or create one), then (2) start a dynamic `Workflow` that builds it, tracking the work in tasktracker and using the build + verify skills. It does NOT analyze parallelism up front, ask the user to choose a mode, hand back, or fall back to a sequential skil
tools
--- name: grumpy-reviewer description: A single grumpy, nitpicky structural code reviewer that runs as an isolated subagent and treats the code as third-party work submitted by a junior programmer for validation. It cares about exactly one thing — maintainability — judged through separation of concerns, service-oriented design, helper-method extraction, small files, and the rule of 7 (as any grouping nears 7 members, it pushes for sub-groupings). It is deliberately kept OUT of the implementation
development
--- name: tt-workflow-run description: Tasktracker-native autonomous build-loop orchestrator. Drives a first-class `workflow_run` end-to-end — create the run (Gate 1 lifecycle completeness + Gate 2 zero-defects-in), then loop while `getNextReadyTask(projectId)` returns a slice — `setActiveTask` → record a pre-slice `scanArchitectureDrift` baseline → delegate the slice to `/tt-implement-phase` (which does the code work, registers the architecture delta in-slice, and auto-logs defects/learnings/fr
tools
Tasktracker-native project-wide parallel audit using the Claude Code Workflow tool (dynamic workflows). Partitions a repo / backlog / architecture and fans out read-only agents (one per partition) that return schema-checked findings, aggregates them into a deduplicated, ranked risk register, and OPTIONALLY writes fixes back as tasks under a Bug Fix phase — with all tasktracker writes done by the PARENT, never the parallel agents (single global active-task pointer). Journaled and resumable, so a rate-limit or crash mid-audit resumes without re-running completed partitions. Use for large, embarrassingly-parallel, read/analyze-heavy jobs where each unit is self-contained and the output aggregates — audit every file/component for risk, find all architecture drift (scanArchitectureDrift) or duplicate tasks (detectDuplicates/auditDuplicates), per-file tech-debt sweep, test-coverage or security-surface scan across a whole project. Triggers on "/tt-workflow-audit", "audit the whole repo", "parallel audit", "scan every file/component", "find all drift/duplicates", "tech-debt sweep (tasktracker)", or any whole-project analyze-at-scale request inside a session with a tasktracker project. Prefer this over /codebase-audit or /code-quality-audit when the project is tracked in tasktracker AND you want the findings written back as tasks; prefer it over team-* modes when the units don't need to negotiate live (they just report).