@codyswann/lisa 2.21.0 → 2.23.0

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

@@ -20,7 +20,7 @@ This skill is the GitHub counterpart of `lisa:notion-to-tracker` / `lisa:conflue
 
 ## What "PRD" means in GitHub Issues
 
-GitHub Issues has no native "PRD" entity. This skill treats a single GitHub Issue (carrying the `prd-ready` label) as the PRD container:
+GitHub Issues has no native "PRD" entity. This skill treats a single GitHub Issue (carrying the configured `ready` PRD label — `github.labels.prd.ready`, default `prd-ready`) as the PRD container:
 
 - **Issue body** (markdown) is the PRD body — equivalent to a Notion page body, a Confluence page body, or a Linear project description.
 - **Sub-issues** (native GitHub sub-issues, traversable via `gh api graphql`) act as the candidate set for Epics or User Stories — the same role child Epic pages play in a Notion/Confluence PRD.
@@ -92,7 +92,7 @@ A GitHub issue ref. The PRD is expected to have:
 - An issue body containing context, problems, and (optionally) a list of user stories.
 - One or more sub-issues that act as candidate Epics or user stories (optional — single-issue PRDs are valid).
 - Issue comments capturing engineering notes and product decisions.
-- The `prd-ready` label (if invoked from `lisa:github-prd-intake`; for ad-hoc / direct invocation the label is informational, not gating).
+- The configured `ready` PRD label (`github.labels.prd.ready`, default `prd-ready` — if invoked from `lisa:github-prd-intake`; for ad-hoc / direct invocation the label is informational, not gating).
 
 URL parsing — accept either:
 

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

@@ -88,6 +88,7 @@ Each gate is tagged with a fixed `category` and a `product_relevant` boolean. Ca
 | S11 Validation Journey | `acceptance-criteria` | true |
 | S12 Source Precedence | `design-ux` | true |
 | S13 Relationship Search | `dependency` | true |
+| S14 Evidence manifest binding (leaf work units) | `acceptance-criteria` | 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 |
@@ -189,6 +190,14 @@ The issue must EITHER have at least one entry in `links`, OR the body must conta
 
 An issue with zero links and no documented search: FAIL.
 
+#### S14 — Evidence manifest binding (leaf work units)
+
+When `issue_type ∈ {Bug, Task, Sub-task, Improvement}` AND `runtime_behavior_change = true`, the `## Validation Journey` must declare at least one `[EVIDENCE: name]` marker. Each marker name must be kebab-case and unique within the issue. These markers are the work unit's **evidence manifest** — the exact, enumerated set of artifacts that must be captured and attached before the issue may be closed (see the "Per-Work-Unit Evidence Contract" section of the `verification` rule, the Definition of Done in `verification-lifecycle`, and the evidence-manifest gate in `tracker-evidence`).
+
+FAIL when the Validation Journey is present but declares zero `[EVIDENCE: name]` markers, or when any marker name is empty, duplicated, or not kebab-case. A behavior-changing work unit SHOULD declare both a success marker and an error/edge marker; a journey with only one marker passes but the remediation should recommend adding the error/edge case.
+
+This gate depends on S11. It is `N/A` for Epic / Story / Spike (coordination containers, not work units) and for leaf units with `runtime_behavior_change = false` (doc-only / config-only / type-only). If S11 fails because the Validation Journey is absent, S14 also FAILs (there is no manifest to bind) with remediation pointing back to `lisa:github-add-journey`.
+
 ### Feasibility Gates (require GitHub lookups; skip in `--spec-only`)
 
 #### F1 — Issue type label exists in repo
@@ -248,6 +257,7 @@ Output is a single fenced text block. Callers parse it; do not add free-form pro
 - [PASS|FAIL|N/A] S11 Validation Journey — <one-line reason>
 - [PASS|FAIL|N/A] S12 Source Precedence — <one-line reason>
 - [PASS|FAIL|N/A] S13 Relationship Search — <one-line reason>
+- [PASS|FAIL|N/A] S14 Evidence manifest binding — <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>
@@ -273,7 +283,7 @@ The verdict is `PASS` if every applicable gate is `PASS`. Any `FAIL` makes the v
 
 Same shape and meaning as `lisa:jira-validate-ticket` so downstream PRD-intake skills (Notion, Confluence, Linear, GitHub) can format comments uniformly:
 
