skills/surface-intent/SKILL.md
Surface intent before you add, change, or produce something — a claim, design, abstraction, instruction, name, config, or rule. Use this when you are about to introduce something that might already exist or might talk past what is there, when duplication or scope creep is a risk, or when what you produce needs to be clear enough for its reader to act on. Triggers: "is this already covered", "make this clearer", "why does this exist", "before I add this", "am I duplicating this", or any moment you are adding to a system you have not fully read. It directs you to read what already serves the purpose before you act, and to make your own intent legible in what you produce.
npx skillsauth add synapseradio/ai-skills surface-intentInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
There are two kinds of intent in any change. The intent already sitting in what exists, and the intent you are about to express. Most avoidable mistakes — the duplicate rule, the helper that already existed, the design that talks past the one in place — come from skipping the first. You act before you have surfaced what is already there. So this skill has two beats, and the first one comes first.
You are about to add or change something. Before you write it, find out what the system already does about it. Do not assume; look.
Name it in one line. Say plainly what you are about to add or change, and the purpose it serves. "A rule that claims must be checkable." "A helper that formats a date." One sentence. If you cannot say it in one line, you do not yet understand it well enough to add it.
Read what already serves that purpose. Search the system for it — by name, by the words it would use, by where it would live. Open what you find and read it. This is reconnaissance, not a guess. The thing you are about to write is often already written, under a name you did not predict.
Diff against what exists. Compare what you would add to what is already there, on purpose, not on wording:
State what you found. Tell the reader what you searched, what you found, and why you concluded covered, partly, or not. This lets them check your dedup instead of taking your word for it. A silent "I checked" is not checkable.
The deeper method — how to survey, the known / assumed / unknown split, how to
compare two things by their truth-conditions, and a worked example of a duplicate
caught this way — is in references/incoming.md.
Now you are writing the thing. Make your intent legible in the artifact itself, so the next reader does not have to reconstruct it.
Name things for what they are. A name should say what the thing is, so the reader needs no comment to learn what it does. If you reach for a comment to explain what a function or section does, the name is wrong — fix the name. Comments are for why.
Prefer one named root over indirection. When several things share a purpose, name the purpose once and let each thing be a recognizable instance of it. Do not wire them together with pointers and cross-references that hide the shared intent behind a trail the reader has to follow. One named root beats many links.
Make it clear enough to act on. Write so that whoever has to act on this can do so on the first read, without reconstructing what you meant. Clarity is the goal. Say it plainly at the top, and put the deeper framing — the rationale, the edge cases, the vocabulary — in a reference they can open when they need it. The top stays terse; the depth waits below. This is how this skill is built: two beats here, the method in the references.
Self-check before you ship. Ask: could a second reader, holding only the
inputs and my output, follow this and reach the same place? Where the answer is
no, the intent did not make it onto the page — fix it. Rank what is solid above
what is shaky; do not flatten the two into one confident voice. If a claim rests
on your conviction rather than something the reader can check, ground it or cut
it. (Grounding a claim in evidence is its own discipline — warrant — and lives
elsewhere; this skill only points at the seam. See references/outgoing.md.)
The full expression discipline — naming, intent over indirection, calibrating for
clarity, progressive disclosure, the reflexive self-check, and where the warrant
boundary sits — is in references/outgoing.md.
references/incoming.md — the reconnaissance and dedup method for Beat 1.references/outgoing.md — the expression discipline for Beat 2.data-ai
Locate where a small change shifts the whole system
tools
Surface unstated assumptions at multiple levels and rank them
data-ai
Assess how well evidence supports claims
testing
Spot logical errors in reasoning