architecture/skills/vision-to-backlog/SKILL.md

name, description, model, argument-hint, user-invocable

name	description	model	argument-hint	user-invocable
vision-to-backlog	Orchestrate the full product strategy chain from manifesto to executable backlog. Use when breaking down product vision into work, or when user says /vision-to-backlog.	haiku	vision-file	true

Vision to Backlog

@/.claude/skills/product-strategy/SKILL.md @/.claude/skills/gitea/SKILL.md

Orchestrate the disciplined chain: Manifesto → Vision → Problem Space → Contexts → Domain → Capabilities → Features → Issues.

Arguments

Optional: path to vision.md file (defaults to ./vision.md)

Process

1. Locate Manifesto and Vision

Manifesto (organization-level):

cat ~/.claude/manifesto.md
# Or if in architecture repo:
cat ./manifesto.md

Vision (product-level):

# If argument provided: use that file
# Otherwise: look for vision.md in current repo
cat ./vision.md

Verify both files exist. If vision doesn't exist, help user create it following product-strategy framework.

2. Vision Decision Gate

Show vision to user and ask:

Can you answer these crisply:

• Who is this product for?
• What pain is eliminated?
• What job is now trivial?
• What won't we do?

If NO → help refine vision first, don't proceed. If YES → continue to problem space.

3. Spawn Problem Space Analyst

Use Task tool to spawn problem-space-analyst agent:

Analyze the product vision to identify the problem space.

Manifesto: [path]
Vision: [path]
Codebase: [current directory]

Output:
- Event timeline (business events, not entities)
- User journeys
- Decision points
- Irreversible vs reversible actions
- Where mistakes are expensive

Follow problem-space-analyst agent instructions.

Agent returns Problem Map artifact.

4. Problem Space Decision Gate

Show Problem Map to user and ask:

Do you see events, not entities?

• If NO → problem space needs more work
• If YES → continue to context mapping

5. Spawn Context Mapper

Use Task tool to spawn context-mapper agent:

Identify bounded contexts from the problem space.

Problem Map: [from previous step]
Codebase: [current directory]

Analyze:
- Intended contexts (from problem space)
- Actual contexts (from codebase structure)
- Misalignments

Output:
- Bounded Context Map
- Boundary rules
- Refactoring needs (if brownfield)

Follow context-mapper agent instructions.

Agent returns Bounded Context Map.

6. Context Decision Gate

Show Bounded Context Map to user and ask:

Are boundaries clear?

• Different language per context?
• Different lifecycles per context?

If NO → revise contexts If YES → continue to domain modeling

7. Spawn Domain Modeler (Per Context)

For each bounded context, spawn domain-modeler agent:

Model the domain for bounded context: [CONTEXT_NAME]

Context: [context details from map]
Codebase: [current directory]

Identify:
- Aggregates (only where invariants exist)
- Commands
- Events
- Policies
- Read models

Compare with existing code if present.

Follow domain-modeler agent instructions.

Agent returns Domain Model for this context.

8. Domain Model Decision Gate

For each context, verify:

Does each aggregate enforce an invariant?

• If NO → simplify (might be read model or policy)
• If YES → continue

9. Spawn Capability Extractor

Use Task tool to spawn capability-extractor agent:

Extract product capabilities from domain models.

Domain Models: [all contexts]

Output:
- Capability Map
- System abilities that cause meaningful domain changes

Follow capability-extractor agent instructions.

Agent returns Capability Map.

10. Capability Decision Gate

Show Capability Map to user and ask:

Which capabilities do you want to build?

• Show all capabilities with descriptions
• Let user select subset
• Prioritize if needed

11. Spawn Backlog Builder

Use Task tool to spawn backlog-builder agent:

Generate features and issues from selected capabilities.

Selected Capabilities: [user selection]
Domain Models: [all contexts]
Codebase: [current directory]

For each capability:
1. Define features (user-visible value)
2. Decompose into issues (domain-order: commands, rules, events, reads, UI)
3. Identify refactoring issues (if misaligned with domain)

Follow issue-writing skill format.

Follow backlog-builder agent instructions.

Agent returns Features + Issues.

12. Feature Decision Gate

Show generated features and ask:

Does each feature move a capability? Is each feature demoable?

If NO → refine features If YES → continue to issue creation

13. Issue Review and Creation

Present all generated issues to user:

## Generated Backlog

### Context: [Context Name]
**Refactoring:**
- #issue: [title]
- #issue: [title]

**Features:**
- Feature: [name]
  - #issue: [title] (command)
  - #issue: [title] (domain rule)
  - #issue: [title] (event)
  - #issue: [title] (read model)
  - #issue: [title] (UI)

Ask user:

• Create all issues?
• Select specific issues?
• Modify any before creating?

14. Create Issues in Gitea

For each approved issue:

tea issues create \
  --title "[issue title]" \
  --description "[full issue with acceptance criteria]"

Apply labels:

• feature or refactor
• bounded-context/[context-name]
• capability/[capability-name]

15. Link Dependencies

For issues with dependencies:

tea issues deps add <dependent-issue> <blocker-issue>

16. Final Report

Show created issues with links:

## Backlog Created

### Context: Authentication
- #42: Implement User aggregate
- #43: Add RegisterUser command
- #44: Publish UserRegistered event

### Context: Orders
- #45: Refactor Order model to enforce invariants
- #46: Add PlaceOrder command
- #47: Publish OrderPlaced event

Total: 6 issues created across 2 contexts
View backlog: [gitea issues link]

Guidelines

Follow the chain:

• Don't skip steps
• Each step has decision gate
• User approves before proceeding

Let agents work:

• Agents do analysis autonomously
• Orchestrator just dispatches and gates

Decision gates prevent waste:

• Stop early if vision unclear
• Verify events before contexts
• Verify invariants before building

Brownfield handling:

• Agents analyze existing code at each step
• Generate refactoring issues for misalignments
• Generate feature issues for new capabilities

Issue quality:

• Reference domain concepts, not UI
• Follow domain decomposition order
• Link dependencies properly

Tips

• Run when starting new product or major feature area
• Each artifact is presented for review
• User can iterate at any decision gate
• Issues are DDD-informed and executable
• Works for greenfield and brownfield