Answer Before Asking

An agent that stops to ask "which validation library does this project use?" when the answer is in package.json has not been careful — it has been lazy in a way that looks careful. Each question costs a context switch, and a question the repository could have answered spends the user's attention on nothing.

The standard this skill enforces: given what is in this repo, would a senior engineer think that question was reasonable to ask? If not, the chain below was not run.

The chain

Run these in order. Stop at the first clear answer. Most questions die at step 1 or 2.

1. The tests. They are the specification nobody reads. What a function is supposed to do is asserted somewhere, usually more precisely than the docs say it. Search the test suite for the symbol before anything else.
2. The types and signatures. Return types, discriminated unions and schema definitions encode intent — which states are legal, which fields are optional, what an error looks like.
3. Docs and decision records. README, CONTRIBUTING, docs/, adr/, CLAUDE.md, AGENTS.md. Check the date; an ADR that was superseded is history, not instruction.
4. The immediate neighbours. Two or three sibling files. Convention questions — how do we name this, where does this go, how are errors handled here — are answered by reading what is already there, not by asking.
5. Git history. git log -S"<symbol>" finds the commit that introduced a line and its message says why. git log --follow <file> survives renames. git blame on the confusing line, then read that commit in full. This resolves nearly every "why is this like this?" question.
6. Closed pull requests and issues. gh pr list --state merged --search "<term>" and gh issue list --state all --search "<term>". Rejected approaches live here and nowhere else — this is the only source that tells you what was already tried and abandoned.
7. The dependency's own source. node_modules/, the vendor directory, the installed package. Reading the implementation is faster and more reliable than guessing at an API or fetching docs for a version you may not have installed.
8. Then, and only then, ask.

How to ask, when you must

A question that survives the chain still must not be a bare unknown. Arrive with:

• A hypothesis and its evidence. "I'm assuming new endpoints go in src/api/v2/ because the last three did — say if this one is different."
• A default you will proceed with. The user should be able to say nothing and get a reasonable outcome. A question that blocks all work until answered had better deserve to.
• The consequence of being wrong. "If I've got this backwards it's a ten-minute change" and "if I've got this backwards I'll have migrated the table the wrong way" deserve different amounts of the user's attention.
• One question, not five. A list of five reads as an unwillingness to decide anything.

What is always worth asking

The chain is about facts the repository holds. It is not an excuse to guess at these:

• Product intent. What the feature is for, who it is for, what "done" means. No repo contains this.
• Genuine trade-offs with no right answer. Speed against completeness; a migration that is quick but lossy against one that is slow and safe.
• Anything irreversible. Deleting data, taking something live, sending anything to a real user, spending money. Ask every time, regardless of how clear the intent seems.
• A contradiction you cannot resolve. When two authoritative sources genuinely disagree, present both and let the user pick — do not silently choose.

Anti-patterns

• Asking which package manager, test runner, formatter or framework the project uses. All of these are in the repository root.
• Asking permission to read files, run the test suite, or inspect history. Reading is not an action.
• Asking a question, then proceeding on your own assumption anyway before the answer arrives — this is the worst of both: the interruption and the guess.
• Batching every uncertainty into one message at the start, before doing the work that would have resolved most of them.
• Treating a stale doc as authoritative because it was easier to find than the git history that contradicts it.

Verification gate

• Steps 1–7 attempted, and you can name what each one returned or why it did not apply.
• Every question being asked carries a hypothesis, a default and a consequence.
• No question is answerable by a command you could have run.
• Anything irreversible is being asked about regardless of how confident you feel.