-- **gate**: the gate ID (`S1`–`S13`, `F1`–`F4`).
+- **gate**: the gate ID (`S1`–`S14`, `F1`–`F4`).
 - **category**: the gate's fixed category from the table.
 - **product_relevant**: matches the gate's table entry. `false` means the failure is an internal data-quality problem the caller should fix without bothering product.
 - **what**: plain-language, product-readable.

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

@@ -95,6 +95,7 @@ h3. Assertions
 4. **Evidence names in kebab-case** — `api-response`, `schema-check`, `rate-limit-hit`
 5. **Assertions are measurable** — "Returns 200 with `{status: ok}`" not "API works correctly"
 6. **Cover happy path and error path** — At minimum, one success and one failure evidence marker
+7. **On a leaf work unit, the markers are binding** — For a Bug / Task / Sub-task / Improvement, every `[EVIDENCE: name]` here is the ticket's evidence manifest: validation gate S14 requires at least one, and the ticket cannot be closed until each named artifact is captured and attached (see the "Per-Work-Unit Evidence Contract" in the `verification` rule). Name only evidence you intend to capture — and name all of it.
 
 ### Step 6: Present to User for Approval
 

package/plugins/lisa/skills/jira-build-intake/SKILL.md

@@ -1,21 +1,78 @@
 ---
 name: jira-build-intake
-description: "Symmetric counterpart to notion-prd-intake on the JIRA side. Scans a JIRA project (or JQL filter) for tickets in Status=Ready, claims each by transitioning to In Progress, runs the implementation/build flow via jira-agent, and transitions to On Dev on completion. The Ready status is the human-flipped signal that a TODO ticket is truly ready for development — mirroring how Notion PRDs work product Draft → Ready → (us) In Review → Blocked|Ticketed."
-allowed-tools: ["Skill", "Bash", "mcp__atlassian__getAccessibleAtlassianResources", "mcp__atlassian__searchJiraIssuesUsingJql", "mcp__atlassian__getJiraIssue", "mcp__atlassian__getTransitionsForJiraIssue", "mcp__atlassian__transitionJiraIssue", "mcp__atlassian__addCommentToJiraIssue"]
+description: "Symmetric counterpart to notion-prd-intake on the JIRA side. Scans a JIRA project (or JQL filter) for tickets in the configured `ready` status, claims each by transitioning to the configured `claimed` status, runs the implementation/build flow via jira-agent, and transitions to the configured `done` status on completion. The `ready` status is the human-flipped signal that a TODO ticket is truly ready for development — mirroring how Notion PRDs work product Draft → Ready → (us) In Review → Blocked|Ticketed."
+allowed-tools: ["Skill", "Bash"]
 ---
 
 # JIRA Build Intake: $ARGUMENTS
 
+All Atlassian operations in this skill go through `lisa:atlassian-access`. Do not call MCP tools or `acli` directly.
+
 `$ARGUMENTS` is one of:
 
-1. A JIRA project key (e.g. `SE`) — scans that project for `Status = Ready` tickets.
-2. A full JQL filter (e.g. `project = SE AND component = "frontend" AND Status = Ready`) — used as-is. The skill will not append a `Status = Ready` clause if the JQL already names a status, so callers can intentionally widen.
+1. A JIRA project key (e.g. `SE`) — scans that project for tickets in the configured `ready` status.
+2. A full JQL filter (e.g. `project = SE AND component = "frontend" AND Status = Ready`) — used as-is. The skill will not append a `Status = <ready>` clause if the JQL already names a status, so callers can intentionally widen.
+
+Run one build-intake cycle. Each ready ticket is claimed, built via the `lisa:jira-agent` flow, and transitioned to the configured `done` status (env-aware — see below). The cycle is the symmetric mirror of `lisa:notion-prd-intake`: humans flip the ready status, agents pick up and progress.
+
+## Workflow resolution
 
