Files
architecture/skills/vision-to-backlog/SKILL.md
Hugo Nijhuis fd713c8697 fix(vision-to-backlog): organize artifacts in .product-strategy/ directory
Create .product-strategy/ directory to organize all strategy artifacts
instead of cluttering root directory.

Changes:
- Step 2: Create .product-strategy/ directory early in workflow
- Each agent spawn: Specify output path (e.g., .product-strategy/problem-map.md)
- Agents reference prior artifacts by path
- Final report lists all artifact locations

Artifacts saved:
- .product-strategy/problem-map.md
- .product-strategy/context-map.md
- .product-strategy/domain-*.md (one per context)
- .product-strategy/capabilities.md
- .product-strategy/backlog.md

Keeps root directory clean and strategy artifacts organized.

Co-Authored-By: Claude Code <noreply@anthropic.com>
2026-01-12 18:53:47 +01:00

350 lines
8.0 KiB
Markdown

---
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. Create Artifacts Directory
Create directory for strategy artifacts:
```bash
mkdir -p .product-strategy
```
All artifacts will be saved here to keep root clean.
### 3. 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.
### 4. 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
Save artifact to: .product-strategy/problem-map.md
Follow problem-space-analyst agent instructions.
```
Agent returns Problem Map artifact saved to `.product-strategy/problem-map.md`.
### 5. 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
### 6. Spawn Context Mapper
Use Task tool to spawn `context-mapper` agent:
```
Identify bounded contexts from the problem space.
Problem Map: .product-strategy/problem-map.md
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)
Save artifact to: .product-strategy/context-map.md
Follow context-mapper agent instructions.
```
Agent returns Bounded Context Map saved to `.product-strategy/context-map.md`.
### 7. 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
### 8. 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 .product-strategy/context-map.md]
Codebase: [current directory]
Identify:
- Aggregates (only where invariants exist)
- Commands
- Events
- Policies
- Read models
Compare with existing code if present.
Save artifact to: .product-strategy/domain-[context-name].md
Follow domain-modeler agent instructions.
```
Agent returns Domain Model saved to `.product-strategy/domain-[context-name].md`.
### 9. 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
### 10. Spawn Capability Extractor
Use Task tool to spawn `capability-extractor` agent:
```
Extract product capabilities from domain models.
Domain Models: .product-strategy/domain-*.md
Output:
- Capability Map
- System abilities that cause meaningful domain changes
Save artifact to: .product-strategy/capabilities.md
Follow capability-extractor agent instructions.
```
Agent returns Capability Map saved to `.product-strategy/capabilities.md`.
### 11. 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
### 12. Spawn Backlog Builder
Use Task tool to spawn `backlog-builder` agent:
```
Generate features and issues from selected capabilities.
Selected Capabilities: [user selection from .product-strategy/capabilities.md]
Domain Models: .product-strategy/domain-*.md
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.
Save artifact to: .product-strategy/backlog.md
Follow backlog-builder agent instructions.
```
Agent returns Features + Issues saved to `.product-strategy/backlog.md`.
### 13. 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
### 14. Issue Review
Present all generated issues from `.product-strategy/backlog.md` 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:
**Ready to create these issues in Gitea?**
- If YES → automatically proceed to create all issues (step 14)
- If NO → ask what to modify, regenerate, ask again
### 15. Create Issues in Gitea (automatic after approval)
**After user approves in step 13, automatically create all issues.**
For each 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]`
### 16. Link Dependencies
For issues with dependencies:
```bash
tea issues deps add <dependent-issue> <blocker-issue>
```
### 17. 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]
All artifacts saved in .product-strategy/:
- problem-map.md
- context-map.md
- domain-*.md (one per context)
- capabilities.md
- backlog.md
```
## Guidelines
**Follow the chain:**
- Don't skip steps
- Each step has decision gate
- User approves before proceeding to next step
**Automatic execution after approval:**
- After user approves at decision gate, automatically proceed
- Don't wait for another prompt
- Execute the next step immediately
- Example: "Ready to create issues?" → YES → create all issues automatically
**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
- But once approved, automatically continue
**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