Skip to content
skillsafebeta
← Report library
Purpose / Other

Interview Me Skill Security Audit

What the author says it does (original text)

Extracts what the user actually wants instead of what they think they should want. Achieves this through one-question-at-a-time interview until ~95% confidence about the underlying intent. Use when an ask is underspecified ("build me X" without "for whom" or "why now"), when the user explicitly invokes ("interview me", "grill me", "are we sure?", "stress-test my thinking"), or when you catch yours

Independent security check

Security risks found

Files checked
1
Risks found
2
Could it run dangerous commands?Looks for programs run straight after downloading, remote control of your computer, and hidden commands.No risks found
Could it expose your files or keys?Looks for uploads of files containing passwords or keys, and keys written directly in the code.No risks found
Could it delete files or keep running?Looks for broad file deletion, disk overwrites, and programs set to start automatically.No risks found
Could it bypass safety checks?Looks for skipped website security checks, excessive file access, or actions that skip your approval.No risks found
Could it mislead the AI or hide text?Checks the skill instructions for requests to ignore you, influence the report, or hide text in invisible characters.Risks found: 2
Medium risk

Mandatory confirmation rules may disregard a user's attempt to end the interview or authorize progress

Source references: 3
What we found

The workflow rejects “Sounds good,” “Sure, let's go,” and an instruction to start as confirmation, requiring repeated restatement until it receives its preferred form of explicit “yes.” This substitutes the Skill's subjective confirmation standard for the user's control over pace and authorization.

Why this matters

Even when the user is ready to proceed, the agent may block planning or implementation, continue questioning, and pressure the user to use the Skill's required wording merely to exit the loop.

This is an active process requirement, not merely an example: even after “Sounds good,” “Sure, let's go,” or “okay let's start,” the agent is told to keep probing until it receives the Skill’s preferred form of explicit confirmation. If the user intends to end the interview and authorize progress, this can delay work and substitute the agent’s interpretation of wording for the user’s control of the interaction. The several-round stopping rule limits the risk, so the evidence supports friction and autonomy concerns, not an endless loop. Users can ask the author to accept clear proceed instructions or impose a question limit.

SKILL.md:115In the instructionsOpen original file
The gate is an explicit "yes." The following are **not** yes:- "Whatever you think is best." → The user is delegating, which means they don't have 95% confidence either. Re-ask with two concrete options framed as a choice.- "Sounds good." → Ambiguous. Ask: "Anything you'd refine?" Silence isn't confirmation.- "Sure, let's go." → Often a polite exit, not an endorsement. Same follow-up.- Silence followed by "okay let's start." → The user has given up on the interview, not converged. Stop and ask whether you've missed something.
Show 2 other places
SKILL.md:122In the instructionsOpen original file
If they correct you, fold the correction in and restate. Loop until you get an explicit yes.
SKILL.md:132In the instructionsOpen original file
This is a checkable test, not a vibe. It also has a floor: if you've gone several rounds and still can't predict, that's information about the ask, not a reason to keep grinding. Stop and tell the user: "I've asked X questions and I still can't predict your reactions. Something foundational is missing. Want to step back?"
Medium risk

Deliberately leading guesses can anchor the user's decisions

Source references: 4
What we found

The Skill requires every question to include the agent's guess and recommends occasionally guessing in a direction where pushback is expected; it also states that “Leading is the point.” Although it acknowledges agreement bias, the design still introduces the agent's chosen framing before the user answers.

Why this matters

An agreeable, hurried, or less-experienced user may accept the suggested answer, producing a “confirmed intent” that reflects the agent's assumptions and then shapes downstream product or commercial decisions.

This is an active interview design: every question must include the agent’s proposed answer, the text explicitly says leading is intentional, and it recommends occasionally choosing a direction expected to provoke disagreement. That can anchor the user to the agent-selected framing or options, especially when the user is inclined to agree. The Skill recognizes and tries to mitigate acquiescence, but that does not remove the influence of presenting the guess first. Users can ask for neutral questions first, optional guesses, or a chance to state their own answer before seeing the agent’s hypothesis.

