/spec
WeIndie skill · v0.2What are we actually trying to do?
Reaches shared understanding before the work starts — on planning, research, writing or code.
Sent this link by someone? /spec is a skill you can add to an AI tool — or just try the prompt below in a conversation you already have open.
Example
A short request with a lot of unsaid context — and not a line of code in sight.
Help me write a message to my landlord about the boiler without it sounding harsh.
Sure — here's a polite draft asking them to arrange a repair at their earliest convenience.
Before drafting: I know it's about the boiler and you don't want to sound harsh. I'm assuming it's a repeat problem rather than the first report — say if not. One thing that changes the whole message: what do you actually want out of it? (A) it fixed quickly, no friction (B) a firm record because this has dragged on (C) compensation or rent reduction. I'd guess B from "without sounding harsh". Tell me the letter and I'll write it.
Try once
Nothing to install. Copy this into a conversation that is already underway, and see whether the idea is useful before you commit to it.
Before you start, work out whether we actually understand this the same way. Use what is already in this conversation first, then sort it into what you know, what you can reasonably infer, what you could look up yourself, and what genuinely needs a decision from me. Close the first three yourself and say your inferences out loud. Ask me only about the last group, and where the answer can be reduced to choices, offer me the choices rather than an open question. Recommend what you would do. Stop as soon as we understand it well enough to move.
A short, portable version. The installed skill carries the fuller behaviour — when to stay quiet, how to report, what not to flag — and neither needs your AI to be able to read this page.
When
/spec is allowed to find nothing.
Useful when
- There is more context in your head than you have actually said out loud.
- The request is short and the work it implies is large.
- The work is expensive, public, or hard to undo.
Probably not needed when
- The task is small, reversible and unambiguous.
- The goal was established earlier in the same conversation.
- Asking would cost more than trying it and adjusting.
Install
Make it yours
A few choices that change how /spec behaves. Everything here happens in this browser — nothing is sent anywhere, and nothing is saved.
Change the defaults
View generated SKILL.md
Compare with default
Skill source
The whole skill, and the same file every download is built from. Nothing downloadable here should be less inspectable than the page explaining it.
--- name: spec description: Reach shared understanding before work starts — on anything, not only code. license: MIT metadata: version: "0.2" source: https://weindie.com/spec --- # /spec **What are we actually trying to do?** Most disappointing AI work is not badly executed. It is well executed against a goal nobody established. This skill spends the first minute of a task making sure both sides understand the same thing, and then gets out of the way. It is not a coding skill. Use it before planning something, researching a purchase, writing a message you are not sure how to pitch, making a decision, or thinking an idea through out loud. Code is one case, not the point. The test is not "is this specified?" It is: > Do we understand this well enough to move? ## Useful when - There is more context in your head than you have actually said out loud. - The request is short and the work it implies is large. - Several reasonable readings of the request lead somewhere different. - The work is expensive, public, or hard to undo. ## Probably not needed when - The task is small, reversible and unambiguous. - The goal was established earlier in the same conversation. - Asking would cost more than trying it and adjusting. Re-establishing an established goal is just delay. If the context is already clear enough, say so and start. ## How to run the check 1. **Use what is already there.** Read the conversation, the files, the ticket. Never ask something that has already been answered. 2. **Sort what you have** into five piles: known, reasonably inferred, answerable by your own research, still ambiguous, and genuinely needs a decision from the human. 3. **Close the first three yourself.** Infer sensible defaults and say them out loud. Look up what can be looked up. 4. **Ask only about the last pile** — decisions that are actually the human's to make, where different answers lead to materially different work. 5. **Surface contradictions** rather than quietly picking a side. 6. **Stop when there is enough to move.** The goal is confidence to proceed, not a complete specification. ## Reporting - Lead with the goal in one sentence, then what "done" would look like. - Say the inferences out loud, so they are cheap to correct. - Recommend. A question that comes with a suggested answer is worth three open ones; a skill that only interrogates is a questionnaire, not a collaborator. - Keep the understanding shorter than the work it precedes. - Once work is underway, raise important new ambiguity instead of guessing silently — but use judgement. Not every small unknown is worth an interruption. ## Defaults you can change These are the adjustable lines of this skill. A customised copy from <https://weindie.com/spec> replaces them and records what changed. - **Questioning level.** Ask at most two or three questions, and only where different answers would lead to materially different work. - **Question style.** Offer a short list of options whenever the answer can sensibly be reduced to choices, and fall back to an open question only when it cannot. - **Small tasks.** Skip this check for small, reversible, unambiguous tasks and begin the work directly. - **What survives.** Keep the working understanding in the conversation. When the work is done, preserve only what genuinely needs to outlive it, in whichever ticket, document or note it naturally belongs to.
Where this came from
Spec First was a development method: work moved through problem, scope, domain, behaviour, tests, then code, with the behaviour written as Gherkin .feature files a machine could read. It was public for seven months and is now retired. What it got right was the first step — that most disappointing work is not badly executed, it is well executed against a goal nobody established — and that step turned out not to be about software at all.
/spec is that step on its own, at the size of a conversation: no directory, no file format, no stages to adopt, just the check that both sides understand the same thing before the work starts. Spec First's own address, spec-first.com, now points at this page.