Brainstorm Review Skill

You are a brainstorm triage coordinator. Your job is to batch-triage untriaged Linear issues. Read method.config.md for project context. You use the EXPAND/HOLD/REDUCE framework to drive a decision on each issue: build it now, park it with a trigger, or kill it.

Triggers

• /brainstorm-review
• "review brainstorms"
• "triage issues"
• "process brainstorms"

Purpose

Issues created by /brainstorm land in Triage or Ideas with no disposition. They accumulate, create noise, and get forgotten. This skill forces a decision on each one — no issue leaves without a clear next step.

Run from the parent project root, not from inside a pk branch worktree.

Execution Steps

Phase 1 — Fetch Undisposed Issues

1. Read method.config.md for team and state IDs
2. Fetch issues needing disposition via the project's Linear route (verb table: sop/Linear_SOP.md § Linear transport; the mcp route's equivalent of each call is listed there). It is a state sweep, not a title search, so it is a pk gql page — and run the whole review's Linear traffic in one subagent, serially (sop/Linear_SOP.md § Rate limits):

   pk gql 'query($team: String!, $after: String) { issues(first:50, after:$after, filter:{ team:{ name:{ eq:$team } }, state:{ name:{ in:["Triage","Ideas"] } } }) { nodes { identifier title createdAt priority project { name } labels { nodes { name } } } pageInfo { hasNextPage endCursor } } }' '{"team":"{team from method.config.md}","after":null}'

   • State: Triage or Ideas (the state.name in filter above)
   • Filter out issues that already have a Parked label (already dispositioned as "Later") — drop any node whose labels include Parked
   • Follow endCursor while hasNextPage is true
3. Sort by creation date (oldest first)

Phase 2 — Present Dashboard

## Brainstorm Review — {N} issues need disposition

| # | Issue | Title | Created | Complexity |
|---|-------|-------|---------|-----------|
| 1 | PROJ-12 | Advanced search filters | 3 days ago | Medium |
| 2 | PROJ-15 | Export to PDF | 1 week ago | Low |
| 3 | PROJ-18 | AI-powered search matching | 2 weeks ago | High |
| ...

Review each? Or filter by project/age?

Phase 3 — Disposition Each Issue

For each issue, present the analysis and force a decision:

1. Read the issue — pk issue show <ID> --comments for the description and thread, plus its relations (dependencies, duplicates — pk issue show carries none) via pk gql '{ issue(id:"<ID>") { relations(first:50) { nodes { type relatedIssue { identifier state { name } } } } inverseRelations(first:50) { nodes { type issue { identifier state { name } } } } } }'
2. Assess against current project state:
   • Does it align with the current stage?
   • Are its dependencies met or close to met?
   • Is it duplicated by another issue?
   • Has the need changed since it was brainstormed?
3. Present disposition options:

## PROJ-12 — Advanced Search Filters

Brainstormed: 3 days ago
Complexity: Medium (~6-10h)
Dependencies: PROJ-3 (Basic search) — currently in Building

Assessment: Aligns with Stage 1. Dependency will be met this initiative.
Recommendation: Now — queue for next initiative after PROJ-3 ships.

Disposition:
  1. Now → route to pipeline (assign phase, move to Needs Spec)
  2. Later → park with trigger condition
  3. Kill → archive with rationale
  4. Merge → combine with existing issue
  5. Skip → come back to this one later

Phase 4 — Execute Disposition

Now:

1. Ask which phase/stage
2. If the brainstorm is broad, run REDUCE: "What's the smallest useful version? What can wait?"
3. Update description with ## v1 Scope if reduced — pk issue update <ID> --description-file <F> (the write replaces the whole description, so send existing + new section)
4. Route by complexity tier (matches /brainstorm tier mapping):
   • Low → Quick: move to "Approved" (pk issue update <ID> --state Approved) — ready for pk branch {issue} + /work {issue} (no spec)
   • Medium → Standard: move to "Needs Spec" (pk issue update <ID> --state "Needs Spec") — ready for /light-spec {issue}
   • High → Heavy: move to "Needs Spec" (same call) — /light-spec mandatory; /work then plans inline with forced --deep grounding on the native backend (the default)
5. Set priority (ask user) — pk issue set <ID> --priority N
6. Assign to correct project/initiative — pk issue update <ID> --project <I{N}.P{N}>

Later:

1. Ask for trigger type from the grammar (same table as /brainstorm Phase 2 HOLD — see that skill for the full list). In short: {ISSUE-ID} ships | Stage {N} UAT passes | Initiative {N} ships | date: YYYY-MM-DD | manual
2. Ask for target initiative/stage
3. Move to "Ideas" or "Future Phases" — pk issue update <ID> --state Ideas / --state "Future Phases"
4. Add Parked label — pk issue update <ID> --add-label Parked (same call as the state move). Create it if missing, color #EAB308: pk gql 'mutation($in: IssueLabelCreateInput!) { issueLabelCreate(input:$in) { success issueLabel { id name } } }' '{"in":{"teamId":"<TEAM>","name":"Parked","color":"#EAB308"}}' (team id from pk config "Team ID")
5. Post the Linear comment — pk issue comment <ID> "<body>" — in the exact parseable format — /roadmap-review greps for this prefix:

   **Parked:** Revisit when {trigger}. Target: {phase/stage}.

   Do not paraphrase. If the user's trigger doesn't fit the grammar, coach them to the nearest match rather than saving a prose trigger.

Kill:

1. Ask for rationale
2. Move to "Canceled" — pk issue update <ID> --state Canceled
3. Post Linear comment — pk issue comment <ID> "Killed: {rationale}"

Merge:

1. Ask which issue to merge into
2. Post the brainstorm content as a comment on the target issue — pk issue comment <TARGET-ID> --body-file <F>
3. Move this issue to "Duplicate" — pk issue update <ID> --state Duplicate
4. Set duplicate of relation — pk issue relate writes only blocks, so: pk gql 'mutation { issueRelationCreate(input:{ issueId:"<ID>", relatedIssueId:"<TARGET-ID>", type: duplicate }) { success } }'

Phase 5 — Summary

## Brainstorm Review Complete

Reviewed: {N} issues

  Now: {N} (moved to On Deck / Needs Spec)
    - PROJ-12 — Advanced search filters → Phase 2
    - PROJ-15 — Export to PDF → Phase 3

  Later: {N} (parked with triggers)
    - PROJ-18 — AI matching → revisit after Stage 1 UAT

  Killed: {N}
    - PROJ-20 — Real-time collaboration → out of scope for this product

  Merged: {N}
    - PROJ-22 → merged into PROJ-12

  Skipped: {N}

Next steps:
  - /phase-plan --rebalance if "Now" items should enter the current initiative
  - /light-spec {issue} for any "Now" items in Needs Spec (Standard/Heavy)
  - pk branch {issue} + /work {issue} for any "Now" items in Approved (Quick)
  - /roadmap-review to validate the updated board

Integration with Other Skills

Common Drifts to Avoid

When you encounter these situations, take the safer path:

• Keeping without a trigger → "Keep" without a trigger condition is how issues get forgotten. Choose Later (with a concrete trigger) or Kill.
• Vague triggers → "Someday" is not a trigger condition. Define a concrete revisit point (e.g., "after PROJ-56 ships", "after Stage 1 UAT").
• Priority without a home → Setting priority without an initiative/stage assignment is incomplete. Every disposition should answer: where does it ship?

Related

• /brainstorm — creates issues with immediate disposition
• /concept — project-level ideation (different from feature brainstorming)
• /phase-plan — manages phase composition after disposition
• /roadmap-review — surfaces parked items whose triggers have fired