.claude/skills/roadmap/SKILL.md
Create sequential phases from spec. Creates ./.gtd/<task_name>/ROADMAP.md
npx skillsauth add Hoang604/get-thing-done roadmapInstall 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.
Core responsibilities:
Flow: Read Spec → Group → Order → Write </objective>
<context> **Required files:**./.gtd/<task_name>/SPEC.md — Must exist and be FINALIZEDOutput:
./.gtd/<task_name>/ROADMAP.md
</context>Each phase should produce something usable or testable. Not "Phase 1: Research" — that's an activity, not a deliverable.
Good: "Phase 1: Basic API endpoint that returns hardcoded data" Bad: "Phase 1: Set up project structure"
Phase 2 should depend on Phase 1. If phases can be done in any order, they might be the same phase.
3-5 phases is ideal. Each phase: 1-3 plans. Each plan: 2-3 tasks.
</philosophy> <process>Bash:
if ! grep -q "FINALIZED" "./.gtd/<task_name>/SPEC.md" 2>/dev/null; then
echo "Error: SPEC.md must exist and be FINALIZED"
exit 1
fi
Read ./.gtd/<task_name>/SPEC.md and list all must have and nice to have.
Create a mental checklist:
For each criterion, ask:
Group related criteria into phases.
Arrange phases so each builds on the previous:
Write to ./.gtd/<task_name>/ROADMAP.md:
# Roadmap
**Spec:** ./.gtd/<task_name>/SPEC.md
**Goal:** {goal}
**Created:** {date}
## Must-Haves
- [ ] {must-have 1}
- [ ] {must-have 2}
## Nice-To-Haves
- [ ] {nice-to-have 1}
- [ ] {nice-to-have 2}
## Phases
<must-have>
### Phase 1: {name}
**Status**: ⬜ Not Started
**Objective**: {description}
### Phase 2: {name}
**Status**: ⬜ Not Started
**Objective**: {description}
...
</must-have>
<nice-to-have>
### Phase n (optional): {name}
**Status**: ⬜ Not Started
**Objective**: {description}
</nice-to-have>
</process>
<offer_next>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
GTD ► ROADMAP COMPLETE ✓
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Roadmap written to ./.gtd/<task_name>/ROADMAP.md
{N} phases defined
| Phase | Name | Criteria |
|-------|------|----------|
| 1 | {name} | {count} |
| 2 | {name} | {count} |
Coverage: 100% of spec criteria assigned
─────────────────────────────────────────────────────
▶ Next Up
/plan 1 — create execution plan for Phase 1
─────────────────────────────────────────────────────
</offer_next>
<forced_stop> STOP. The workflow is complete. Do NOT automatically run the next command. Wait for the user. </forced_stop>
testing
manual trigger by user, do not auto invoke
tools
manual trigger by user, do not auto invoke
development
Trace execution paths and document how code actually behaves. Use when you need to understand how features work, walk through code flows, explain component behavior, trace where data comes from, understand relationships between components, or audit for orphaned events and dead code.
testing
Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.