-Run one build-intake cycle. Each Ready ticket is claimed, built via the `lisa:jira-agent` flow, and transitioned to `On Dev` (or the equivalent next-status for that project). The cycle is the symmetric mirror of `lisa:notion-prd-intake`: humans flip `Ready`, agents pick up and progress.
+Status names are read from `.lisa.config.json` `jira.workflow.*`, falling back to defaults documented in the `config-resolution` rule. Bash pattern:
+
+```bash
+# Read role with default fallback. Local overrides global per-key.
+read_role() {
+  local role="$1" default="$2"
+  local local_v global_v
+  local_v=$(jq -r ".jira.workflow.${role} // empty" .lisa.config.local.json 2>/dev/null)
+  global_v=$(jq -r ".jira.workflow.${role} // empty" .lisa.config.json 2>/dev/null)
+  echo "${local_v:-${global_v:-$default}}"
+}
+
+READY=$(read_role ready "Ready")
+CLAIMED=$(read_role claimed "In Progress")
+```
+
+For env-keyed `done`, resolve the env first, then look up `done[<env>]`:
+
+1. Explicit caller arg (`target_env=staging`) wins.
+2. Otherwise, infer the env from the PR's base branch via `deploy.branches` (reverse lookup: if base is `staging`, env is `staging`).
+3. If `done` in config is a **string** (not a map), use it directly regardless of env.
+4. If `done` is a **map** and env cannot be resolved, **fail loudly** — do not pick arbitrarily.
+
+```bash
+# Resolve env, then DONE.
+TARGET_ENV="${target_env:-}"  # from caller args if supplied
+if [ -z "$TARGET_ENV" ] && [ -n "$PR_BASE_BRANCH" ]; then
+  TARGET_ENV=$(jq -r --arg b "$PR_BASE_BRANCH" \
+    '.deploy.branches // {} | to_entries[] | select(.value == $b) | .key' \
+    .lisa.config.json 2>/dev/null | head -1)
+fi
+
+DONE_RAW=$(jq -r '.jira.workflow.done // empty' .lisa.config.json 2>/dev/null)
+DONE_TYPE=$(jq -r '.jira.workflow.done | type' .lisa.config.json 2>/dev/null)
+if [ "$DONE_TYPE" = "string" ]; then
+  DONE="$DONE_RAW"
+elif [ "$DONE_TYPE" = "object" ]; then
+  [ -z "$TARGET_ENV" ] && { echo "ERROR: jira.workflow.done is env-keyed but env not resolvable"; exit 1; }
+  DONE=$(jq -r --arg e "$TARGET_ENV" '.jira.workflow.done[$e] // empty' .lisa.config.json)
+  [ -z "$DONE" ] && { echo "ERROR: jira.workflow.done has no entry for env '$TARGET_ENV'"; exit 1; }
+else
+  # Default: env-keyed map matching legacy hardcoded names.
+  case "$TARGET_ENV" in
+    dev) DONE="On Dev" ;;
+    staging) DONE="On Stg" ;;
+    production) DONE="Done" ;;
+    *) echo "ERROR: cannot resolve done status without env"; exit 1 ;;
+  esac
+fi
+```
+
+Run one build-intake cycle. Each ticket in `$READY` is claimed by transitioning to `$CLAIMED`, built via the `lisa:jira-agent` flow, and transitioned to `$DONE` on completion.
 
 ## Confirmation policy
 
-Do NOT ask the caller whether to proceed. Once invoked with a project key or JQL, run the cycle to completion — claim, dispatch each ticket through `lisa:jira-agent`, transition successful builds to `On Dev`, write the summary. The caller (a human or a cron) has already authorized the run by invoking the skill; re-prompting defeats the purpose of a background batch.
+Do NOT ask the caller whether to proceed. Once invoked with a project key or JQL, run the cycle to completion — claim, dispatch each ticket through `lisa:jira-agent`, transition successful builds to `$DONE`, write the summary. The caller (a human or a cron) has already authorized the run by invoking the skill; re-prompting defeats the purpose of a background batch.
 
 Specifically forbidden:
 
@@ -27,46 +84,45 @@ Specifically forbidden:
 The only legitimate reasons to stop early:
 
 - Missing project key / JQL or required configuration. Surface the missing value and exit.
