feat: add composable product strategy capability (vision-to-backlog)
Replace monolithic ddd-analyst with composable agent architecture following opinionated product strategy chain from manifesto to executable backlog. New Components: - product-strategy skill: 7-step framework with decision gates - vision-to-backlog skill: Orchestrator with user decision gates (Haiku) - problem-space-analyst agent: Vision → Event timeline (Haiku) - context-mapper agent: Events → Bounded contexts (Haiku) - domain-modeler agent: Contexts → Domain models (Haiku) - capability-extractor agent: Domain → Capabilities (Haiku) - backlog-builder agent: Capabilities → Features → Issues (Haiku) The Chain: Manifesto → Vision → Problem Space → Contexts → Domain → Capabilities → Features → Issues Each step has decision gate preventing waste. Agents work autonomously, orchestrator manages gates and user decisions. Benefits: - Composable: Each agent reusable independently - DDD embedded throughout (not isolated) - Prevents cargo-cult DDD (problem space before modeling) - Works for greenfield + brownfield - All Haiku models (cost-optimized) Removed: - ddd-breakdown skill (replaced by vision-to-backlog) - ddd-analyst agent (replaced by 5 specialized agents) Co-Authored-By: Claude Code <noreply@anthropic.com>
This commit is contained in:
314
skills/vision-to-backlog/SKILL.md
Normal file
314
skills/vision-to-backlog/SKILL.md
Normal file
@@ -0,0 +1,314 @@
|
||||
---
|
||||
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: haiku
|
||||
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
|
||||
Reference in New Issue
Block a user