architecture/skills/ddd-breakdown/SKILL.md

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

name	description	model	argument-hint	user-invocable
ddd-breakdown	Analyze product vision using DDD to identify bounded contexts and generate implementation issues. Use when breaking down features into DDD-based vertical slices, or when user says /ddd-breakdown.	haiku	vision-file	true

DDD Breakdown

@/.claude/skills/ddd/SKILL.md @/.claude/skills/issue-writing/SKILL.md @~/.claude/skills/gitea/SKILL.md

Analyze product vision through a DDD lens to generate implementation issues.

Process

1. Locate manifesto and vision:

   Manifesto (organization-level):

   # Always in architecture repo
   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 before proceeding.

2. Spawn DDD analyst agent:

   Use Task tool to spawn ddd-analyst agent:

   Analyze this product using DDD principles.
   
   Manifesto: [path to manifesto.md]
   Vision: [path to vision.md]
   Codebase: [current working directory]
   
   Identify bounded contexts, map features to DDD patterns, and generate
   user stories with DDD implementation guidance.
   

   The agent will:

   • Analyze manifesto (personas, beliefs, domain language)
   • Analyze vision (goals, features, milestones)
   • Explore codebase (existing structure, boundaries, misalignments)
   • Identify bounded contexts (intended vs actual)
   • Map features to DDD patterns (aggregates, commands, events)
   • Generate user stories with acceptance criteria and DDD guidance

3. Review agent output:

   The agent returns structured analysis:

   • Bounded contexts identified
   • User stories per context
   • Refactoring needs
   • Suggested implementation order

   Present this to the user for review.

4. Confirm issue creation:

   Ask user:

   • Create all issues?
   • Select specific issues to create?
   • Modify any stories before creating?

5. Create issues in Gitea:

   For each approved user story:

   tea issues create \
     --title "[story title]" \
     --description "[full story with DDD guidance]"
   

   Apply labels:

   • feature (or refactor for refactoring issues)
   • bounded-context/[context-name]
   • Any other relevant labels from the story

6. Link dependencies:

   For stories with dependencies:

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

7. Report results:

   Show created issues with links:

   ## Issues Created
   
   ### Context: [Context Name]
   - #123: [Issue title]
   - #124: [Issue title]
   
   ### Context: [Another Context]
   - #125: [Issue title]
   
   ### Refactoring
   - #126: [Issue title]
   
   View all: [link to issues page]
   

Guidelines

• Manifesto is organization-wide: Always read from architecture repo
• Vision is product-specific: Read from current repo or provided path
• Let agent do the analysis: Don't try to identify contexts yourself, spawn the agent
• Review before creating: Always show user the analysis before creating issues
• Label by context: Use bounded-context/[name] labels for filtering
• Link dependencies: Use tea issues deps add for blockers
• Implementation order matters: Create foundational issues (refactoring, core aggregates) first

Tips

• Run this when starting a new product or major feature area
• Re-run periodically to identify drift between vision and code
• Use with /vision skill to manage product vision
• Combine with /plan-issues for additional breakdown
• Review with team before creating all issues