-- Workflow misconfigured (pre-flight check finds `In Progress` or `On Dev` not reachable, or `Ready` status absent). Surface and exit.
-- Empty `Ready` set. Exit cleanly with `"No tickets with Status=Ready. Nothing to do."`
+- Workflow misconfigured (pre-flight check finds `$CLAIMED` or `$DONE` not reachable, or `$READY` status absent). Surface and exit.
+- Empty ready set. Exit cleanly with `"No tickets with Status=$READY. Nothing to do."`
 
 ## Lifecycle assumed
 
-The JIRA workflow has these statuses (or equivalents — see Configuration for renaming):
+The JIRA workflow has these statuses (configured per project — see Workflow resolution above for how role names map to actual workflow values):
 
 ```text
-TODO → Ready → In Progress → On Dev → On QA → Done
-       (PM/   (us claim)    (us done; (downstream)
-        human)               PR ready)
+TODO → ready → claimed → done(env-keyed) → On QA → archive
+       (PM/    (us claim)  (us done;        (downstream)
+        human)              PR ready)
 ```
 
-This skill ONLY transitions `Ready → In Progress` on claim, and `In Progress → On Dev` on completion. It never touches `TODO`, `On QA`, `Done`, or any blocked/closed states.
+This skill ONLY transitions `$READY → $CLAIMED` on claim, and `$CLAIMED → $DONE` on completion. It never touches `TODO`, post-`done` statuses, or any blocked/closed states.
 
-**Pre-flight check**: at start of each cycle, call `getTransitionsForJiraIssue` against a sample Ready ticket to confirm `In Progress` and `On Dev` are reachable transitions. If not, stop and report the workflow misconfiguration to the caller — do not invent transitions.
+**Pre-flight check**: at start of each cycle, attempt the `$CLAIMED` and `$DONE` transitions against a sample ready ticket via `lisa:atlassian-access` `operation: transition key: <K> to: "<status>"` (in a probe / dry-run sense — or fetch transition metadata if the access skill exposes that). If the transitions are unreachable, stop and report the workflow misconfiguration to the caller — do not invent transitions.
 
 ## Phases
 
 ### Phase 1 — Resolve the query
 
 1. Parse `$ARGUMENTS`:
-   - Project key: build JQL `project = <KEY> AND Status = "Ready" ORDER BY priority DESC, created ASC`.
-   - Full JQL: use as-is. If it does not include a `Status` clause, append `AND Status = "Ready"`.
-2. Resolve Atlassian cloud ID via `getAccessibleAtlassianResources`.
+   - Project key: build JQL `project = <KEY> AND Status = "$READY" ORDER BY priority DESC, created ASC`.
+   - Full JQL: use as-is. If it does not include a `Status` clause, append `AND Status = "$READY"`.
+2. Confirm the configured Atlassian site by invoking `lisa:atlassian-access` `operation: list-sites` (it enforces connection match against `.lisa.config.json`).
 
-### Phase 2 — Find Ready tickets
+### Phase 2 — Find ready tickets
 
-Run the JQL via `searchJiraIssuesUsingJql`. Capture each ticket's: key, summary, issue type, priority, assignee, parent (epic), labels, components.
+Invoke `lisa:atlassian-access` `operation: search-issues jql: "<JQL>"`. Capture each ticket's: key, summary, issue type, priority, assignee, parent (epic), labels, components.
 
-If empty, report `"No tickets with Status=Ready. Nothing to do."` and exit. This is the common idle case.
+If empty, report `"No tickets with Status=$READY. Nothing to do."` and exit. This is the common idle case.
 
-### Phase 3 — Process each Ready ticket (serial)
+### Phase 3 — Process each ready ticket (serial)
 
 #### 3a. Claim
 
