@codyswann/lisa 1.82.0 → 1.83.0

package/plugins/lisa/skills/spec-conformance/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: spec-conformance
+description: "Verifies that shipped work matches its spec section-by-section — acceptance criteria, Out of Scope, Technical Approach, Validation Journey assertions, and any explicit deliverables. Builds a coverage matrix mapping each requirement to evidence, flags scope creep separately from misses, and produces a verdict (CONFORMS / PARTIAL / DIVERGES). Runs during the verification phase alongside empirical system verification."
+allowed-tools: ["Read", "Glob", "Grep", "Bash", "Skill", "mcp__atlassian__getJiraIssue", "mcp__atlassian__searchJiraIssuesUsingJql", "mcp__atlassian__getAccessibleAtlassianResources"]
+---
+
+# Spec Conformance: $ARGUMENTS
+
+Compare shipped work against its spec section-by-section. This is the "accountant lens" — did the work ship exactly what was written, nothing more, nothing less? It is NOT UX review (that's `product-specialist`) and it is NOT empirical system verification (that's `verification-specialist`). Run it alongside those, not instead of them.
+
+## Phase 1 — Resolve Spec Source
+
+Determine the source of truth for this work. Check in this order:
+
+1. **Explicit spec argument** — plan file path (e.g. `.claude/plans/<name>.md`), JIRA key (e.g. `PROJ-123`), Linear key, GitHub issue URL, or PRD path passed as `$ARGUMENTS`.
+2. **Linked JIRA ticket** — if the current branch or PR body references a JIRA key, use it.
+3. **PR body** — if the PR description contains a "Spec" or "Ticket" link, follow it.
+4. **Plan file on disk** — check `.claude/plans/` for an active plan matching the branch name.
+
+If none of the above resolves, stop. Do not guess what the spec was. Report: "No spec source found — pass a plan file, ticket key, or PR URL."
+
+Based on the source, load the full spec:
+
+| Source | How to Load |
+|--------|-------------|
+| Plan file (`.md`) | `Read` the file |
+| JIRA key | Invoke `/jira-read-ticket <KEY>` to get the full context bundle (primary ticket + epic + linked tickets) |
+| Linear key | Fetch via Linear MCP if available; else `Bash` with Linear CLI; else report "Linear reader unavailable" |
+| GitHub issue | `gh issue view <number> --json title,body,comments,labels,milestone` |
+| PRD | `Read` the file or fetch via Notion MCP if it's a Notion URL |
+
+## Phase 2 — Extract Requirements
+
+Parse the spec into a structured requirement list. Do NOT skip sections — every requirement becomes a row in the coverage matrix.
+
+Sections to extract:
+
+| Section | What to Extract | Classification |
+|---------|-----------------|----------------|
+| Acceptance Criteria | Each Gherkin scenario or bullet | `acceptance` |
+| Out of Scope | Each excluded item | `excluded` (flags scope creep) |
+| Technical Approach | Each concrete implementation commitment (not narrative) | `technical` |
+| Validation Journey Assertions | Each `Assertion:` bullet | `assertion` |
+| Deliverables | Each explicit deliverable (migration, doc, endpoint, script) | `deliverable` |
+| Plan file tasks | Each task marked complete in the plan | `task` |
+| Linked blocker resolutions | Each `is blocked by` that required work in this ticket | `blocker` |
+
+If an acceptance criterion is not in Gherkin, still extract it as a requirement — but flag it as `LOW_SPECIFICITY` so the verdict downgrades.
+Downgrade rule: if any `LOW_SPECIFICITY` requirement exists, the maximum possible verdict is `PARTIAL` unless the spec is tightened and re-evaluated.
+
+Skip narrative prose (Context / Business Value) — it isn't directly verifiable. Reference it only when explaining a miss.
+
+## Phase 3 — Inspect Shipped Work
+
+Gather evidence of what was actually shipped:
+
+1. **Diff scope** — the commits on the current branch vs. the default branch:
+   ```bash
+   BASE_BRANCH="$(git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@')"
+   git log "${BASE_BRANCH}"..HEAD --oneline
+   git diff "${BASE_BRANCH}"...HEAD --stat
+   ```
+2. **File-level changes** — per-file diff for each changed file:
+   ```bash
+   git diff "${BASE_BRANCH}"...HEAD -- <file>
+   ```
+3. **Test coverage** — which tests were added/changed for the requirements:
+   ```bash
+   git diff "${BASE_BRANCH}"...HEAD -- '**/*.test.*' '**/*.spec.*'
+   ```
+4. **Empirical evidence** — output of `verification-specialist` if available (proof artifacts, API captures, UI screenshots, DB queries). If that report isn't in context, ask the caller for it before proceeding — do not substitute reading code for running the system.
+5. **PR description** — `gh pr view --json title,body,files` if a PR exists.
+6. **Deployed state** — if the verification phase already hit a deployed environment, use those captures.
+
+Do NOT run the system yourself — that's the verification-specialist's job. Your job is to map their evidence to the spec.
+
+## Phase 4 — Build Coverage Matrix
+
+For every requirement extracted in Phase 2, produce one row:
+
+| Column | Value |
+|--------|-------|
+| Requirement ID | Stable identifier (e.g. `AC-1`, `OOS-2`, `ASSERT-3`) |
+| Classification | `acceptance` / `excluded` / `technical` / `assertion` / `deliverable` / `task` / `blocker` |
+| Requirement Text | Verbatim from spec |
+| Evidence | Specific pointer — file:line, test name, verification report section, PR file, screenshot name |
+| Status | `MATCH` / `PARTIAL` / `MISSING` / `SCOPE_CREEP_VIOLATION` |
+| Notes | One line — why partial, what's missing, or where evidence is thin |
+
+### Status definitions
+
+- **`MATCH`** — requirement is implemented AND there is empirical evidence it works (test + verification report).
+- **`PARTIAL`** — implementation exists but evidence is incomplete (e.g. code present, no test; or test present, no run-time verification).
+- **`MISSING`** — requirement has no corresponding implementation OR no evidence at all.
+- **`SCOPE_CREEP_VIOLATION`** — used for `excluded` classification only. An Out-of-Scope item appears to have been shipped anyway. This is a different failure than a miss — it means the agent exceeded the spec.
+
+### Scope creep detection
+
+Separately from the matrix, scan the diff for work NOT traceable to any requirement. For each such change:
+
+- Identify the file/module
+- Summarize the change in one line
+- Classify as `UNTRACEABLE_CHANGE` (not necessarily wrong — refactors often land here — but MUST be surfaced)
+
+Untraceable changes are not automatic failures. They become findings the human reviews.
+
+## Phase 5 — Verdict
+
+Produce exactly one verdict:
+
+- **`CONFORMS`** — every requirement is `MATCH`. No `SCOPE_CREEP_VIOLATION`. Untraceable changes, if any, are clearly refactors or test support.
+- **`PARTIAL`** — some requirements are `PARTIAL` but none are `MISSING` or `SCOPE_CREEP_VIOLATION`. Work is mostly there but evidence is thin.
+- **`DIVERGES`** — at least one requirement is `MISSING`, OR at least one `SCOPE_CREEP_VIOLATION` exists, OR there are substantive untraceable changes that materially alter behavior.
+
+A verdict of `PARTIAL` or `DIVERGES` blocks task completion. The caller must resolve the gaps (implement the miss, remove the creep, add the missing evidence) before re-running.
+
+## Phase 6 — Output
+
+Structure the report so it can be pasted into a PR comment or JIRA ticket:
+
+```text
+## Spec Conformance Report
+
+**Spec source:** <plan file / JIRA key / Linear / GitHub issue / PRD>
+**Shipped scope:** <N commits, M files, K tests on branch <branch> vs <default-branch>>
+
+### Coverage Matrix
+
+| ID | Class | Requirement | Evidence | Status | Notes |
+|----|-------|-------------|----------|--------|-------|
+| AC-1 | acceptance | [text] | [pointer] | MATCH | |
+| AC-2 | acceptance | [text] | — | MISSING | No corresponding code or test |
+| OOS-1 | excluded | [text] | src/foo.ts:42 | SCOPE_CREEP_VIOLATION | Added anyway |
+| ASSERT-1 | assertion | [text] | verification-report §2 | PARTIAL | Asserted in code, not run in verification |
+
+### Untraceable Changes
+- src/utils/helpers.ts — extracted shared regex constant (refactor, no behavior change)
+- src/auth/session.ts — added retry logic (NOT IN SPEC — verify intentional)
+
+### Verdict: CONFORMS | PARTIAL | DIVERGES
+
+**Matches:** N/Total
+**Partial:** N
+**Missing:** N
+**Scope creep violations:** N
+**Untraceable changes flagged for review:** N
+
+### Required Actions (if PARTIAL or DIVERGES)
+1. [specific action — implement X, remove Y, add test for Z, capture evidence for W]
+2. ...
+```
+
+## Rules
+
+- Never substitute "I read the code and it looks right" for empirical evidence. If verification-specialist hasn't run yet, request its report before producing a verdict.
+- Never mark a requirement `MATCH` based on the presence of code alone — evidence means test + runtime observation.
+- Always surface scope creep separately from misses. They are distinct failures.
+- Always surface untraceable changes — even benign refactors — so the human can confirm intent.
+- The Out of Scope section is load-bearing. If the spec has one, every item must appear in the matrix as `excluded`.
+- If the spec has no acceptance criteria, flag the spec itself as inadequate before running the matrix. The verdict is `DIVERGES` for spec inadequacy until criteria are added.
+- Do not invent requirements the spec didn't state. If the shipped work does something reasonable but unspecified, it becomes an untraceable change, not a match.

