@codyswann/lisa 2.303.0 → 2.304.1

package/package.json

@@ -115,7 +115,7 @@
     "brace-expansion": ">=5.0.8"
   },
   "name": "@codyswann/lisa",
-  "version": "2.303.0",
+  "version": "2.304.1",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

package/plugins/lisa/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.303.0",
+  "version": "2.304.1",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.303.0",
+  "version": "2.304.1",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

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

@@ -218,6 +218,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/.codex-plugin/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/.codex-plugin/skills/lisa-github-to-tracker/SKILL.md

@@ -203,6 +203,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/.codex-plugin/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/.codex-plugin/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/.codex-plugin/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/.codex-plugin/skills/lisa-linear-to-tracker/SKILL.md

@@ -203,6 +203,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/.codex-plugin/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>

package/plugins/lisa/.codex-plugin/skills/lisa-linear-write-prd/SKILL.md

@@ -86,6 +86,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 project-label at all times.
 - Match dedupe by marker, never by project name.
 - Preserve an existing canonical `## Lisa Usage` section on update; never append a second usage

package/plugins/lisa/.codex-plugin/skills/lisa-notion-to-tracker/SKILL.md

@@ -184,6 +184,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, 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/.codex-plugin/skills/lisa-notion-write-prd/SKILL.md

@@ -100,6 +100,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-notion-access`; never touch the Notion API/MCP directly.
 - Match dedupe by marker, never by title.
 - Preserve an existing canonical `## Lisa Usage` section on update; never append a second usage

package/plugins/lisa/.codex-plugin/skills/lisa-research/SKILL.md

@@ -56,7 +56,9 @@ A PRD **created in the configured PRD source** (per the intent-routing rule's Re
 definition) structured as: problem statement, high-level solution description, links (if needed),
 user stories (each with its own functional/non-functional requirements and, only for stories with
 new UI/visual work, a design-file pointer), overall acceptance criteria, open questions, and the
-"Recommended Tooling for Plan Phase" section. The final
+"Recommended Tooling for Plan Phase" section. Requirements MUST conform to the
+`prd-definition-of-ready` rule: identified atoms (`R1`, `R2`, …), one behavior each in an
+EARS-pattern shape, each with a measurable fit criterion, plus the non-functional checklist. The final
 flow step invokes `lisa-prd-source-write`, which creates the PRD in the configured `source` (Notion
 page in the PRD database, Confluence page under the lifecycle parent, GitHub issue, or Linear
 project) in the `draft` role by default or `ready` when `prd_ready=true`. **The PRD lives in the

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