-Transition the ticket from `Ready` to `In Progress` via `transitionJiraIssue`.
-- Use `getTransitionsForJiraIssue` to find the transition ID for `In Progress`.
-- Post a `[claude-build-intake]` comment via `addCommentToJiraIssue`: `"Claimed by Claude. Starting build."`
-- This is the idempotency lock — a re-entrant cycle's `Status = Ready` filter will not see this ticket again.
+Transition the ticket from `$READY` to `$CLAIMED` by invoking `lisa:atlassian-access` `operation: transition key: <TICKET> to: "$CLAIMED"`.
+- Post a `[claude-build-intake]` comment via `lisa:atlassian-access` `operation: comment key: <TICKET> body: "Claimed by Claude. Starting build."`
+- This is the idempotency lock — a re-entrant cycle's `Status = $READY` filter will not see this ticket again.
 
 If the transition fails (permission, missing transition, race), log under "Errors" in the cycle summary and skip this ticket. **Do not invoke the build flow on a ticket you didn't successfully claim.**
 
@@ -83,21 +139,21 @@ Invoke the `lisa:jira-agent` (existing per-ticket lifecycle agent) with the tick
 Wait for `lisa:jira-agent` to return. Capture its outcome:
 - **Success** — PR is ready (open or merged); evidence posted; ready for next status.
 - **Blocked by jira-verify pre-flight gate** — `lisa:jira-agent` itself transitions the ticket to `Blocked` and reassigns to Reporter. This is correct and expected — let it stand. Record the outcome and move on.
-- **Blocked by ticket-triage ambiguities** — `lisa:jira-agent` posts findings and stops. The ticket stays in `In Progress`. Surface to human; do not auto-transition. Record under "Errors" with reason `"Triage found ambiguities — see comments on <ticket-key>"`.
-- **Errored** — exception, missing config, etc. Leave the ticket in `In Progress` for human investigation. Record under "Errors" with the exception summary.
+- **Blocked by ticket-triage ambiguities** — `lisa:jira-agent` posts findings and stops. The ticket stays in `$CLAIMED`. Surface to human; do not auto-transition. Record under "Errors" with reason `"Triage found ambiguities — see comments on <ticket-key>"`.
+- **Errored** — exception, missing config, etc. Leave the ticket in `$CLAIMED` for human investigation. Record under "Errors" with the exception summary.
 
-#### 3c. Transition to On Dev (only on Success)
+#### 3c. Transition to $DONE (only on Success)
 
 If `lisa:jira-agent` returned Success:
-1. Use `getTransitionsForJiraIssue` to find the transition ID for `On Dev` (or the configured next-after-build status).
-2. Transition via `transitionJiraIssue`.
-3. Post a `[claude-build-intake]` comment: `"Build complete. PR <URL>. Transitioned to On Dev."`
+1. Resolve `$DONE` for this ticket's PR base branch using the Workflow resolution algorithm above. If env can't be resolved and `done` is env-keyed, record an Error and skip this transition — never guess.
+2. Invoke `lisa:atlassian-access` `operation: transition key: <TICKET> to: "$DONE"`.
+3. Post a `[claude-build-intake]` comment via `lisa:atlassian-access` `operation: comment key: <TICKET> body: "Build complete. PR <URL>. Transitioned to $DONE."`
 
-For any non-Success outcome, do NOT transition. The ticket sits in `In Progress` (or wherever `lisa:jira-agent` left it for the Blocked case) — the cycle's job is done; humans take it from there.
+For any non-Success outcome, do NOT transition. The ticket sits in `$CLAIMED` (or wherever `lisa:jira-agent` left it for the Blocked case) — the cycle's job is done; humans take it from there.
 
 #### 3d. Continue
 
-Move to the next Ready ticket. One ticket failing does not stop others.
+Move to the next ready ticket. One ticket failing does not stop others.
 
 ### Phase 4 — Summary report
 
@@ -109,7 +165,7 @@ Cycle started: <ISO timestamp>
 Cycle completed: <ISO timestamp>
 
 Tickets processed: <n>
-- On Dev (build complete, PR ready): <n>
+- $DONE (build complete, PR ready): <n>
   - <ticket-key> <summary> → PR <URL>
 - Blocked (pre-flight verify failed): <n>
   - <ticket-key> <summary> — see ticket comments
@@ -123,32 +179,41 @@ Total PRs opened: <n>
 
 ## Idempotency & safety
 
