agentleFS
Sign inStart free
erendevelopserendevelops/erendev-claude-skills/idea-interrogator/SKILL.md

idea-interrogator

Skill2 starsChanged 3 months agoMITView on GitHub

Use when the user shares a new project/app/feature idea and wants critical feedback before building — validating scope, doability, time cost, purpose, expectations, or features. Use when they ask "should I build this", "is this worth doing", "grill me on this idea", or want a go/no-go read before writing a PRD.

The file

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    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:

    Before writing a PRD or starting implementation planning

    line 16
  2. Distinctive:

    Not for: refining an idea that's already been validated (use visual-identity or project-brief instead), or auditing existing shipped code.

    line 19
  3. Distinctive:

    Ask ONE question at a time, in this order, adapting wording to the idea:

    line 23
  4. Very specific:

    After the interview, write idea-interrogator-verdict.md to the current working directory with this structure:

    line 39

≈ “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

Idea Interrogator

Overview

A structured interrogation of a project idea, one question at a time, ending in a clear go/no-go verdict with reasoning. Same rigor as a standard project-grill session — not harsher, not softer. The verdict is always a recommendation, never a gate: the user decides whether to continue regardless of the call.

When to Use

  • User shares a new project/app/feature idea and wants it stress-tested
  • Before writing a PRD or starting implementation planning
  • User explicitly asks "should I build this", "is this worth it", "grill me"

Not for: refining an idea that's already been validated (use visual-identity or project-brief instead), or auditing existing shipped code.

Process

Ask ONE question at a time, in this order, adapting wording to the idea:

  1. Scope — what's actually included vs. explicitly out?
  2. Doability — what's the hardest unsolved part? Any dependency on unproven tech, unavailable data, or a skill the user doesn't have yet?
  3. Time / worthiness — how long realistically, and is the payoff worth that time given what else the user could do with it?
  4. Purpose — why this, why now? What breaks if it doesn't exist?
  5. Expectations — what does "done" look like? What does success look like a month after shipping?
  6. Features — what's the minimal version vs. the wishlist creep?

Push back on vague answers before moving to the next question — "faster" and "better" aren't answers, ask for a number or a concrete comparison.

Deliverable

After the interview, write idea-interrogator-verdict.md to the current working directory with this structure:

# Idea Interrogator Verdict: <project name>

## Verdict: GO | NO-GO | GO WITH CHANGES

<2-4 sentence reasoning tying back to the weakest answer from the interview>

## Captured Details
- **Scope:** ...
- **Doability risks:** ...
- **Time estimate / worth:** ...
- **Purpose:** ...
- **Success definition:** ...
- **Core features (MVP):** ...
- **Explicitly deferred:** ...

State the verdict plainly. Never tell the user they can't proceed — a NO-GO is information, not a block. If they want to continue anyway, that's their call.

Common Mistakes

  • Asking all 6 questions in one message — defeats the interrogation, ask one at a time and let answers inform follow-ups.
  • Softening the verdict to avoid disagreement — state the real read.
  • Skipping the output file — downstream skills (visual-identity, project-brief) rely on it being on disk under this exact filename.

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