About plan-session
plan-session is a design-session skill for turning a defined problem into a concrete design or plan. It guides product or exploratory discussions, preserves constraints, and structures the resulting document for execution.
Key features
- 01Selects Product or Builder mode
- 02Reviews existing briefs and constraints
- 03Batches consequential questions
- 04Compares approaches and tradeoffs
- 05Structures an execution-ready design
Use cases
- 01Shaping a product problem into a plan
- 02Exploring tools and ideas in Builder mode
- 03Documenting a design with risks and acceptance criteria
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/plan-sessionin Claude Code to confirm it loaded.
Bundled filesagents/openai.yamldiscovery.md
Details
From the project READMEDesign Session
Understand the problem and produce a concrete design or plan. Use Product mode for demand and user outcomes, Builder mode for exploratory tools and ideas. Infer the mode from the request or ask if the distinction materially changes the work; load only that section of discovery.md.
Conversation
Read existing briefs and constraints first. Ask a focused question only for consequential missing information; batch independent questions when useful. Group up to four independent questions into one question prompt rather than one prompt each, and fold TODO or deferral rulings into the final checkpoint; batching keeps every question. Preserve the user's answers, scope rulings and preferred pace. Honor “skip questions” on the first request, state any assumptions and proceed. Do not require a final forcing question or another confirmation of settled context.
Challenge a premise with evidence when it matters. No fabricated disagreement, adversarial performance or diagnostic labels. If the user wants a creative experiment, do not force a commercial demand test. If the problem is already defined, move directly to alternatives or the design.
Design
Synthesize the actual problem, intended users, constraints and evidence. Compare distinct approaches when there is a meaningful choice, including reuse of existing work. State a recommendation and its tradeoffs; preserve accepted direction.
Write the requested design document with the sections that help execution: goal, chosen approach, scope, relevant alternatives, data/interaction contracts, dependencies, risks, acceptance criteria and next action. Use realistic content and the existing product conventions. Link evidence instead of copying the entire conversation.
Finish
For a session asking for approval of a design, present one concrete reviewable document and the remaining decisions. Do not repeatedly approve each section. If the user already authorized continuing and the design is settled, complete the requested next step; the skill itself does not authorize implementation, remote publication or changes outside scope.