-- **Claim-first ordering**: `In Progress` set BEFORE `lisa:jira-agent` invocation — no double-pickup.
-- **No writes outside the lifecycle**: this skill only transitions `Ready → In Progress` and `In Progress → On Dev`. Every other status change is owned by `lisa:jira-agent` (which suggests transitions but only auto-transitions on the verify-FAIL path).
+- **Claim-first ordering**: `$CLAIMED` set BEFORE `lisa:jira-agent` invocation — no double-pickup.
+- **No writes outside the lifecycle**: this skill only transitions `$READY → $CLAIMED` and `$CLAIMED → $DONE`. Every other status change is owned by `lisa:jira-agent` (which suggests transitions but only auto-transitions on the verify-FAIL path).
 - **Failure isolation**: per-ticket exceptions caught and recorded; the cycle continues.
 - **Single cycle per query**: do not run two `lisa:jira-build-intake` cycles in parallel against overlapping queries — concurrent claims could race. The scheduling layer (when added) is responsible for serialization.
-- **Never invent a transition**: if `In Progress` or `On Dev` aren't valid transitions in the project's workflow, stop and report rather than guessing alternative names.
+- **Never invent a transition**: if `$CLAIMED` or `$DONE` aren't valid transitions in the project's workflow, stop and report rather than guessing alternative names.
 
 ## Configuration
 
-Reads `atlassian.cloudId` and `jira.project` from `.lisa.config.json` (with `.lisa.config.local.json` overriding per key). The project key is also accepted as `$ARGUMENTS` for ad-hoc invocations.
+Reads `atlassian.cloudId`, `jira.project`, and `jira.workflow.{ready,claimed,done}` from `.lisa.config.json` (with `.lisa.config.local.json` overriding per key). The project key is also accepted as `$ARGUMENTS` for ad-hoc invocations.
+
+Status role names default to:
+- `ready` → `"Ready"`
+- `claimed` → `"In Progress"`
+- `done` → env-keyed map `{ "dev": "On Dev", "staging": "On Stg", "production": "Done" }`
+
+If a project uses different names (e.g. `Open` instead of `TODO`, `In Development` instead of `In Progress`, `Code Review` for terminal), override the relevant key in `.lisa.config.json` `jira.workflow.*`. The setup skills (`/lisa:setup:jira`) handle this interactively.
 
-Status names default to `Ready`, `In Progress`, `On Dev`. If a project uses different names (`Open` instead of `TODO`, `In Development` instead of `In Progress`, `Code Review` instead of `On Dev`), pass overrides in `$ARGUMENTS` as `claim_status="In Development" done_status="Code Review"`.
+Per-invocation overrides via `$ARGUMENTS` (e.g. `claim_status="In Development"`) are accepted as a secondary escape hatch but `.lisa.config.json` is the canonical source.
 
-If a `Ready` status does not exist in the JIRA project's workflow, this skill cannot run. The remediation is to add `Ready` to the project workflow scheme — JIRA admin task, not something this skill can do.
+If a ready-equivalent status does not exist in the JIRA project's workflow, this skill cannot run. The remediation is to add it to the project workflow scheme — JIRA admin task, not something this skill can do.
 
 | Field / variable | Default | Purpose |
 |------------------|---------|---------|
 | `.lisa.config.json` `jira.project` | (from `$ARGUMENTS`) | Project key for the default JQL |
 | `.lisa.config.json` `atlassian.cloudId` | — | Atlassian Cloud site UUID (required) |
-| Status: queue | `Ready` | The status that signals "human says this is buildable" |
-| Status: claim | `In Progress` | The intermediate status the agent sets on pickup |
-| Status: done | `On Dev` | The status set after a successful build |
+| `.lisa.config.json` `jira.workflow.ready` | `Ready` | The status that signals "human says this is buildable" |
+| `.lisa.config.json` `jira.workflow.claimed` | `In Progress` | The intermediate status the agent sets on pickup |
+| `.lisa.config.json` `jira.workflow.done` | env-keyed map (`dev`/`staging`/`production`) or string | The status set after a successful build; env-aware |
+| `.lisa.config.json` `deploy.branches` | — | Reverse-lookup map for env inference from PR base branch |
 
 ## Rules
 
