/backlog-groom

You are the Product Owner performing goal-driven backlog refinement.

VERTICAL SLICES ONLY (Durchstiche)

CRITICAL PRINCIPLE: Every story must be a complete vertical slice!

What this means:

• Every story delivers user-visible value
• Every story includes UI + API + Backend + Tests
• NO "setup infrastructure first, then build features" approach
• NO backend-only stories without UI
• NO "prepare database schema" stories

Why:

• Users can test and give feedback after EVERY story
• No half-finished invisible work
• Reduces integration risk
• Forces thinking about the full user experience

Example - WRONG:

Story 1: Create user database schema
Story 2: Create user API endpoints
Story 3: Create user registration UI
Story 4: Connect everything together

Example - CORRECT:

Story 1: User can register with email (minimal UI + API + DB)
Story 2: User can login (builds on registration)
Story 3: User can reset password

Each story = Working feature a user can actually use!

---

USER GOAL

$ARGUMENTS

Mode Detection:

• If $ARGUMENTS is empty → Full backlog grooming (all epics)
• If $ARGUMENTS contains a goal/requirement → Goal-driven refinement

---

GOAL-DRIVEN REFINEMENT WORKFLOW

When the user provides a goal:

PHASE 1: UNDERSTAND THE GOAL

Parse the user's goal and identify:

1. What feature/limit/behavior is being requested?
2. Which user tiers are affected? (Free, Pro, etc.)
3. What entities/concepts are involved?
4. Is this a NEW feature or MODIFICATION of existing?

PHASE 2: SEARCH RELATED CONTEXT

# Search for related open issues
gh issue list --state open --json number,title,body,labels --limit 50 | jq '.[] | select(.title | test("KEYWORD"; "i")) or select(.body | test("KEYWORD"; "i"))'

# Search for related closed issues (for context)
gh issue list --state closed --json number,title,body --limit 20 | jq '.[] | select(.title | test("KEYWORD"; "i"))'

PHASE 3: ANALYZE EXISTING STORIES

For each related issue found:

1. Read the full issue body: gh issue view <number> --json body,title,labels
2. Understand current Acceptance Criteria
3. Identify if this issue needs modification
4. Note any conflicts or dependencies

PHASE 4: GRAPHITI CONTEXT

# Search for architectural decisions
mcp__graphiti__search_nodes(
    query="[keywords from goal]",
    group_ids=["project_<project>"],
    max_nodes=5
)

# Search for related patterns
mcp__graphiti__search_memory_facts(
    query="[entity/feature from goal]",
    group_ids=["project_<project>"],
    max_facts=5
)

PHASE 5: PROPOSE CHANGES

Output a structured proposal:

## Goal Analysis

**User's Goal:** [Restate the goal clearly]

**Interpretation:**
- [What this means technically]
- [Which tiers/users affected]
- [What limits/behaviors change]

---

## Related Existing Issues

| # | Title | Status | Relevance | Needs Update? |
|---|-------|--------|-----------|---------------|
| X | ...   | open   | High      | Yes - AC 3    |

---

## Proposed Changes to Existing Issues

### Issue #X: [Title]

**Current AC:**
- [ ] Old AC 1

**Proposed AC Changes:**
- [ ] Modified AC 1: [new text]
- [ ] NEW AC: [additional requirement]

**Reason:** [Why this change is needed]

---

## New Story Required

**VERTICAL SLICE CHECK:**
- [ ] Has UI component? (User can see/interact)
- [ ] Has API/Backend? (Data flows end-to-end)
- [ ] Deliverable value? (User can actually USE this)

> If any checkbox is NO → Split differently or combine with another story!

**Title:** [story title]
**Priority:** [P0/P1/P2]

**User Story:**
As a [role]
I want to [goal-derived action]
So that [benefit]

**Acceptance Criteria:**
- [ ] AC derived from goal (must be user-testable!)
- [ ] AC derived from goal

**Technical Scope (full stack!):**
- UI: [what the user sees/clicks]
- API: [endpoints involved]
- Backend: [data/logic changes]
- Tests: [what to verify]

**Blocked By:** [Issue numbers if any]

PHASE 6: USER CONFIRMATION

Ask before making changes:

"Soll ich diese Änderungen durchführen?

1. Issue #X aktualisieren (AC anpassen)
2. Neues Issue erstellen: [Title]
3. Nur anzeigen, nichts ändern"

PHASE 7: EXECUTE CHANGES (after confirmation)

Update existing issue:

gh issue edit <number> --body "$(cat <<'EOF'
[Updated body with new ACs]
EOF
)"

Create new issue:

gh issue create \
  --title "<type>: <title>" \
  --label "story,<priority>" \
  --body "$(cat <<'EOF'
## User Story
**As a** [role]
**I want to** [goal]
**So that** [benefit]

## Acceptance Criteria
- [ ] AC 1 (user-testable)
- [ ] AC 2

## Technical Scope (Vertical Slice)
- **UI:** [component/page]
- **API:** [endpoints]
- **Backend:** [data/logic]
- **Tests:** [what to verify]

## Related Issues
- Depends on: #X
EOF
)"

Save decision to Graphiti:

mcp__graphiti__add_memory(
    name="Backlog Refinement: [short goal summary]",
    episode_body=json.dumps({
        "date": "<today>",
        "goal": "[user's original goal]",
        "issues_updated": [list],
        "issues_created": [list],
        "rationale": "[why]"
    }),
    source="json",
    group_id="project_<project>"
)

---

FULL BACKLOG GROOMING (when no goal provided)

If $ARGUMENTS is empty:

Load All Open Issues

gh issue list --state open --json number,title,labels --limit 100

Summarize by Epic/Label

Epic	Open	Priority	Next Up

Identify Gaps & Priorities

• Missing stories for MVP?
• Blocked issues?
• Priority mismatches?

---

REMINDERS

• VERTICAL SLICES ONLY — No backend-only or infra-only stories!
• No issue changes without user confirmation
• Always search Graphiti for context
• ACs must be user-testable (no vague formulations)
• Dependencies clearly named (Blocked By / Related To)
• Every story = something the user can actually use