package/plugins/lisa/skills/ticket-triage/SKILL.md

@@ -6,7 +6,7 @@ allowed-tools: ["Read", "Glob", "Grep", "Bash"]
 
 # Ticket Triage: $ARGUMENTS
 
-Perform analytical triage on the JIRA ticket. The caller has fetched the ticket details (summary, description, acceptance criteria, labels, status, comments) and provided them in context.
+Perform analytical triage on the JIRA ticket. The caller MUST have run `jira-read-ticket` first and provided the resulting context bundle — which includes the primary ticket, all linked tickets (blocks / is blocked by / relates to / duplicates), epic parent, epic siblings, subtasks, and remote PR state. Do not triage from a bare ticket summary — if the bundle is missing link or epic context, stop and instruct the caller to run `/jira-read-ticket` first.
 
 Repository name for scoped labels and comment headers: determine via `basename $(git rev-parse --show-toplevel)`.
 
@@ -23,6 +23,18 @@ If NO relevant code is found in this repo:
 
 If relevant code IS found, proceed to Phase 2.
 
+## Phase 1.5 -- Relationship & Epic Awareness
+
+From the context bundle, evaluate relationships before analyzing this ticket in isolation:
+
+- **Open blockers (`is blocked by`)**: if any blocker is not `Done` or its linked PR is not merged, raise an ambiguity: "Blocker {KEY} is not shipped — work cannot meaningfully start." This is an automatic `BLOCKED` verdict unless the human confirms the blocker state is acceptable.
+- **Epic siblings in progress**: if a sibling under the same epic is `In Progress` / `In Review` with a different assignee and overlapping scope, raise it as an edge case in Phase 4 ("Duplicate-work risk with {KEY}").
+- **`duplicates` / `is duplicated by` links**: if this ticket is a duplicate of an open ticket, verdict is `BLOCKED` with the recommendation to close as duplicate rather than implement.
+- **`relates to` links with shipped PRs**: flag the PRs in the verification methodology (Phase 5) as prior art worth reviewing before writing new code.
+
+Do not re-fetch tickets — the bundle already has the context.
+If Phase 1.5 finds an automatic blocker condition (`is blocked by` not shipped, or duplicate-of-open), emit `BLOCKED` immediately and skip to Phase 6 output formatting.
+
 ## Phase 2 -- Cross-Repo Awareness
 
 Parse the ticket's existing comments for triage headers from OTHER repositories. Look for patterns like:
