| name | plan-expert |
| description | Planning and architecture decision domain expert. Knows about: - Creating ADRs (Architecture Decision Records) - Creating technical specifications - Listing and discovering planning artifacts - Transforming plans into executable VTM tasks - Integrating with research tools (thinking-partner) Use when: - User wants to document an architectural decision - User needs to create a technical specification - User wants to explore or list existing ADRs/specs - User is ready to convert planning docs into tasks - User needs research before making a decision |
| trigger_phrases | create an adr, document a decision, document this decision, write an adr, create a spec, write a specification, technical spec, show my adrs, list adrs, show my specs, list specs, what adrs do i have, what specs exist, turn this into tasks, convert to vtm, add to vtm, make this executable, let's plan, help me plan, plan a feature, research options |
Plan Expert Skill
What This Skill Does
Guides you through the complete planning workflow from ideation to executable VTM tasks. Handles ADR and spec creation conversationally, helps you discover existing planning artifacts, and bridges your plans into VTM for execution.
Auto-discovers when you mention planning, documentation, or decision-making activities.
Available Commands
/plan:to-vtm <adr-file> <spec-file>- Transform ADR+Spec pair into VTM tasks/helpers:thinking-partner- Research and ideation support (coming soon)
Planning Workflow
The complete planning-to-execution workflow:
1. Ideation & Research
↓ (use /helpers:thinking-partner)
2. Document Decision (ADR)
↓ (plan-expert creates ADR file)
3. Write Technical Spec
↓ (plan-expert creates spec file)
4. Transform to VTM Tasks
↓ (plan-expert calls /plan:to-vtm)
5. Execute Tasks
↓ (use vtm-expert for execution)
When Claude Uses This
Creating ADRs
When you say:
- "I want to document our decision about PostgreSQL"
- "Create an ADR for the API authentication approach"
- "We decided to use REST instead of GraphQL, let's document that"
Claude will:
- Ask clarifying questions about the decision
- Create ADR file in
docs/adr/ADR-XXX-{topic}.md - Populate template from
.claude/templates/adr-template.md - Guide you through sections (Context, Decision, Consequences)
Creating Specifications
When you say:
- "Write a spec for the user authentication feature"
- "I need a technical specification for the API layer"
- "Create a spec for implementing the database migration system"
Claude will:
- Link to the relevant ADR (if exists)
- Create spec file in
docs/specs/spec-{topic}.md - Populate template from
.claude/templates/spec-template.md - Guide you through sections (Overview, Architecture, Implementation, Tasks)
- Include acceptance criteria and test requirements
Listing Planning Artifacts
When you say:
- "Show me my ADRs"
- "What specifications do I have?"
- "List all architectural decisions"
Claude will:
- Use filesystem MCP to scan directories
- Display formatted list with:
- File names
- Decision/spec titles
- Status (proposed, accepted, deprecated)
- Creation dates
Converting to VTM Tasks
When you say:
- "Turn this ADR and spec into VTM tasks"
- "Add these tasks to my VTM"
- "Make this executable"
Claude will:
- Verify ADR+Spec pair exists
- Call
/plan:to-vtm <adr-file> <spec-file> - Show preview of extracted tasks with dependencies
- Ask for confirmation before ingesting
ADR Template Structure
When creating an ADR, the plan-expert follows this template:
# ADR-XXX: {Decision Title}
## Status
Proposed | Accepted | Deprecated | Superseded
## Context
What is the issue we're trying to solve? What constraints exist?
## Decision
What did we decide to do and why?
## Consequences
### Positive
- What benefits come from this decision?
### Negative
- What drawbacks or costs?
- What mitigations exist?
## Alternatives Considered
What other options did we evaluate and why did we reject them?
Spec Template Structure
When creating a spec, the plan-expert follows this template:
# Technical Specification: {Feature Name}
## Related ADR
- ADR-XXX: {Link to decision}
## Overview
Brief description of what we're building and why.
## Architecture
High-level design with components and data flow.
## Implementation Details
Detailed breakdown of what needs to be built.
## Tasks
1. Task 1 description
- Dependencies: None
- Test strategy: TDD/Unit/Integration/Direct
- Estimated hours: X
2. Task 2 description
- Dependencies: Task 1
- Test strategy: TDD
- Estimated hours: Y
## Acceptance Criteria
- AC1: Specific, testable criterion
- AC2: Another testable criterion
## Test Strategy
How to verify this works (unit, integration, e2e).
## Performance Requirements
Any performance constraints or targets.
Integration with /plan:to-vtm
The /plan:to-vtm command performs intelligent task extraction:
Input:
- ADR file (decision context)
- Spec file (implementation details)
Process:
- Reads both files with line numbers
- Generates VTM summary (incomplete tasks only)
- Launches AI agent to extract tasks
- Agent analyzes dependencies semantically
- Validates schema, dependencies, circular deps
- Shows preview with dependency chains
Output:
- Validated tasks added to vtm.json
- Dependencies correctly linked
- Rich context preserved (links to source docs)
- Ready to execute with
/vtm:next
Token Efficiency
The plan-to-vtm bridge achieves 80% token reduction:
- VTM summary filters to incomplete tasks only
- Completed tasks reduced to capability summaries
- Agent receives only relevant context
- Prevents token budget exhaustion
Best Practices
ADR First, Spec Second
- Always document the decision before implementation details
- Specs should reference their ADR
One ADR per Decision
- Keep ADRs focused on single decisions
- Link related ADRs if needed
Detailed Acceptance Criteria
- Specs should have testable ACs
- Each AC becomes validation for tasks
Explicit Dependencies
- Spec tasks should list dependencies clearly
- Agent uses this for VTM dependency analysis
Test Strategy per Task
- Specify TDD/Unit/Integration/Direct
- Aligns with VTM test_strategy field
MCP Integration
The plan-expert skill uses these MCP servers:
Filesystem MCP:
- Read/write ADR files (
docs/adr/*.md) - Read/write spec files (
docs/specs/*.md) - List and discover planning artifacts
- Template population from
.claude/templates/adr-template.mdand.claude/templates/spec-template.md
Firecrawl MCP (via /helpers:thinking-partner):
- Deep research on GitHub, technical forums, documentation
- Scrape architecture examples
Tavily MCP (via /helpers:thinking-partner):
- General web search for research
- Find best practices and patterns
Context7 MCP (via /helpers:thinking-partner):
- Official library documentation
- Code examples from package docs
Example Session
User: "I need to plan a new authentication system"
Claude (plan-expert): Let me help you plan that. First, have you
researched authentication approaches yet? I can help with that using
the thinking-partner.
User: "Yes, I've decided on JWT with refresh tokens"
Claude: Great! Let's document that decision. I'll create an ADR.
[Creates docs/adr/ADR-047-jwt-authentication.md from adr-template.md]
Claude: I've created ADR-047. Let me populate it with your decision...
[Populates Context, Decision, Consequences sections]
Claude: Now let's create the technical specification. What components
need to be built?
User: "Auth middleware, token service, refresh endpoint, logout"
Claude: Perfect. I'll create the spec with those tasks.
[Creates docs/specs/spec-jwt-authentication.md from spec-template.md]
Claude: I've created the spec with 8 tasks. Ready to add these to VTM?
User: "Yes, do it"
Claude: [Calls /plan:to-vtm docs/adr/ADR-047-jwt-authentication.md docs/specs/spec-jwt-authentication.md]
[Shows preview of 8 tasks with dependencies]
Claude: I see 8 new tasks. Task dependencies look good:
- TASK-020: JWT token service (no dependencies)
- TASK-021: Auth middleware (depends on TASK-020)
- TASK-022: Refresh endpoint (depends on TASK-020, TASK-021)
- ...
Shall I add these to your VTM?
User: "Yes"
Claude: ✅ Added 8 tasks to VTM. Run /vtm:next to see what's ready!
Directory Structure
Expected project structure for plan domain:
project-root/
├── docs/
│ ├── adr/
│ │ ├── ADR-001-initial-architecture.md
│ │ ├── ADR-042-database-choice.md
│ │ └── ADR-047-jwt-authentication.md
│ └── specs/
│ ├── spec-initial-setup.md
│ ├── spec-database-layer.md
│ └── spec-jwt-authentication.md
├── .claude/
│ └── templates/
│ ├── adr-template.md
│ └── spec-template.md
└── vtm.json
Customization
Add Your Own Trigger Phrases
Edit the frontmatter above to include project-specific terms:
trigger_phrases:
- "create an adr"
- "new architecture decision" # Add this
- "rfp" # Your team uses "RFP" for specs
- "implementation plan" # Alternative to "spec"
Templates
The plan-expert uses these templates:
.claude/templates/adr-template.md- ADR format.claude/templates/spec-template.md- Spec format
You can customize these templates to match your team's preferences.
Technical Details
Architecture:
- Skill uses filesystem MCP for all file operations
- Commands wrap VTM CLI for transformation
- Agent-based extraction (not parsers) for flexibility
- Multi-layer validation before ingestion
Data Flow:
User intent → plan-expert detects →
Filesystem MCP (create/list files) →
User edits docs →
/plan:to-vtm (transform) →
vtm CLI (validate + ingest) →
VTM updated
Error Handling
ADR Creation Errors:
- Directory missing: plan-expert creates
docs/adr/directory - Duplicate ADR number: Suggests next available number
- Template missing: Falls back to inline template
Spec Creation Errors:
- No ADR reference: Warns but allows creation
- Directory missing: Creates
docs/specs/directory - Template missing: Falls back to inline template
Transformation Errors:
- ADR not found: Clear error with path
- Spec not found: Clear error with path
- Validation errors: Shows all errors, suggests fixes
- Circular dependencies: Shows cycle path
See Also
- ADR-046: Plan-VTM Bridge Architecture
- Technical spec:
specs/spec-plan-to-vtm.md - Command:
.claude/commands/plan/to-vtm.md - Design:
.claude/designs/plan.json
Status
Implemented:
- ✅ /plan:to-vtm command (transformation)
In Progress:
- 🔄 plan-expert skill (this file)
Planned:
- ⏳ /helpers:thinking-partner command
- ⏳ Validation hooks (pre-commit, pre-to-vtm)
- ⏳ MCP server registrations