flag-untestable-words-in-a-spec
Use when reviewing a spec, ticket, or acceptance criteria before build. Greps out vague qualifiers that cannot be tested and forces each to a threshold or an example.
- License 许可
- MIT
- 最近更新
- 2026-11-14
- Stars
- ★ 81
- Forks
- 17
01 前言 Front Matter
- name
- flag-untestable-words-in-a-spec
- description
- Use when reviewing a spec, ticket, or acceptance criteria before build. Greps out vague qualifiers that cannot be tested and forces each to a threshold or an example.
02 资源文件 3
- 许可证LICENSE1.0 KB
- 参考文档SOURCE.md357 B
- 参考文档TRUST.auto.yaml2.2 KB
03 SKILL.md 正文
Flag untestable words in a spec
"Fast", "robust", and "intuitive" cannot fail, so they cannot be verified. This skill finds the vague words and replaces each with a number, an example, or a decision.
Procedure
-
Run a vague-word scan over the spec:
grep -inE '\b(fast|slow|robust|reliable|scalable|intuitive|seamless|user-friendly|simple|easy|better|improve|optimize|soon|recently|properly|correctly|sometimes)\b' spec.md. -
For each hit decide which of three fixes applies: replace with a measurable threshold, replace with a concrete example, or delete the claim.
-
Convert comparative words to a baseline and a target: "faster" becomes "p95 under 300 ms, from 800 ms today".
-
Convert quality words to an observable behaviour: "robust" becomes "survives a 500 from the upstream without a 5xx to the client".
-
Convert quantity words ("many", "most", "soon") to a number and a window.
-
Raise any word that hides a genuine dispute to a decision record rather than quietly picking a threshold.
-
Re-run the scan after editing; a clean pass means every remaining claim is testable.
-
Do the same scan on the ticket title, which frequently carries the vaguest phrase.
-
Add project-specific vague words to the scan list, such as internal jargon that means different things to different teams.
-
Record which hits were false positives so the next reviewer does not re-litigate the same line.
-
Add the scan to the pull request template so vague wording is caught before review, not after.
Pitfalls
-
Replacing "fast" with an arbitrary number the requester never agreed to; thresholds are decisions, not guesses.
-
Flagging words like "simple" that are legitimately in a non-normative sentence, then over-editing prose.
-
Fixing the spec text but not the acceptance criteria that reference the same vague word.
-
Letting "soon" survive as a deadline; a date or window is required.
-
Treating the grep as the goal rather than the meaning; an empty grep over nonsense prose is still nonsense.
-
Editing prose that is deliberately non-normative and does not belong in a test.
-
Replacing a vague word with a precise one nobody agreed to, smuggling a decision into an edit.
-
Escalating every vague word to a decision record, which buries the ones that truly need one.
Verification
grep -inE '\b(fast|robust|intuitive|seamless|simple|easy|soon)\b' spec.md || echo clean
Report each flagged word, its fix (threshold, example, or deleted), and any word you escalated to a decision record.
04 同仓库更多 Skills
recipe-performance
Diagnose a specific MetaMask user flow's real-app performance and Sentry critical-user-flow telemetry with deterministic mm-harness recipes. Use for CUF boundaries, cold/warm/background-resume behavior, latency regressions, lifecycle tags, duplicate or blocking network requests, long tasks, layout/paint cost, screen redraws, React rerenders, or browser trace analysis where tests alone cannot prove the real app.
mexc-spot-websocket
MEXC Spot WebSocket workflows for public streams, protobuf handling, depth maintenance, listen keys, and private streams without exposing API keys.
mexc-spot-rest
MEXC Spot REST workflows for public data, signed account requests, orders, wallet/admin actions, and secure signing without exposing API keys.
mexc-futures-websocket
MEXC Futures WebSocket workflows for public streams, private account/order/position streams, ping/pong, subscriptions, and depth maintenance.
0xklen-version-and-refresh-sanctions-lists
暂无简介
verify-tests-cover-changed-lines
Use when a PR adds code that the existing suite may not exercise. Measures patch coverage — the share of newly changed lines hit by tests — before approving.