@@ -111,7 +123,7 @@ Every verification method must be specific enough that an automated agent could
 Evaluate the findings and produce exactly one verdict:
 
 - **`NOT_RELEVANT`** -- No relevant code was found in this repository (Phase 1). The caller should add the triage label and skip implementation in this repo.
-- **`BLOCKED`** -- Ambiguities were found in Phase 3. Work MUST NOT proceed until the ambiguities are resolved by a human. The caller should post findings, add the triage label, and STOP.
+- **`BLOCKED`** -- Blocking conditions were found in Phase 1.5 (open blockers, duplicate-of-open) and/or ambiguities were found in Phase 3. Work MUST NOT proceed until resolved by a human. The caller should post findings, add the triage label, and STOP.
 - **`PASSED_WITH_FINDINGS`** -- No ambiguities, but edge cases or verification findings were identified. Work can proceed. The caller should post findings and add the triage label.
 - **`PASSED`** -- No ambiguities, edge cases, or verification gaps found. Work can proceed. The caller should add the triage label.
 

package/plugins/lisa/skills/verification-lifecycle/SKILL.md

@@ -42,9 +42,23 @@ A verification plan that only lists `bun run test`, `bun run typecheck`, or `bun
 
 After implementation, run the verification plan. Execute each verification type in order.
 
-### 7. Loop
+### 7. Spec Conformance
 
-If any verification fails, fix the issue and re-verify. Do not declare done until all required types pass. If a verification is stuck after 3 attempts, escalate.
+After empirical verification produces evidence, run spec conformance as a separate, mandatory step. Invoke the `spec-conformance` skill (or delegate to the `spec-conformance-specialist` agent) with the spec source — plan file, JIRA/Linear/GitHub key, or PRD.
+
+Spec conformance answers a question empirical verification does NOT: does the shipped work match what was asked, section-by-section? It consumes the empirical evidence from step 6 and builds a coverage matrix over every requirement (acceptance criteria, Out of Scope, technical commitments, Validation Journey assertions, deliverables).
+
+Required outputs:
+- Coverage matrix with one row per requirement
+- Scope creep findings (Out-of-Scope violations, surfaced separately from misses)
+- Untraceable change findings (diff not traceable to any requirement)
+- Verdict: `CONFORMS`, `PARTIAL`, or `DIVERGES`
+
+`PARTIAL` or `DIVERGES` blocks completion. Fix the gaps (implement the miss, remove the creep, capture the missing evidence) and re-run both empirical verification AND spec conformance. Never skip this step — it catches failures that empirical verification by itself does not, such as a feature that works but wasn't asked for, or a spec item that was quietly dropped.
+
+### 8. Loop
+
+If any verification or spec-conformance check fails, fix the issue and re-verify. Do not declare done until all required types pass AND the spec-conformance verdict is `CONFORMS`. If a verification or conformance check is stuck after 3 attempts, escalate.
 
 ---
 
@@ -180,8 +194,9 @@ Agents must follow this sequence unless explicitly instructed otherwise:
 8. Implement the change.
 9. Execute verification plan — run the actual system and observe results.
 10. Collect proof artifacts.
-11. Summarize what changed, what was verified, and remaining risk.
-12. Label the result with a verification level.
+11. Run spec conformance — build coverage matrix against the spec source (plan/ticket/issue), flag scope creep and untraceable changes, produce verdict.
+12. Summarize what changed, what was verified, conformance verdict, and remaining risk.
+13. Label the result with a verification level.
 
 ---
 
@@ -290,9 +305,10 @@ A task is done only when:
 
 - End user is identified
 - All applicable verification types are classified and executed
-- Verification lifecycle is completed (classify, check tooling, plan, execute, loop)
+- Verification lifecycle is completed (classify, check tooling, plan, execute, spec conformance, loop)
 - Required verification surfaces and tooling surfaces are used or explicitly unavailable
 - Proof artifacts are captured
+- Spec conformance verdict is `CONFORMS` (not `PARTIAL`, not `DIVERGES`)
 - Verification level is declared
 - Risks and gaps are documented
 

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "1.82.0",
+  "version": "1.83.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "1.82.0",
+  "version": "1.83.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "1.82.0",
+  "version": "1.83.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "1.82.0",
+  "version": "1.83.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "1.82.0",
+  "version": "1.83.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/src/base/agents/jira-agent.md

@@ -2,6 +2,8 @@
 name: jira-agent
 description: JIRA lifecycle agent. Reads tickets, determines intent (Bug → Implement/Fix, Story/Task → Implement/Build, Epic → Plan, Spike → Implement/Investigate), delegates to the appropriate flow, syncs progress at milestones, and posts evidence at completion.
 skills:
+  - jira-read-ticket
+  - jira-write-ticket
   - jira-sync
   - jira-evidence
   - jira-verify
@@ -17,13 +19,20 @@ You are a JIRA lifecycle agent. Your job is to read a JIRA ticket, determine wha
 
 ### 1. Read the Ticket
 
-Read the ticket fully using the Atlassian MCP tools or CLI:
-- Description, comments, attachments, linked issues
-- Epic parent, subtasks, story points
-- Current status, assignee, labels
-- Extract any credentials, URLs, or reproduction steps from the ticket body
+Invoke the `jira-read-ticket` skill with the ticket key. This is mandatory — do NOT read the ticket ad-hoc via MCP calls. The skill fetches the primary ticket AND its full graph in one pass:
 
-If you cannot access the ticket, stop and report what access is needed.
+- Full description, acceptance criteria, Validation Journey
+- All comments in chronological order
+- All metadata (status, assignee, labels, components, fix version, priority, story points, sprint)
+- Remote links — PRs (with state and unresolved review comments via `gh`), Confluence pages, dashboards
+- Every linked ticket (`blocks`, `is blocked by`, `relates to`, `duplicates`, `clones`) with their descriptions, statuses, and recent comments
+- Epic parent — full description, comments, and acceptance criteria
+- Epic siblings — so you see in-flight related work before starting
+- Subtasks
+
+Pass the resulting context bundle verbatim to every downstream agent. Extract credentials, URLs, and reproduction steps from the bundle. If the skill reports that the ticket is inaccessible, stop and report what access is needed.
+
+**Never act on a ticket in isolation.** If the bundle shows open blockers, flag them and stop. If it shows an epic sibling in progress with a different assignee, surface that before proceeding so work isn't duplicated.
 
 ### 2. Validate Ticket Quality
 
@@ -97,7 +106,7 @@ Based on the milestone, suggest (but don't auto-transition):
 ## Rules
 
 - Never auto-transition ticket status — always suggest and let the human confirm
-- Always read the full ticket before determining intent — don't rely on ticket type alone
-- If the ticket references other tickets, read those too for context
+- Always read the full ticket graph via `jira-read-ticket` before determining intent — don't rely on ticket type alone
+- Never create or materially edit a ticket by calling MCP write tools directly — always delegate to `jira-write-ticket` so relationships, Gherkin criteria, and metadata gates are enforced
 - If sign-in credentials are in the ticket, extract and pass them to the flow
 - If the ticket has a Validation Journey section, pass it to the verifier agent

package/plugins/src/base/agents/spec-conformance-specialist.md

@@ -0,0 +1,49 @@
+---
+name: spec-conformance-specialist
+description: "Spec conformance specialist agent. Verifies shipped work matches its spec exactly — acceptance criteria, Out of Scope, Technical Approach, Validation Journey assertions, and deliverables. Produces a coverage matrix, flags scope creep separately from misses, and issues a verdict (CONFORMS / PARTIAL / DIVERGES). Runs alongside verification-specialist and product-specialist during the verification phase; they catch different failure modes."
+skills:
+  - spec-conformance
+  - jira-read-ticket
+---
+
+# Spec Conformance Specialist Agent
+
+You are a spec conformance specialist. Your job is to prove that the shipped work matches its spec **exactly** — nothing more, nothing less.
+
+## Scope
+
+You answer one question: **Does what shipped match what was asked?**
+
+That is distinct from two adjacent questions that other agents own:
+
+| Question | Owner |
+|----------|-------|
+| Does the system actually run and produce correct observable output? | `verification-specialist` |
+| Is the user experience coherent and are error states humane? | `product-specialist` |
+| Does every line of shipped code trace back to a requirement, and is nothing missing from the spec? | **you** |
+
+You depend on `verification-specialist`'s empirical evidence — you do not gather it yourself. If their report is not available, request it before producing a verdict.
+
+## Process
+
+Follow the `spec-conformance` skill end-to-end:
+
+1. Resolve the spec source (plan file, JIRA key, Linear, GitHub issue, PRD).
+2. Extract every requirement into a structured list — acceptance criteria, Out of Scope, technical commitments, Validation Journey assertions, deliverables.
+3. Inspect shipped work (diff, tests, PR body, verification-specialist evidence).
+4. Build the coverage matrix — every requirement gets a row with a status.
+5. Detect scope creep and untraceable changes separately.
+6. Produce the verdict.
+
+## Output
+
+Return the structured report defined in the skill. Never summarize or drop rows. The matrix is the deliverable — a human or another agent reads it to decide whether to ship.
+
+## Rules
+
+- **Require empirical evidence.** A requirement is not `MATCH` because code exists. It is `MATCH` only when there is a test AND runtime observation (captured by verification-specialist).
+- **Scope creep is a distinct failure.** Do not fold `SCOPE_CREEP_VIOLATION` into "missing" or "untraceable." Scope creep means Out of Scope was violated — it blocks shipping.
+- **Untraceable changes get surfaced, not judged.** Refactors and test helpers often land here. Surface them so the human can confirm intent; do not automatically fail.
+- **If the spec itself is inadequate** (no acceptance criteria, no Out of Scope, no Validation Journey for runtime changes), the verdict is `DIVERGES` until the spec is tightened. Do not paper over an ambiguous spec with a generous match.
+- **Never gather empirical evidence yourself.** That is verification-specialist's job. You read their report. If it's missing, block and ask.
+- **Never approve your own work.** If you produced the implementation in this session, say so explicitly in the report and recommend the human double-check — self-review of conformance is weakest when the same mind built the thing.

package/plugins/src/base/agents/verification-specialist.md

@@ -4,6 +4,7 @@ description: Verification specialist agent. Discovers project tooling and execut
 skills:
   - verification-lifecycle
   - jira-journey
+  - spec-conformance
 ---
 
 # Verification Specialist Agent

package/plugins/src/base/commands/jira/read-ticket.md

@@ -0,0 +1,7 @@
+---
+description: "Read a JIRA ticket with full scope — metadata, comments, remote PRs, linked tickets, epic siblings, subtasks"
+allowed-tools: ["Skill"]
+argument-hint: "<TICKET-ID>"
+---
+
+Use the /lisa:jira-read-ticket skill to fetch the full scope of the JIRA ticket and its related graph. $ARGUMENTS

package/plugins/src/base/commands/jira/write-ticket.md

@@ -0,0 +1,7 @@
+---
+description: "Create or update a JIRA ticket with enforced relationships, Gherkin criteria, and metadata quality gates"
+allowed-tools: ["Skill"]
+argument-hint: "[TICKET-ID | <create-intent-description>]"
+---
+
+Use the /lisa:jira-write-ticket skill to create or update the JIRA ticket with full relationship discovery and quality enforcement. $ARGUMENTS

package/plugins/src/base/commands/spec-conformance.md

@@ -0,0 +1,7 @@
+---
+description: "Verify shipped work matches its spec — coverage matrix with scope-creep detection and verdict"
+allowed-tools: ["Skill"]
+argument-hint: "[plan-file | TICKET-KEY | issue-url]"
+---
+
+Use the /lisa:spec-conformance skill to compare shipped work against its spec and produce a coverage matrix with verdict. $ARGUMENTS

package/plugins/src/base/skills/jira-create/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: jira-create
 description: This skill should be used when creating JIRA epics, stories, and tasks from code files or descriptions. It analyzes the provided input, determines the appropriate issue hierarchy, and creates issues with comprehensive quality requirements including test-first development and documentation.
-allowed-tools: ["Read", "Glob", "LS", "mcp__atlassian__createJiraIssue", "mcp__atlassian__getVisibleJiraProjects", "mcp__atlassian__getJiraProjectIssueTypesMetadata", "mcp__atlassian__getAccessibleAtlassianResources"]
+allowed-tools: ["Read", "Glob", "LS", "Skill", "mcp__atlassian__getVisibleJiraProjects", "mcp__atlassian__getJiraProjectIssueTypesMetadata", "mcp__atlassian__getAccessibleAtlassianResources"]
 ---
 
 # Create JIRA Issues from $ARGUMENTS
@@ -93,3 +93,9 @@ Default project: from jira-cli config (override via arguments)
 Exclude unless requested: migration plans, performance tests
 
 Execute the analysis and create the complete JIRA structure with proper parent-child relationships.
+
+## Delegation to jira-write-ticket
+
+For every individual ticket that will be created, delegate to the `jira-write-ticket` skill rather than calling `mcp__atlassian__createJiraIssue` directly. `jira-write-ticket` enforces description quality (Gherkin acceptance criteria, stakeholder/developer/assistant sections), relationship discovery (`blocks`, `is blocked by`, `relates to`, remote PR/Confluence/dashboard links), epic parent validation, and post-create verification.
+
+This skill's role is to analyze the input and decide the hierarchy (which epics, which stories, which tasks, in what parent-child structure). `jira-write-ticket` handles the actual write with full quality gates.

package/plugins/src/base/skills/jira-read-ticket/SKILL.md

@@ -0,0 +1,180 @@
+---
+name: jira-read-ticket
+description: "Fetches the full scope of a JIRA ticket — metadata, description, acceptance criteria, all comments, remote links (PRs, Confluence, dashboards), issue links (blocks/is blocked by/relates to/duplicates/clones), epic parent with siblings, and subtasks. Produces a consolidated context bundle that downstream agents consume so they never act on a single ticket in isolation."
+allowed-tools: ["Bash", "mcp__atlassian__getJiraIssue", "mcp__atlassian__getJiraIssueRemoteIssueLinks", "mcp__atlassian__searchJiraIssuesUsingJql", "mcp__atlassian__getAccessibleAtlassianResources"]
+---
+
+# Read JIRA Ticket: $ARGUMENTS
+
+Fetch the full scope of the ticket AND its related graph. Downstream agents must never act on a ticket in isolation — always call this skill first so they see blockers, epic siblings, linked PRs, and historical comments.
+
+Repository name for scoped comments and logs: `basename $(git rev-parse --show-toplevel)`.
+
+## Phase 1 — Resolve Context
+
+1. Call `mcp__atlassian__getAccessibleAtlassianResources` to get the cloud ID.
+2. If $ARGUMENTS is not a ticket key (e.g. `PROJ-123`), stop and report. Do NOT guess.
+
+## Phase 2 — Fetch Primary Ticket
+
+Call `mcp__atlassian__getJiraIssue` for the target ticket. Extract and preserve:
+
+### Metadata
+
+- Key, summary, issue type, status, resolution
+- Priority, assignee, reporter, creator
+- Labels, components, fix versions, affects versions
+- Sprint, story points, original/remaining estimate
+- Created, updated, resolved dates
+- Parent (epic link or parent issue)
+- Custom fields relevant to the project (read every custom field — do not filter)
+
+### Body
+
+- Full description (preserve formatting)
+- Acceptance criteria section if separately structured
+- **Validation Journey** section if present (pass verbatim to downstream)
+- Attachments list (names + URLs, do not download unless needed)
+
+### Comments
+
+Fetch ALL comments in chronological order. Do not truncate. For each:
+- Author, timestamp, body
+- Flag comments that contain: credentials, reproduction steps, status updates from stakeholders, decisions, or triage headers like `[repo-name]`
+
+## Phase 3 — Fetch Remote Links
+
+Call `mcp__atlassian__getJiraIssueRemoteIssueLinks`. For each remote link:
+
+- **GitHub PR or commit** (`github.com/.../(pull|commit)/...`): run `gh pr view <url> --json title,state,body,mergedAt,reviewDecision,comments,reviews` (for PRs) or `gh api repos/<owner>/<repo>/commits/<sha>` (for commits). Capture title, state, body, unresolved review comments, merge status.
+- **Confluence page**: capture title and URL. Do not fetch body unless a downstream task explicitly needs it.
+- **Dashboard, log link, or external URL**: capture title and URL only.
+
+If `gh` is not authenticated, note "gh auth required" and continue — do not abort.
+
+## Phase 4 — Fetch Issue Links (Relationships)
+
+Every linked ticket must be fetched. Do not skip any link type. For each link in the primary ticket's `issuelinks` field, group by type:
+
+- `blocks` / `is blocked by`
+- `relates to`
+- `duplicates` / `is duplicated by`
+- `clones` / `is cloned by`
+- Any other custom link types configured in the project
+
+For each linked ticket, call `mcp__atlassian__getJiraIssue` and capture:
+
+- Key, summary, type, status, resolution
+- Description (full, unless closed with resolution `Won't Do`/`Duplicate` — then summary only)
+- Acceptance criteria
+- Last 10 comments (chronological)
+- Remote links (PR URLs and state only — skip deep fetch unless the link is `blocks` or `is blocked by`)
+
+**Special handling for `is blocked by`:** fetch the full PR/commit details via `gh` for each blocker's remote links so the agent knows whether the blocker is actually shipped.
+
+## Phase 5 — Fetch Epic Context
+
+If the primary ticket has an epic parent (or IS an epic):
+
+1. Fetch the epic itself via `mcp__atlassian__getJiraIssue` — full description, acceptance criteria, all comments, Validation Journey.
+2. Find epic siblings via JQL:
+   ```jql
+   "Epic Link" = <EPIC-KEY> AND key != <TICKET-KEY>
+   ```
+   Use `mcp__atlassian__searchJiraIssuesUsingJql`. For each sibling capture: key, summary, type, status, assignee, priority.
+3. Read each sibling's description at a SUMMARY level (first paragraph only) — the goal is to surface related in-flight work, not duplicate full content. If a sibling is `In Progress` or `In Review` with an assignee different from the current ticket, flag it prominently.
+
+If the primary ticket IS an epic, also fetch all children via the JQL above.
+
+## Phase 6 — Fetch Subtasks
+
+If the primary ticket has subtasks, fetch each via `mcp__atlassian__getJiraIssue`: key, summary, type, status, assignee, description (first paragraph), acceptance criteria.
+
+## Phase 7 — Assemble Context Bundle
+
+Produce a single structured output that the caller can pass verbatim to downstream agents. Use this format:
+
+```text
+# Ticket Context: <KEY>
+
+## Primary Ticket
+- Key: <KEY>
+- Type: <type>
+- Status: <status>
+- Priority: <priority>
+- Assignee: <name>
+- Epic: <epic-key> — <epic-summary>
+- Sprint: <sprint>
+- Labels: <labels>
+- Components: <components>
+
+### Description
+<full description>
+
+### Acceptance Criteria
+<criteria>
+
+### Validation Journey
+<section or "None">
+
+### Comments (<count>)
+<chronological comments, flagged items called out>
+
+### Attachments
+<list>
+
+## Remote Links
+### Pull Requests (<count>)
+- <url> — <title> — <state> — <reviewDecision>
+  <body summary + unresolved review comments>
+
+### Confluence
+- <title> — <url>
+
+### Other
+- <title> — <url>
+
+## Issue Links
+### Blocks (<count>)
+<per-ticket block>
+
+### Is Blocked By (<count>)
+<per-ticket block with PR state>
+
+### Relates To (<count>)
+<per-ticket block>
+
+### Duplicates / Clones
+<per-ticket block>
+
+## Epic Context
+### Epic <EPIC-KEY> — <summary>
+- Status: <status>
+- Description: <full>
+- Comments: <chronological>
+- Validation Journey: <section or None>
+
+### Siblings In-Flight (<count>)
+- <KEY> — <status> — <assignee> — <summary>  **[FLAG: in progress by other assignee]**
+
+### Other Siblings (<count>)
+- <KEY> — <status> — <summary>
+
+## Subtasks (<count>)
+- <KEY> — <status> — <assignee> — <summary>
+
+## Summary for Downstream
+- Full ticket count pulled: <N>
+- Blockers still open: <list>
+- Related in-flight work: <list>
+- Relevant PRs: <list with state>
+```
+
+## Rules
+
+- Never summarize or truncate the primary ticket's description or Validation Journey.
+- Never skip a link type, even if it seems unrelated — the agent downstream decides relevance.
+- If a linked ticket returns an access error, capture the error and continue. Do not abort the read.
+- Flag in-flight sibling work prominently so the caller can avoid duplicate implementation.
+- If the ticket has no epic parent, state this explicitly — do not silently skip Phase 5.
+- Output is pure context. This skill never modifies the ticket.