@codyswann/lisa 2.215.0 → 2.217.0

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

@@ -38,16 +38,24 @@ resolvable anchor exists).
 ```text
 ## confluence-to-tracker dry-run: <PRD title>
 
+### Requirement register
+- R1 §"<section heading>": "<verbatim requirement text>"
+- R2 §"<section heading>": "<verbatim requirement text>"
+- ...
+
 ### Planned hierarchy
 - Epic: <summary>
   prd_section: "<heading text from the PRD that produced this epic>"
   prd_anchor: "<inline-comment anchor text>"   # null if no specific section
+  requirements: [R1, R2]   # register ids this ticket exists to satisfy; [] only for derived work
   - Story 1.1: <summary>
     prd_section: "<heading or user-story line>"
     prd_anchor: "<anchor>"
+    requirements: [R1]
     - Sub-task [<repo>]: <summary>
       prd_section: "<heading or AC bullet>"
       prd_anchor: "<anchor>"
+      requirements: [R1]
     - ...
   - Story 1.2: ...
 
@@ -93,6 +101,38 @@ Why parent-page-based, not label-based: scoped Atlassian API tokens cannot write
 
 Bypassing `lisa-tracker-write` produces thin tickets that the rest of the lifecycle (triage, ticket-verify, journey, evidence) treats as broken. Read operations on Atlassian (ticket reads, JQL search, Confluence page reads, comment fetches) are still performed in this skill — but ONLY via `lisa-atlassian-access` (`operation: read-ticket | search-issues | read-page | search-pages | list-sites`), never via direct MCP tool calls or `acli`.
 
+## Source Requirement Section (shared format)
+
+Every ticket created by this skill — epic, story, and sub-task alike —
+carries a `## Source Requirement` section in its description so anyone can
+answer "why was this done?" without leaving the ticket:
+
+```markdown
+## Source Requirement
+
+- **PRD**: [<PRD title>](<PRD URL>) §"<section heading>"
+- **Requirement (R3)**: "<verbatim requirement text from the PRD>"
+
+This ticket exists to satisfy the quoted requirement. If implementation
+scope drifts from the quoted text, the PRD is the authority — raise the
+conflict rather than silently reinterpreting it.
+```
+
+Rules:
+
+- **Verbatim quotes, never paraphrases.** The quote is what survives later
+  PRD edits, and it must be readable by a non-technical operator.
+- **Multiple requirements** → one `**Requirement (Rn)**` line each.
+- **Derived / cross-cutting work** (no single requirement) uses the
+  supporting form instead:
+  `- **Requirement**: Derived work supporting R3, R7 — no single PRD section.`
+- **All the way down**: sub-tasks carry full quotes, not just a pointer at
+  the parent Story, so a leaf claimed by build-intake in isolation is
+  self-explanatory.
+- JIRA descriptions render the section as `h2. Source Requirement`;
+  GitHub/Linear use the markdown heading. `lisa-tracker-write` and the
+  validators treat the section as mandatory for PRD-sourced tickets.
+
 ## Input
 
 A Confluence PRD page URL or page ID. The PRD is expected to have:
@@ -156,6 +196,34 @@ If env vars are not available, ask the user to provide them explicitly before pr
    - Engineering comments (prefixed with "Engineering:" or wrench emoji) that identify technical constraints
    - Cross-PRD dependencies (references to other features or shared infrastructure)
 
