Requirements language is normative: shall binds, should suggests, may permits. Package the spec so the distinction survives the AI's reading.
Requirements documents fail in AI hands when normative language flattens: "shall" and "should" blur into "the system does", and a binding requirement becomes a suggestion in the summary. The requirements type adds the rules that keep the hierarchy: shall/must statements are binding, should/may are weaker and stay distinguishable, and requirement identifiers (R1, R2…) become the citation unit. Paired with documentation mode's exact-quoting discipline, the package turns a spec into something the model reads like an engineer. This setup loads an export-feature spec with acceptance criteria.
Keep the language normative
Shall binds, should suggests — the type rules state it so the reading preserves it.
Cite by identifier
R1, R2 become the unit of reference; "the spec says" becomes "R3 requires".
Check designs against it
The task frames the package: evaluate what I describe against these requirements.
An explicit ANALYSIS RULE: "Treat 'shall' and 'must' statements as binding requirements; 'should' and 'may' are weaker — keep the distinction." So R2's rejected-partial-exports stays binding while R4's email notification ("should") stays weaker. Long Input Formatter writes that rule into the package; the assistant you run it in does the reading, so this preserves the hierarchy, it does not enforce it.
So claims stay checkable. Requirement identifiers R1 to R5 are declared the citation unit, and the source travels verbatim between <<<SOURCE START>>> and <<<SOURCE END>>> with [§N — title] section markers. The GROUNDING rule ties every behavioral claim to the section that states it, turning "the spec says" into "R3 requires" so you can audit each answer against the source.
Reading an existing one; the TASK is "Check the design I will describe against these requirements," so the package frames the model as a compliance reader over your R1 to R5 spec. Writing the requirements document itself points to Markdown Output Builder's PRD mode, and pulling requirements into structured fields is the Extraction Prompt Generator's job.
Pasting a document raw mixes material with instructions. Package it: explicit delimiters, citable [§N] section labels, and grounding rules — the source travels verbatim.
Transcript analysis fails when speakers blur. Transcript mode packages the conversation with attribution rules: who said it, when it was revised, and no words in anyone's mouth.
A grounded workflow starts with a grounded source: package the reference once with strict rules, then run every question of the session against it.
Token budget planning for real workloads: how much of the window a transcript actually consumes, what is left for the answer, and how much headroom remains.
The "message too long" error has a structural fix: split at paragraph boundaries into sequenced chunks with wait rules, instead of pasting fragments and hoping.
Formats fuzzy agent instructions into a structured prompt with objective, available tools, constraints, success criteria, and failure handling.
Package source material with delimiters, citable section labels, and grounding rules — material and instructions stay separate.