@@ -0,0 +1,32 @@
+# PRD Definition of Ready (requirement atoms)
+
+**A requirements document is ready when a planner can decompose it mechanically and a verifier can check the result against it.** Both properties come from the shape of the requirements, not the prose around them. Modeled on ISO/IEC/IEEE 29148's requirement quality characteristics and the EARS sentence patterns; the fit criterion is Volere's.
+
+## The atom
+
+Every requirement is an **identified atom**:
+
+- **Identified** — carries an id (`R1`, `R2`, …). Ids are per-generation; the verbatim text is the durable anchor (same convention as the `*-to-tracker` Requirement Register).
+- **Singular** — one behavior per atom. "The system shall X and Y when Z" is two atoms.
+- **Unambiguous** — no vagueness lexicon: *as appropriate, user-friendly, fast, robust, handle gracefully, etc., and/or, optimize, seamless, intuitive, support* (unbounded). Each is a word no test can check.
+- **Verifiable** — carries a **fit criterion**: the measurable test of satisfaction ("p95 upload completes < 4s for files ≤ 25 MB"). A requirement no test could check is a wish.
+- **Pattern-shaped (SHOULD)** — one of the EARS patterns, which decompose into Gherkin mechanically:
+  - Ubiquitous: *The `<system>` shall `<response>`*
+  - Event-driven: *When `<trigger>`, the `<system>` shall `<response>`*
+  - State-driven: *While `<state>`, the `<system>` shall `<response>`*
+  - Unwanted behavior: *If `<condition>`, then the `<system>` shall `<response>`*
+  - Optional feature: *Where `<feature>` is present, the `<system>` shall `<response>`*
+
+## The document
+
+Beyond the atoms, a ready PRD carries: problem statement · solution outline · user stories grouping their atoms · an explicit **non-functional checklist** (walk the ISO 25010 axes — performance, security, reliability, usability, compatibility, maintainability — and either state the requirement as an atom or state "no requirement"; silence is not a decision) · out of scope · open questions (the honest home for what is NOT ready).
+
+## Enforcement points
+
+- **Write time** — `lisa-research` authors to this shape; `*-write-prd` skills carry it as a body rule.
+- **Intake time (the universal gate)** — `*-to-tracker` Phase 1.45 validates every register atom, because human-authored PRDs never pass through the write path. Failures are product clarifications quoting the atom verbatim with candidate rewrites.
+- **Verify time** — `verify-prd` / spec-conformance consume the atoms; fit criteria become the conformance checks.
+
+Downstream, ticket gate S16 quotes these atoms verbatim and `prd-ticket-coverage` audits atom→ticket coverage — both degrade when "one requirement" is secretly three welded together.
+
+Full rationale, the vagueness lexicon, and worked rewrites: [the reference body of this rule](../reference/prd-definition-of-ready.md).

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

@@ -0,0 +1,27 @@
+# Work-Item Definition of Ready (type-keyed)
+
+**`ready` means: a stateless agent can claim this item and drive it to its terminal state with zero human clarification.** Every readiness gate exists because its absence forces a question; the bar is type-keyed because different work types break autonomy differently.
+
+## Shared core (every leaf, enforced by `*-validate-*` S1–S16)
+
+Three-audience description · Gherkin acceptance criteria (except Spike) · Out of Scope · single-repo scope · relationship search · typed evidence manifest on runtime changes · Source Requirement traceability when PRD-sourced · provable read access to every named external surface.
+
+## Per-type additions
+
+| Type | Must additionally carry | Terminal state is |
+|---|---|---|
+| **Bug** | agent-executable reproduction (or a failing test) · expected-vs-actual with the *source* of "expected" · environment + version observed, last-known-good when known · reproducibility rate (always / intermittent + frequency) · at least one occurrence evidence link | the same repro/test fails before the fix and passes after |
+| **Story** | user-visible AC; SHOULD name non-happy-path states (error / empty / loading) for UI stories · design source precedence when artifacts exist | every AC exercised on the running product |
+| **Task** | an observable done-state and the command/check that proves it | the verification check passes |
+| **Improvement** | metric + measurement method the agent can run · measured baseline value · numeric target | measured value meets the target |
+| **Spike** | the question · the decision it enables + options weighed · a timebox · deliverable format **and location** | a deliverable at the named location that answers the question — findings, decision, options weighed |
+| **Sub-task** | a parent, always · otherwise the bar of its own type | per its type |
+| **Epic / container** | never build-ready (`leaf-only-lifecycle`) · judged on decomposition completeness, not buildability | all required children terminal |
+
+## The stateless-pickup test (S18)
+
+The final gate checks the property itself instead of proxies for it: read the item as a fresh agent with no session context, using only the item and what it links to. List every question you would have to ask a human before starting, choosing between materially different implementations, or declaring done. **Ready = zero questions.** Each question found is the FAIL remediation, verbatim.
+
+Sources this bar distills: INVEST (stories) · ISTQB / IEEE 1044 defect anatomy and minimal-reproducible-example practice (bugs) · SMART (improvements) · Scrum's Definition of Ready (the framing) · TASC AC8.6 (the normative criterion).
+
+Full rationale and worked examples: [the reference body of this rule](../reference/work-item-definition-of-ready.md).