product-requirements skillA
product-requirements is agent-read markdown (skill) from cbrock84/headcount: Writes down what is being built so a team can build it and know when they are done — problem and success measure before solution, scope stated by exclusion, user-visible behavior including the states everyone forgets, acceptance criteria someone can test, and the open questions named rather than buried. Use this to write a specification, review one that is causing rework, or work out why a delivered feature technically matched the request and still was not what anyone wanted..
Indexed from public GitHub and served as immutable, content-addressed versions. Install it pinned to an exact SHA-256 with the mdr CLI, and every file is verified against the hash recorded here before it reaches your agent. The deterministic audit below grades the latest version, and the same file always earns the same grade.
What the file says
# Product requirements A specification exists to prevent expensive rediscovery — of decisions already made, of scope already agreed, and of the edge cases that are found either now on a page or later in production. ## Lead with the problem and the number, not the solution Open with who has the problem, what it costs them today, and what you expect to change if this ships — expressed as a measure with a target and a date. A document that starts with a solution invites the team to optimize the wrong thing and gives you no way to tell afterward whether it worked. **Decide the success measure before building, not at launch.** A number chosen afterward is chosen to be met. ## State scope by exclusion Everyone reads what is in scope and assumes the rest is coming. An explicit "not in this" list is the cheapest thing in the document and prevents most scope arguments — including the ones that arrive as clarifications rather than as requests. Say what is deferred versus what is rejected. Those are different, and conflating them means the rejected thing comes back. ## Describe behavior, not implementation …
Read the whole file at its exact version.
How to install
mdr add cbrock84/headcount/product-requirements@git:20260916.e72e404mdr add cbrock84/headcount/product-requirements@sha256:56e47a3c8beefae7Pin to a label to follow the author's releases, or to a sha256 to freeze the exact bytes forever. Either way the resolved hash is written to mdr.lock, and mdr install reproduces it on any machine.
[](https://markdownregistry.com/a/art_wlow2xl44y6g7bqh)
0 badge views in 30 days
Versions
| version | committed | commit | size | audit | |
|---|---|---|---|---|---|
| git:20260916.e72e404 latest | 2026-09-16 | e72e404 | 3,881 B | A | view · diff |
| git:20260901.9844f9d | 2026-09-01 | 9844f9d | 3,542 B | A | view |
Audit of the latest version
- pass: Frontmatter block present
- pass: Frontmatter declares a name
- pass: Frontmatter declares a description
- pass: Size between 200 bytes and 200 KB (3881 bytes)
- pass: No zero-width or bidi control characters
- pass: No instruction hidden inside an HTML comment
- pass: No link to an exfiltration or paste host
- pass: No credential-shaped string
- pass: No instruction to send local credentials anywhere
- pass: No text hidden with inline styles
- pass: No prompt-injection phrasing
- pass: No curl or wget piped into a shell
- pass: No recursive delete of root, home or parent
- pass: No instruction to read or print local credentials
- pass: No base64 blob over 200 characters
- pass: No link to a raw IP address
- pass: No script tag
Source
cbrock84/headcount · 1,664 stars · license MIT · pushed 2026-09-17 · branch main
API
GET https://markdownregistry.com/api/v1/artifacts/art_wlow2xl44y6g7bqh GET https://markdownregistry.com/api/v1/resolve?ref=cbrock84/headcount/product-requirements GET https://markdownregistry.com/api/v1/blob/56e47a3c8beefae7035219ef9c25f3035235ae8834144f6f7cce9fa0eb76f015
Your agent does the legwork. You hear about the deals worth your word. Hand yours the standing instructions at modelranch.com and it joins the network that reads files like this one.