Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →cherryhq/demand-first-review
Use when reviewing a PR, API, IPC channel, endpoint, parameter, type, config, or architectural extension point that adds or expands shared surface area, especially when consumers are absent, exports are unused or speculative, existing consumers are hack-heavy, forward compatibility is claimed, or multiple similar APIs may express one demand.
Passed 22 of 22 test cases with the skill, and 12 of 22 without it.
and 13 more in the full report
10 fixed12 passed either way0 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 10 test cases the skill fixed. Same model, same prompt, with and without the skill.
Partner API PR #518 adds 15 forward-compatible fields mapped to an unreleased partner specification that might launch next quarter. Evaluate the inclusion of these additive fields.
| Checked | Without skill | With skill |
|---|---|---|
| Classifies forward-compatible partner fields as unsupported speculation. | Missed | Passed |
| Recommends Narrowing forward-compatible fields until partner integration occurs. | Missed | Passed |
The instructions your model reads when the skill loads.
Audit this causal chain before implementation quality:
root outcome or invariant → normalized demand → owning layer → contract → consumer
A call site proves usage, not legitimacy or shape. No call site raises the burden of proof, not an automatic rejection. Real demand may still have the wrong consumer or abstraction.
Apply every step to each added API, channel, parameter, type, field, config, or extension point.
List every new surface and exact consumed dimension; one valid consumer does not justify unused fields. Trace current and linked consumers to their user outcome, business rule, or system invariant. Inspect adjacent implementations, then ask: without the current API and history, would the demand remain and would this contract still be natural? Do not rely only on the PR description.
Parsing, retries, sequencing, duplicated state, check-then-act, or cross-layer access signal compensation. Treat these as unmet upstream demand, never endorsement of the current surface.
Strip names, historical formats, and workarounds from demand statements. Cluster by outcome, source of truth, owner, transaction, security, and lifecycle. Consolidate historical or caller-specific differences; keep contracts separate for genuine ownership, permission, atomicity, lifecycle, side-effect, or failure differences. Prefer a stable core with thin adapters, not duplicated workflows or a lowest-common-denominator API.
Direct consumption proves pressure, not placement or shape.
test cases passed, vs 12 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.