Interview me
A collection of rigorous, phase-isolated SDLC skills to tether autonomous agents to real-world engineering standards.
npx -y skills add NjoyimPeguy/augments --skill interview-meAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use whenever a request, plan, or design is unclear or underspecified — in any phase, before you build on it. Answers from the codebase first, asks only what it can't determine. Skip for trivial or already-precise requests.
SKILL.md
2.7 KB, as published. Nobody here has run it
Interview Me
Close the gap between what was asked and what is actually wanted — before you build on it. A cross-cutting clarification technique: grill a goal, a requirement, or a plan — the method is the same. The cheapest bug to fix is the one never built.
When to use
- A request is vague ("add auth", "make it faster") or has more than one reasonable reading.
- Assumptions are piling up before a plan or feature.
- Skip when the task is trivial or already fully specified — interrogating wastes turns.
- Skipping never licenses a silent decision. If the request leaves an open point you resolve yourself — a "maybe X?", a "not sure if I need that" — state the decision and your one-line reason in your reply so the user can redirect: decide-and-state, never decide-and-bury. "It's cheap to build" is the rationalization to catch — the cost is not the build, it is the user discovering you decided for them.
Procedure
1. Scan before you ask. Read the request, then explore the codebase and context for what is already decided: conventions, similar features, libraries in use, naming. Never ask what the code already answers.
2. Ask ONE question at a time. For each open decision, in one short message:
- state what you found ("you already use Zod for validation"),
- name the decision,
- recommend a default with one line of reasoning.
Prefer yes/no or a small multiple choice. Wait for the answer before the next question.
3. Use each answer to prune. An answer often settles later questions — drop them. Aim for ~3–6 questions total. If you need more, say why first.
4. Stop when another question would not change the outcome — or when the user says go. Do not gold-plate the interview.
5. Write a short alignment brief (not a spec): goal, decisions + rationale, explicit non-goals, open risks. Keep it tight — see references/brief-template.md. Save it to .augments/briefs/{{YYYY-MM-DD}}-{{topic}}.md (the standard briefs location; another path only if the user has set one), or keep it inline if it's tiny enough not to need a file.
6. Offer, do not force, the next step: "Turn this into a plan?" → writing-plans.
Common mistakes
- Asking what a 30-second code search would answer.
- Dumping many questions at once instead of adapting to answers.
- Producing a heavy spec — the brief is a short paragraph plus a few bullets.
- Interviewing trivial tasks.