---
name: answer-before-asking
description: Runs a fixed lookup chain through tests, types, git history, closed pull requests and dependency source before interrupting the user with a clarifying question, and requires any question that survives to arrive with a hypothesis and a default. Use at the start of any task where a requirement, convention or intent looks ambiguous.
license: MIT
compatibility: Any repository under git. Uses gh for issue and pull request history where available.
metadata:
  category: productivity
  version: "1.0.0"
---

# 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.