+### Phase 1.4: Requirement Register (traceability)
+
+Every ticket this skill creates must be able to answer "why was this done?"
+by pointing at the PRD requirement it satisfies. Build that mapping now,
+while parsing the PRD — it cannot be reliably reconstructed afterwards.
+
+1. **Atomize the PRD into requirements** in document order: goals, user
+   stories, functional and non-functional requirements, acceptance-criteria
+   bullets, and important notes. Use the same atomization
+   `lisa-prd-ticket-coverage` uses so the two views line up.
+2. **Assign sequential register ids** (`R1`, `R2`, …). Ids are
+   per-generation, not durable — the **verbatim quote is the durable
+   anchor**; if the PRD is edited and re-planned, ids may shift but quotes
+   still identify the requirement.
+3. **Record each entry** as `{ id, verbatim_text, section_heading }` plus
+   the inline-comment anchor capture described in the dry-run format above.
+4. **Tag every planned ticket** — epic, story, AND sub-task — with the
+   register ids it exists to satisfy. All the way down: sub-tasks carry
+   their own requirement quotes so a leaf dispatched in isolation is
+   self-explanatory. A ticket that genuinely traces to no single
+   requirement (cross-cutting infrastructure, derived enablement work)
+   gets `requirements: []` and must say which requirements it *supports*
+   in its Source Requirement section instead.
+
+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.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.
@@ -202,8 +270,10 @@ For each PRD epic, **invoke the `lisa-tracker-write` skill** (do not invoke `lis
 
 - `project_key`: resolved by `lisa-tracker-write` from `.lisa.config.json`
 - `issue_type`: `Epic`
+- `prd_source`: the originating PRD URL — mandatory for every ticket this skill creates; it arms the validator's S16 traceability gate
 - `summary`: epic title from the PRD
 - `description_body`: a draft of the 3-audience description containing:
+  - A **Source Requirement** section (see the shared format above) citing the Confluence page URL, section heading, and the verbatim text of every register requirement (`R-id`) this epic exists to satisfy
   - **Context / Business Value**: epic summary from the PRD, originating Confluence URL, business outcome
   - **Technical Approach**: cross-cutting integration points and constraints surfaced in Phase 2 codebase research
   - List of user stories the epic contains
@@ -232,9 +302,10 @@ For each story, **invoke `lisa-tracker-write`** with:
 
 - `project_key`: resolved by `lisa-tracker-write` from `.lisa.config.json`
 - `issue_type`: `Story`
+- `prd_source`: the originating PRD URL — mandatory for every ticket this skill creates; it arms the validator's S16 traceability gate
 - `epic_parent`: the Epic key captured in Phase 3 (mandatory)
 - `summary`: prefixed per the naming convention above
-- `description_body`: 3-audience description as in `lisa-notion-to-tracker` Phase 4
+- `description_body`: 3-audience description as in `lisa-notion-to-tracker` Phase 4, including as its first element a **Source Requirement** section (shared format above) quoting the register requirement(s) this story satisfies
 - `artifacts`: the Phase 1.5 artifacts filtered by domain per the inheritance table below
 
 | Story type | Inherits domains |
@@ -259,6 +330,7 @@ Delegate sub-task creation to **parallel agents** (one per epic or batch of stor
 Each sub-task MUST:
 1. **Be scoped to exactly ONE repo** — indicated in brackets in the summary: `[repo-name]` and in the description's `## Repository` / `h2. Repository` section
 2. **Include an Empirical Verification Plan** — real user-like verification, NOT unit tests, linting, or typechecking
+3. **Carry its own `## Source Requirement` section** (shared format above) with the full verbatim quote(s) from the Phase 1.4 register — a leaf claimed by build-intake in isolation must be self-explanatory. When a sub-task is split per-repo, every split child inherits the same requirement quote(s).
 
 **Leaf-only build-ready (`leaf-only-lifecycle`)**: Sub-tasks are the **leaf work units** of the decomposition — they are the ONLY items in the hierarchy that receive the build-ready label. `lisa-tracker-write` applies `status:ready` here so downstream build intake (`lisa-tracker-build-intake`) claims the leaves and never the Epic or Stories. Apply `status:ready` to each Sub-task; never to its parent Story or Epic (Phases 3–4). `lisa-tracker-write` enforces the same invariant on the write side, so a Sub-task split into per-repo children (the cross-repo case above) carries build-ready on the children, not on any intermediate parent that gains child work.
 
@@ -283,6 +355,7 @@ After all tickets are created, present a summary table to the user:
 - All Epics with keys and URLs
 - All Stories grouped by Epic
 - All Sub-tasks grouped by Story with repo tags
+- **Requirement coverage** — one row per Phase 1.4 register entry (`R-id`, quote excerpt, tickets that declare it); requirements with zero tickets are a gap to resolve before reporting success
 - Repo distribution
 - **Artifact Preservation Matrix**
 - Blockers list with recommendations and alternatives
@@ -298,7 +371,8 @@ Invoke `lisa-prd-backlink` with:
 
 - `source_type: "confluence"`
 - `source_ref`: the original Confluence page URL
-- `tickets`: the full list created in Phases 3–5, each entry as `{ key, title, type, url, parent_key }`
+- `tickets`: the full list created in Phases 3–5, each entry as `{ key, title, type, url, parent_key, requirements }` — `requirements` is the list of Phase 1.4 register ids the ticket satisfies (empty for derived work)
+- `requirement_register`: the Phase 1.4 register (`{ id, verbatim_text, section_heading }` entries), so the back-link section can render the requirement → tickets view
 
 If `lisa-prd-backlink` fails (page permission denied, Confluence unreachable), surface the error in the Phase 6 report rather than aborting — the tickets are already created. Recommend the user re-run `lisa-prd-backlink` standalone once the source is reachable.
 
@@ -327,10 +401,11 @@ tickets that downstream skills (triage, journey, evidence) cannot use.
 
 For each sub-task, invoke `lisa-tracker-write` with:
 - issue_type: "Sub-task"
+- prd_source: [the originating PRD URL — mandatory; arms the S16 traceability gate]
 - parent: the parent story key
 - project_key: [PROJECT]
 - summary: prefixed with the repo in brackets, e.g. "[backend-api] Add audit log table"
-- description_body: a 3-section draft (Context / Technical Approach / Acceptance Criteria) plus `h2. Repository` naming exactly one repo
+- description_body: a 3-section draft (Context / Technical Approach / Acceptance Criteria) plus `h2. Repository` naming exactly one repo, plus `h2. Source Requirement` quoting the PRD requirement(s) this sub-task satisfies VERBATIM with the PRD link and register id(s) — [paste the exact requirement text and R-ids for each sub-task from the requirement register; do not let the agent paraphrase]
 - gherkin_acceptance_criteria: derived from the story's functional requirements
 - sign_in_account: [test user credentials from config — name + role + how to obtain]
 - target_environment: "dev"

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

@@ -36,21 +36,29 @@ This skill supports two modes, controlled by a `dry_run` flag in `$ARGUMENTS`:
 - **`dry_run: false`** (default — full mode): run all phases, write tickets via `lisa-tracker-write`, run the preservation gate, report.
 - **`dry_run: true`** (planning + validation only — no writes): run Phases 1, 1.5, 1.6, 2, 3, 4 to plan the hierarchy and draft each ticket spec, then call `lisa-tracker-validate` (with `--spec-only`) on every drafted ticket. Aggregate the per-ticket validator reports into a single dry-run report. **Skip Phase 5 (sub-task creation), Phase 5.5 (preservation gate), and Phase 6 (results report)** — none of those make sense without writes. Return the dry-run report so the caller (e.g. `lisa-github-prd-intake`) can decide whether to proceed.
 
-Dry-run output format is identical to `lisa-notion-to-tracker` / `lisa-confluence-to-tracker` / `lisa-linear-to-tracker`. Reuse the same fields, including `prd_anchor` and `prd_section`. For GitHub, `prd_anchor` is a section heading from the PRD body when the failure traces to a specific section; otherwise `null` (the caller posts unanchored failures as a rollup comment on the PRD issue).
+Dry-run output format is identical to `lisa-notion-to-tracker` / `lisa-confluence-to-tracker` / `lisa-linear-to-tracker`. Reuse the same fields, including `prd_anchor` and `prd_section`, the `### Requirement register` section, and the per-node `requirements:` lists. For GitHub, `prd_anchor` is a section heading from the PRD body when the failure traces to a specific section; otherwise `null` (the caller posts unanchored failures as a rollup comment on the PRD issue).
 
 ```text
 ## github-to-tracker dry-run: <PRD title>
 
+### Requirement register
+- R1 §"<section heading>": "<verbatim requirement text>"
+- R2 §"<section heading>": "<verbatim requirement text>"
+- ...
+
 ### Planned hierarchy
 - Epic: <summary>
   prd_section: "<heading text from the PRD body or sub-issue title that produced this epic>"
   prd_anchor: "<heading text or sub-issue ref or null>"
+  requirements: [R1, R2]   # register ids this ticket exists to satisfy; [] only for derived work
   - Story 1.1: <summary>
     prd_section: "<heading or user-story line>"
     prd_anchor: "<heading or sub-issue ref or null>"
+    requirements: [R1]
     - Sub-task [<repo>]: <summary>
       prd_section: "<heading or AC bullet>"
       prd_anchor: "<heading or sub-issue ref or null>"
+      requirements: [R1]
     - ...
   - Story 1.2: ...
 
@@ -85,6 +93,38 @@ Bypassing the shim layer produces tickets that the rest of the lifecycle (triage
 
 The `gh` reads in this skill are limited to reading the source PRD issue, its sub-issues, and its comments. They never write.
 
+## Source Requirement Section (shared format)
+
+Every ticket created by this skill — Epic, Story, and Sub-task alike —
+carries a `## Source Requirement` section in its body so anyone can
+answer "why was this done?" without leaving the ticket:
+
+```markdown
+## Source Requirement
+
+- **PRD**: [<PRD title>](<PRD URL>) §"<section heading>"
+- **Requirement (R3)**: "<verbatim requirement text from the PRD>"
+
+This ticket exists to satisfy the quoted requirement. If implementation
+scope drifts from the quoted text, the PRD is the authority — raise the
+conflict rather than silently reinterpreting it.
+```
+
+Rules:
+
+- **Verbatim quotes, never paraphrases.** The quote is what survives later
+  PRD edits, and it must be readable by a non-technical operator.
+- **Multiple requirements** → one `**Requirement (Rn)**` line each.
+- **Derived / cross-cutting work** (no single requirement) uses the
+  supporting form instead:
+  `- **Requirement**: Derived work supporting R3, R7 — no single PRD section.`
+- **All the way down**: sub-tasks carry full quotes, not just a pointer at
+  the parent Story, so a leaf claimed by build-intake in isolation is
+  self-explanatory.
+- JIRA descriptions render the section as `h2. Source Requirement`;
+  GitHub/Linear use the markdown heading. `lisa-tracker-write` and the
+  validators treat the section as mandatory for PRD-sourced tickets.
+
 ## Input
 
 A GitHub issue ref. The PRD is expected to have:
@@ -141,6 +181,36 @@ If env vars are not available, ask the user to provide them explicitly before pr
    - Engineering comments (prefixed with "Engineering:" or 🔧) that identify technical constraints.
    - Cross-PRD dependencies (references to other GitHub issues, Notion / Confluence / Linear PRDs, shared infrastructure).
 
+### Phase 1.4: Requirement Register (traceability)
+
+Every ticket this skill creates must be able to answer "why was this done?"
+by pointing at the PRD requirement it satisfies. Build that mapping now,
+while parsing the PRD — it cannot be reliably reconstructed afterwards.
+
+1. **Atomize the PRD into requirements** in document order: goals, user
+   stories, functional and non-functional requirements, acceptance-criteria
+   bullets, and important notes — across the PRD issue body AND every
+   sub-issue body. Use the same atomization `lisa-prd-ticket-coverage`
+   uses so the two views line up.
+2. **Assign sequential register ids** (`R1`, `R2`, …). Ids are
+   per-generation, not durable — the **verbatim quote is the durable
+   anchor**; if the PRD is edited and re-planned, ids may shift but quotes
+   still identify the requirement.
+3. **Record each entry** as `{ id, verbatim_text, section_heading }`,
+   where `section_heading` is the markdown heading (or sub-issue ref)
+   the requirement lives under — the same value used for `prd_anchor`.
+4. **Tag every planned ticket** — Epic, Story, AND Sub-task — with the
+   register ids it exists to satisfy. All the way down: sub-tasks carry
+   their own requirement quotes so a leaf dispatched in isolation is
+   self-explanatory. A ticket that genuinely traces to no single
+   requirement (cross-cutting infrastructure, derived enablement work)
+   gets `requirements: []` and must say which requirements it *supports*
+   in its Source Requirement section instead.
+
+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.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.
@@ -186,8 +256,10 @@ Walkthrough findings are surfaced back to product via the orchestrating intake s
 For each epic identified in Phase 1, **invoke the `lisa-tracker-write` shim** (do not call `lisa-jira-write-ticket` or `lisa-github-write-issue` directly). Pass it everything it needs to enforce its quality gates:
 
 - `issue_type`: `Epic`
+- `prd_source`: the originating PRD URL — mandatory for every ticket this skill creates; it arms the validator's S16 traceability gate
 - `summary`: epic title from the PRD
 - `body`: a draft of the multi-section description containing:
+  - A **Source Requirement** section (see the shared format above) citing the GitHub Issue PRD URL, section heading, and the verbatim text of every register requirement (`R-id`) this epic exists to satisfy
   - **Context / Business Value**: epic summary from the PRD, originating GitHub PRD URL, business outcome
   - **Technical Approach**: cross-cutting integration points and constraints surfaced in Phase 2 codebase research
   - List of user stories the epic contains
@@ -217,9 +289,10 @@ For each Epic, plan two kinds of Stories:
 For each Story, **invoke `lisa-tracker-write`** with:
 
 - `issue_type`: `Story`
+- `prd_source`: the originating PRD URL — mandatory for every ticket this skill creates; it arms the validator's S16 traceability gate
 - `parent_ref` / `epic_parent`: the Epic ref captured in Phase 3 (mandatory)
 - `summary`: prefixed per the naming convention above
-- `body`: multi-section description as in `lisa-notion-to-tracker` Phase 4
+- `body`: multi-section description as in `lisa-notion-to-tracker` Phase 4, including as its first element a **Source Requirement** section (shared format above) quoting the register requirement(s) this story satisfies
 - `artifacts`: the Phase 1.5 artifacts filtered by domain per the inheritance table:
 
 | Story type | Inherits domains |
@@ -244,6 +317,7 @@ Delegate sub-task creation to **parallel agents** (one per epic or batch of stor
 Each sub-task MUST:
 1. **Be scoped to exactly ONE repo** — indicated in brackets in the summary: `[repo-name]` and in the body/description's `## Repository` / `h2. Repository` section.
 2. **Include an Empirical Verification Plan** — real user-like verification, NOT unit tests, linting, or typechecking.
+3. **Carry its own `## Source Requirement` section** (shared format above) with the full verbatim quote(s) from the Phase 1.4 register — a leaf claimed by build-intake in isolation must be self-explanatory. When a sub-task is split per-repo, every split child inherits the same requirement quote(s).
 
 **Leaf-only build-ready (`leaf-only-lifecycle`)**: Sub-tasks are the **leaf work units** of the decomposition — they are the ONLY items in the hierarchy that receive the build-ready label. `lisa-tracker-write` applies `status:ready` here so downstream build intake (`lisa-github-build-intake`) claims the leaves and never the Epic or Stories. Apply `status:ready` to each Sub-task; never to its parent Story or Epic (Phases 3–4). `lisa-github-write-issue` enforces the same invariant on the write side, so a Sub-task split into per-repo children (the cross-repo case above) carries build-ready on the children, not on any intermediate parent that gains child work.
 
@@ -268,6 +342,7 @@ After all tickets are created, present a summary table to the user:
 - All Epics with refs and URLs
 - All Stories grouped by Epic
 - All Sub-tasks grouped by Story with repo tags
+- **Requirement coverage** — one row per Phase 1.4 register entry (`R-id`, quote excerpt, tickets that declare it); requirements with zero tickets are a gap to resolve before reporting success
 - Repo distribution
 - **Artifact Preservation Matrix**
 - Blockers list with recommendations and alternatives
@@ -283,7 +358,8 @@ Invoke `lisa-prd-backlink` with:
 
 - `source_type: "github"`
 - `source_ref`: the original GitHub Issue URL or `<org>/<repo>#<n>` token
-- `tickets`: the full list created in Phases 3–5, each entry as `{ key, title, type, url, parent_key }`
+- `tickets`: the full list created in Phases 3–5, each entry as `{ key, title, type, url, parent_key, requirements }` — `requirements` is the list of Phase 1.4 register ids the ticket satisfies (empty for derived work)
+- `requirement_register`: the Phase 1.4 register (`{ id, verbatim_text, section_heading }` entries), so the back-link section can render the requirement → tickets view
 
 If `lisa-prd-backlink` fails (permission denied, GitHub unreachable, issue locked), surface the error in the Phase 6 report rather than aborting — the tickets are already created. Recommend the user re-run `lisa-prd-backlink` standalone once the source is reachable.
 
@@ -312,9 +388,10 @@ that downstream skills (triage, journey, evidence) cannot use.
 
 For each sub-task, invoke `lisa-tracker-write` with:
 - issue_type: "Sub-task"
+- prd_source: [the originating PRD URL — mandatory; arms the S16 traceability gate]
 - parent_ref: the parent story ref
 - summary: prefixed with the repo in brackets, e.g. "[backend-api] Add audit log table"
-- body: a multi-section draft (Context / Technical Approach / Acceptance Criteria / etc.) plus `## Repository` / `h2. Repository` naming exactly one repo
+- body: a multi-section draft (Context / Technical Approach / Acceptance Criteria / etc.) plus `## Repository` / `h2. Repository` naming exactly one repo, plus `## Source Requirement` quoting the PRD requirement(s) this sub-task satisfies VERBATIM with the PRD link and register id(s) — [paste the exact requirement text and R-ids for each sub-task from the requirement register; do not let the agent paraphrase]
 - gherkin_acceptance_criteria: derived from the story's functional requirements
 - sign_in_account: [test user credentials from config]
 - target_environment: "dev"

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

@@ -65,6 +65,7 @@ remote_links: [{ url: "https://github.com/.../pull/42", title: "PR #42" }]
 journey_followup: auto            # auto | none — see S11
 build_ready: true                 # caller asserts the build-ready role (status:ready) is/would be applied — see S15
 child_refs: ["my-org/my-repo#601", "my-org/my-repo#602"]   # known child work (sub-issues / task-list / "Blocked by" parentage) — see S15
+prd_source: "https://notion.so/..."    # set when the issue was generated from a PRD — requires the Source Requirement section, see S16
 ```
 
 If the caller passes only an issue ref, fetch via `gh issue view <number> --repo <org>/<repo> --json number,title,body,labels,state,milestone,assignees`, parse the body sections, derive the spec fields, then run gates. The parser lives in `lisa-github-read-issue` (composition).
@@ -92,6 +93,7 @@ Each gate is tagged with a fixed `category` and a `product_relevant` boolean. Ca
 | S13 Relationship Search | `dependency` | true |
 | S14 Evidence manifest binding (leaf work units) | `acceptance-criteria` | true |
 | S15 Leaf-only build-ready | `structural` | false |
+| S16 Source Requirement traceability | `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 |
@@ -235,6 +237,34 @@ Remediation: `"Build-ready (status:ready) is leaf-only per leaf-only-lifecycle.
 
 `product_relevant: false` — a build-ready container is a lifecycle/decomposition error for the caller to repair, not a product question.
 
+#### S16 — Source Requirement traceability (PRD-sourced issues)
+
+Answers "why was this done?": every issue generated from a PRD must carry
+the requirement it exists to satisfy, quoted verbatim, at every level of
+the hierarchy — sub-issues included, so a leaf claimed by build-intake in
+isolation is self-explanatory.
+
+**When the gate applies.** Run S16 whenever the spec declares `prd_source`
+(all `*-to-tracker` decomposition paths set it). Without `prd_source`
+(ad-hoc issues with no PRD lineage) the gate is `N/A` — but if a
+`Source Requirement` section is present anyway, still validate its shape
+so a malformed section never passes silently.
+
+**What must be present.** a `Source Requirement` section (`##` markdown heading) containing:
+
+1. A link to the source PRD (the `**PRD**:` line), and
+2. At least one `**Requirement` line with **verbatim quoted text**, or the
+   explicit derived-work form (`Derived work supporting R3, R7 — no single
+   PRD section.`).
+
+Missing section, missing PRD link, empty/paraphrased requirement text
+(quotes shorter than a few words, or prose with no quotation), or a bare
+R-id with no quote: FAIL with remediation
+`"Add a Source Requirement section citing the PRD link and quoting the requirement(s) this issue satisfies verbatim (see the Source Requirement shared format in the *-to-tracker skills). Derived work must name the requirements it supports."`
+
+`product_relevant: true` — a issue whose requirement cannot be traced is
+a product-clarity problem: nobody can tell why the work exists.
+
 ### Feasibility Gates (require GitHub lookups; skip in `--spec-only`)
 
 #### F1 — Issue type label exists in repo
@@ -321,6 +351,7 @@ Output is a single fenced text block. Callers parse it; do not add free-form pro
 - [PASS|FAIL|N/A] S13 Relationship Search — <one-line reason>
 - [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>
 
 ### Feasibility Gates  (omit this section when --spec-only)
 - [PASS|FAIL|N/A] F1 Issue type label exists in repo — <one-line reason>

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

@@ -41,6 +41,7 @@ Resolve `<ORG>` and `<REPO>` from the ref or from `.lisa.config.json`.
 | Target backend environment | Runtime-behavior changes | Recorded under `## Target Backend Environment`. Skip only for doc / config / type-only. |
 | Sign-in account / credentials | Authenticated-surface tickets | Recorded under `## Sign-in Required`. |
 | Repository | Bug, Task, Sub-task | GitHub Issues live in exactly one repo by definition — record the repo name under `## Repository`, and reject any AC bullet that references a different repo. |
+| Source Requirement | PRD-sourced issues (`prd_source` provided) | `## Source Requirement` with PRD link + verbatim requirement quote(s) — see Phase 3; enforced at every level, sub-issues included. |
 
 Optional but recommended: assignee, milestone, components (label `component:<name>`), story points (label `points:<n>`), labels.
 
@@ -51,6 +52,20 @@ Use `gh api repos/<org>/<repo>/labels --paginate` to discover existing labels be
 The description (issue body) MUST address three audiences. Reject and rewrite if any are missing.
 
 ```markdown
+## Source Requirement
+[Required whenever the issue originates from a PRD (the caller passes
+ `prd_source`). Answers "why was this done?" — cite the PRD and quote the
+ requirement(s) VERBATIM, never paraphrased:
+ - **PRD**: <PRD title + link> §"<section heading>"
+ - **Requirement (R3)**: "<verbatim requirement text from the PRD>"
+ One Requirement line per satisfied requirement. Derived / cross-cutting
+ work that traces to no single requirement uses the supporting form:
+ "Derived work supporting R3, R7 — no single PRD section." Close with:
+ "This issue exists to satisfy the quoted requirement. If implementation
+ scope drifts from the quoted text, the PRD is the authority — raise the
+ conflict rather than silently reinterpreting it." Omit the section only
+ for ad-hoc issues with no PRD lineage.]
+
 ## Context / Business Value
 [Why this matters. Stakeholder-facing. Concrete user impact or business outcome.
  Link to the originating Slack thread, PRD page, incident, or customer report.]
@@ -115,6 +130,7 @@ Scenario: <name>
 ```
 
 Rules:
+- PRD-sourced issues (caller passed `prd_source`) MUST carry the Source Requirement section with verbatim quotes — paraphrases are rejected (validator gate S16). This applies at every level, sub-issues included: a leaf claimed in isolation must explain its own "why".
 - Every acceptance criterion uses Given/When/Then. No vague "should work" language.
 - Every criterion is independently verifiable.
 - If the issue is a Bug, include reproduction steps, expected vs. actual behavior, and environment.

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

@@ -62,6 +62,7 @@ links: [{ key: "PROJ-99", type: "is blocked by" }]   # known issue links (may be
 remote_links: [{ url: "https://github.com/...", title: "PR #42" }]
 build_ready: true                 # caller asserts the build-ready role (status:ready) is/would be applied — see S15
 child_refs: ["PROJ-601", "PROJ-602"]   # known child work (sub-tasks / "is blocked by" parentage) — see S15
+prd_source: "https://notion.so/..."    # set when the ticket was generated from a PRD — requires the Source Requirement section, see S16
 ```
 
 If the caller passes only a ticket key, fetch the ticket via `lisa-atlassian-access` `operation: read-ticket key: <KEY>`, derive the same fields from the fetched data — including `build_ready` (label set contains `status:ready`) and `child_refs` (sub-tasks plus `is blocked by` parentage, resolved as in `lisa-jira-read-ticket`) so S15 can classify the ticket — then run gates.
@@ -89,6 +90,7 @@ Each gate is tagged with a fixed `category` and a `product_relevant` boolean. Ca
 | S13 Relationship Search | `dependency` | true |
 | S14 Evidence manifest binding (leaf work units) | `acceptance-criteria` | true |
 | S15 Leaf-only build-ready | `structural` | false |
+| S16 Source Requirement traceability | `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 |
@@ -236,6 +238,35 @@ Remediation: `"Build-ready (status:ready) is leaf-only per leaf-only-lifecycle.
 
 `product_relevant: false` — a build-ready container is a lifecycle/decomposition error for the caller to repair, not a product question.
 
+#### S16 — Source Requirement traceability (PRD-sourced tickets)
+
+Answers "why was this done?": every ticket generated from a PRD must carry
+the requirement it exists to satisfy, quoted verbatim, at every level of
+the hierarchy — sub-tasks included, so a leaf claimed by build-intake in
+isolation is self-explanatory.
+
+**When the gate applies.** Run S16 whenever the spec declares `prd_source`
+(all `*-to-tracker` decomposition paths set it). Without `prd_source`
+(ad-hoc tickets with no PRD lineage) the gate is `N/A` — but if a
+`Source Requirement` section is present anyway, still validate its shape
+so a malformed section never passes silently.
+
+**What must be present.** A `Source Requirement` section (`h2.` / `##` in
+proposed text, or an ADF heading in live JIRA) containing:
+
+1. A link to the source PRD (the `**PRD**:` line), and
+2. At least one `**Requirement` line with **verbatim quoted text**, or the
+   explicit derived-work form (`Derived work supporting R3, R7 — no single
+   PRD section.`).
+
+Missing section, missing PRD link, empty/paraphrased requirement text
+(quotes shorter than a few words, or prose with no quotation), or a bare
+R-id with no quote: FAIL with remediation
+`"Add a Source Requirement section citing the PRD link and quoting the requirement(s) this ticket satisfies verbatim (see the Source Requirement shared format in the *-to-tracker skills). Derived work must name the requirements it supports."`
+
+`product_relevant: true` — a ticket whose requirement cannot be traced is
+a product-clarity problem: nobody can tell why the work exists.
+
 ### Feasibility Gates (require JIRA lookups; skip in dry-run if requested)
 
 #### F1 — Issue type valid in project
@@ -310,6 +341,7 @@ Output is a single fenced text block. Callers parse it; do not add free-form pro
 - [PASS|FAIL|N/A] S13 Relationship Search — <one-line reason>
 - [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>
 
 ### Feasibility Gates  (omit this section when --spec-only)
 - [PASS|FAIL|N/A] F1 Issue type valid in project — <one-line reason>

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

@@ -38,6 +38,7 @@ Required fields (stop and ask if missing — do not invent values):
 | Target backend environment | Runtime-behavior changes | `dev` / `staging` / `prod`; recorded in description (Phase 3). Skip only for doc/config/type-only tickets. |
 | Sign-in account / credentials | Tickets that touch authenticated surfaces | Name the account (or source — 1Password item, env var, seeded fixture) and role; recorded in description (Phase 3). Omit when sign-in is not required. |
 | Single-repo scope | Bug, Task, Sub-task, Improvement | These leaf work units MUST cover one repo only. If the work crosses repos, split it before creating. Epic / Spike / Story may span repos. |
+| Source Requirement | PRD-sourced tickets (`prd_source` provided) | `h2. Source Requirement` with PRD link + verbatim requirement quote(s) — see Phase 3; enforced at every level, sub-tasks included |
 
 Optional but recommended: assignee, components, fix versions, labels, sprint, story points, reporter.
 
@@ -48,6 +49,20 @@ Issue-type validity and required custom fields are enforced by `lisa-jira-valida
 The description MUST address three audiences. Reject and rewrite if any are missing.
 
 ```text
+h2. Source Requirement
+[Required whenever the ticket originates from a PRD (the caller passes
+ `prd_source`). Answers "why was this done?" — cite the PRD and quote the
+ requirement(s) VERBATIM, never paraphrased:
+ - **PRD**: <PRD title + link> §"<section heading>"
+ - **Requirement (R3)**: "<verbatim requirement text from the PRD>"
+ One Requirement line per satisfied requirement. Derived / cross-cutting
+ work that traces to no single requirement uses the supporting form:
+ "Derived work supporting R3, R7 — no single PRD section." Close with:
+ "This ticket exists to satisfy the quoted requirement. If implementation
+ scope drifts from the quoted text, the PRD is the authority — raise the
+ conflict rather than silently reinterpreting it." Omit the section only
+ for ad-hoc tickets with no PRD lineage.]
+
 h2. Context / Business Value
 [Why this matters. Stakeholder-facing. Concrete user impact or business outcome.
  Link to the originating Slack thread, Notion doc, incident, or customer report.]
@@ -93,6 +108,7 @@ h2. Validation Journey
 ```
 
 Rules:
+- PRD-sourced tickets (caller passed `prd_source`) MUST carry the Source Requirement section with verbatim quotes — paraphrases are rejected (validator gate S16). This applies at every level, sub-tasks included: a leaf claimed in isolation must explain its own "why".
 - Every acceptance criterion uses Given/When/Then. No vague "should work" language.
 - Every criterion is independently verifiable (UI, API, data, or performance check).
 - If the ticket is a Bug, include reproduction steps, expected vs. actual behavior, and environment.