// Translates finalized feature plans into comprehensive tickets for autonomous development. Use after project-planning and reviewing-plans sessions are complete. Creates self-contained tickets with inlined requirements and verification commands.
Reviews completed work by exploring features as a user would, finding gaps between intent and implementation, writing failing tests for real issues, and creating tickets for genuine problems. Runs automatically after all planned tasks complete.
Autonomously discovers ready tasks from Tickets, executes them with Research → Implement → Verify cycles, continuing with related work while context remains healthy - invoke directly without specifying a task
Creates new Claude Code agent skills with proper structure, frontmatter, and best practices. Use when the user wants to create a new skill, add capabilities, or extend Claude with domain-specific expertise.
Autonomously investigates REQUIRES-INVESTIGATION tasks through deep parallel research (internal and external), synthesizes findings, and either resolves with an actionable task or escalates to HUMAN-TASK when genuine human judgment is needed. Use when autonomous-development creates investigation tasks.
Orchestrates comprehensive feature planning through autonomous research phases and map-reduce cycles. Researches codebase first to understand current state, only interviews user for human judgment questions, then runs research waves after each interview round. Produces detailed implementation plans with executable verification commands.
Captures project vision and philosophy through structured interview, producing comprehensive vision documentation and condensed summary. Use before project-planning for new projects or major architectural work requiring design alignment. Ensures blockers and autonomous development can align with project goals.
| name | plan-to-tickets |
| description | Translates finalized feature plans into comprehensive tickets for autonomous development. Use after project-planning and reviewing-plans sessions are complete. Creates self-contained tickets with inlined requirements and verification commands. |
Translate a finalized feature plan into comprehensive tickets suitable for autonomous development. This skill is the bridge between planning (iterative, document-focused) and implementation (task-focused, ticket-driven).
project-planning skill has generated a planreviewing-plans skill sessions have refined the plan to satisfactiondocs/feature-plans/[feature-name]/reviewing-plans instead)project-planning first)Tickets must be executable without referring back to plan documents.
This means:
Why? The autonomous-development skill picks up tickets and executes them. Agents shouldn't need to read plan documents - everything they need should be in the ticket itself.
0. PLAN SELECTION (user confirms which plan)
1. PLAN PARSING (sub-agent)
- Read all plan files
- Extract tasks with metadata
- Build dependency graph
- Write parsed structure to temp file
2. TICKET GENERATION (parallel sub-agents)
- Batch tasks across 1-8 agents based on count
- Each agent creates tickets for its batch
- Aggregate mappings after all complete
3. EPIC CREATION (if 5+ tickets)
- Create epic ticket to track 100% completion
- Include plan validation instructions in description
4. DEPENDENCY LINKING (sub-agent)
- Link tickets according to plan dependencies
- Link ALL tickets as blocking the epic (if created)
- Verify no cycles
5. VALIDATION (sub-agent)
- Count match: plan tasks vs tickets created
- Spot-check ticket content
- Verify dependency structure
- Verify epic has all tickets as deps (if applicable)
6. REPORT
- Summary of tickets created
- Epic ticket ID (if created)
- Dependency overview
- Ready for autonomous-development
You are a COORDINATOR. You dispatch sub-agents and route information.
Your responsibilities:
You NEVER:
Always confirm which plan to translate.
I'll translate the [specified] plan at docs/feature-plans/[name]/ into tickets.
Is that correct? This will create tickets for autonomous implementation.
List available plans:
ls -la docs/feature-plans/
Then ask:
I found these feature plans:
1. multithreaded-runtime/ (modified 2 hours ago)
2. auth-system/ (modified 3 days ago)
Which plan would you like me to translate into tickets?
Note: Only translate plans that have been reviewed and finalized.
Wait for user confirmation before proceeding.
Goal: Extract all tasks from plan documents into structured format.
Setup:
mkdir -p /tmp/plan-to-tickets-[timestamp]/
Deploy Plan Parser sub-agent:
Parse feature plan for ticket generation.
Input: docs/feature-plans/[feature-name]/
Output: /tmp/plan-to-tickets-[ts]/PARSED_PLAN.md
Instructions:
1. Read the project CLAUDE.md first (understand project conventions)
2. Read all .md files in the plan directory
3. For each task found, extract:
- Task ID (from plan, e.g., "Phase 2, Task 3")
- Title
- Full description (everything needed to implement)
- File paths to create/modify
- Dependencies (which other tasks must complete first)
- Verification commands (copy exactly from plan)
- Acceptance criteria
- Any flexibility allowances noted
4. Build dependency graph (which tasks block which)
5. Produce parsed plan with:
- List of all tasks with extracted fields
- Dependency adjacency list
- Total task count
- Any parsing issues encountered
Return: Summary + file path + task count
Goal: Create one ticket per task with fully inlined content.
Parallelization strategy: Ticket creation is embarrassingly parallel. Each task becomes an independent ticket with no cross-dependencies during creation. Batch tasks across multiple sub-agents for speed.
Batch sizing:
Deploy Ticket Generator sub-agents (in parallel):
For each batch, spawn a sub-agent with:
Generate tickets from parsed plan (batch [N] of [M]).
Context:
- Parsed plan: /tmp/plan-to-tickets-[ts]/PARSED_PLAN.md
- Feature name: [feature-name]
- Task range: Tasks [start] through [end] (inclusive)
Output: /tmp/plan-to-tickets-[ts]/TICKETS_BATCH_[N].md
Instructions:
1. Read the using-tickets skill (invoke it) to understand tk CLI
2. Read the parsed plan file
3. For EACH task in your assigned range, create a ticket:
tk create "[Feature]: [Task Title]" \
--type task \
--priority [map phase to priority: phase 1 = P1, phase 2 = P2, etc.] \
--description "$(cat <<'EOF'
## Summary
[Full task description from plan - INLINE, don't reference docs]
## Files
[List of files to create/modify with full paths]
## Implementation Notes
[Any specific guidance, patterns to follow, constraints]
## Flexibility
[If plan noted "A or B acceptable", include that here with heuristics]
## Verification
[Copy verification commands EXACTLY from plan]
## Acceptance Criteria
[Copy acceptance criteria EXACTLY from plan]
EOF
)"
4. Track each created ticket ID alongside its plan task ID
5. Write mapping to YOUR batch output file:
- Plan Task ID → Ticket ID
- Full ticket creation log
- Any errors encountered
CRITICAL: Ticket descriptions must be SELF-CONTAINED. An agent reading only
the ticket should have everything needed to implement and verify the task.
Return: Summary + file path + tickets created count
Aggregate batch outputs:
After ALL parallel agents complete, aggregate the mappings:
cat /tmp/plan-to-tickets-[ts]/TICKETS_BATCH_*.md > /tmp/plan-to-tickets-[ts]/TICKETS_CREATED.md
Verify total count matches expected task count from Stage 1. If any batch failed, report errors before proceeding.
Every ticket description MUST include:
Goal: Create an epic ticket to track 100% completion when there are 5+ tickets.
Threshold: 5 or more tickets → create epic. Fewer than 5 → skip this stage.
Why an epic? Large plans need a final validation step. The epic ensures:
Create the epic:
tk create "EPIC: [Feature Name] - Complete Implementation" \
--type epic \
--priority 2 \
--description "$(cat <<'EOF'
## Purpose
This epic tracks 100% completion of the [feature-name] implementation.
**Do not close this ticket until ALL dependent tickets are complete AND validation passes.**
## Plan Reference
Plan location: docs/feature-plans/[feature-name]/
## Validation Instructions (REQUIRED before closing)
When all dependent tickets are complete, perform this validation:
### 1. Plan Coverage Check
Read the original plan and verify each planned task was implemented:
```bash
# List all tasks from plan
cat docs/feature-plans/[feature-name]/*.md | grep -E "^###? (Task|Step)"
# Compare against completed tickets
tk ls --status=closed | grep "[Feature]"
For each planned task, verify:
Run ALL verification commands from the plan:
# Run test suite
[test commands from plan]
# Run any integration checks
[integration commands from plan]
All verification commands must pass.
If gaps are found:
tk dep [epic-id] [new-ticket-id]If implementation deviated from plan, document in this ticket:
**Record epic ID:** Write to `/tmp/plan-to-tickets-[ts]/EPIC.md`:
Epic ID: [ticket-id] Feature: [feature-name] Plan location: docs/feature-plans/[feature-name]/ Dependent tickets: [count]
## Stage 4: Dependency Linking
**Goal:** Connect tickets according to plan's dependency structure, and link all tickets to the epic (if created).
**Deploy Dependency Linker sub-agent:**
Link ticket dependencies.
Context:
Output: /tmp/plan-to-tickets-[ts]/DEPS_LINKED.md
Instructions:
Read parsed plan for dependency graph
Read ticket mapping for task→ticket ID translation
Check if EPIC.md exists (epic was created)
For each dependency in plan:
If epic exists, link ALL tickets as blocking the epic:
After all links created, verify no cycles:
Produce linking report with:
Return: Summary + file path + deps linked count + epic deps count + cycle status
## Stage 5: Validation
**Goal:** Verify tickets accurately represent the plan.
**Deploy Validator sub-agent:**
Validate tickets match plan.
Context:
Output: /tmp/plan-to-tickets-[ts]/VALIDATION.md
Instructions:
Count validation:
Content spot-check (5-10 tickets):
Dependency validation:
Epic validation (if EPIC.md exists):
Ready-work check:
Produce validation report with:
Return: Summary + file path + status + epic validation status
**Gate Logic:**
- NEEDS_FIXES → Report issues, ask user how to proceed
- VALID → Continue to Stage 6
## Stage 6: Report & Cleanup
**Summarize to user:**
[List ticket IDs with titles, grouped by phase/priority]
Epic ID: [epic-id] Purpose: Tracks 100% completion and validates implementation against plan
The epic:
[High-level overview: Phase 1 → Phase 2 → Phase 3 → ... → Epic]
Run tk ready to see tasks available for immediate work.
When all tickets are done, close the epic by following its validation instructions:
Start autonomous development:
claude -p "Use autonomous-development skill"
Or run the autonomous loop:
while true; do
claude -p "Use autonomous-development skill" || break
sleep 2
done
### Commit Tickets
**Commit the ticket database changes:**
```bash
git add .tickets/
git commit -m "chore: generate tickets for [feature-name]
- [X] tickets created from finalized plan
- [Y] dependencies linked
- Epic: [epic-id] (if created, else omit this line)
- Ready for autonomous-development"
Cleanup:
rm -rf /tmp/plan-to-tickets-[ts]/
Default mapping from plan phases to ticket priorities:
| Plan Phase | Ticket Priority | Rationale |
|---|---|---|
| Phase 1 (Foundation) | P1 | Must complete first |
| Phase 2 | P2 | After foundation |
| Phase 3 | P2 | Same priority, deps control order |
| Phase 4+ | P2-P3 | Later phases |
| HUMAN-TASK | P0 | Blocks other work |
Override based on plan's explicit priority markings if present.
If plan contains tasks marked "HUMAN-TASK:":
tk create "HUMAN-TASK: [description]" \
--type task \
--priority 0 \
--description "[Full context for human decision]"
These will block dependent work until resolved.
If a plan task spans multiple concerns or seems insufficiently decomposed:
reviewing-plans pass to break it downautonomous-development create sub-tickets during implementationIf a task lacks verification commands:
This skill creates tickets FROM plans. It does not update plans or sync back. Plans are the source of truth during planning; tickets are the frozen snapshot for execution.
Every ticket must be implementable without reading plan documents. Inline everything.
The dependency graph in tickets must match the plan. tk ready should return exactly the tasks that have no blockers.
Running this skill twice on the same plan will create DUPLICATE tickets. Check tk ls before running if unsure.
Always validate tickets match plans before starting autonomous development. Catch errors early.
Plans with 5+ tickets get an epic ticket that:
When closing the epic:
project-planning
↓
Creates plan docs
↓
reviewing-plans (1-N sessions)
↓
Refines plan docs
↓
plan-to-tickets (THIS SKILL)
↓
Creates tickets + epic (if 5+ tickets)
↓
autonomous-development (loop)
↓
Executes tickets until all done
↓
epic validation (if epic exists)
↓
Validate against plan, create gap tickets if needed
↓
Close epic when 100% validated
tk init firsttk dep [epic-id] [new-ticket-id] for each gap