interview
Skill453 starsChanged 4 months agoApache-2.0View on GitHub
Interview you one question at a time, each choice with a recommendation, to settle a big outcome before agents work alone. Use when: asked to interview you about a goal or plan.
94 other projects use a version of this.
Adopted by
Most recently taken up by
- chrisdesmondSML/chris-skillstheir own version, first seen Nov 8, 2026
- Firzus/agent-skillstheir own version, first seen Nov 8, 2026
- claude-code-hardened/claude-code-hardenedtheir own version, first seen Nov 8, 2026
- MMACABRE/SKILLStheir own version, first seen Nov 8, 2026
- yuri-xyz/skillstheir own version, first seen Nov 8, 2026
- codewhale-hq/codewhale-plugin-marketplacetheir own version, first seen Nov 8, 2026
Used with
Projects with it also use fetch-library-docs, contributor 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.
Rehan-Ul-HaqSkillfetch-library-docs
Fetches official documentation for external libraries and frameworks (React, Next.js, Prisma, FastAPI, Express, Tailwind, MongoDB, etc.) with 60-90% token savings via content-type filtering. Use this skill when implementing features using library APIs, debugging library-specific errors, troubleshooting configuration issues, installing or setting up frameworks, integrating third-party packages, upgrading between library versions, or looking up correct API patterns and best practices. Triggers automatically during coding work - fetch docs before writing library code to get correct patterns, not after guessing wrong.
Also in 4 projects that use this
NimbleBrainIncSkillcontributor
Get started contributing to NimbleBrain open source — find an integration to build, set up your environment, propose an idea, or check on your work. Use when onboarding as a contributor. Triggers include "I'm a new contributor", "what should I build", "show me open issues", "file an issue".
Also in 3 projects that use this
mjunaidcaSkillbrowsing-with-playwright
Browser automation using Playwright MCP. Navigate websites, fill forms, click elements, take screenshots, and extract data. Use when tasks require web browsing, form submission, web scraping, UI testing, or any browser interaction. NOT when only fetching static content (use curl/wget instead).
Also in 4 projects that use this
qa-amanSkillteach-me
Teach a topic, video, article, codebase change, spec, or transcript until the user demonstrably understands it, using staged instruction, a running checklist doc, and quizzes. Use whenever the user says "teach me", "explain this in detail", "help me understand X", "/teach-me", "walk me through this", "I want to learn X", "understand this deeply", or pastes a YouTube URL, article, paper, PR, or spec and asks to understand it rather than summarize it. Also use when the user wants study notes or raw material from a source they are learning. Do NOT use for a quick factual lookup, a summary request, or when the user just wants the answer.
Also in 8 projects that use this
trebaudSkillfind-unknowns
Workflow for surfacing a task's unknowns before, during, and after implementation — blind spot pass, brainstorm/prototype, interview, references, implementation plan, deviation notes, quiz. Use when starting work in an unfamiliar domain or codebase, when a task feels underspecified, when the user says "find my unknowns", "blindspot pass", "what am I missing", "help me scope this", or when a long task came back wrong.
Also in 3 projects that use this
donatassimkusSkilloffer
Offer design, pricing strategy, and business model architecture. Invoke when asked about making an offer better, pricing a product or service, naming an offer, raising prices, generating fast cash, increasing lifetime value, finding the right customer, qualifying buyers, or designing a business model where customers pay for their own acquisition. Use when someone says their offer isn't converting, they need to charge more, they want to add bonuses or guarantees, or they need a money model for their business.
Also in 3 projects that use this
Other versions94 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 94
- claude-code-best/claude-code★ 23ksame name
- Q00/ouroboros★ 6.3ksame name
- Hisn00w/ASu-skills★ 6.1ksame name
- genkovich/sdd★ 187same name
- jvm-skills/jvm-skills★ 140same name
- kv0906/pm-kit★ 138same name
- tobieapb/claude-interactive-documentation-workflow★ 105same name
- panaversity/claude-code-skills-lab★ 57same name
- roman01la/skills-agents★ 48same name
- hiddenjobs/job-search-mcp★ 25same name
84 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository32 other files it gives its agents.
- AGENTS.mdAGENTS.md
- cli/AGENTS.mdAGENTS.md
- agent-nativeSkill
- agy-nativeSkill
- architectureSkill
- claude-execSkill
- codex-execSkill
- councilSkill
- craft-goalSkill
- docSkill
- domainSkill
- ergonomicsSkill
- idea-genieSkill
- implementSkill
- memorySkill
- navigateSkill
- orchestrateSkill
- planSkill
- postmortemSkill
- premortemSkill
- refactorSkill
- researchSkill
- reverse-engineerSkill
- reviewSkill
- rpiSkill
- securitySkill
- skill-builderSkill
- skill-evalSkill
- testSkill
- triageSkill
- using-gcSkill
- validateSkill
The file
We split this skill into the rules it gives an agent
7 rules. 0 are common, 7 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 80 edited versions we read keep these.
7
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
- Distinctive: line 42
Pick the branch: Start with the outcome, then the open branch that most changes acceptance, scope or authority whose prerequisites are …
- Distinctive: line 44
Keep dependent choices open rather than inventing their prerequisites.
- Distinctive: line 50
Wait for the answer.
- Distinctive: line 51
Record: only what the caller decides, and a fact they supply as their report, not a decision.
- Distinctive: line 67
Never narrow what the caller asked for.
- Distinctive: line 96
When a word is vague, overloaded or has synonyms, ask which term the domain uses.
- Distinctive: line 131
Stop when the caller stops, the next question would only restate a settled answer, the work proves to be one slice (not when testing a held …
“Common” is measured: kept by at least 6 in 10 of the 80 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.
Files
Interview
Shape a big outcome with the caller, one question per turn, before agents run alone: you look up facts; the caller makes choices and supplies what only they know. Interview creates nothing new (no goal, bead or file), changes no status, claim or closure, and only appends notes to an existing intent source (Show the state). To test a plan, design or decision the caller already holds, see a held plan.
Each turn
- Look it up in the tracker, docs and code first. Ask the caller only for choices (outcome, proof, non-goals, authority, budgets, priorities, risk tolerance) and for facts no source holds: what they tried or ruled out, their outside systems, what their users already do. Ask such a fact openly, with no recommendation, before the choices that rest on it. If the caller contradicts a source, cite both and ask whether the source is stale or the caller wants a change.
- Pick the branch. Start with the outcome, then the open branch that most changes acceptance, scope or authority whose prerequisites are settled. Keep dependent choices open rather than inventing their prerequisites. After each answer, reconsider which choice can now be settled; a changed parent decision reopens only the answers that rely on it. Defer branches that cannot change the next action, with a condition for returning to them.
- Ask one question in this shape, so the caller can accept, amend or reject in one line; a fact question omits the recommendation and tradeoff. Wait for the answer.
- Record only what the caller decides, and a fact they supply as their report, not a decision. A skip stays open; "your call" accepts the recommendation shown.
Settled: <what the last answer decided, or nothing yet>. Open: <count>.
Q<n>: <the decision>. <the question, with 2 to 4 options when they exist>
My recommendation: <answer>, because <source or reason>.
Tradeoff: <the one cost that matters>Because "your call" turns the recommendation into scope, recommend only what the outcome needs. Add a criterion, safeguard, authority or budget the caller did not name only when the outcome fails without it or harm would land before anyone notices. Offer anything else costly to add later (stored data, a published interface, money, security) as an option, not as the recommendation. Never narrow what the caller asked for. Draw budget and authority options from a source (prior goals, the tracker, the caller's words); with none, ask openly.
Answerer
The caller answers by default. On request ("let a council answer my interview"), a council answers through Council's interview-panel mode; the caller accepts or amends its answers in one pass before anything is recorded, and authority, budgets and acceptance changes stay the caller's. Fact questions stay with the caller in this mode; the council answers only choices. If only another person can answer, keep the choice Open and offer a questionnaire for that person. The caller sends it; Interview contacts no one.
BDD: acceptance as examples
Drive each criterion to a Given/When/Then with an observable result and its proving evidence. Draft the example yourself as the recommendation; the caller accepts or edits it. "Works reliably" is not acceptance; ask what would be seen.
Given a Job has already completed
When the worker receives that Job again
Then it returns the completed result without a second side effect
# Proof: a redelivery test asserts one side effect and the completed resultDDD: one term per concept
When a word is vague, overloaded or has synonyms, ask which term the domain uses. Record one term with a one-line definition and use only it in examples, notes, code and tests. Domain owns deeper modeling.
Show the state
Show these lists on request, after a revision and at stop:
- Decided: each choice; acceptance carries its Given/When/Then and proof. A fact the caller supplied appears here labeled as their report.
- Terms: each settled term with its one-line definition.
- Open: unanswered choices, most consequential first.
- Deferred: choices that change no next decision, and what revives them.
Number each choice Q<n> when first listed. As an item changes, Open and
Deferred included, append its line to the intent source (root epic, issue or
conversation) if the request or existing authorization covers editing it (the
conversation always does); otherwise show it for the caller to append. The
last line per Q<n> or term is current. Before treating acceptance as frozen by
a running goal, confirm its current state from the native goal runtime or the
caller. A saved Navigate checkpoint or open child build beads alone do not
establish a running goal. If that state is unknown and matters to the proposed
update, ask. While a goal runs, append no changed criterion or term; list it
under Open in the conversation
as an acceptance change for the caller to hold and re-craft. In BD:
bd context --json # confirm the destination before any write
bd show <epic-id> # on resume: the last line per Q<n> or term; start from Open
bd update <epic-id> --append-notes "decided Q<n>: <choice> | example: <Given/When/Then> | proof: <evidence>"
# or: "fact Q<n>: <report>" "term: <word> = <definition>" "open Q<n>: <choice>" "deferred Q<n>: <choice> | revive when <condition>"Stop and hand off
Stop when the caller stops, the next question would only restate a settled answer, the work proves to be one slice (not when testing a held plan), or everything Craft Goal admission needs is settled:
- outcome, and non-goals the caller named or rejected;
- terminal acceptance, each criterion with its proving evidence;
- authority: reads, writes, external effects, Git, and when agents must ask;
- numeric wave and goal budgets and the HOLD threshold;
- the first falsifiable question;
- the tracker the goal runs on and its root epic, or that the first wave creates it.
While the caller is still here, test the settled answers once. Then hand over the lists; the caller starts the next step: Craft Goal for several related experiments, RPI or Plan for one outcome with items 1 to 3 and real bounds. Open items stay open; never fill one to finish.
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.

