---
name: ddd-breakdown
description: >
  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.
model: haiku
argument-hint: [vision-file]
user-invocable: 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):
   ```bash
   # Always in architecture repo
   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 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:
   ```bash
   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:
   ```bash
   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