@codyswann/lisa 2.189.7 → 2.189.9

package/plugins/lisa-cursor/skills/jira-journey/SKILL.md

@@ -1,127 +0,0 @@
----
-name: jira-journey
-description: "Parse a JIRA ticket's Validation Journey section, execute the verification steps using appropriate tools (curl, test commands, database queries), capture evidence, and post to JIRA + GitHub PR using the jira-evidence skill."
-allowed-tools: ["Bash", "Read", "Glob", "Grep", "Skill"]
----
-
-# JIRA Validation Journey (TypeScript)
-
-All Atlassian operations in this skill go through `lisa:atlassian-access`. Do not call MCP tools or `acli` directly. Note: the helper scripts (`scripts/parse-plan.py`, `scripts/jira-evidence/post-evidence.sh`) currently use direct API calls and are pending migration to route through `atlassian-access`.
-
-Parse a JIRA ticket's Validation Journey, execute the verification steps using the appropriate tools for the change type, capture evidence at each `[EVIDENCE: name]` marker, and post to JIRA + GitHub PR.
-
-## Arguments
-
-`$ARGUMENTS`: `<TICKET_ID> [PR_NUMBER]`
-
-- `TICKET_ID` (required): JIRA ticket key (e.g., `PROJ-123`)
-- `PR_NUMBER` (optional): GitHub PR number to update description
-
-## Prerequisites
-
-- `JIRA_API_TOKEN` environment variable set
-- `jira-cli` configured (`~/.config/.jira/.config.yml`)
-- `gh` CLI authenticated
-- Appropriate services running for the verification type (dev server, database, etc.)
-
-## Workflow
-
-### Step 1: Parse the Validation Journey
-
-Run the parser script to extract the Validation Journey from the JIRA ticket description:
-
-```bash
-python3 .claude/skills/jira-journey/scripts/parse-plan.py <TICKET_ID>
-```
-
-The script outputs JSON with: `ticket`, `prerequisites`, `steps`, `viewports`, `assertions`.
-
-Note: `viewports` may be empty for TypeScript tickets — that is expected.
-
-### Step 2: Satisfy Prerequisites
-
-Before starting the journey, verify each prerequisite:
-
-1. Check if required services are running
-2. Verify database connectivity if needed
-3. Ensure environment variables are set
-4. Run any setup commands mentioned in prerequisites
-
-### Step 3: Execute Steps and Capture Evidence
-
-Execute each step sequentially. For each step, determine the verification approach based on the step text and change type:
-
-- **API endpoints** → Run curl commands, capture HTTP response to `evidence/NN-name.txt`
-- **Database changes** → Run psql/migration commands, capture schema output to `evidence/NN-name.txt`
-- **Background jobs** → Trigger the job, check queue/state, capture logs to `evidence/NN-name.txt`
-- **Library/utility changes** → Run tests, capture output to `evidence/NN-name.txt`
-- **Security fixes** → Reproduce exploit attempt, verify fix, capture output to `evidence/NN-name.txt`
-
-At each `[EVIDENCE: name]` marker, capture stdout/stderr to a numbered file:
-
-#### Evidence Naming Convention
-
-Evidence files are named: `{NN}-{evidence-name}.txt` (or `.json` for structured data)
-
-- `NN`: zero-padded sequential number (01, 02, 03...)
-- `evidence-name`: the value from `[EVIDENCE: name]` in the JIRA step
-
-Example:
-
-```text
-evidence/
-  01-health-check.json
-  02-schema-after-migration.txt
-  03-rate-limit-response.txt
-  comment.txt
-  comment.md
-```
-
-### Step 4: Generate Evidence Templates
-
-After capturing all evidence, run the template generator:
-
-```bash
-python3 .claude/skills/jira-journey/scripts/generate-templates.py \
-  <TICKET_ID> \
-  <PR_NUMBER> \
-  <BRANCH_NAME> \
-  ./evidence
-```
-
-This generates `evidence/comment.txt` (JIRA wiki markup) and `evidence/comment.md` (GitHub markdown) with evidence formatted as code blocks.
-
-### Step 5: Post Evidence
-
-Use the jira-evidence skill to post everything:
-
-```bash
-bash .claude/skills/jira-evidence/scripts/post-evidence.sh <TICKET_ID> ./evidence <PR_NUMBER>
-```
-
-### Step 6: Verify
-
-Confirm evidence is posted to both the JIRA ticket and GitHub PR.
-
-## Verification Patterns Reference
-
-The agent should use patterns from the project's `verfication.md` when executing steps:
-
-| Change Type | Verification Method | Evidence Format |
-|---|---|---|
-| API endpoint | `curl -s localhost:PORT/endpoint` | JSON response |
-| Database migration | `psql -c "\d table"` or migration output | Schema text |
-| Background job | Trigger + check state | Log output |
-| Library/utility | `bun run test -- path/to/test` | Test output |
-| Security fix | Reproduce + verify fix | Request/response |
-| Auth/authz | Multi-role verification | Status codes per role |
-
-## Troubleshooting
-
-### Evidence file is empty
-
-Ensure the command succeeded and produced output. Use `2>&1` to capture both stdout and stderr.
-
-### Parser returns no steps
-
-The ticket may not have a Validation Journey section. Use `/jira-add-journey <TICKET_ID>` to add one.

