@codyswann/lisa 2.303.0 → 2.304.0

package/plugins/lisa-copilot/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-copilot/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-copilot/skills/lisa-notion-to-tracker/SKILL.md

@@ -190,6 +190,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-copilot/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-copilot/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-cursor/.claude-plugin/plugin.json

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

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

@@ -0,0 +1,86 @@
+---
+description: "PRD Definition of Ready — Reference"
+alwaysApply: false
+---
+
+# 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-cursor/rules/prd-definition-of-ready.mdc

@@ -0,0 +1,37 @@
+---
+description: "PRD Definition of Ready (requirement atoms)"
+alwaysApply: true
+---
+
+# 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](prd-definition-of-ready-reference.mdc).

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

@@ -0,0 +1,150 @@
+---
+description: "Work-Item Definition of Ready — Reference"
+alwaysApply: false
+---
+
+# 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-cursor/rules/work-item-definition-of-ready.mdc

@@ -0,0 +1,32 @@
+---
+description: "Work-Item Definition of Ready (type-keyed)"
+alwaysApply: true
+---
+
+# 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](work-item-definition-of-ready-reference.mdc).

package/plugins/lisa-cursor/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-cursor/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-cursor/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.