SKILL.md:71In the instructionsOpen original file
**Why attach a guess:**- The user reacts faster to a wrong guess than they generate an answer from scratch- It commits you to a hypothesis you can be visibly wrong about, which keeps you honest- It surfaces *your* assumptions, which is what the interview is meant to exposeThe risk here is a polite user agreeing with your guess to be agreeable. Mitigate by being visibly willing to be wrong, and occasionally guess in a direction you expect the user to push back on.
Show 3 other places
SKILL.md:197In the instructionsOpen original file
| "I should give them several options to pick from" | Options work when the user knows what they want and is choosing between trade-offs. They don't know what they want yet. Listing options widens the search; asking narrows it. || "If I attach my guess, I'm leading them" | Leading is the point. Reacting is faster than generating from scratch. The risk is sycophancy, not leading; mitigate by being visibly willing to be wrong. || "We've talked enough, I get it" | Test it: can you predict their reaction to the next three questions? If not, you don't get it yet. |
SKILL.md:53In the instructionsOpen original file
### Step 2: Ask one question at a time, each with a guess attachedFormat:```Q: <one focused question>GUESS: <your hypothesis for the answer, with the reasoning that produced it>```
SKILL.md:73In the instructionsOpen original file
- The user reacts faster to a wrong guess than they generate an answer from scratch- It commits you to a hypothesis you can be visibly wrong about, which keeps you honest- It surfaces *your* assumptions, which is what the interview is meant to exposeThe risk here is a polite user agreeing with your guess to be agreeable. Mitigate by being visibly willing to be wrong, and occasionally guess in a direction you expect the user to push back on.
Could it change links or payment recipients without asking?Looks for forced referral or payment changes combined with instructions to hide the change.No risks found

Inside this skill

8 instruction sections

The Skill first states a hypothesis and confidence level about the user's intent, then asks one question at a time and waits for each response.

View source
SKILL.md:42In the instructionsOpen original file
Before asking anything, write down your current best read of what the user wants in **one sentence**, plus an honest confidence number (0–100%):
SKILL.md:62In the instructionsOpen original file
Wait for the user to react before asking the next question.

It is limited to live interaction and explicitly says not to invoke it in CI, scheduled jobs, or autonomous loops; an underspecified request should instead be reported as blocked.

View source
SKILL.md:36In the instructionsOpen original file
This skill needs a live, responsive user. **Do not invoke in non-interactive contexts** like CI pipelines, scheduled runs, `/loop`, or autonomous-loop. If you're in one of those and the ask is underspecified, flag that as a blocker for the user instead of guessing.

Its deliverable is only a confirmed statement of intent, not a specification, plan, or code. It proposes saving that statement to docs/intent/[topic].md only after user confirmation.

View source
SKILL.md:136In the instructionsOpen original file
The output of this skill is a **confirmed statement of intent**: the restate from Step 4, with an explicit yes from Step 5. That's the deliverable. Specs, plans, and task lists are downstream; they consume the intent this skill produces.
SKILL.md:138In the instructionsOpen original file
If the user wants the intent to persist (a multi-session project, a handoff to another collaborator), offer to save it to `docs/intent/[topic].md`. Only save if they confirm.
Start here · InstructionsSKILL.md
interview-me
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source. 2 more sections are available in the original file.
Files and check records1 files

Coverage and gaps

Content covered in each file

These are the source ranges included in this check, not a guarantee that every issue has been resolved.

  • SKILL.mdFull text included

This report is for the version above. We read the available code and instructions without running the skill or checking extra packages it installs. This is not a promise of safety: a different version or setup may behave differently.

  • SKILL.mdInstructions
Lines read
226
File checksum (to compare versions)
3e0bdf9191031d473a584a423f63a1f35515b6f85d58895ff10f05d8e5222f2e