Two additions from researching AWS Kiro and BMAD-METHOD against cad's ADR-0002 direction:
EARS-lite acceptance criteria (Kiro pattern) — spec-driven-dev/feature-spec currently do prose success criteria only. Add an EARS-lite section (formal, near-machine-checkable phrasing: "WHEN <trigger> THE SYSTEM SHALL <response>") as an option alongside prose, not a replacement — closes the requirements half of cad's audit trail, which today is Gitea-issue-body prose only.
Inline context snapshot (BMAD pattern) — BMAD's Scrum-Master-agent step compiles hyper-detailed story files with full architectural context embedded inline, not just linked. Add a step to feature-spec (or wherever the executor-facing handoff happens) that snapshots relevant architecture/ADR context into the spec itself, so the executor doesn't have to re-derive it from a reference.
Ref: cad research fork verdict (2026-07-25).
Two additions from researching AWS Kiro and BMAD-METHOD against cad's ADR-0002 direction:
1. **EARS-lite acceptance criteria** (Kiro pattern) — `spec-driven-dev`/`feature-spec` currently do prose success criteria only. Add an EARS-lite section (formal, near-machine-checkable phrasing: "WHEN \<trigger\> THE SYSTEM SHALL \<response\>") as an option alongside prose, not a replacement — closes the requirements half of cad's audit trail, which today is Gitea-issue-body prose only.
2. **Inline context snapshot** (BMAD pattern) — BMAD's Scrum-Master-agent step compiles hyper-detailed story files with full architectural context embedded inline, not just linked. Add a step to `feature-spec` (or wherever the executor-facing handoff happens) that snapshots relevant architecture/ADR context into the spec itself, so the executor doesn't have to re-derive it from a reference.
Ref: cad research fork verdict (2026-07-25).
Both additions shipped in 51a2d39 — CI run #39 green.
EARS-lite is in both spec-driven-dev and feature-spec, as an option beside prose, with the fourth (unconditional) EARS form included — see below for why that mattered. feature-spec's template gains a ### Behavioural criteria (EARS-lite) slot.
Context snapshot is in feature-spec only, where the executor-facing handoff happens.
The RED phase argued against half of this issue
A subagent with no skill loaded wrote a genuinely good spec for an approval-gated invoice pipeline, and closed with this, unprompted:
I deliberately left out the extraction mechanism and the full pain.001 field mapping, because both are owned by the existing architecture document and duplicating them here would create two drifting sources of truth.
That is the correct objection to BMAD's inline-context pattern, and it came from the baseline rather than from review. So the section is built around answering it rather than ignoring it: snapshot only what the implementer cannot look up and cannot proceed without, always cite source and version, and open with a line saying the source wins on disagreement.
Prose success criteria, by contrast, came out strong unaided — measurable, boundary-aware. EARS phrasing never appeared. That is where the real gap was, and it is the half of this issue that needed no argument.
The GREEN run found seven defects, all fixed before commit
The most instructive one is a trap this issue would have walked into:
Lines 51-57 of the skill are this spec's domain, verbatim — the state name awaiting_approval in my spec is copied from line 52, and the confidence-floor rule is copied from lines 53-54. The feature request never mentions extraction confidence; I adopted it because the skill put it in front of me. Anyone evaluating whether EARS-lite improves specs should re-test with an example from a different domain, or they'll measure copying, not reasoning.
An on-domain example does not teach a shape, it donates requirements. The example is now firmware/contactor, deliberately unlike anything in this estate, with that failure written up as the reason.
The rest:
No unconditional form. The invariant that matters ("no instruction above threshold ever reaches a file") had to be bent into WHILE an invoice is in awaiting_approval, which — as the run pointed out — "is satisfied by a system that never puts anything into awaiting_approval in the first place". Added THE SYSTEM SHALL <response>.
"Maps 1:1 onto a test" was false for the WHILE form, which is universally quantified. That sentence justified the whole section, so it is now accurate about which forms map to one test.
The provenance rule had no answer for its own commonest case — an author who also cannot read the source. Now: mark it UNVERIFIED — reconstructed, not read in those words, and make confirmation the implementer's first task.
"Snapshot only what this spec's decisions rest on" was too narrow. A table name underpins no decision here and still blocks writing the migration. Widened, with omissions stated deliberately so they read as choices.
"Say so in the section itself" did not say what or at what granularity. Now one opening line, not a per-fact annotation.
The template had no slot for EARS lines, so their placement was a guess.
Both additions shipped in `51a2d39` — CI run [#39](https://git.d-ma.be/mathias/skills/actions/runs/4856) green.
**EARS-lite** is in both `spec-driven-dev` and `feature-spec`, as an option beside prose, with the fourth (unconditional) EARS form included — see below for why that mattered. `feature-spec`'s template gains a `### Behavioural criteria (EARS-lite)` slot.
**Context snapshot** is in `feature-spec` only, where the executor-facing handoff happens.
## The RED phase argued against half of this issue
A subagent with no skill loaded wrote a genuinely good spec for an approval-gated invoice pipeline, and closed with this, unprompted:
> I deliberately left out the extraction mechanism and the full pain.001 field mapping, because both are owned by the existing architecture document and duplicating them here would create **two drifting sources of truth**.
That is the correct objection to BMAD's inline-context pattern, and it came from the baseline rather than from review. So the section is built around answering it rather than ignoring it: snapshot only what the implementer cannot look up and cannot proceed without, always cite source and version, and open with a line saying the source wins on disagreement.
Prose success criteria, by contrast, came out strong unaided — measurable, boundary-aware. EARS phrasing never appeared. That is where the real gap was, and it is the half of this issue that needed no argument.
## The GREEN run found seven defects, all fixed before commit
The most instructive one is a trap this issue would have walked into:
> Lines 51-57 of the skill are *this spec's domain, verbatim* — the state name `awaiting_approval` in my spec is copied from line 52, and the confidence-floor rule is copied from lines 53-54. **The feature request never mentions extraction confidence; I adopted it because the skill put it in front of me.** Anyone evaluating whether EARS-lite improves specs should re-test with an example from a different domain, or they'll measure copying, not reasoning.
An on-domain example does not teach a shape, it donates requirements. The example is now firmware/contactor, deliberately unlike anything in this estate, with that failure written up as the reason.
The rest:
- **No unconditional form.** The invariant that matters ("no instruction above threshold ever reaches a file") had to be bent into `WHILE an invoice is in awaiting_approval`, which — as the run pointed out — "is satisfied by a system that never puts anything into `awaiting_approval` in the first place". Added `THE SYSTEM SHALL <response>`.
- **"Maps 1:1 onto a test" was false** for the `WHILE` form, which is universally quantified. That sentence justified the whole section, so it is now accurate about which forms map to one test.
- **The provenance rule had no answer for its own commonest case** — an author who also cannot read the source. Now: mark it `UNVERIFIED — reconstructed, not read` in those words, and make confirmation the implementer's first task.
- **"Snapshot only what this spec's decisions rest on" was too narrow.** A table name underpins no decision here and still blocks writing the migration. Widened, with omissions stated deliberately so they read as choices.
- **"Say so in the section itself"** did not say what or at what granularity. Now one opening line, not a per-fact annotation.
- **The template had no slot for EARS lines**, so their placement was a guess.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Two additions from researching AWS Kiro and BMAD-METHOD against cad's ADR-0002 direction:
spec-driven-dev/feature-speccurrently do prose success criteria only. Add an EARS-lite section (formal, near-machine-checkable phrasing: "WHEN <trigger> THE SYSTEM SHALL <response>") as an option alongside prose, not a replacement — closes the requirements half of cad's audit trail, which today is Gitea-issue-body prose only.feature-spec(or wherever the executor-facing handoff happens) that snapshots relevant architecture/ADR context into the spec itself, so the executor doesn't have to re-derive it from a reference.Ref: cad research fork verdict (2026-07-25).
Both additions shipped in
51a2d39— CI run #39 green.EARS-lite is in both
spec-driven-devandfeature-spec, as an option beside prose, with the fourth (unconditional) EARS form included — see below for why that mattered.feature-spec's template gains a### Behavioural criteria (EARS-lite)slot.Context snapshot is in
feature-speconly, where the executor-facing handoff happens.The RED phase argued against half of this issue
A subagent with no skill loaded wrote a genuinely good spec for an approval-gated invoice pipeline, and closed with this, unprompted:
That is the correct objection to BMAD's inline-context pattern, and it came from the baseline rather than from review. So the section is built around answering it rather than ignoring it: snapshot only what the implementer cannot look up and cannot proceed without, always cite source and version, and open with a line saying the source wins on disagreement.
Prose success criteria, by contrast, came out strong unaided — measurable, boundary-aware. EARS phrasing never appeared. That is where the real gap was, and it is the half of this issue that needed no argument.
The GREEN run found seven defects, all fixed before commit
The most instructive one is a trap this issue would have walked into:
An on-domain example does not teach a shape, it donates requirements. The example is now firmware/contactor, deliberately unlike anything in this estate, with that failure written up as the reason.
The rest:
WHILE an invoice is in awaiting_approval, which — as the run pointed out — "is satisfied by a system that never puts anything intoawaiting_approvalin the first place". AddedTHE SYSTEM SHALL <response>.WHILEform, which is universally quantified. That sentence justified the whole section, so it is now accurate about which forms map to one test.UNVERIFIED — reconstructed, not readin those words, and make confirmation the implementer's first task.