package/plugins/lisa-cursor/skills/jira-read-ticket/SKILL.md

@@ -1,198 +0,0 @@
----
-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", "Skill"]
----
-
-# Read JIRA Ticket: $ARGUMENTS
-
-All Atlassian operations in this skill go through `lisa:atlassian-access`. Do not call MCP tools or `acli` directly.
-
-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. Invoke `lisa:atlassian-access` via the Skill tool with `operation: list-sites` to confirm the configured site is reachable and resolve 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
-
-Invoke `lisa:atlassian-access` via the Skill tool with `operation: read-ticket key: <TICKET-KEY>` for the target ticket. The access layer MUST request an explicit full JIRA field set for this operation (`acli jira workitem view --fields '*all'`, REST `fields=*all`, or an equivalent substrate-specific field list). Do not accept or re-use a default `acli workitem view` payload; its default six-field response omits parent, components, labels, priority, and custom fields, which makes leaf-only, relationship-search, build-ready, and required-custom-field gates read false-empty data. 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 — capture `id`, `filename`, `mimeType`, `size`, and `content` URL for each. Do not download unless a downstream task needs the bytes (see "Downloading attachments" below).
-
-#### Downloading attachments (opt-in)
-
-The Atlassian MCP exposes attachment metadata but no binary-fetch tool ([JRACLOUD-97830](https://jira.atlassian.com/browse/JRACLOUD-97830), [ECO-1265](https://jira.atlassian.com/browse/ECO-1265)). Fetch attachment bytes only when a downstream task explicitly needs them — e.g., a design-fidelity check on an image, log-file analysis, PDF text extraction. For everything else, keep the URL reference and move on.
-
-```bash
-bash .claude/skills/jira-read-ticket/scripts/download-attachment.sh <id-or-content-url> <output-path>
-```
-
-Requires `JIRA_SERVER`, `JIRA_LOGIN`, and `JIRA_API_TOKEN` in the environment (same contract as `jira-evidence`). If those are not set the helper exits with code 2 and a clear remediation message — record the URL only and continue.
-
-After download, branch on `mimeType`:
-- `image/*` — pass the local path to image-aware downstream tools
-- `text/*`, `application/json`, `application/xml`, `application/x-yaml` — read inline as text
-- `application/pdf` — extract text via downstream tooling if needed
-- everything else — record path only; do not attempt to inline binary content
-
-### 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
-
-The primary ticket payload returned by `lisa:atlassian-access` `operation: read-ticket` includes the issue's remote links. If the substrate returns remote links separately, request them via `lisa:atlassian-access` with `operation: read-ticket key: <K>` (the operation MUST return remote links — extend `atlassian-access` if it doesn't). 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, invoke `lisa:atlassian-access` with `operation: read-ticket key: <LINKED-KEY>` 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 `lisa:atlassian-access` `operation: read-ticket key: <EPIC-KEY>` — full description, acceptance criteria, all comments, Validation Journey.
-2. Find epic siblings via JQL:
-   ```jql
-   "Epic Link" = <EPIC-KEY> AND key != <TICKET-KEY>
-   ```
-   Invoke `lisa:atlassian-access` with `operation: search-issues jql: "<above-JQL>"`. 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 `lisa:atlassian-access` `operation: read-ticket key: <SUBTASK-KEY>`: 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 with id, filename, mimeType, size, content URL — note any that were downloaded and their local paths>
-
-## 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-cursor/skills/jira-sync/SKILL.md

@@ -1,108 +0,0 @@
----
-name: jira-sync
-description: "Syncs plan progress to a linked JIRA ticket. Posts plan contents, progress updates, branch links, and PR links at key milestones. Use this skill throughout the plan lifecycle to keep tickets in sync."
-allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep"]
----
-
-# JIRA Ticket Sync
-
-All Atlassian operations in this skill go through `lisa:atlassian-access`. Do not call MCP tools or `acli` directly.
-
-Sync current plan progress to JIRA ticket: $ARGUMENTS
-
-If no argument provided, search for a ticket URL in the active plan file (most recently modified `.md` in `plans/`).
-
-Optional arguments include `pr_url=<url>` for the live pull request and `merge_sha=<sha>` once merged.
-
-## Workflow
-
-### Step 1: Identify Ticket and Context
-
-1. **Parse ticket ID** from `$ARGUMENTS` or extract from the active plan file
-2. **Fetch current ticket state** by invoking `lisa:atlassian-access` via the Skill tool with `operation: read-ticket key: <TICKET-ID>`
-3. **Determine current milestone** by checking:
-   - Does a plan file exist? → Plan created
-   - Is there a working branch? → Implementation started
-   - Are tasks in progress? → Active implementation
-   - Is there an open PR? → PR ready for review
-   - Is the PR merged? → Complete
-
-### Step 2: Gather Update Content
-
-Based on the current milestone:
-
-| Milestone | Content to Post |
-|-----------|-----------------|
-| **Plan created** | Plan summary, branch name, link to PR (if draft exists) |
-| **Implementation in progress** | Task completion summary (X of Y tasks done), any blockers |
-| **PR ready** | PR link, summary of changes, test results |
-| **PR merged** | Final summary, suggest moving ticket to "Done" |
-
-### Step 3: Post Update
-
-Before adding a comment, check for an existing milestone comment to avoid duplicates (idempotency):
-
-1. **Fetch existing comments** by invoking `lisa:atlassian-access` with `operation: search-issues jql: "..."` or by reading the ticket's comments. Look for a comment whose body contains a stable milestone marker (e.g., the heading `## Plan Created`, `## Implementation in Progress`, `## PR Ready`, or `## PR Merged`) that matches the current milestone.
-2. **If a matching comment already exists**, skip posting and proceed to field updates — idempotent re-runs must not create duplicates.
-3. **If no matching comment exists**, add a new comment by invoking `lisa:atlassian-access` with `operation: comment key: <TICKET-ID> body: "..."`.
-4. **Update ticket fields** if applicable:
-   - Add branch name to a custom field or comment
-   - Add PR link to a custom field or comment
-5. **Report** what was synced to the user
-
-### Step 3b: Ensure PR Backlink
-
-When `$ARGUMENTS` includes `pr_url=<url>` for `PR ready` or `PR merged`, ensure the JIRA ticket has a durable ticket -> PR link:
-
-1. Prefer the JIRA development-link surface when the site's GitHub/JIRA integration or remote-link API is available through `lisa:atlassian-access`; verify by re-reading the ticket's remote links / development metadata.
-2. If native linkage is unavailable, unconfigured, cross-system, or cannot be verified, create or update a single managed JIRA comment containing the PR URL. The comment must start with `[lisa-pr-link]` and include the milestone (`pr-ready` or `pr-merged`) and merge SHA when available.
-3. Keep the fallback idempotent: read existing comments, find the `[lisa-pr-link]` comment for the same PR URL, and update/skip it instead of appending duplicates. If the current access layer cannot update comments in place, skip when an identical managed comment already exists and otherwise add exactly one replacement comment with the stable marker.
-
-The PR body/branch issue key is the PR -> ticket side. This step is the required ticket -> PR side.
-
-### Step 4: Suggest Status Transition
-
-Based on the milestone, suggest (but don't automatically perform) a status transition:
-
-| Milestone | Suggested Status |
-|-----------|-----------------|
-| Plan created | "In Progress" |
-| PR ready | configured `jira.workflow.review` status, or no transition when unconfigured |
-| PR merged | "Done" |
-
-### Step 5: Parent Status Rollup (`--rollup`)
-
-When invoked with `--rollup`, this skill **derives a parent/container ticket's status from the roll-up of its children** (Stories under an Epic; Sub-tasks under a Story/Task) instead of posting a milestone update on a leaf. This implements the JIRA child/subtask-status arm of the **Parent status rollup (the state machine)** section of the `leaf-only-lifecycle` rule — cite that rule, do not restate the policy.
-
-**Resolve the child set the same way `lisa:jira-read-ticket` does** — the native Epic → Story → Sub-task hierarchy (Epic link / parent field for Stories, the subtask relationship for Sub-tasks), each with its current status. Fetch via `lisa:atlassian-access` (`operation: read-ticket` / `search-issues` with the parent's `"Epic Link" = <KEY>` or `parent = <KEY>` JQL). If the ticket has **no** children it is a leaf — rollup is N/A; behave as a normal milestone sync.
-
-**Evaluate the required children over the env ladder `in-progress < dev < staging < production` (the ordered keys of the JIRA env-keyed `done` map, e.g. `On Dev < On Stg < Done`) and take the first match** (canonical roles from `config-resolution`; the JIRA status map defaults to `Blocked`, `In Progress`, `Code Review`, env-keyed `done`):
-
-| If among the required child leaves… | Derived parent role | JIRA status |
-|---|---|---|
-| any child is **blocked** | `blocked` | `Blocked` |
-| else **every** required child has shipped to some env (each at a `done`-map value, e.g. `On Dev`/`On Stg`/`Done`) | `done[min-env]` | the **least-advanced** env status among them (all `On Stg` → `On Stg`; mixed `On Dev`+`On Stg` → `On Dev`; all production → `Done`) |
-| else any child has **started** (`In Progress` / `Code Review`, or shipped to an env while a sibling has not) | `claimed` | `In Progress` |
-| else (children exist, none started) | — | unchanged — parent keeps its non-ready container status |
-
-- **Blocked dominates** — a single blocked child surfaces `Blocked` on the parent even while siblings progress.
-- **Least-advanced env wins** — the parent reaches an env only when every required child has reached at least that env; it never sits ahead of its laggard child. Apply native terminal resolution (the `leaf-only-lifecycle` Terminal native closure) only when the resolved env is the production `Done`, never at `On Dev`/`On Stg`.
-- **"Required" children only** — won't-do / optional children do not hold the parent open.
-- **Recursive** — an Epic reaches an env only when its Stories have themselves rolled up to at least that env; a Story reaches it only when its Sub-tasks have. Evaluate bottom-up.
-- **Never set the parent to the build-ready status** — `ready` is leaf-only. Rollup only moves the parent between non-ready container statuses.
-- **`review` is optional for JIRA** (`config-resolution`) — a project that omits `Code Review` keeps the parent in `In Progress` until it shifts to an env; skip the intermediate review hop rather than forcing a non-existent status (a `leaf-only-lifecycle` "vendor support varies" note).
-
-**Single-environment collapse (this repo).** The env rungs resolve via the env-keyed `done` logic in `config-resolution`. In this repo `deploy.branches` declares only `production: main`, so `done` collapses to a single status, the only env rung is production, and the lifecycle is `Ready → In Progress → Code Review → Done` with **no** dev/staging promotion hops; the rollup never resolves a dev or staging `done`. Multi-environment projects keep the env-keyed map and roll a parent up to intermediate env statuses (`On Dev`/`On Stg`).
-
-**Apply the derived status** (only when it differs from the parent's current status) via `lisa:atlassian-access` `operation: transition`, and post an idempotent rollup comment naming the derived state and the child tally. **Safe default:** if the derived terminal cannot be resolved (ambiguous required-set or unresolvable env `done`), do not guess — post the derived suggestion as a comment and leave the parent's status untouched.
-
-## Important Notes
-
-- **Never auto-transition ticket status** — always suggest and let the user confirm. The one exception is the explicit `--rollup` parent derivation (Step 5), which transitions a *parent's* status per the `leaf-only-lifecycle` rule — never a leaf's, and never to the build-ready status.
-- **Idempotent updates** — running sync multiple times at the same milestone should not create duplicate comments
-- **Comment format** — use JIRA markdown with clear headers and bullet points
-- **Rollup cites the rule by slug** — parent state derivation follows the `leaf-only-lifecycle` rule's state machine; this skill does not restate the policy.
-
-## Execution
-
-Sync the ticket now.