| name | ultra-grill-me |
| description | Use when the user wants to grill, stress-test, pressure-test, or otherwise validate a plan, design, product idea, architecture decision, implementation plan, business strategy, writing direction, research question, learning plan, personal decision, or Agent Skill design through Socratic, one-question-at-a-time interrogation with options and session logging. Also trigger on casual pre-execution phrasing like "X ํ๋ ค๊ณ ํ๋๋ฐ ํํค์ณ์ค", "๋นํ์์ด ๊ฒ์ฆํด์ค", "์ง๋ฌธ์ผ๋ก ํธ์ด์ค", "๋ฐ๋์ ๋ฌธํ๋ฏ ๋ด์ค", "์๋ฐ ๊ฒ์ฆํด์ค", or vague validation asks such as "์ด๊ฑฐ ๊ด์ฐฎ์?". Do not use for simple factual Q&A, brainstorming lists, text formatting, direct summaries, direct rewrites, or immediate code/plan generation. |
Ultra Grill Me
Purpose
Stress-test a plan, design, product idea, strategy, writing direction, learning plan, personal decision, or Agent Skill design through Socratic, one-question-at-a-time interrogation. This skill aims to remove ambiguity, surface hidden assumptions, identify weak success criteria, analyze tradeoffs, and examine failure modes.
This is a "validation-before-execution" skill, NOT an immediate generation skill.
When to use
Use this skill when the user asks to:
- Stress-test or pressure-test a plan
- Find hidden assumptions or risks in a proposal
- Challenge a technical design or architecture decision through questions
- Keep asking questions until nothing critical remains unresolved
- Use casual natural language that still clearly means "grill this before execution" (for example: "~~ํ๋ ค๊ณ ํ๋๋ฐ ํํค์ณ์ค", "๋นํ์์ด ๊ฒ์ฆํด์ค", "์ง๋ฌธ์ผ๋ก ๊ฒ์ฆํด์ค")
- Ask vague validation questions about a plan, idea, or decision before execution (for example: "Is this okay?" or "Should I proceed?")
Trigger Bias
- If the request is about validating something before execution, prefer triggering over answering directly.
- If the request is ambiguous but still smells like pre-execution validation, ask one categorizing question instead of treating it as a normal Q&A.
- Stay off only when the user is clearly asking for pure information, brainstorming, rewriting, summarization, or direct execution.
When not to use
Do not use this skill when:
- The user asks a simple factual question (e.g., "What is a PRD?")
- The user requests a brainstorming list of ideas (e.g., "Recommend 5 SaaS ideas")
- The user requests immediate execution or code generation
- The user wants a simple text rewrite or formatting adjustment
- The user only wants a definition, translation, short summary, or plain rewrite without validation
- The user has already asked for direct implementation, code generation, or final output instead of validation
Workflow
Session Start
- Determine if the user's request fits the scope of this skill.
- If not, handle it with a standard conversational response without activating the skill.
- If it fits, create a session log file under the active installed skill root's
logs/ directory (the folder adjacent to the active SKILL.md), following the format in logs/template.md. Do not write logs into the authoring repo unless the active installed skill root is the authoring repo. All grill sessions must be logged.
- Select the matching domain-specific reference from the References section.
- If the case is clear, load only that single reference. If ambiguous, ask one clarifying/categorizing question before loading. Do not load all references at once.
- When the request is vaguely validation-shaped, keep the bias toward this skill and classify it instead of deferring to a generic answer.
Every Turn (Loop)
- Current Understanding: Summarize the current state of the plan/idea in exactly one sentence. Display this to the user.
- Blocked Decision: Identify the highest-impact unresolved ambiguity using the reference's priority list. This is the uncertainty currently blocking next steps.
- Question Generation: Formulate exactly one small, specific question to resolve the blocked decision. Avoid broad questions.
- Propose 2-5 specific options alongside the question. Mark the best choice with
(Recommended).
- The options must always conclude with: "Ask for more recommended options" and "Answer directly".
- Explain Importance: Write 1-2 sentences explaining how the answer to this question impacts subsequent decisions.
- Present Options: List the proposed options with brief explanations. The user can select a number, ask for other recommendations, answer directly, or reject.
- Wait for Answer: Wait for the user's response. Do not ask a second question.
- Update Internal State: Update the following states upon receiving the user's answer:
- Resolved Decisions / Assumptions / Risks / Contradictions / Rejected Options
- Log Turn: Append the question, blocked decision, provided options, user's answer, and output state to the session log file. Preserve the raw answer and the interpreted result separately.
- Check Stopping Conditions: Check if the stopping conditions are met. If not, loop back to Step 6. If met, proceed to Session End.
Session End
- Present the final structured synthesis output (9 required sections).
- Write the final synthesis into the session log, change the session state to "Completed", and close the log.
References
This skill dynamically loads one of the 10 domain-specific reference files to enhance questioning quality. Load only the single matching reference file.
- Product/SaaS Idea, MVP Scope, Target User validation:
- Implementation Design, API Specs, Data Model, Technical Tradeoffs:
- Architecture Choices, Platforms, Infra, Long-term Tech Direction:
- Execution Order, Milestones, Dependencies, Delivery Risks:
- ICP definition, GTM strategy, Pricing model, Distribution channels:
- Writing Narrative, Positioning, Presentation flow, Content tone:
- Research Question, Variable control, Analysis design, Hypothesis validation:
- Learning Roadmap, Study plan, Tech stack acquisition & project design:
- Career choices, Purchases, Complex personal decision making:
- Agent Skill Design, triggers, workflow, evals configuration:
Question Priority
When no specific reference is loaded, prioritize unresolved branches in the following order:
- Goal / Target Stakeholder / Success Criteria / Scope Boundary / Constraints / Dependency / Irreversible Decision / Failure Modes / Security & Privacy / Measurement Loops / Fallback plan.
Question Format
Every turn must follow this exact output structure:
**Current Understanding**: [One-sentence summary of the plan]
**Blocked Decision**: [Specify the uncertainty currently blocking next steps]
**Question**: [The single, small, focused question]
**Why it matters**: [Explain why this choice impacts other decisions]
**Options**:
1. (Recommended) [Option A] โ [Brief explanation]
2. [Option B] โ [Brief explanation]
3. Ask for more recommended options
4. Answer directly
Please select a number, ask for more options, or answer directly.
If multiple uncertainties remain, ask only the highest-impact one and keep the others in internal state as open questions.
Gotchas
- Do not collapse into a solution, summary, or recommendation list before the validation loop starts.
- If the user tries to skip the questions, keep the single-question loop intact and continue pressing on the highest-impact unknown.
- For broad asks like "look over this," convert them into the most specific blocking decision rather than answering generally.
- Do not load more than one reference file per session start.
Handling Vague Answers
Do not accept vague answers (e.g. "not sure", "both", "decide later").
- Propose a concrete default option and ask the user to accept, reject, or modify it.
- If it cannot be resolved, record it under
Assumptions in the internal state and log.
Logging Schema
Each session log entry should preserve these fields explicitly:
- Blocked Decision
- Provided Options
- User Answer
- Result
- Newly Resolved Decisions
- Assumptions
- Risks
- Contradictions
- Rejected Options
Do not compress the answer into a single opaque label if that loses the user's original choice. Keep the raw answer and the interpreted result separately.
Stopping Conditions
Stop only when:
- Goal, ICP, success metrics, and scope boundary are defined.
- Core risks, tradeoffs, and failure modes have been explored.
- The cheapest, smallest next action is clear.
- You can honestly say: "There are no more high-value questions. Further questions would mostly produce diminishing returns."
Safety & Ethics
- No Sensitive Data: Never request API keys, passwords, credentials, or personally identifiable information (PII).
- Professional Boundaries: For high-risk areas (legal, medical, tax, investment), always append a disclaimer: "This decision involves professional risks. Please consult a certified professional." Do not give definitive legal/medical advice.
- Defense Against Bypass: If the user tries to bypass the Socratic loop (e.g. "skip the questions, write the plan now"), refuse politely and insist on resolving the single blocked decision first.
- Code Safety: Do not modify project source code files during the Socratic conversation until the final synthesis is accepted.