record-what-the-requirement-left-out
Use when a requirement defines what a feature does but not its boundaries. Logs the excluded non-goals, assumptions, and open questions with the spec so gaps cannot resurface as scope surprises.
- License 许可
- MIT
- 最近更新
- 2026-11-14
- Stars
- ★ 81
- Forks
- 17
01 前言 Front Matter
- name
- record-what-the-requirement-left-out
- description
- Use when a requirement defines what a feature does but not its boundaries. Logs the excluded non-goals, assumptions, and open questions with the spec so gaps cannot resurface as scope surprises.
02 资源文件 3
- 许可证LICENSE1.0 KB
- 参考文档SOURCE.md362 B
- 参考文档TRUST.auto.yaml2.2 KB
03 SKILL.md 正文
Record what the requirement left out
A spec is defined as much by what it excludes as by what it states. This skill records the non-goals, the assumptions, and the unresolved questions beside the spec, so nothing is silently assumed.
Procedure
-
Read the requirement and list three categories in
boundaries.md:non-goals(deliberately excluded),assumptions(believed true but unverified), andopen questions(undecided). -
For each non-goal name who asked for it and why it was excluded, so a future reader sees the reasoning, not just a veto.
-
For each assumption write the evidence (or
none) and the impact if it is false; an assumption with no evidence and high impact is an open question in disguise. -
For each open question name the decider and the date by which it must be answered, or it will be answered by accident during the build.
-
Cross-check assumptions against the acceptance criteria; a criterion resting on an unverified assumption is fragile and should be flagged.
-
Review the boundary list with the requester before freezing the spec, since people catch omissions better than incorrect statements.
-
Version the file with the spec so boundaries travel with the requirements, not in a chat thread.
-
Revisit before each review; a resolved open question moves to non-goals or into the spec, and the list stays current.
-
Distinguish a deliberate non-goal from a forgotten one by naming who decided and when.
-
Add a section for constraints imposed from outside the team, such as platform limits or contracts.
-
Link each assumption to the evidence file or ticket so it can be rechecked when it expires.
Pitfalls
-
Leaving the non-goals implicit, so every reviewer assumes a different boundary.
-
Recording an assumption without its impact, which hides the ones that matter.
-
Open questions with no owner or deadline, which is how a decision gets made by whoever codes first.
-
Writing boundaries in a separate doc that nobody opens with the spec.
-
Treating "we'll decide later" as a non-goal; it is an open question with a deadline missing.
-
Listing open questions without dates, which quietly become the build team's problem.
-
Treating the boundaries doc as a one-time artefact instead of a living companion to the spec.
-
Merging a non-goal back into scope without updating the boundary file.
Verification
grep -c '^non-goal\|^assumption\|^open question' boundaries.md; grep -c 'owner:\|date:' boundaries.md
Report the non-goal count, every assumption lacking evidence, and each open question's owner and deadline.
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.