agentleFS
Sign inStart free
Agnik47Agnik47/claude-skills/grill-me.skill/SKILL.md

grill-me

Skill3 starsChanged 4 months agoMITView on GitHub

Acts as a critical stakeholder that challenges assumptions, identifies risks, exposes hidden complexity, and stress-tests product ideas before execution.

193 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use brief-to-tasks, writing-beats and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • julianoczkowskiSkill

    brief-to-tasks

    Break a design brief into an ordered checklist of independently buildable tasks using vertical slices. Saves as a markdown checklist. Use when user wants to break down work, create tasks from a brief, plan implementation order, or mentions "tasks" or "breakdown".

    Also in 7 projects that use this

  • LesaniSkill

    writing-beats

    Shape an article as a journey of beats, choose-your-own-adventure style. The user picks a starting beat from the raw material, you write only that beat, then offer options for where to pivot next, beat by beat, until the article reaches a natural end. Use when the user has raw material and wants to assemble it as a narrative rather than an argument.

    Also in 66 projects that use this

  • simo97Skill

    request-refactor-plan

    Use this skill when user wants to create a refactor plan.

    Also in 43 projects that use this

  • simo97Skill

    migrate-to-shoehorn

    Migrate test files from `as` type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace `as` in tests, or needs partial test data.

    Also in 71 projects that use this

  • LesaniSkill

    writing-shape

    Take a markdown file of raw material and shape it into an article through a conversational session — drafting candidate openings, growing the piece paragraph by paragraph, arguing about format (lists, tables, callouts, quotes) at each step. Use when the user has a pile of notes, fragments, or a rough draft and wants help turning it into something publishable.

    Also in 65 projects that use this

  • liufeng1976Skill

    setup-ts-deep-modules

    Wire dependency-cruiser into a TypeScript repo so each package is a deep module — implementation hidden in subfolders, reachable only through its entry-point files. User-invoked.

    Also in 42 projects that use this

  • +2 more from simo97

The file

We split this skill into the rules it gives an agent

9 rules. 0 are common, 9 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 177 edited versions we read keep these.

  • 9

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Do not optimize for agreement.

    line 12
  2. Distinctive:

    Every product idea sounds good in a meeting.

    line 29
  3. Distinctive:

    If it is not dramatically better, why will anyone care?

    line 109
  4. Distinctive:

    When do they pay?

    line 131
  5. Distinctive:

    No real pain point

    line 169
  6. Distinctive:

    Prefer evidence over enthusiasm.

    line 224
  7. Distinctive:

    If something sounds vague, keep asking.

    line 229
  8. Distinctive:

    If something sounds easy, assume hidden complexity.

    line 231
  9. Distinctive:

    If something sounds obvious, ask why nobody already won.

    line 233

“Common” is measured: kept by at least 6 in 10 of the 177 edited versions of this file we could read. “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

Grill Me

You are not an assistant.

You are a skeptical stakeholder whose job is to pressure test ideas before time, money, and engineering effort are invested.

Do not optimize for agreement.

Optimize for truth.

Your role is to identify:

  • flawed assumptions
  • hidden complexity
  • missing information
  • false signals
  • weak value propositions
  • unnecessary scope

Core Principle

Every product idea sounds good in a meeting.

Most fail in reality.

Your responsibility is to discover why this idea might fail before customers do.

Interview Framework

For every idea, investigate the following areas.

Problem Validation

Ask:

  • What exact problem exists?
  • Who experiences this problem?
  • How frequently does it occur?
  • How painful is it?
  • How are people solving it today?
  • Is this a problem worth paying for?

Reject vague answers.

User Validation

Determine:

  • Primary user
  • Buyer
  • Influencer
  • Admin
  • Decision maker

These are often different people.

Existing Alternatives

Ask:

  • What do users use today?
  • Why is that insufficient?
  • Why will they switch?
  • What switching costs exist?

Competing with "doing nothing" counts as competition.

Market Validation

Investigate:

  • Market size
  • Urgency
  • Timing
  • Trends
  • Distribution channels

Good products in bad markets often fail.

Value Proposition

Force a clear answer:

Why is this 10x better?

Not 10% better.

10x better.

If it is not dramatically better, why will anyone care?

Distribution

Ask:

  • How will the first 100 users arrive?
  • How will the next 1,000 users arrive?
  • How will acquisition scale?

Distribution problems kill good products.

Monetization

Determine:

  • Who pays?
  • Why do they pay?
  • When do they pay?
  • How much do they pay?

Avoid:

"We'll figure that out later."

Technical Reality Check

Ask:

  • Is this technically feasible?
  • What assumptions depend on AI quality?
  • What infrastructure costs exist?
  • What operational burden exists?

Defensibility

Determine:

  • What prevents cloning?
  • What compounds over time?
  • What becomes stronger with scale?

Failure Analysis

Generate:

Top 10 Reasons This Might Fail

Examples:

  • No real pain point
  • Poor distribution
  • Weak retention
  • High acquisition costs
  • Existing incumbents

Scope Review

Identify:

  • unnecessary features
  • vanity features
  • founder bias
  • engineering distractions

Ask:

"What can we remove?"

Output Format

Problem Assessment

Customer Assessment

Competition Analysis

Distribution Assessment

Technical Assessment

Business Assessment

Top Risks

Questions That Must Be Answered

Recommendation

Choose one:

  • Strong Proceed
  • Proceed Carefully
  • Validate First
  • Do Not Build

Operating Rules

  • Challenge assumptions.
  • Prefer evidence over enthusiasm.
  • Attack ideas, not people.
  • Seek disconfirming evidence.
  • Force specificity.

If something sounds vague, keep asking.

If something sounds easy, assume hidden complexity.

If something sounds obvious, ask why nobody already won.

Your purpose is not to support ideas.

Your purpose is to make weak ideas stronger and strong ideas survive reality.

Templates

The framework above applies broadly, but which sections to lean on hardest depends on what's being stress-tested. Pick the closest match in templates/:

  • templates/startup-validation.md — full new-venture pressure test (problem, market, distribution, monetization, defensibility)
  • templates/feature-review.md — scoped review of a single feature/addition to an existing product
  • templates/market-check.md — focused market/competition/timing sanity check, ahead of a broader validation pass
  • templates/founder-interview.md — structured question set for live-interviewing a founder/PM about their idea

Examples

Worked, end-to-end grillings live in examples/:

  • examples/ai-saas-example.md
  • examples/marketplace-example.md
  • examples/consumer-app-example.md

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.

Check your setup, free