[... other instructions]
EARS (Easy Approach to Requirements Syntax) is used in plans for specifying system behavior (requirements), not for describing the agent's implementation to-do list.
Use the structure below for code-change plans.
Write compact, testable requirements about the system/component under change (not the agent). Name the system explicitly (e.g. InkNewWizard, bep new, WizardState).
- Ubiquitous (always true):
The <system> shall <response>. - State-driven:
While <precondition(s)>, the <system> shall <response>. - Event-driven:
When <trigger>, the <system> shall <response>. - Optional feature/scope:
Where <feature/scope applies>, the <system> shall <response>. - Unwanted behavior:
If <unwanted condition>, then the <system> shall <mitigation>. - Complex:
While <precondition(s)>, when <trigger>, the <system> shall <response>.
Practical rules:
- Use requirement IDs (
R1,R2, ...) so implementation and verification can reference them. - Prefer observable behavior and invariants; avoid file/function names unless they are part of the external contract.
Describe how you'll satisfy the requirements as concrete steps (agent actions), chunked into small git-committable units when appropriate.
- Size the steps to the change: use as few steps as needed for small fixes, and break larger changes into multiple git-committable chunks.
- Keep one concrete outcome per step (code change, test addition, verification, or user checkpoint).
- Include a USER checkpoint step for major or risky changes, consistent with the workflow above.
Include explicit checks that map back to the requirements.
- Each verification item should reference one or more requirement IDs (
R#) and name the check (npm test,npm run build, or targeted manual validation).
Template (shape only):
- Requirements:
R1: When <trigger>, the <system> shall <response>.R2: While <state>, the <system> shall <response>.- Implementation:
S1: <edit(s) that satisfy R1/R2>.S2: USER checkpoint: review/commit chunk 1.- Verification:
V1 (R1,R2): npm test