Menu
Use for genuinely open, load-bearing product or architecture decisions after inspecting the project.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | brainstorming |
| description | Use for genuinely open, load-bearing product or architecture decisions after inspecting the project. |
Use brainstorming when product behavior, architecture, interaction design, a contract, or another load-bearing choice remains genuinely open after inspecting the project. The goal is to resolve uncertainty that would otherwise change the construction path or user-visible result.
Do not create a separate design ceremony for a specified local change with one reasonable path. Explain why that path is determined, then implement directly.
Explain a real choice through the overall project architecture, the logical relationship between modules, construction consequences, and the product or operational behavior affected. Use an accessible analogy when it clarifies the relationship. Do not lead with code symbols unless the user asks for code detail or an identifier is needed to explain a blocker.
For an unresolved load-bearing decision, present one coherent approval request that covers the decision, trade-offs, and consequences. Do not split a single approval into repeated process gates.
Before recommending or taking commit, push, branch, or worktree actions, inspect the current context for an existing preference. Ask once when the preference is absent and the choice changes the workflow. Never push without clear authority.
Write a design document when it provides durable value for multi-step execution, handoff, or future maintenance. A brief determined change does not need one.
After approval, choose the lightest suitable execution path for the task shape:
Keep the decision connected to the product outcome during implementation rather than turning the design into a second set of ceremony requirements.
When a visual question would be clearer as a mockup, diagram, or layout comparison, offer the visual companion then. Keep conceptual requirements and textual trade-offs in the conversation when a visual surface adds no clarity.
Consult after receiving review feedback and before implementation when the feedback needs evidence-based evaluation.
Consult before delegating implementation when an approved plan benefits from worker context isolation and durable coordination.
Consult before attempting a fix when root cause or behavior is unclear, failures repeat, components interact, or guessing would be unsafe.
Consult before implementing an observable behavior change when a meaningful automated test seam exists; use proportional red-green evidence.
Consult directly matching task playbooks before substantial design, debugging, implementation, review, or completion work without forcing full workflow execution.
Consult before making a substantive completion claim; require current trustworthy evidence and semantic acceptance.
