@codyswann/lisa 2.303.0 → 2.304.1

package/plugins/lisa/rules/reference/prd-definition-of-ready.md

@@ -0,0 +1,81 @@
+# PRD Definition of Ready — Reference
+
+The eager head carries the atom definition and enforcement points; this
+reference carries the rationale, the full vagueness lexicon, and worked
+rewrites. The companion rule `work-item-definition-of-ready` governs the next
+stage down (tickets); this rule governs what the Plan factory decomposes from.
+
+## Why requirement shape is the whole game
+
+The pipeline consumes requirements three times, and each consumer needs a
+different property that only shaped atoms provide:
+
+1. **Plan decomposes** — an EARS-shaped atom (*When X, the system shall Y*)
+   maps to a Gherkin scenario (*When X / Then Y*) nearly mechanically. Prose
+   paragraphs force the planner to invent the split, which is where scope
+   quietly drifts between the PRD and the backlog.
+2. **Tickets trace** — gate S16 quotes the requirement verbatim on every leaf.
+   A verbatim quote of a paragraph containing three requirements is an
+   ambiguous trace: which of the three does this ticket satisfy?
+3. **Verification checks conformance** — spec-conformance and `verify-prd`
+   read the PRD back against the shipped result. A fit criterion is a
+   conformance check waiting to run; an adjective is not.
+
+The standards being distilled: **ISO/IEC/IEEE 29148** (successor to IEEE 830)
+supplies the per-requirement quality characteristics — necessary, appropriate,
+unambiguous, complete, singular, feasible, verifiable, correct — and the
+practice of banning untestable phrasing. **EARS** (Mavin et al.) supplies the
+five sentence patterns. **Volere** supplies the fit criterion. **ISO 25010**
+supplies the non-functional axes for the completeness walk. None of these are
+imported wholesale; this rule takes exactly the parts a machine planner and a
+machine verifier consume.
+
+## The vagueness lexicon
+
+Presence of these (and their kin) in a requirement atom FAILs it as
+unverifiable — each is a phrase no test can check:
+
+> as appropriate · as needed · if necessary · user-friendly · intuitive ·
+> seamless · robust · flexible · fast · quickly · efficient · optimize ·
+> minimize / maximize (unbounded) · handle gracefully · support (unbounded) ·
+> etc. · and/or · TBD inside an atom (TBD belongs in Open Questions)
+
+The lexicon is a floor, not a ceiling — validators should flag any phrasing
+they cannot turn into a check.
+
+## Worked rewrites
+
+| Before (fails) | After (passes) |
+|---|---|
+| "Uploads should be fast and handle errors gracefully." | R4: *When a user uploads a file ≤ 25 MB, the system shall complete the upload within 4s at p95.* Fit: perf-trace on staging. R5: *If an upload fails, then the system shall show a retryable error naming the cause.* Fit: screenshot of the error state per failure class. |
+| "The dashboard should be user-friendly and support filtering, sorting, etc." | R7: *The dashboard shall filter by status, owner, and date range.* R8: *The dashboard shall sort by any visible column.* Fit: each verb exercised in an E2E journey. ("etc." is deleted — unnamed features are unbuilt features.) |
+| "Optimize the pipeline." | R2: *The nightly pipeline shall complete within 30 minutes for a 10k-item batch* (baseline: 47m measured 2026-07-01). Fit: pipeline duration metric. — note this is Improvement-shaped: baseline + target, per `work-item-definition-of-ready`. |
+
+## Singularity repair
+
+When an atom contains multiple behaviors, the register splits it (`R4` →
+`R4a`, `R4b`) — **mechanically when the split preserves meaning**, as a
+product clarification when it does not. The split is recorded in the dry-run
+report; it is never silent, because the PRD author's numbering is part of the
+traceability contract.
+
+## The non-functional walk
+
+A PRD is complete only when the ISO 25010 axes were each considered:
+performance, security, reliability, usability, compatibility,
+maintainability/operability. The required artifact is one line per axis —
+either an atom or an explicit "no requirement." The point is not ceremony; it
+is that **silence and "no requirement" are different facts**, and only one of
+them is a decision a verifier can hold the product to.
+
+## Relationship to the lifecycle
+
+- **Write** — `lisa-research` authors atoms; `*-write-prd` carries the body
+  rule. Factory-authored PRDs are born conforming.
+- **Intake** — `*-to-tracker` Phase 1.45 is the universal gate (human-authored
+  PRDs arrive here without passing any write path). Failures quote the atom
+  verbatim, name the defect, and offer 1–3 candidate rewrites — the
+  EARS-shaped rewrite is the default recommendation. Routed like every other
+  intake failure: PRD to `blocked`, product-readable comments.
+- **Verify** — fit criteria become the spec-conformance checks; the
+  requirement register ids appear in the PRD backlink and the coverage audit.

package/plugins/lisa/rules/reference/work-item-definition-of-ready.md

