@codyswann/lisa 1.82.2 → 1.83.0

package/package.json

@@ -76,7 +76,7 @@
     "lodash": ">=4.18.1"
   },
   "name": "@codyswann/lisa",
-  "version": "1.82.2",
+  "version": "1.83.0",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

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

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

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

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

@@ -0,0 +1,178 @@
+---
+name: jira-write-ticket
+description: "Creates or updates a JIRA ticket following organizational best practices. Enforces description quality (coding assistant / developer / stakeholder sections), Gherkin acceptance criteria, epic parent relationship, explicit link discovery (blocks / is blocked by / relates to / duplicates / clones), remote links (PRs, Confluence, dashboards), labels, components, fix version, priority, story points, and Validation Journey. Rejects thin tickets — use this skill any time a ticket is created or significantly edited."
+allowed-tools: ["Bash", "Skill", "mcp__atlassian__getJiraIssue", "mcp__atlassian__searchJiraIssuesUsingJql", "mcp__atlassian__createJiraIssue", "mcp__atlassian__editJiraIssue", "mcp__atlassian__createIssueLink", "mcp__atlassian__getIssueLinkTypes", "mcp__atlassian__addCommentToJiraIssue", "mcp__atlassian__getVisibleJiraProjects", "mcp__atlassian__getJiraProjectIssueTypesMetadata", "mcp__atlassian__getAccessibleAtlassianResources"]
+---
+
+# Write JIRA Ticket: $ARGUMENTS
+
+Create or update a JIRA ticket with all required relationships, metadata, and quality gates. Every section below is mandatory. Thin tickets are rejected.
+
+Repository name for scoped comments: `basename $(git rev-parse --show-toplevel)`.
+
+## Phase 1 — Resolve Intent
+
+Determine from $ARGUMENTS and context whether this is a CREATE or UPDATE:
+
+- **CREATE**: no existing ticket key provided
+- **UPDATE**: ticket key provided — call `/jira-read-ticket <KEY>` first to load the full current state before editing. Never overwrite without reading.
+
+Resolve cloud ID via `mcp__atlassian__getAccessibleAtlassianResources`.
+
+## Phase 2 — Gather Required Inputs
+
+Required fields (stop and ask if missing — do not invent values):
+
+| Field | Required For | Notes |
+|-------|--------------|-------|
+| Project key | CREATE | Call `getVisibleJiraProjects` if unknown |
+| Issue type | CREATE | Story, Task, Bug, Epic, Spike, Improvement |
+| Summary | CREATE, UPDATE | One line, imperative voice, under 100 chars |
+| Description | CREATE, UPDATE | Multi-section — see Phase 3 |
+| Epic parent | Non-bug, non-epic | Enforced by `jira-verify` |
+| Priority | CREATE | Default to project default if unstated |
+| Acceptance criteria | Story, Task, Bug, Improvement | Gherkin — see Phase 3 |
+| Validation Journey | Runtime-behavior changes | Delegate to `/jira-add-journey` |
+
+Optional but recommended: assignee, components, fix versions, labels, sprint, story points, reporter.
+
+Use `mcp__atlassian__getJiraProjectIssueTypesMetadata` to verify the issue type exists in the project and discover required custom fields.
+
+## Phase 3 — Description Quality
+
+The description MUST address three audiences. Reject and rewrite if any are missing.
+
+```text
+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.]
+
+h2. Technical Approach
+[Developer-facing. Integration points, impacted modules, data model implications,
+ relevant tradeoffs. Not a full design doc — a pointer for someone picking it up.]
+
+h2. Acceptance Criteria
+# Given <precondition>
+  When <action>
+  Then <observable outcome>
+# Given <precondition>
+  When <action>
+  Then <observable outcome>
+
+h2. Out of Scope
+[Explicit list of what this ticket does NOT cover. Forces scope discipline.]
+
+h2. Validation Journey
+[Delegate to /jira-add-journey if the ticket changes runtime behavior.
+ Skip only for doc-only, config-only, or type-only tickets.]
+```
+
+Rules:
+- 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.
+- If the ticket is a Spike, include the question being answered and the definition of done (decision doc, prototype, or findings).
+
+## Phase 4 — Relationship Discovery (Mandatory)
+
+Before creating or updating, find candidate relationships. Do NOT skip — this is the step agents most often omit.
+
+### 4a. Epic Parent
+
+If the ticket is not a Bug and not an Epic, it MUST have an epic parent:
+
+1. If explicitly provided, use it.
+2. Otherwise search active epics:
+   ```jql
+   project = <PROJECT> AND issuetype = Epic AND statusCategory != Done
+   ```
+   via `mcp__atlassian__searchJiraIssuesUsingJql`. Match on keywords from the summary and description.
+3. If no epic matches, stop and ask the human to create or pick one. Do NOT orphan the ticket.
+
+### 4b. Related Tickets
+
+Run targeted JQL searches to surface candidate links. Present candidates to the human (or record them on the ticket as a comment) before skipping. Suggested searches:
+
+```jql
+# Open tickets touching the same component
+project = <PROJECT> AND component = "<component>" AND statusCategory != Done
+
+# Open tickets with overlapping keywords
+project = <PROJECT> AND (summary ~ "<keyword>" OR description ~ "<keyword>") AND statusCategory != Done
+
+# Epic siblings
+"Epic Link" = <EPIC-KEY>
+
+# Recent tickets touching the same labels
+project = <PROJECT> AND labels in (<labels>) AND updated >= -30d
+```
+
+For each candidate, classify the relationship:
+
+| Link Type | When to Use |
+|-----------|-------------|
+| `blocks` | This ticket must ship before the linked ticket can proceed |
+| `is blocked by` | The linked ticket must ship before this one can proceed |
+| `relates to` | Shared context, no ordering constraint |
+| `duplicates` | This ticket already exists — close one as duplicate |
+| `clones` | This ticket was created from the linked one (e.g. per-repo copies) |
+
+### 4c. Remote Links
+
+Identify and attach:
+- GitHub PRs, branches, or commits related to this work
+- Confluence pages (design docs, RFCs, runbooks)
+- Dashboards (Grafana, Datadog, Sentry issue)
+- Incident tickets (PagerDuty, Statuspage)
+
+Use Jira's web UI or `mcp__atlassian__editJiraIssue` to set the `Development` field / remote links where supported.
+
+## Phase 5 — Set Metadata
+
+Before create/update, verify each field is populated where applicable:
+
+- Labels: include at minimum one triage label if relevant (e.g. `claude-triaged-{repo}` is added later by triage, not here)
+- Components: map from the modules the work touches
+- Fix Version: set if the team uses versioned releases
+- Priority: explicit — no "unset"
+- Story points: estimate for Story/Task/Bug, skip for Epic/Spike
+- Sprint: only if actively sprinting this work
+- Assignee: leave unset if unknown rather than auto-assigning
+
+## Phase 6 — Create or Update
+
+### CREATE
+
+1. Call `mcp__atlassian__createJiraIssue` with all Phase 2/3/5 fields and the epic parent from Phase 4a.
+2. Capture the returned ticket key.
+3. For each relationship from Phase 4b, call `mcp__atlassian__createIssueLink` with the correct link type (verify names via `mcp__atlassian__getIssueLinkTypes` if unsure).
+4. Attach remote links from Phase 4c.
+5. If the ticket changes runtime behavior, invoke the `jira-add-journey` skill to append the Validation Journey section.
+
+### UPDATE
+
+1. Call `mcp__atlassian__editJiraIssue` with only the fields being changed. Do NOT resend fields that weren't in the change set — it blows away history.
+2. Add new relationships via `mcp__atlassian__createIssueLink`. Existing links are not touched unless explicitly removed.
+3. If description changes, preserve sections you are not editing. Re-read via `/jira-read-ticket` first.
+
+## Phase 7 — Verify
+
+Call the `jira-verify` skill on the resulting ticket. If it reports failures, fix them before returning. Do not report success on a ticket that fails verify.
+
+## Phase 8 — Announce
+
+Post a creation comment via `mcp__atlassian__addCommentToJiraIssue` with:
+- `[{repo}]` prefix if the ticket is repo-scoped
+- Who the ticket is assigned to (if known)
+- The relationships that were set (`blocks`, `is blocked by`, `relates to`) with links
+- Any remote PRs attached
+
+Skip this step only on UPDATE when no material change was made.
+
+## Rules
+
+- Never create a non-bug ticket without an epic parent.
+- Never skip relationship discovery — record "none found" explicitly if the search returned nothing.
+- Never invent custom field values. If the project requires a field you don't have, stop and ask.
+- Never overwrite a description without reading the current version first.
+- All writes go through this skill so best practices are enforced uniformly. Downstream skills (e.g. `jira-create`) should delegate here rather than calling the MCP write tools directly.