Spec
Skill yuri-semenenko/ai-engineering-workspace/claude-code/.claude/skills/spec
Write a minimal spec — goal, non-goals, acceptance criteria, open questions — before implementing a feature or change. Use when the user asks to "spec this", "напиши спеку", "what does done mean here", "acceptance criteria for X", or before starting a non-trivial implementation without a clear definition of done. Different from /rfc (explores architecture options, 10 sections) and /adr (records a decision already made) — /spec pins down what "done" means for one concrete change, in five to twenty lines. Its acceptance criteria become the input for /verify.From its SKILL.md
npx -y skills add yuri-semenenko/ai-engineering-workspace --skill specAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.1 KB, 573 tokens by cl100k_base, as published. Nobody here has run it
Spec
Pin down what "done" means before writing code. Even a five-line spec beats none: it forces the boundary question (what are we not doing?) and gives /verify something concrete to check against. This is the lightweight entry to the Define phase — reach for /rfc only when there are genuinely competing architectural options to weigh.
Rationalizations
| Rationalization | Rebuttal |
|---|---|
| "Task too simple for a spec." | Acceptance criteria apply at any scale. A simple task gets a five-line spec, not zero. |
| "The requirements are obvious from the ask." | Then writing them down costs a minute and catches the one place they weren't. |
| "We'll figure out the edge cases while coding." | Edge cases decided mid-implementation default to whatever is easiest to code, not what's right. |
| "A spec will slow us down." | Rework from a misunderstood requirement is slower than twenty lines of markdown. |
Format
## Goal
<1-2 sentences: the user-visible outcome, not the implementation.>
## Non-goals
<What this change deliberately does NOT do. The scope fence —
anything here appearing in the diff is scope creep.>
## Acceptance criteria
<Testable statements. Each one either passes or fails — no "works well".
- [ ] <observable behavior, ideally with concrete input → output>
- [ ] <error/edge case behavior>>
## Open questions
<Anything blocking or ambiguous. If a question changes the approach,
resolve it before coding; otherwise note the assumption and proceed.>
Rules
- Proportional depth. Five lines for a small fix, ~20 for a feature. If it wants more than a page, the task is either too big (split it) or architectural (use
/rfc). - Criteria must be falsifiable. "Fast", "clean", "user-friendly" are not criteria. "P95 under 200ms", "keyboard-navigable" are.
- Non-goals are load-bearing. They are the scope-discipline contract: the implementation touches only what the spec names.
- Surface assumptions explicitly (per persona). An unstated assumption in a spec is a bug filed in advance.
- Hand off to verification. When implementation ends, walk the acceptance criteria as the
/verifychecklist — each unchecked box is unfinished work, not a footnote.
Output
The spec in the format above, in the conversation (or written to a file if the user names a location). If open questions block the approach, ask them before proposing implementation. Otherwise end with the spec and wait — writing the spec is not permission to start coding.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most quality gates skills give in 573 tokens
Counted across 1,195 of the 2,094 authors here whose files we hold, read 2026-08-07
- Read the output and check the exit codein 54 of 1195, across 14 files
- Verify requirements using a line-by-line checklistin 53 of 1195, across 12 files
- Identify the verification command proving the claimin 51 of 1195, across 12 files
- Run the full verification commandin 50 of 1195, across 11 files
- Verify output confirms the claimin 49 of 1195, across 12 files
- Check version control diff after agent delegationin 46 of 1195, across 6 files
- State claim with evidencein 44 of 1195, across 4 files
- Run the test suitein 33 of 1195, across 26 files
- Keep state in memory by defaultin 27 of 1195, across 6 files
- Make prototype runnable with one commandin 26 of 1195, across 5 files
- Produce a verification reportin 25 of 1195, across 14 files
- Detect the package manager from lockfilesin 24 of 1195, across 5 files
Said here and by no other author read
- define the user-visible goal
- list explicit non-goals
- write falsifiable acceptance criteria
- list open blocking questions
- scale the spec to the task size
- split tasks exceeding one page
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.