メニュー
Clarify an ambiguous or consequential change before planning or implementation when more than one sound approach exists.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Compare Claude Code and Codex on the same real code-change task with isolated worktrees, identical gates, transcripts, time, and cost.
Align AGENTS.md, rules, README, plans, and chronicles with the codebase; use --clean to archive obsolete task docs into ATLAS.md.
Research current best practices and turn the evidence into a clear recommendation. Use for state-of-the-art, evidence-based, optimal-approach, comparison, or pros-and-cons questions in any field.
Add CHANGELOG.md entries, derive them from commits, or cut a Keep a Changelog and SemVer release.
Create a user-requested Conventional Commit from the staged changes.
Define or implement regression proof for a project or business flow. Use for test strategy, black-box or deep-integration tests, business KPIs and thresholds, test audits, missing tests, or test implementation.
| name | brainstorming |
| description | Clarify an ambiguous or consequential change before planning or implementation when more than one sound approach exists. |
| user-invocable | true |
| allowed-tools | Glob, Grep, Read, Bash, Task, AskUserQuestion, Skill |
If $ARGUMENTS is empty, ask what the user wants to explore and stop.
Inspect the repository before asking technical questions. State the current problem hypothesis, the observed facts behind it, and the unknowns that could change the result or proof.
Interview until both sides agree on why the change matters, what is in scope, what solved looks like, and how failure would be exposed. Ask one decision at a time, wait for the answer, and include your recommended answer with its trade-off. Facts come from exploration; decisions belong to the user.
Use best-practices when current external evidence can change the choice. Create a research file only when the result will remain useful after this task.
Offer alternatives only when they are genuinely different. Recommend the simplest one that meets the agreed result and company/project constraints.
Do not plan or implement until the shared understanding is explicit. A detailed request or prior spec is a stronger trigger, not an exemption — it fixes the WHAT, not the HOW. For data models and system boundaries, resolve identity, cardinality, lifecycle, ownership, time, and derivation before choosing a schema. Then return it to the full development loop, which gates implementation on explicit plan approval.
