메뉴
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 직업 분류 기준
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.
| 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: ...