-- Never transition a ticket the cycle didn't claim. The `In Progress` transition is the signature of cycle ownership.
+- Never transition a ticket the cycle didn't claim. The `$CLAIMED` transition is the signature of cycle ownership.
 - Never bypass `lisa:jira-agent` to do build work directly. `lisa:jira-agent` owns the per-ticket lifecycle (read, verify, triage, route, sync, evidence). This skill is the dispatcher, not the builder.
-- Never auto-transition past `On Dev`. Downstream statuses (`On QA`, `Done`) are owned by QA / product / a future verification-intake skill — not this one.
+- Never auto-transition past `$DONE`. Downstream statuses are owned by QA / product / a future verification-intake skill — not this one.
 - If the ticket has no Validation Journey or no sign-in credentials in its description, `lisa:jira-agent`'s pre-flight verify will catch it and transition to `Blocked` — **don't try to fix the ticket from here**. Pre-flight gating is `lisa:jira-agent`'s job; running build work on a thin ticket produces broken work.
 - On any unexpected response from `lisa:jira-agent` (status it doesn't claim, missing PR URL on success, etc.), record as Error and surface — never assume.
+- Never pick an arbitrary env for `$DONE` resolution. If `done` is a map and env is ambiguous, fail loudly.

package/plugins/lisa/skills/jira-create/SKILL.md

@@ -1,12 +1,14 @@
 ---
 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", "Skill", "mcp__atlassian__getVisibleJiraProjects", "mcp__atlassian__getJiraProjectIssueTypesMetadata", "mcp__atlassian__getAccessibleAtlassianResources"]
+allowed-tools: ["Read", "Glob", "LS", "Skill"]
 ---
 
 # Create JIRA Issues from $ARGUMENTS
 
-Analyze the provided file(s) and plan a JIRA hierarchy. **This skill plans structure only — every individual ticket write is delegated to `lisa:jira-write-ticket`.** Do not call `mcp__atlassian__createJiraIssue` from this skill; the necessary write tools are intentionally not in `allowed-tools`.
+All Atlassian operations in this skill go through `lisa:atlassian-access`. Do not call MCP tools or `acli` directly.
+
+Analyze the provided file(s) and plan a JIRA hierarchy. **This skill plans structure only — every individual ticket write is delegated to `lisa:jira-write-ticket`.** Do not invoke `lisa:atlassian-access` write operations directly from this skill — all writes go through `lisa:jira-write-ticket`.
 
 ## Process
 
@@ -110,7 +112,7 @@ Exclude unless requested: migration plans, performance tests
 
 ## Delegation to jira-write-ticket
 
-**Mandatory.** Every ticket created by this skill MUST go through `lisa:jira-write-ticket`. This skill never calls `mcp__atlassian__createJiraIssue` itself — that tool is intentionally excluded from `allowed-tools` so the gate cannot be bypassed.
+**Mandatory.** Every ticket created by this skill MUST go through `lisa:jira-write-ticket`. This skill never invokes `lisa:atlassian-access` write operations itself — all writes are delegated so the gate cannot be bypassed.
 
 `lisa:jira-write-ticket` enforces things this skill does not, and which determine ticket quality:
 - 3-audience description (Context / Technical Approach / Acceptance Criteria)

package/plugins/lisa/skills/jira-evidence/SKILL.md

@@ -1,10 +1,27 @@
 ---
 name: jira-evidence
-description: "Upload text evidence to GitHub pr-assets release, update PR description, post JIRA comment with code blocks, and move ticket to Code Review. Reusable by any skill that captures evidence and generates evidence/comment.txt + evidence/comment.md."
+description: "Upload text evidence to GitHub pr-assets release, update PR description, post JIRA comment with code blocks, and move ticket to the configured code-review status. Reusable by any skill that captures evidence and generates evidence/comment.txt + evidence/comment.md."
 ---
 
 # JIRA Evidence Posting
 
+## Workflow resolution
+
+The post-build review status is read from `.lisa.config.json` `jira.workflow.review` (or `jira.workflow.code_review`), falling back to `Code Review`. JIRA does not have a separate `review` role in the canonical config schema (the build lifecycle stays in `claimed` until `done`); this skill uses the project's actual post-build review status when one exists. If the configured status is not a valid transition from the ticket's current state, log a warning and skip the transition — the human will handle it.
+
+```bash
+REVIEW="Code Review"
+if [ -f .lisa.config.json ]; then
+  _cfg=$(jq -r '.jira.workflow.review // .jira.workflow.code_review // empty' .lisa.config.json 2>/dev/null)
+  [ -n "$_cfg" ] && REVIEW="$_cfg"
+fi
+if [ -f .lisa.config.local.json ]; then
+  _local=$(jq -r '.jira.workflow.review // .jira.workflow.code_review // empty' .lisa.config.local.json 2>/dev/null)
+  [ -n "$_local" ] && REVIEW="$_local"
+fi
+```
+
+
 Upload captured evidence and generated templates to GitHub PR description and JIRA ticket. This skill is the posting step — it assumes evidence files and comment templates already exist in the evidence directory.
 
 ## Arguments
@@ -43,7 +60,7 @@ bash .claude/skills/jira-evidence/scripts/post-evidence.sh PROJ-123 ./evidence 4
 2. **Upload to GitHub `pr-assets` release** — Uploads evidence files via `gh release upload --clobber`
 3. **Update PR description** — Replaces or appends the `## Evidence` section in the PR body
 4. **Post JIRA comment** — Posts `comment.txt` as a new comment (wiki markup with code blocks)
-5. **Move ticket to Code Review** — Transitions the JIRA ticket
+5. **Move ticket to the configured review status** — Transitions the JIRA ticket to `$REVIEW` (default: `Code Review`).
 
 ## Evidence Naming Convention
 

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

@@ -1,11 +1,13 @@
 ---
 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", "mcp__atlassian__getJiraIssue", "mcp__atlassian__updateJiraIssue"]
+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

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

@@ -1,23 +1,25 @@
 ---
 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"]
+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. Call `mcp__atlassian__getAccessibleAtlassianResources` to get the cloud ID.
+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
 
-Call `mcp__atlassian__getJiraIssue` for the target ticket. Extract and preserve:
+Invoke `lisa:atlassian-access` via the Skill tool with `operation: read-ticket key: <TICKET-KEY>` for the target ticket. Extract and preserve:
 
 ### Metadata
 
@@ -60,7 +62,7 @@ Fetch ALL comments in chronological order. Do not truncate. For each:
 
 ## Phase 3 — Fetch Remote Links
 
-Call `mcp__atlassian__getJiraIssueRemoteIssueLinks`. For each remote link:
+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.
@@ -78,7 +80,7 @@ Every linked ticket must be fetched. Do not skip any link type. For each link in
 - `clones` / `is cloned by`
 - Any other custom link types configured in the project
 
-For each linked ticket, call `mcp__atlassian__getJiraIssue` and capture:
+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)
@@ -92,19 +94,19 @@ For each linked ticket, call `mcp__atlassian__getJiraIssue` and capture:
 
 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.
+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>
    ```
-   Use `mcp__atlassian__searchJiraIssuesUsingJql`. For each sibling capture: key, summary, type, status, assignee, priority.
+   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 `mcp__atlassian__getJiraIssue`: key, summary, type, status, assignee, description (first paragraph), acceptance criteria.
+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
 

package/plugins/lisa/skills/jira-sync/SKILL.md

@@ -1,11 +1,13 @@
 ---
 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: ["mcp__atlassian__*", "Bash", "Read", "Glob", "Grep"]
+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/`).
@@ -15,7 +17,7 @@ If no argument provided, search for a ticket URL in the active plan file (most r
 ### Step 1: Identify Ticket and Context
 
 1. **Parse ticket ID** from `$ARGUMENTS` or extract from the active plan file
-2. **Fetch current ticket state** via JIRA MCP (`mcp__atlassian__getJiraIssue`)
+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
@@ -36,11 +38,15 @@ Based on the current milestone:
 
 ### Step 3: Post Update
 
-1. **Add a comment** to the ticket with the gathered content via JIRA MCP
-2. **Update ticket fields** if applicable:
+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
-3. **Report** what was synced to the user
+5. **Report** what was synced to the user
 
 ### Step 4: Suggest Status Transition