brainstorming
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or planning anything new, in software or out of it (a talk, a business, a renovation).
phx-briefInteractive briefing of a plan file — explains reasoning, schema decisions, component choices. Use when developers need to understand a plan before approving.
Independent GitHub snapshot · Automated classification · Original documentation governs
Interactive walkthrough of a plan's reasoning, decisions, and solution shape. Designed for developers who need to understand a plan in 1-2 minutes instead of reading the full document.
Plans answer "what to do" but bury "why." This skill bridges that gap with an interactive walkthrough.
/phx-brief # Latest plan
/phx-brief .claude/plans/user-auth/plan.md # Specific plan
$ARGUMENTS = Path to plan file (optional, auto-detects latest)Read the plan file and determine mode from phase statuses:
[PENDING] = Pre-work briefing (what WILL happen)[COMPLETED] or [IN_PROGRESS] = Post-work briefing
(what WAS done and why)If $ARGUMENTS has a path, use it
Otherwise, find latest plan:
Use Glob to find .claude/plans/*/plan.md and pick the most recent.
If no plan found, tell user and suggest /phx-plan
Read the plan file
Read what's available (don't fail if missing):
.claude/plans/{slug}/summaries/consolidated.md (research summary).claude/plans/{slug}/scratchpad.md (decisions, dead-ends).claude/plans/{slug}/progress.md (work log, post-work only)Present ONE section at a time, wrapped in the visual briefing block
(see references/briefing-guide.md Visual Formatting).
The section MUST be emitted as visible response text BEFORE the
AskUserQuestion call. Content composed only in thinking/reasoning
is invisible to the user, and the question field is too short to
carry it. If the user would see only a "Continue?" dialog, the section
was never shown. Write the ★ Briefing block as normal output first,
then ask:
| # | Title | Source |
|---|---|---|
| 1 | What We're Building | Summary + Scope |
| 2 | Key Decisions | Technical Decisions + scratchpad rationale |
| 3 | Solution Shape | Phases overview + Data Model |
| 4 | Risks & Confidence | Risks table + unknowns/spikes |
| # | Title | Source |
|---|---|---|
| 1 | What Was Built | Summary + completion status |
| 2 | Key Decisions & Why | Technical Decisions + scratchpad |
| 3 | How It Was Built | Phases with implementation notes |
| 4 | Lessons & Patterns | Risks encountered + patterns used |
See references/briefing-guide.md for section content templates.
/phx-work without explicit user requestAskUserQuestion; never
deliver a section only inside thinking or the question fieldAfter final section (or when user stops):
That's the briefing! For full details, see:
{plan_path}
Ready to proceed? Try `/phx-work {plan_path}` to start execution.
Post-work variant:
That's what was built! For full details, see:
{plan_path}
Consider `/phx-compound` to capture key learnings for future reference.
/phx-plan --> /phx-brief (optional) --> /phx-work --> /phx-brief (optional)
create understand before execute understand after
For plans with 5+ phases or 4+ key decisions, consider suggesting
visual rendering after Section 3. See
references/visual-explainer.md for thresholds and commands.