to-issues triage pattern in plan-epics/plan-stories

[rucka]

Story Statement

As a planner
I want the to-issues triage pattern in plan-epics/plan-stories: vertical slices matched against the existing tree (extend vs create)
So that brainstorm phase-3 output and any planning merges into the backlog instead of duplicating it (R3.3)

Where: plan-epics / plan-stories skills; PM tool

Epic Context

Parent Epic: Structured & parametrized brainstorming #205
Status: Refined
Priority: P0 (Must-Have)

Status Workflow

• Refined: Story is detailed, estimated, and ready for development
• In Progress: Story is actively being developed
• Done: Story delivered and accepted

Acceptance Criteria

Functional Requirements

Given-When-Then Format:

1. Given an input tree/blob (from brainstorm or direct invocation)
   When plan-epics/plan-stories run
   Then each candidate item is matched against the existing backlog and proposed as EXTEND or CREATE, with the rationale shown before any write

2. Given the decomposition step
   When stories are produced
   Then they are vertical slices passing INVEST validation (existing plan-stories rule preserved)

3. Given items are written
   When creation completes
   Then every item is linked to its parent and related issues (sub-issue hierarchy + references)

4. Given a re-run with the same input
   When matching runs again
   Then no duplicates are created (idempotency by title/parent matching)

Business Rules

• Dry-run list + user confirmation before writes (consistent with plan-* behavior)
• Extend proposed when overlap is substantial; create otherwise — threshold documented in the skill

Edge Cases and Error Handling

• Ambiguous match: presented as question with recommendation (extend vs create)
• Closed matching item: never extended; create with reference

Definition of Done Checklist

Development Completion

• All acceptance criteria implemented and verified
• Skill updates follow authoring conventions
• Code review completed and approved
• Documentation updated — docs site (planning pages)

Quality Assurance

• Idempotency verified (double run)
• Extend-vs-create proposals verified on fixture backlog

Story Sizing and Sprint Readiness

Refined Story Points

Final Story Points: 3 (M)
Confidence Level: Medium
Sizing Justification: two skill updates + matching rules; no new artifacts

Sprint Capacity Validation

Sprint Fit Assessment: yes, single sprint
Total Effort Assessment: fits — Yes

Dependencies and Coordination

Story Dependencies

Prerequisite Stories: none
Dependent Stories: #230 brainstorm (phase 3 composes this)

Validation and Testing Strategy

Acceptance Testing Approach

Testing Methods: fixture backlog + candidate tree → proposal list assertions; double-run test

Notes and Additional Context

Documentation Links: R3.3 · Spec G3 · pattern ref. mattpocock to-issues

Technical Analysis

Implementation Approach

Technical Strategy: extend plan-epics and plan-stories SKILL.md with a matching step (query existing tree via PM tool, propose extend/create with rationale, confirm, write via write-issue)
Key Components: matching rules section; proposal/confirmation flow; idempotency key
Integration Points: brainstorm phase 3; write-issue; PM tool hierarchy queries

Technical Risks and Mitigation

Risk	Impact	Probability	Mitigation Strategy
Over-eager extend proposals	Medium	Medium	conservative threshold + always user-confirmed

Task Breakdown

Checklist

• T1 — Matching rules (extend-vs-create criteria + idempotency key)
• T2 — plan-epics update (match step + proposal flow)
• T3 — plan-stories update (same + INVEST preserved)
• T4 — QA (fixtures, double-run) + docs site

Dependency Graph

T1 → (T2 ∥ T3) → T4

AC Coverage

Task	AC1	AC2	AC3	AC4
T1	✓			✓
T2	✓		✓
T3	✓	✓	✓
T4	✓	✓	✓	✓