---
name: vision-to-backlog
description: >
  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.
model: claude-haiku-4-5
argument-hint: [vision-file]
user-invocable: 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):
```bash
cat ~/.claude/manifesto.md
# Or if in architecture repo:
cat ./manifesto.md
```

**Vision** (product-level):
```bash
# 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:
```bash
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:
```bash
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