pair-process-brainstorm — 3 phases, parametrized ($root, orientation)

[rucka]

Story Statement

As a product team
I want pair-process-brainstorm: 3 phases (grill interview → domain integration → tree triage), parametrized — free theme or $root issue, functional/technical orientation from type/tags
So that discovery on existing projects is structured and lands as an integrated Draft epic/story tree without touching the PRD (R3.1–R3.4, R3.7)

Where: conversation + PM tool (phase 3 output) + adoption context files (phase 2, via map-* capabilities)

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 invocation with no arguments
   When the session starts
   Then the FIRST interview question asks the level (broad feature/initiative vs punctual story) — decision Q7 — and phase 1 produces the raw requirements blob (R3.7) via grill

2. Given $root <issue-id>
   When the session starts
   Then level and orientation (functional/technical) are deduced from issue type and tags (epic → broad/functional; story → punctual; tech/tech-debt → technical) and phase 3 integrates the tree under the root

3. Given phase 2 with domain artifacts present
   When discovery results are integrated
   Then map-subdomains (broad/functional) or map-contexts (punctual/technical) run scoped to the touched areas, context-map is updated inline, and features conflicting with registered rules are flagged citing the DDR; if context-map.md is absent, phase 2 degrades gracefully (no failure)

4. Given phase 3
   When the tree is produced
   Then it composes the to-issues pattern (to-issues triage pattern in plan-epics/plan-stories #231) via plan-epics/plan-stories: Draft items, vertical slices, linked to existing backlog items — and the PRD is never modified

Business Rules

• The ONLY new process skill (D24)
• Phase order fixed: interview → domain → triage; each phase output feeds the next
• Compound insertion (R3.1): extend-vs-create decided against the existing tree

Edge Cases and Error Handling

• $root not found: HALT with clear message
• User stops after phase 1: raw blob offered as handoff file (working/) for later resume
• No PM tool configured: phases 1–2 work; phase 3 HALTs with setup pointer

Definition of Done Checklist

Development Completion

• All acceptance criteria implemented and verified
• Skill follows authoring conventions (composition of grill, map-, plan-)
• Code review completed and approved
• Documentation updated — docs site page (process overview updated)

Quality Assurance

• End-to-end session on pair repo (dogfood) producing a real Draft tree
• Graceful-degrade path verified (no context-map)

Story Sizing and Sprint Readiness

Refined Story Points

Final Story Points: 5 (L)
Confidence Level: Medium
Sizing Justification: composition-heavy but phases delegate to existing/parallel capabilities (grill #229, map-* #203, to-issues #231); resized from XL(8) per decision Q9

Sprint Capacity Validation

Sprint Fit Assessment: yes, single sprint given prerequisites land first
Total Effort Assessment: fits — Yes

Dependencies and Coordination

Story Dependencies

Prerequisite Stories: #229 grill; #231 to-issues pattern; soft: #203 (map-* reclassification + context-map — degrades gracefully), specifically #244 (context-map.md artifact + context-map-maintenance.md guideline) — #244's Loading/Conflict-Flag instructions ("Any skill that touches domain scope... should, when it reaches that step: Load/Check/Flag/Update-inline") are written generically for any consuming skill and are currently wired only into refine-story; this story (T2, Phase 2) is where the same Load/Check/Flag/Update-inline sequence gets wired into brainstorm, closing #244's AC4 half that's currently unimplemented pending this story.
Dependent Stories: none (entry point)

Validation and Testing Strategy

Acceptance Testing Approach

Testing Methods: scripted sessions (no-root broad; $root epic; $root tech story); dogfood run on pair
Test Data Requirements: sample epic/story/tech-debt issues as roots

Notes and Additional Context

Refinement Session Insights: Q7 (level = first question) and Q9 (single story, L5) decided
Documentation Links: R3.1–R3.4, R3.7 · Spec G3 · D24

Technical Analysis

Implementation Approach

Technical Strategy: new process skill in .skills/process/pair-process-brainstorm/: phase 1 composes grill; phase 2 composes map-subdomains/map-contexts (scoped) + inline context updates; phase 3 composes plan-epics/plan-stories with the to-issues pattern; orientation deduction from PM-tool issue type/tags
Key Components: SKILL.md (3 phases, params, HALT); orientation matrix; handoff on interrupt
Integration Points: grill (#229), map-* (#203), plan-epics/plan-stories (#231), write-issue

Technical Risks and Mitigation

Risk	Impact	Probability	Mitigation Strategy
Phase 3 floods backlog	Medium	Medium	dry-run list + user confirmation before write (consistent with plan-* skills)
Orientation misdeduction	Low	Medium	deduced values stated up-front, user can override

Task Breakdown

Checklist

• T1 — SKILL.md skeleton + phase 1 (grill composition, level question, raw blob output)
• T2 — Phase 2 (map-* composition scoped + context-map inline updates + DDR conflict flag + graceful degrade)
• T3 — Phase 3 (to-issues via plan-epics/plan-stories, dry-run + confirm, root integration)
• T4 — Orientation deduction from type/tags + override
• T5 — Dogfood session + docs site + distribution

Dependency Graph

T1 → T2 → T3 → T4 → T5

AC Coverage

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