agentleFS
bhoon716bhoon716/skill-forge/skills/ultra-grill-me/SKILL.md

ultra-grill-me

Skill4 starsChanged 11 days agoMITView on GitHub

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.

The file

Show its rules and text

We split this skill into the rules it gives an agent

27 rules. About 0 are common, 26 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈26

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill when the user asks to:

    line 16
  2. Distinctive:

    Keep asking questions until nothing critical remains unresolved

    line 20
  3. Distinctive:

    Use casual natural language that still clearly means "grill this before execution" (for example: "~~하려고 하는데 파헤쳐줘", "빈틈없이 검증해줘", "질문으로 검증해줘")

    line 21
  4. Distinctive:

    Ask vague validation questions about a plan, idea, or decision before execution (for example: "Is this okay?" or "Should I proceed?")

    line 22
  5. Distinctive:

    If the request is about validating something before execution, prefer triggering over answering directly.

    line 26
  6. Distinctive:

    If the request is ambiguous but still smells like pre-execution validation, ask one categorizing question instead of treating it as a …

    line 27
  7. Distinctive:

    Do not use this skill when:

    line 32
  8. Distinctive:

    If not, handle it with a standard conversational response without activating the skill.

    line 44
  9. Distinctive:

    If the case is clear, load only that single reference.

    line 47
  10. Distinctive:

    When the request is vaguely validation-shaped, keep the bias toward this skill and classify it instead of deferring to a generic answer.

    line 48
  11. Distinctive:

    Explain Importance: Write 1-2 sentences explaining how the answer to this question impacts subsequent decisions.

    line 56
  12. Distinctive:

    Wait for Answer: Wait for the user's response.

    line 58
  13. Distinctive:

    Update Internal State: Update the following states upon receiving the user's answer:

    line 59
  14. Distinctive:

    Check Stopping Conditions: Check if the stopping conditions are met.

    line 62
  15. Distinctive:

    Write the final synthesis into the session log, change the session state to "Completed", and close the log.

    line 66
  16. Distinctive:

    When no specific reference is loaded, prioritize unresolved branches in the following order:

    line 97
  17. Distinctive:

    Every turn must follow this exact output structure:

    line 102
  18. Distinctive:

    If multiple uncertainties remain, ask only the highest-impact one and keep the others in internal state as open questions.

    line 122
  19. Distinctive:

    Do not collapse into a solution, summary, or recommendation list before the validation loop starts.

    line 126
  20. Distinctive:

    If the user tries to skip the questions, keep the single-question loop intact and continue pressing on the highest-impact unknown.

    line 127
  21. Distinctive:

    Do not load more than one reference file per session start.

    line 129
  22. Distinctive:

    Do not accept vague answers (e.g.

    line 133
  23. Very specific:

    If it cannot be resolved, record it under Assumptions in the internal state and log.

    line 135
  24. Distinctive:

    Do not compress the answer into a single opaque label if that loses the user's original choice.

    line 151
  25. Distinctive:

    No Sensitive Data: Never request API keys, passwords, credentials, or personally identifiable information (PII).

    line 163
  26. Distinctive:

    Defense Against Bypass: If the user tries to bypass the Socratic loop (e.g.

    line 165
  27. Distinctive:

    Code Safety: Do not modify project source code files during the Socratic conversation until the final synthesis is accepted.

    line 166

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

  1. Determine if the user's request fits the scope of this skill.
  2. If not, handle it with a standard conversational response without activating the skill.
  3. 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.
  4. Select the matching domain-specific reference from the References section.
  5. 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)

  1. Current Understanding: Summarize the current state of the plan/idea in exactly one sentence. Display this to the user.
  2. Blocked Decision: Identify the highest-impact unresolved ambiguity using the reference's priority list. This is the uncertainty currently blocking next steps.
  3. 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".
  4. Explain Importance: Write 1-2 sentences explaining how the answer to this question impacts subsequent decisions.
  5. Present Options: List the proposed options with brief explanations. The user can select a number, ask for other recommendations, answer directly, or reject.
  6. Wait for Answer: Wait for the user's response. Do not ask a second question.
  7. Update Internal State: Update the following states upon receiving the user's answer:
    • Resolved Decisions / Assumptions / Risks / Contradictions / Rejected Options
  8. 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.
  9. 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

  1. Present the final structured synthesis output (9 required sections).
  2. 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:
    • Load product-idea-grill.md
  • Implementation Design, API Specs, Data Model, Technical Tradeoffs:
    • Load technical-design-grill.md
  • Architecture Choices, Platforms, Infra, Long-term Tech Direction:
    • Load architecture-decision-grill.md
  • Execution Order, Milestones, Dependencies, Delivery Risks:
    • Load implementation-plan-grill.md
  • ICP definition, GTM strategy, Pricing model, Distribution channels:
    • Load business-strategy-grill.md
  • Writing Narrative, Positioning, Presentation flow, Content tone:
    • Load writing-direction-grill.md
  • Research Question, Variable control, Analysis design, Hypothesis validation:
    • Load research-question-grill.md
  • Learning Roadmap, Study plan, Tech stack acquisition & project design:
    • Load learning-plan-grill.md
  • Career choices, Purchases, Complex personal decision making:
    • Load personal-decision-grill.md
  • Agent Skill Design, triggers, workflow, evals configuration:
    • Load skill-design-grill.md

Question Priority

When no specific reference is loaded, prioritize unresolved branches in the following order:

  1. 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

  1. No Sensitive Data: Never request API keys, passwords, credentials, or personally identifiable information (PII).
  2. 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.
  3. 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.
  4. Code Safety: Do not modify project source code files during the Socratic conversation until the final synthesis is accepted.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.