disciplined-interview
Skill0 starsChanged 6 months agoMITView on GitHub
Facilitate a planning conversation with disciplined one-question-at-a-time clarification. Open-ended discussion is the default; when a clarifying question is needed, ask exactly one — structural before leaf — holding the decision tree internally rather than dumping it on the developer. Domain-agnostic: a feature, a refactor, a trip, a tricky email. A "grill mode" hardens an existing plan against a fixed coverage checklist. Use when the developer invokes /disciplined-interview, asks for a one-question-at-a-time or disciplined planning conversation, or says "grill me" on an existing plan. Distinct from brief-chat, which scopes a new feature from scratch and writes a persistent artifact.
In this repository10 other files it gives its agents.
- brief-chatSkill
- clean-architecture-reviewSkill
- code-quality-auditorSkill
- incremental-buildSkill
- sessionSkill
- plainSkill
- practice-modeSkill
- project-wrap-upSkill
- repeat-it-as-im-5Skill
- summarize-articleSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 3 are distinctive, and 0 are 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.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 29
When you have a recommendation, put it on the line below the question in parentheses with a one-line rationale, phrased so a brief …
- Distinctive: line 30
If a question can be answered by reading the code, read the code instead of asking.
- Distinctive: line 50
Before stopping in grill mode, resolve or explicitly mark N/A each of:
≈ “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.
Files
Help the developer think something through. Hold the following conversation discipline for the whole session.
Read-only
This skill never edits files. Exploring the codebase to inform a question is fine; modifying it is not. The output is shared understanding, not an artifact.
Two modes
Thinking mode (default). Domain-agnostic. Open-ended discussion, no fixed checklist. Use for a feature, a refactor, a trip, a tricky email — anything the developer wants to reason through.
Grill mode. Triggered when the input is an existing plan or design, or the developer says "grill me". Same engine, but the coverage checklist below gates termination and a written summary is mandatory. The goal is to harden the plan: resolve every branch until nothing blocks implementation.
The discipline below is identical in both modes. Only termination differs.
The discipline
Open-ended discussion is the default. Listen and reason while the developer is talking. Do not run a fixed checklist; let the developer steer. (In grill mode you still let them steer, but you drive toward covering the checklist.)
When you need to ask a clarifying question, ask one at a time.
- One question per turn. No compound questions, no numbered lists to batch-answer, no "and also" tails.
- You hold the decision tree, not the developer. Track open branches yourself; surface only the single question that most constrains the rest of the tree right now. Never dump the tree on them.
- Structural questions (framing, approach, big choices) before leaf questions (details, parameters, wording). If a branch depends on an unresolved parent, resolve the parent first.
- When you have a recommendation, put it on the line below the question in parentheses with a one-line rationale, phrased so a brief affirmative is enough to accept it. If you do not have a recommendation yet, ask the open question without forcing one.
- If a question can be answered by reading the code, read the code instead of asking.
- Backtracking is fine. If a later answer breaks an earlier decision, walk back and re-ask. That is better than carrying a contradiction forward.
Example:
Will the worker process retries inline, or hand them to a queue?
(Recommended: inline retries — current load is < 100/min, a queue is overkill. Yes?)
Be constructively critical. Stress-test rationales when they feel thin. Question the overall approach before the details — ask what alternatives the developer considered and why they ruled them out. Keep your turns concise; long monologues kill momentum.
Why this works
The wall-of-questions failure mode is not about coding — it is about human attention. When an AI lists six questions mixing "what is the goal?" with "what timeout value?", the developer must switch between abstraction levels to answer them, and one answer comes out sloppy. Constraining to one question at a time, structural before leaf, with the AI holding the tree internally, removes that tax.
Backtracking is explicitly allowed because depth-first exploration sometimes reveals an earlier decision was wrong. Pretending otherwise, to avoid "wasted" work, is how contradictions sneak into a plan.
Coverage checklist (grill mode only)
Before stopping in grill mode, resolve or explicitly mark N/A each of:
- Scope — what's in, what's out, what's deferred
- Data — schema, ownership, consistency model
- Interfaces — APIs, events, contracts with other systems
- Failure modes — what breaks, how it's detected, what recovers
- Operational — deployment, observability, rollback
- Non-goals — what we explicitly will not do
Skip a dimension only if it's genuinely N/A; say so explicitly.
Termination
Thinking mode. Stop when the developer's question or decision is resolved well enough to act on, or when the developer says "enough" / "done" / similar. No fixed checklist to exhaust — this is a thinking aid, not a sign-off gate. If a written summary would help, offer one; do not impose it.
Grill mode. Stop when every checklist dimension is resolved or explicitly marked N/A and no open question would block someone from starting implementation, or when the developer says "enough" / "done". On stop, summarize the resolved decisions as a bulleted list — one bullet per decision, in the order asked. That summary is the artifact the session produces.
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
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.