@@ -0,0 +1,145 @@
+# Work-Item Definition of Ready — Reference
+
+The eager head carries the table; this reference carries the reasoning, the
+failure modes each requirement prevents, and worked examples. The enforcing
+gates live in the three tracker validators (`lisa-jira-validate-ticket`,
+`lisa-github-validate-issue`, `lisa-linear-validate-issue`), which cite this
+rule so the bar cannot drift per vendor.
+
+## The design principle
+
+A readiness gate is justified by exactly one thing: **its absence forces a
+human question.** The goal state is that a stateless agent — fresh session, no
+memory of any prior conversation — claims any ready item and drives it to its
+terminal state with zero human clarification. Every requirement below is an
+answer to a question agents otherwise ask mid-flight, which is the most
+expensive time to ask it: the item is claimed, the human is absent, and the
+choice is stall (blocked, human round-trip) or guess (rework when wrong).
+
+The bar is **type-keyed** because work types break autonomy differently. A
+Story with perfect Gherkin but no design source makes the agent guess visuals.
+A Bug with perfect prose but no executable repro makes the agent guess whether
+it even fixed anything. One generic checklist over-asks some types (Gherkin on
+a Spike is noise) and under-asks others (three bullets on a Bug).
+
+## Bug — the defect anatomy
+
+Modeled on the ISTQB defect-report content list, IEEE 1044, and
+minimal-reproducible-example practice, tightened for a machine executor:
+
+1. **Agent-executable reproduction.** Numbered steps a stateless agent can run
+   mechanically: exact entry point, named account/role (consistent with the
+   Sign-in Required section when authenticated), concrete data state, exact
+   actions. "Open the dashboard and click around until it breaks" is
+   human-followable, not agent-executable — it FAILs. A linked failing test
+   satisfies this requirement outright and is the preferred form.
+2. **Expected vs. actual, with the source of "expected."** Name or link where
+   the expected behavior comes from — spec, PRD requirement, prior release. A
+   fix target must be a fact, not an opinion, or the agent can confidently fix
+   to the wrong behavior.
+3. **Environment and version.** Where reproduced, and the build/commit
+   observed. Include last-known-good when known — that regression window is
+   what makes bisection possible. `unknown` is acceptable but must be stated.
+4. **Reproducibility rate.** Always vs. intermittent (with observed
+   frequency). An intermittent bug invalidates run-the-repro-once as a
+   verification plan; the verifier needs to know to run it N times or
+   instrument instead.
+5. **Occurrence evidence.** At least one link or attachment proving the bug
+   happened: error-tracker issue, log excerpt, stack trace, screenshot or
+   recording. Input evidence, distinct from the output evidence manifest.
+
+**Terminal state:** the reproduction (or failing test) fails before the fix
+and passes after — both runs captured under the evidence manifest. This is
+what makes a Bug autonomously closable: done-ness is a mechanical check, not a
+judgment.
+
+## Story
+
+The generic gates (three audiences, Gherkin, Out of Scope, source precedence)
+were designed around Stories, so Stories are the best-covered type already.
+The additional expectations:
+
+- UI-touching stories SHOULD name the non-happy-path states — error, empty,
+  loading — in the AC. These are the states product-walkthroughs flag as
+  missing after the fact; naming them up front converts a review finding into
+  a requirement.
+- Keep stories INVEST-small: a story too large to hold in one session is the
+  leading cause of mid-flight questions. Prefer decomposition over heroics.
+
+**Terminal state:** every AC scenario exercised against the running product.
+
+## Task
+
+A Task is "do this specific thing" — its risk is a fuzzy finish line, not a
+fuzzy user. It must carry an observable done-state and the command or check
+that proves it ("`bun run verify:x` exits 0", "the workflow file validates and
+the job appears in CI"). **Terminal state:** that check passes.
+
+## Improvement — the measured delta
+
+An Improvement without numbers has no verifiable terminal state by
+construction: "make it faster" can never be autonomously closed. Required:
+
+1. **Metric + measurement method** the agent can run (command, query,
+   dashboard export — something mechanical).
+2. **Baseline** — the current measured value. A number, not an adjective.
+3. **Target** — the numeric value or bound that defines done.
+
+If no baseline exists yet, measuring it is the first task — file it as such.
+**Terminal state:** the measurement method reports a value meeting the target.
+
+## Spike — the investigation contract
+
+A Spike's output is knowledge, so its readiness is about making knowledge
+checkable:
+
+1. **The question** being answered.
+2. **The decision it enables**, and the options being weighed — so the answer
+   is written to be decidable against, not merely interesting.
+3. **A timebox** — spikes without one become open-ended research.
+4. **Deliverable format and location** — decision doc, prototype, findings
+   page, and *where it will live* (wiki page, decision record, attachment).
+
+Gherkin AC is intentionally N/A for Spikes (S4 already exempts them).
+**Terminal state:** a deliverable exists at the named location **and answers the
+question** — it records the findings, the recommended decision, and the
+options weighed. An empty or placeholder document at the right path is not
+terminal.
+
+## Sub-task
+
+Always has a parent (no stranded-leaf exception), and otherwise carries the
+bar of its own nature — a bug-shaped sub-task carries the bug anatomy.
+
+## Epic and containers
+
+Containers are never build-ready (`leaf-only-lifecycle`); their readiness
+question is decomposition completeness — does every PRD requirement trace to a
+leaf (`prd-ticket-coverage`) — not buildability.
+
+## The stateless-pickup dry-run (gate S18)
+
+Structure gates are proxies; this gate checks the property directly. The
+validator simulates a stateless read of the item plus its resolvable links —
+session knowledge deliberately excluded, because the next claimant will not
+have it — and lists every question it would need answered before starting,
+before choosing between materially different implementations, or before
+declaring done. Zero questions = PASS. Each question found is emitted verbatim
+as its own remediation line; those lines are exactly the clarifying comments
+the caller posts to the source. This is the enforcement of the intake
+contract's core promise, and of TASC AC8.6: *ready means zero-clarification
+executable.*
+
+## Relationship to the lifecycle
+
+- **Write time** — `*-write-*` runs the applicable pre-write gates; a spec
+  failing the type-keyed bar is repaired or rejected before it exists. S18 is
+  not a write-time gate — most specs are not yet build-ready when written.
+- **Ready time** — the bar is what the build-ready role asserts, and S18 runs
+  here, on build-ready leaves only, making the assertion checked rather than
+  hoped.
+- **Claim time** — `ticket-triage` remains the analytical deep-check against
+  the codebase (edge cases, duplicate work, rework classification). With this
+  bar enforced upstream, triage's ambiguity phase should find nothing a
+  validator could have caught — its findings become a monitoring signal for
+  gaps in this rule.

package/plugins/lisa/skills/lisa-confluence-to-tracker/SKILL.md

@@ -224,6 +224,30 @@ The register feeds three consumers: the `## Source Requirement` section on
 every created ticket (Phases 3–5), the dry-run report (above), and the
 requirement tokens in the PRD back-link (Phase 7).
 
+### Phase 1.45: Requirement Quality Gates (prd-definition-of-ready)
+
+Validate every Phase 1.4 register entry against the `prd-definition-of-ready` rule before
+planning proceeds. Per atom:
+
+- **Singular** — one behavior per entry. An entry welding multiple shall/when clauses together is
+  split in the register (R4 → R4a/R4b) when the split is mechanical and meaning-preserving; when
+  the split would change meaning, it is a product question, not a repair.
+- **Unambiguous** — FAIL on the vagueness lexicon ("as appropriate", "user-friendly", "fast",
+  "handle gracefully", "etc.", "and/or", unbounded "optimize"/"support"): phrasing no test can
+  check. The full lexicon lives in the rule's reference body.
+- **Verifiable** — a fit criterion (the measurable test of satisfaction) is present or
+  mechanically derivable from the text; a requirement no test could check is not admitted as a
+  requirement.
+- **Pattern shape (SHOULD)** — an EARS pattern (ubiquitous / When / While / If-then / Where) or an
+  equivalent single-behavior sentence; conforming shapes decompose into Gherkin mechanically.
+
+Failures here are **requirement-level product clarifications**, not internal errors: report each in
+the dry-run report as a `product-clarity` item quoting the atom verbatim, naming the defect, and
+offering 1–3 candidate rewrites (an EARS-shaped rewrite is the default recommendation). In intake
+flows these route to the PRD's `blocked` role with comments, exactly like ticket-validator
+failures. Mechanical splits and derived fit criteria are repaired in-register and recorded in the
+report — never silently.
+
 ### Phase 1.5: Extract Source Artifacts
 
 PRDs typically reference external design, UX, and data artifacts (Figma files, Lovable prototypes, Loom walkthroughs, screenshots, example payloads, peer Confluence pages). These MUST be preserved onto the resulting tickets — otherwise developers picking up a ticket lose the source of truth. This is the failure mode this step exists to prevent.

package/plugins/lisa/skills/lisa-confluence-write-prd/SKILL.md

@@ -99,6 +99,8 @@ outcome: created | reused
 
 ## Rules
 
+- The PRD body's requirements MUST conform to `prd-definition-of-ready`: identified atoms (`R1`, `R2`, …), one behavior each in an EARS-pattern shape, each with a measurable fit criterion, plus the non-functional checklist. This governs factory-authored bodies; human-authored PRDs are validated at intake instead (`*-to-tracker` Phase 1.45).
+
 - All access via `lisa-atlassian-access`; never call Atlassian directly.
 - State is the parent page, not a label — never attempt Confluence label writes (they 401 on scoped
   tokens; see `config-resolution`).

package/plugins/lisa/skills/lisa-github-to-tracker/SKILL.md

@@ -211,6 +211,30 @@ The register feeds three consumers: the `## Source Requirement` section on
 every created ticket (Phases 3–5), the dry-run report (above), and the
 requirement tokens in the PRD back-link (Phase 7).
 
+### Phase 1.45: Requirement Quality Gates (prd-definition-of-ready)
+
+Validate every Phase 1.4 register entry against the `prd-definition-of-ready` rule before
+planning proceeds. Per atom:
+
+- **Singular** — one behavior per entry. An entry welding multiple shall/when clauses together is
+  split in the register (R4 → R4a/R4b) when the split is mechanical and meaning-preserving; when
+  the split would change meaning, it is a product question, not a repair.
+- **Unambiguous** — FAIL on the vagueness lexicon ("as appropriate", "user-friendly", "fast",
+  "handle gracefully", "etc.", "and/or", unbounded "optimize"/"support"): phrasing no test can
+  check. The full lexicon lives in the rule's reference body.
+- **Verifiable** — a fit criterion (the measurable test of satisfaction) is present or
+  mechanically derivable from the text; a requirement no test could check is not admitted as a
+  requirement.
+- **Pattern shape (SHOULD)** — an EARS pattern (ubiquitous / When / While / If-then / Where) or an
+  equivalent single-behavior sentence; conforming shapes decompose into Gherkin mechanically.
+
+Failures here are **requirement-level product clarifications**, not internal errors: report each in
+the dry-run report as a `product-clarity` item quoting the atom verbatim, naming the defect, and
+offering 1–3 candidate rewrites (an EARS-shaped rewrite is the default recommendation). In intake
+flows these route to the PRD's `blocked` role with comments, exactly like ticket-validator
+failures. Mechanical splits and derived fit criteria are repaired in-register and recorded in the
+report — never silently.
+
 ### Phase 1.5: Extract Source Artifacts
 
 PRDs typically reference external design, UX, and data artifacts (Figma files, Lovable prototypes, Loom walkthroughs, screenshots, example payloads, peer Notion / Confluence / Linear pages). These MUST be preserved onto the resulting tickets — otherwise developers picking up a ticket lose the source of truth. This is the failure mode this step exists to prevent.

package/plugins/lisa/skills/lisa-github-validate-issue/SKILL.md

@@ -76,6 +76,8 @@ Gates are grouped into **Specification** (spec-only checks, no GitHub lookups) a
 
 Each gate is tagged with a fixed `category` and a `product_relevant` boolean. Categories are the same fixed set used by `lisa-jira-validate-ticket` so downstream PRD-intake comment-formatting policy is shared across vendors.
 
+Per-type content requirements are defined once in the vendor-neutral `work-item-definition-of-ready` rule (eager + reference); gates S4–S6 and S17 enforce them, and S18 enforces the stateless-pickup property directly.
+
 | Gate | Category | Product-relevant |
 |------|----------|------------------|
 | S1 Required core fields | `structural` | false |
@@ -94,6 +96,8 @@ Each gate is tagged with a fixed `category` and a `product_relevant` boolean. Ca
 | S14 Evidence manifest binding (leaf work units) | `acceptance-criteria` | true |
 | S15 Leaf-only build-ready | `structural` | false |
 | S16 Source Requirement traceability | `product-clarity` | true |
+| S17 Improvement measurability | `acceptance-criteria` | true |
+| S18 Stateless-pickup dry-run | `product-clarity` | true |
 | F1 Issue type label exists in repo | `structural` | false |
 | F2 Parent sub-issue exists and is the right type | `structural` | false |
 | F3 Linked issues exist | `structural` | false |
@@ -135,18 +139,26 @@ The `## Acceptance Criteria` section must contain at least one `Scenario:` block
 
 #### S5 — Bug-specific content
 
-When `issue_type = Bug`, body must additionally include:
+When `issue_type = Bug`, body must additionally include the full bug anatomy from the `work-item-definition-of-ready` rule:
+
+- **Agent-executable reproduction** — numbered steps a stateless agent can run mechanically: exact entry point, named account/role (consistent with Sign-in Required when authenticated), concrete data state, exact actions. Human-followable-only prose ("click around until it breaks") FAILs. A linked failing test satisfies this outright and is the preferred form.
+- **Expected vs. actual behavior**, naming or linking the *source* of "expected" (spec, PRD requirement, prior release behavior) — a fix target is a fact, not an opinion.
+- **Environment + version** — where reproduced and the build/commit observed; last-known-good when known (`unknown` must be stated, not omitted).
+- **Reproducibility rate** — always, or intermittent with observed frequency; intermittent invalidates run-once verification.
+- **Occurrence evidence** — at least one link/attachment: error-tracker issue, log excerpt, stack trace, screenshot/recording.
 
-- Reproduction steps
-- Expected vs. actual behavior
-- Environment where reproduced
+A Bug's terminal state is its reproduction: the same steps (or test) fail before the fix and pass after — capture both as evidence: under the S14 manifest when `runtime_behavior_change = true`, or attached directly to the item for non-runtime Bugs (doc/config fixes), where S14 is N/A.
 
 #### S6 — Spike-specific content
 
 When `issue_type = Spike`, body must include:
 
-- The question being answered
-- Definition of done (decision doc / prototype / findings deliverable)
+- The **question** being answered
+- The **decision** the answer enables, and the options being weighed
+- A **timebox**
+- **Deliverable format and location** — decision doc / prototype / findings page, and where it will live, so the terminal state — a deliverable at that location that actually answers the question, with findings, decision and options — is checkable
+
+Gherkin AC is intentionally N/A for Spikes (S4).
 
 #### S7 — Parent sub-issue declared
 
@@ -190,6 +202,8 @@ Accept either placement:
 
 Detect by scanning for the phrase `Source Precedence` (case-insensitive) AND verifying the four axes (business rules, visual, flow, data) are each named.
 
+If the spec doesn't set `artifacts_attached`, infer it the same way S9 infers sign-in: scan the body for design/mock/prototype/data-artifact references (design-tool links, "mock", "prototype", spreadsheet or API artifacts). If such artifacts are referenced and no source-precedence guidance exists: FAIL.
+
 #### S13 — Relationship Search documented
 
 The issue must EITHER have at least one entry in `links`, OR the body must contain a `## Relationship Search` block listing the git history queries and `gh issue list` queries that were run with their outcomes. ("Searched git history for `<keywords>` and `gh issue list` for label `component:X`; no related work found.")
@@ -269,6 +283,22 @@ R-id with no quote: FAIL with remediation
 `product_relevant: true` — a issue whose requirement cannot be traced is
 a product-clarity problem: nobody can tell why the work exists.
 
+#### S17 — Improvement measurability
+
+When `issue_type = Improvement`, the body must define the improvement as a measured delta per `work-item-definition-of-ready`:
+
+- **Metric + measurement method** the agent can run (command, query, dashboard export)
+- **Baseline** — the current measured value (a number, not an adjective)
+- **Target** — the numeric value or bound that defines done
+
+Without a baseline and a target an Improvement has no verifiable terminal state and can never be autonomously closed. FAIL names the missing pieces; when no baseline exists yet, the remediation is to file measuring it as the first step. `N/A` for every other type.
+
+#### S18 — Stateless-pickup dry-run
+
+The autonomy gate, run last, on every build-ready leaf (use the S15 classification; `N/A` for containers and non-build-ready items). Simulate a stateless agent reading only this item and the links it can resolve — session knowledge about the codebase does not count, because the next claimant will not have it. List every question that agent would have to ask a human before starting work, before choosing between materially different implementations, or before declaring the work done.
+
+Zero questions → PASS. Any question → FAIL, with each question listed verbatim as its own remediation line — these are exactly the clarifying comments the caller posts to the source. The structure gates are proxies; this gate checks the readiness property itself: `ready` means a stateless agent can drive this item to its terminal state with zero human clarification (see `work-item-definition-of-ready`).
+
 ### Feasibility Gates (require GitHub lookups; skip in `--spec-only`)
 
 #### F1 — Issue type label exists in repo
@@ -423,6 +453,8 @@ Output is a single fenced text block. Callers parse it; do not add free-form pro
 - [PASS|FAIL|N/A] S14 Evidence manifest binding — <one-line reason>
 - [PASS|FAIL|N/A] S15 Leaf-only build-ready — <one-line reason>
 - [PASS|FAIL|N/A] S16 Source Requirement traceability — <one-line reason>
+- [PASS|FAIL|N/A] S17 Improvement measurability — <one-line reason>
+- [PASS|FAIL|N/A] S18 Stateless-pickup dry-run — <one-line reason>
 
 ### Feasibility Gates  (omit this section when --spec-only)
 - [PASS|FAIL|N/A] F1 Issue type label exists in repo — <one-line reason>
@@ -449,7 +481,7 @@ The verdict is `PASS` if every applicable gate is `PASS`. Any `FAIL` makes the v
 
 Same shape and meaning as `lisa-jira-validate-ticket` so downstream PRD-intake skills (Notion, Confluence, Linear, GitHub) can format comments uniformly:
 
-- **gate**: the gate ID (`S1`–`S15`, `F1`–`F5`).
+- **gate**: the gate ID (`S1`–`S18`, `F1`–`F5`).
 - **category**: the gate's fixed category from the table.
 - **product_relevant**: matches the gate's table entry. `false` means the failure is an internal data-quality problem the caller should fix without bothering product.
 - **what**: plain-language, product-readable.

package/plugins/lisa/skills/lisa-github-write-prd/SKILL.md

@@ -146,6 +146,8 @@ outcome: created | reused
 
 ## Rules
 
+- The PRD body's requirements MUST conform to `prd-definition-of-ready`: identified atoms (`R1`, `R2`, …), one behavior each in an EARS-pattern shape, each with a measurable fit criterion, plus the non-functional checklist. This governs factory-authored bodies; human-authored PRDs are validated at intake instead (`*-to-tracker` Phase 1.45).
+
 - Exactly one PRD lifecycle label at all times (leaf-only does not apply — PRDs are not build leaves).
 - Match dedupe by marker, never by title.
 - Preserve an existing canonical `## Lisa Usage` section on update; never append a second usage

package/plugins/lisa/skills/lisa-jira-validate-ticket/SKILL.md

@@ -73,6 +73,8 @@ Gates are grouped into **Specification** (spec-only checks, no JIRA lookups) and
 
 Each gate is tagged with a fixed `category` and a `product_relevant` boolean. Categories drive how downstream callers (notably `lisa-notion-prd-intake`) translate failures into product-facing comments; `product_relevant=false` failures indicate internal data-quality problems (broken parent links, missing core fields) that the agent should fix itself rather than ask product to clarify.
 
+Per-type content requirements are defined once in the vendor-neutral `work-item-definition-of-ready` rule (eager + reference); gates S4–S6 and S17 enforce them, and S18 enforces the stateless-pickup property directly.
+
 | Gate | Category | Product-relevant |
 |------|----------|------------------|
 | S1 Required core fields | `structural` | false |
@@ -91,6 +93,8 @@ Each gate is tagged with a fixed `category` and a `product_relevant` boolean. Ca
 | S14 Evidence manifest binding (leaf work units) | `acceptance-criteria` | true |
 | S15 Leaf-only build-ready | `structural` | false |
 | S16 Source Requirement traceability | `product-clarity` | true |
+| S17 Improvement measurability | `acceptance-criteria` | true |
+| S18 Stateless-pickup dry-run | `product-clarity` | true |
 | F1 Issue type valid in project | `structural` | false |
 | F2 Epic parent exists and is an Epic | `structural` | false |
 | F3 Linked tickets exist | `structural` | false |
@@ -138,16 +142,26 @@ The `Acceptance Criteria` section must contain at least one criterion in `Given
 
 #### S5 — Bug-specific content
 
-When `issue_type = Bug`, description must additionally include:
-- Reproduction steps
-- Expected vs. actual behavior
-- Environment where reproduced
+When `issue_type = Bug`, description must additionally include the full bug anatomy from the `work-item-definition-of-ready` rule:
+
+- **Agent-executable reproduction** — numbered steps a stateless agent can run mechanically: exact entry point, named account/role (consistent with Sign-in Required when authenticated), concrete data state, exact actions. Human-followable-only prose ("click around until it breaks") FAILs. A linked failing test satisfies this outright and is the preferred form.
+- **Expected vs. actual behavior**, naming or linking the *source* of "expected" (spec, PRD requirement, prior release behavior) — a fix target is a fact, not an opinion.
+- **Environment + version** — where reproduced and the build/commit observed; last-known-good when known (`unknown` must be stated, not omitted).
+- **Reproducibility rate** — always, or intermittent with observed frequency; intermittent invalidates run-once verification.
+- **Occurrence evidence** — at least one link/attachment: error-tracker issue, log excerpt, stack trace, screenshot/recording.
+
+A Bug's terminal state is its reproduction: the same steps (or test) fail before the fix and pass after — capture both as evidence: under the S14 manifest when `runtime_behavior_change = true`, or attached directly to the item for non-runtime Bugs (doc/config fixes), where S14 is N/A.
 
 #### S6 — Spike-specific content
 
 When `issue_type = Spike`, description must include:
-- The question being answered
-- Definition of done (decision doc / prototype / findings deliverable)
+
+- The **question** being answered
+- The **decision** the answer enables, and the options being weighed
+- A **timebox**
+- **Deliverable format and location** — decision doc / prototype / findings page, and where it will live, so the terminal state — a deliverable at that location that actually answers the question, with findings, decision and options — is checkable
+
+Gherkin AC is intentionally N/A for Spikes (S4).
 
 #### S7 — Epic parent declared
 
@@ -191,6 +205,8 @@ Accept either placement — both are valid per `lisa-tracker-source-artifacts`:
 
 Detect by scanning for the phrase `Source Precedence` (case-insensitive) anywhere in the description, AND verifying the four axes (business rules, visual, flow, data) are each named. Missing the phrase OR missing one or more axes: FAIL with a remediation that names the missing axes.
 
+If the spec doesn't set `artifacts_attached`, infer it the same way S9 infers sign-in: scan the description for design/mock/prototype/data-artifact references (design-tool links, "mock", "prototype", spreadsheet or API artifacts). If such artifacts are referenced and no source-precedence guidance exists: FAIL.
+
 #### S13 — Relationship Search documented
 
 The ticket must EITHER have at least one issue link in `links`, OR the description / a comment must contain a `## Relationship Search` block listing the git history queries and JQL queries that were run with their outcomes ("Searched git history for `<keywords>` and JQL for component=`X`; no related work found.").
@@ -269,6 +285,22 @@ R-id with no quote: FAIL with remediation
 `product_relevant: true` — a ticket whose requirement cannot be traced is
 a product-clarity problem: nobody can tell why the work exists.
 
+#### S17 — Improvement measurability
+
+When `issue_type = Improvement`, the description must define the improvement as a measured delta per `work-item-definition-of-ready`:
+
+- **Metric + measurement method** the agent can run (command, query, dashboard export)
+- **Baseline** — the current measured value (a number, not an adjective)
+- **Target** — the numeric value or bound that defines done
+
+Without a baseline and a target an Improvement has no verifiable terminal state and can never be autonomously closed. FAIL names the missing pieces; when no baseline exists yet, the remediation is to file measuring it as the first step. `N/A` for every other type.
+
+#### S18 — Stateless-pickup dry-run
+
+The autonomy gate, run last, on every build-ready leaf (use the S15 classification; `N/A` for containers and non-build-ready items). Simulate a stateless agent reading only this item and the links it can resolve — session knowledge about the codebase does not count, because the next claimant will not have it. List every question that agent would have to ask a human before starting work, before choosing between materially different implementations, or before declaring the work done.
+
+Zero questions → PASS. Any question → FAIL, with each question listed verbatim as its own remediation line — these are exactly the clarifying comments the caller posts to the source. The structure gates are proxies; this gate checks the readiness property itself: `ready` means a stateless agent can drive this item to its terminal state with zero human clarification (see `work-item-definition-of-ready`).
+
 ### Feasibility Gates (require JIRA lookups; skip in dry-run if requested)
 
 #### F1 — Issue type valid in project
@@ -354,6 +386,8 @@ Output is a single fenced text block. Callers parse it; do not add free-form pro
 - [PASS|FAIL|N/A] S14 Evidence manifest binding — <one-line reason>
 - [PASS|FAIL|N/A] S15 Leaf-only build-ready — <one-line reason>
 - [PASS|FAIL|N/A] S16 Source Requirement traceability — <one-line reason>
+- [PASS|FAIL|N/A] S17 Improvement measurability — <one-line reason>
+- [PASS|FAIL|N/A] S18 Stateless-pickup dry-run — <one-line reason>
 
 ### Feasibility Gates  (omit this section when --spec-only)
 - [PASS|FAIL|N/A] F1 Issue type valid in project — <one-line reason>
@@ -379,7 +413,7 @@ The verdict is `PASS` if and only if every applicable gate is `PASS`. Any `FAIL`
 
 ### Failure-detail fields
 
-- **gate**: the gate ID (`S1`–`S15`, `F1`–`F5`).
+- **gate**: the gate ID (`S1`–`S18`, `F1`–`F5`).
 - **category**: the gate's fixed category from the table above. Callers use this to label or filter comments — `product-clarity`, `acceptance-criteria`, `design-ux`, `scope`, `dependency`, `data`, `technical`, or `structural`.
 - **product_relevant**: matches the gate's table entry. `false` means the failure is an internal data-quality problem (e.g., the agent built a malformed spec, an issue type is invalid in the project) and the caller should fix it without bothering the product team. `true` means the PRD needs product input to resolve.
 - **what**: plain-language description of the issue. No gate IDs, no JIRA jargon, no engineering shorthand. A product owner reading this on a Notion comment should understand what is unclear and why.

package/plugins/lisa/skills/lisa-linear-to-tracker/SKILL.md

@@ -208,6 +208,30 @@ The register feeds three consumers: the `## Source Requirement` section on
 every created ticket (Phases 3–5), the dry-run report (above), and the
 requirement tokens in the PRD back-link (Phase 7).
 
+### Phase 1.45: Requirement Quality Gates (prd-definition-of-ready)
+
+Validate every Phase 1.4 register entry against the `prd-definition-of-ready` rule before
+planning proceeds. Per atom:
+
+- **Singular** — one behavior per entry. An entry welding multiple shall/when clauses together is
+  split in the register (R4 → R4a/R4b) when the split is mechanical and meaning-preserving; when
+  the split would change meaning, it is a product question, not a repair.
+- **Unambiguous** — FAIL on the vagueness lexicon ("as appropriate", "user-friendly", "fast",
+  "handle gracefully", "etc.", "and/or", unbounded "optimize"/"support"): phrasing no test can
+  check. The full lexicon lives in the rule's reference body.
+- **Verifiable** — a fit criterion (the measurable test of satisfaction) is present or
+  mechanically derivable from the text; a requirement no test could check is not admitted as a
+  requirement.
+- **Pattern shape (SHOULD)** — an EARS pattern (ubiquitous / When / While / If-then / Where) or an
+  equivalent single-behavior sentence; conforming shapes decompose into Gherkin mechanically.
+
+Failures here are **requirement-level product clarifications**, not internal errors: report each in
+the dry-run report as a `product-clarity` item quoting the atom verbatim, naming the defect, and
+offering 1–3 candidate rewrites (an EARS-shaped rewrite is the default recommendation). In intake
+flows these route to the PRD's `blocked` role with comments, exactly like ticket-validator
+failures. Mechanical splits and derived fit criteria are repaired in-register and recorded in the
+report — never silently.
+
 ### Phase 1.5: Extract Source Artifacts
 
 PRDs typically reference external design, UX, and data artifacts (Figma files, Lovable prototypes, Loom walkthroughs, screenshots, example payloads, peer Linear or Confluence pages). These MUST be preserved onto the resulting tickets — otherwise developers picking up a ticket lose the source of truth. This is the failure mode this step exists to prevent.

package/plugins/lisa/skills/lisa-linear-validate-issue/SKILL.md

@@ -74,6 +74,8 @@ Gates are grouped into **Specification** (spec-only checks, no Linear lookups) a
 
 Each gate is tagged with a fixed `category` and a `product_relevant` boolean. Categories drive how downstream callers (notably `lisa-linear-prd-intake`) translate failures into product-facing comments; `product_relevant=false` failures indicate internal data-quality problems the agent should fix itself rather than ask product to clarify.
 
+Per-type content requirements are defined once in the vendor-neutral `work-item-definition-of-ready` rule (eager + reference); gates S4–S6 and S17 enforce them, and S18 enforces the stateless-pickup property directly.
+
 | Gate | Category | Product-relevant |
 |------|----------|------------------|
 | S1 Required core fields | `structural` | false |
@@ -92,6 +94,8 @@ Each gate is tagged with a fixed `category` and a `product_relevant` boolean. Ca
 | S14 Evidence manifest binding (leaf work units) | `acceptance-criteria` | true |
 | S15 Leaf-only build-ready | `structural` | false |
 | S16 Source Requirement traceability | `product-clarity` | true |
+| S17 Improvement measurability | `acceptance-criteria` | true |
+| S18 Stateless-pickup dry-run | `product-clarity` | true |
 | F1 Issue type valid in team | `structural` | false |
 | F2 Project parent exists and is in same team | `structural` | false |
 | F3 Linked items exist | `structural` | false |
@@ -139,16 +143,26 @@ The `Acceptance Criteria` section must contain at least one criterion in `Given
 
 #### S5 — Bug-specific content
 
-When `issue_type = Bug`, description must additionally include:
-- Reproduction steps
-- Expected vs. actual behavior
-- Environment where reproduced
+When `issue_type = Bug`, description must additionally include the full bug anatomy from the `work-item-definition-of-ready` rule:
+
+- **Agent-executable reproduction** — numbered steps a stateless agent can run mechanically: exact entry point, named account/role (consistent with Sign-in Required when authenticated), concrete data state, exact actions. Human-followable-only prose ("click around until it breaks") FAILs. A linked failing test satisfies this outright and is the preferred form.
+- **Expected vs. actual behavior**, naming or linking the *source* of "expected" (spec, PRD requirement, prior release behavior) — a fix target is a fact, not an opinion.
+- **Environment + version** — where reproduced and the build/commit observed; last-known-good when known (`unknown` must be stated, not omitted).
+- **Reproducibility rate** — always, or intermittent with observed frequency; intermittent invalidates run-once verification.
+- **Occurrence evidence** — at least one link/attachment: error-tracker issue, log excerpt, stack trace, screenshot/recording.
+
+A Bug's terminal state is its reproduction: the same steps (or test) fail before the fix and pass after — capture both as evidence: under the S14 manifest when `runtime_behavior_change = true`, or attached directly to the item for non-runtime Bugs (doc/config fixes), where S14 is N/A.
 
 #### S6 — Spike-specific content
 
 When `issue_type = Spike`, description must include:
-- The question being answered
-- Definition of done (decision doc / prototype / findings deliverable)
+
+- The **question** being answered
+- The **decision** the answer enables, and the options being weighed
+- A **timebox**
+- **Deliverable format and location** — decision doc / prototype / findings page, and where it will live, so the terminal state — a deliverable at that location that actually answers the question, with findings, decision and options — is checkable
+
+Gherkin AC is intentionally N/A for Spikes (S4).
 
 #### S7 — Project parent declared
 
@@ -194,6 +208,8 @@ Accept either placement:
 
 Detect by scanning for the phrase `Source Precedence` (case-insensitive) anywhere in the description AND verifying the four axes are each named. Missing the phrase OR any axis: FAIL with remediation naming the missing axes.
 
+If the spec doesn't set `artifacts_attached`, infer it the same way S9 infers sign-in: scan the description for design/mock/prototype/data-artifact references (design-tool links, "mock", "prototype", spreadsheet or API artifacts). If such artifacts are referenced and no source-precedence guidance exists: FAIL.
+
 #### S13 — Relationship Search documented
 
 The item must EITHER have at least one entry in `relations`, OR the description / a comment must contain a `## Relationship Search` block listing the git history queries and Linear MCP queries that were run with their outcomes.
@@ -271,6 +287,22 @@ R-id with no quote: FAIL with remediation
 `product_relevant: true` — a issue whose requirement cannot be traced is
 a product-clarity problem: nobody can tell why the work exists.
 
+#### S17 — Improvement measurability
+
+When `issue_type = Improvement`, the description must define the improvement as a measured delta per `work-item-definition-of-ready`:
+
+- **Metric + measurement method** the agent can run (command, query, dashboard export)
+- **Baseline** — the current measured value (a number, not an adjective)
+- **Target** — the numeric value or bound that defines done
+
+Without a baseline and a target an Improvement has no verifiable terminal state and can never be autonomously closed. FAIL names the missing pieces; when no baseline exists yet, the remediation is to file measuring it as the first step. `N/A` for every other type.
+
+#### S18 — Stateless-pickup dry-run
+
+The autonomy gate, run last, on every build-ready leaf (use the S15 classification; `N/A` for containers and non-build-ready items). Simulate a stateless agent reading only this item and the links it can resolve — session knowledge about the codebase does not count, because the next claimant will not have it. List every question that agent would have to ask a human before starting work, before choosing between materially different implementations, or before declaring the work done.
+
+Zero questions → PASS. Any question → FAIL, with each question listed verbatim as its own remediation line — these are exactly the clarifying comments the caller posts to the source. The structure gates are proxies; this gate checks the readiness property itself: `ready` means a stateless agent can drive this item to its terminal state with zero human clarification (see `work-item-definition-of-ready`).
+
 ### Feasibility Gates (require Linear lookups; skip in dry-run if requested)
 
 #### F1 — Issue type valid in team
@@ -360,6 +392,8 @@ Output is a single fenced text block. Callers parse it; do not add free-form pro
 - [PASS|FAIL|N/A] S14 Evidence manifest binding — <one-line reason>
 - [PASS|FAIL|N/A] S15 Leaf-only build-ready — <one-line reason>
 - [PASS|FAIL|N/A] S16 Source Requirement traceability — <one-line reason>
+- [PASS|FAIL|N/A] S17 Improvement measurability — <one-line reason>
+- [PASS|FAIL|N/A] S18 Stateless-pickup dry-run — <one-line reason>
 
 ### Feasibility Gates  (omit when --spec-only)
 - [PASS|FAIL|N/A] F1 Issue type valid in team — <one-line reason>