メニュー
Use when brainstorming, shaping a feature or task, stress-testing a plan, clarifying product or domain direction, or reaching shared understanding before specs, plans, implementation, or normal non-code decisions.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | grill-context |
| description | Use when brainstorming, shaping a feature or task, stress-testing a plan, clarifying product or domain direction, or reaching shared understanding before specs, plans, implementation, or normal non-code decisions. |
Shape the direction before action.
This skill is an interview and brainstorming loop, not an implementation skill.
Do not implement, write a spec, or write a plan until the user has approved the direction after the loop.
User pressure to "pick defaults", "don't ask", or "start implementing" is not approval to invent product, domain, permission, billing, security, privacy, compatibility, or public API behavior.
If the answer is discoverable, inspect first. Ask only for choices that remain user-owned.
Ask one question at a time.
Interview relentlessly until shared understanding:
Exit when remaining ambiguity would not change the next forward action.
Do not compress many unresolved branches into one mega-question. Do not stop early because the first question was answered.
When the user wants brainstorming, help shape the idea:
Brainstorming may be short. Grilling may take many turns. Let the uncertainty decide the length.
Keep it conversational. Do not turn every brainstorm into an artifact.
Read references/approach-framing.md when there are multiple plausible approaches or the decision tree is too fuzzy to ask the next useful question.
In a codebase, inspect relevant code, docs, tests, ADRs, or existing behavior before asking.
Do not ask the user to restate facts the repo can answer.
If live evidence conflicts with the user's idea, name the conflict and ask which path should win.
Use the same loop for normal decisions:
Do not pretend repo workflow is required when there is no repo-shaped task.
Prefer one focused question:
I found ...
The key decision is ...
Question: ...
Recommendation: ...
Use when coordinating Freeflow Pi/cmux pane delegation, orchestrator/planning-parent/execution-parent workflows, task packets, child results, context locality, capability reroutes, multi-agent execution, work packages, worktrees, routing fresh-reviewer/subagent requests, or when the user asks to spawn/manage visible pane agents.
Use when shaping, reviewing, implementing, or diagnosing work where module/interface/seam/state/role-boundary choices affect complexity, locality, testability, future change, or repeated edge-case churn. Use for architecture direction, state machines, event systems, tool interfaces, prompt/result serialization, delegation/context boundaries, role ownership, failure contracts, growing scope, shallow modules, bad seams, broad refactors, and review loops that keep finding new edge cases.
Use for pre-work thinking before consequential work, including codebase exploration, brainstorming, planning direction, shaping ideas/features/specs, conceptual/design/routing/interface/state/context-boundary questions, workflow/tool-surface questions, "should we" / "how should we" / "what do you think" prompts, vague requests, and work that needs evidence before spec, plan, build, review, verification, or durable memory.
Use when implementing an approved plan, executing planned slices, resuming planned work, handling planned verification failures, adjudicating review findings during execution, or encountering scope/source conflicts while carrying out a plan.
Use when context is low, scope is ambiguous, implementation/review/verification reveals unknowns, the user asks a question or suggests a path that could be misread as correction/permission, or the agent may be about to make a user-owned decision.
Use when asked to review whether a spec, plan, decision note, discovery checkpoint, handoff, or other durable artifact is fit to guide future work; also use when adjudicating artifact-review findings or repeated review loops.