Requirements brief

Reduce a requirements narrative to the need, required behavior, and scope limits.

Condense the supplied requirements into a brief for discussing or implementing the stated need. Use this for required behavior and scope, not a solution design or a new specification.

Start with the user and the task or problem. Group requirements by behavior. Retain actors, permissions, inputs, outputs, limits, timing, dependencies, and failure behavior. Preserve requirement identifiers when supplied. Keep must-have behavior distinct from preferences and future ideas. Do not replace a user need with the first suggested implementation.

Separate in-scope requirements, explicit exclusions, and unresolved questions. Preserve numerical boundaries and whether they are inclusive. Do not resolve conflicting statements silently; show the conflict beside the affected requirement.

Use a short goal followed by labeled bullets. Remove historical discussion and repeated rationale unless they explain a constraint. Keep an open question open, and do not add acceptance tests, architecture, features, or priorities that the source does not support.

Example

Damaged-stock reporting requirements

Before 140 words

The warehouse team needs a way for shift leads to record damaged stock without waiting for the inventory manager. R1 says a shift lead must be able to submit an item code, a positive whole-number quantity, and a reason of up to 300 characters. R2 says only the inventory manager can approve a submission; submitting must not change the stock balance. R3 requires the approved quantity to be deducted once, even if the approval button is clicked repeatedly. Showing a photo is a nice-to-have, not a release requirement. Barcode scanning was discussed in the first workshop but was explicitly excluded from this release. The team has not decided whether a lead may edit a submission after it is rejected. A slide-out panel was suggested as one possible design. The discussion about eliminating the wait was repeated in three workshop notes.

After 80 words

Goal: Let shift leads report damaged stock without waiting for the inventory manager. Required - R1: Submit an item code, positive whole-number quantity, and reason of at most 300 characters. - R2: Only the inventory manager can approve. Submission does not change stock balance. - R3: Approval deducts the quantity once, including repeated clicks. Scope: Photo display is optional. Barcode scanning is excluded this release. A slide-out panel is a design suggestion. Open: Can a lead edit a rejected submission?

Examples illustrate the method. They do not measure model output.

Files and sources

prompt.txt Complete prompt as plain text.
SKILL.md The same prompt with a skill header.
llms.txt (JSON) Prompt, metadata, example, and sources.
LICENSE MIT license text.

An original sho.rten.it skill. Source notes.