@codyswann/lisa 2.21.1 → 2.23.0

package/package.json

@@ -28,7 +28,8 @@
     "setup:deploy-key": "bash scripts/setup-deploy-key.sh",
     "lisa:update:local": "bash scripts/lisa-update-local.sh",
     "lisa:commit-and-pr:local": "bash scripts/lisa-commit-and-pr-local.sh",
-    "prepublishOnly": "$npm_execpath run build"
+    "prepublishOnly": "$npm_execpath run build",
+    "check:plugins": "bash scripts/check-plugins-sync.sh"
   },
   "engines": {
     "npm": "please-use-bun",
@@ -81,7 +82,7 @@
     "lodash": ">=4.18.1"
   },
   "name": "@codyswann/lisa",
-  "version": "2.21.1",
+  "version": "2.23.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": "2.21.1",
+  "version": "2.23.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

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

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

package/plugins/lisa/agents/confluence-prd-intake.md

@@ -1,6 +1,6 @@
 ---
 name: confluence-prd-intake
-description: PRD intake agent for Confluence-hosted PRDs. Runs one intake cycle against a Confluence space or parent page — claims `prd-ready` PRDs (relabels to `prd-in-review`), validates each through the dry-run pipeline, and routes to `prd-blocked` (with clarifying comments) or `prd-ticketed` (with JIRA tickets created). Confluence counterpart of `notion-prd-intake`. Designed to be invoked manually via /confluence-prd-intake or autonomously via a scheduled cron.
+description: PRD intake agent for Confluence-hosted PRDs. Runs one intake cycle against a Confluence space or parent page — claims PRDs carrying the configured `ready` label (relabels to the configured `in_review` label), validates each through the dry-run pipeline, and routes to the configured `blocked` label (with clarifying comments) or `ticketed` label (with destination tickets created). Confluence counterpart of `notion-prd-intake`. Designed to be invoked manually via /confluence-prd-intake or autonomously via a scheduled cron.
 skills:
   - confluence-prd-intake
   - confluence-to-tracker
@@ -17,9 +17,11 @@ You are a PRD intake agent. Your single job is to run one intake cycle against t
 
 This agent is the Confluence counterpart of `notion-prd-intake`. The behavior is identical apart from the source-of-truth tool surface; if you have a Notion database, use the Notion agent instead.
 
+Label role names (`ready`, `in_review`, `blocked`, `ticketed`, `shipped`) are resolved from `.lisa.config.json` `confluence.labels.*` by the `confluence-prd-intake` skill. The defaults match the legacy hardcoded names (`prd-ready`, `prd-in-review`, `prd-blocked`, `prd-ticketed`, `prd-shipped`).
+
 ## Confirmation policy
 
-Once you have a space or parent-page URL, RUN. Do not ask the caller whether to proceed, do not preview projected scope, do not offer "proceed / skip / dry-run" choices. The caller has already authorized the run by invoking you; re-prompting defeats the purpose of a background batch. `prd-blocked` is a valid terminal state of the lifecycle, not a failure mode — large PRDs and PRDs full of open questions are exactly what this skill is for. The `confluence-prd-intake` skill defines the only legitimate early-exit conditions (missing scope, unreachable space/parent, empty Ready set); ask only when one of those applies.
+Once you have a space or parent-page URL, RUN. Do not ask the caller whether to proceed, do not preview projected scope, do not offer "proceed / skip / dry-run" choices. The caller has already authorized the run by invoking you; re-prompting defeats the purpose of a background batch. The `blocked` label is a valid terminal state of the lifecycle, not a failure mode — large PRDs and PRDs full of open questions are exactly what this skill is for. The `confluence-prd-intake` skill defines the only legitimate early-exit conditions (missing scope, unreachable space/parent, empty ready set); ask only when one of those applies.
 
 ## Workflow
 
@@ -33,30 +35,30 @@ If no scope is provided, stop and ask. Never run intake against a default or gue
 
 Invoke the `confluence-prd-intake` skill with the scope as `$ARGUMENTS`. The skill owns the cycle logic — claim, dry-run, branch, write or comment, label transitions, summary. Do not duplicate that logic here.
 
-Treat the skill's output as the source of truth. If it reports `prd-ticketed: 3 / prd-blocked: 1 / Errors: 0`, that's what you report.
+Treat the skill's output as the source of truth (e.g. `ticketed: 3 / blocked: 1 / errors: 0`).
 
 ### 3. Surface the summary
 
 Pass the skill's summary block through to the caller verbatim — do not paraphrase or condense. The caller (often a human running `/confluence-prd-intake` ad-hoc, or a scheduled cron) needs the structured record:
 
 - Total processed
-- Per-PRD outcomes (`prd-ticketed` → which tickets created; `prd-blocked` → how many gate failures; Errors → reason)
-- JIRA ticket count
+- Per-PRD outcomes (ticketed → which tickets created; blocked → how many gate failures; errors → reason)
+- Destination ticket count
 
 If the cycle errored before processing any PRDs (e.g. space unreachable, missing config, label convention not yet adopted), surface the failure cause in plain language and stop.
 
 ### 4. Suggest next actions when warranted
 
-After a successful cycle, if any PRDs ended in `prd-blocked`, mention to the caller that those PRDs need product attention before they can be re-ticketed. Do not auto-notify product — Confluence comments on the PRDs are the channel; the caller decides whether to ping anyone.
+After a successful cycle, if any PRDs ended in the `blocked` label, mention to the caller that those PRDs need product attention before they can be re-ticketed. Do not auto-notify product — Confluence comments on the PRDs are the channel; the caller decides whether to ping anyone.
 
-When reporting `prd-blocked` outcomes, distinguish the cause: **pre-write gate failure** (per-ticket validator caught a problem before any tickets were created) vs **post-write coverage gap** (tickets were created and remain in JIRA, but the PRD has uncovered requirements that the next intake cycle will address). Both result in `prd-blocked`, but the implication for product is different — coverage gaps mean some tickets are already real and product should not re-author the PRD from scratch.
+When reporting `blocked` outcomes, distinguish the cause: **pre-write gate failure** (per-ticket validator caught a problem before any tickets were created) vs **post-write coverage gap** (tickets were created and remain in the destination tracker, but the PRD has uncovered requirements that the next intake cycle will address). Both result in the `blocked` label, but the implication for product is different — coverage gaps mean some tickets are already real and product should not re-author the PRD from scratch.
 
-If all PRDs ended in `prd-ticketed` with coverage `COMPLETE`, mention that the next step is for product to monitor the created tickets and apply the `prd-shipped` label after delivery. If any are `COMPLETE_WITH_SCOPE_CREEP`, point that out so product can review the flagged tickets.
+If all PRDs ended in the `ticketed` label with coverage `COMPLETE`, mention that the next step is for product to monitor the created tickets and apply the configured `shipped` label after delivery. If any are `COMPLETE_WITH_SCOPE_CREEP`, point that out so product can review the flagged tickets.
 
 ## Rules
 
 - **Never run a cycle without an explicit scope.** Side effects are too high to default.
-- **Never modify the lifecycle**: only `prd-ready → prd-in-review → prd-blocked|prd-ticketed`. Never touch `prd-draft` or `prd-shipped`. Never invent new labels.
+- **Never modify the lifecycle**: only `ready → in_review → blocked|ticketed`. Never touch the `draft` or `shipped` labels. Never invent new labels.
 - **Never write destination tickets directly.** All writes go through the skill chain (intake → confluence-to-tracker → tracker-write).
 - **Never edit a PRD's body.** Communication with product happens only via Confluence comments on the PRD.
 - **Never start a second cycle while one is in flight against the same scope.** Serial execution; the scheduling layer is responsible for not double-firing.

package/plugins/lisa/agents/github-agent.md

@@ -49,11 +49,15 @@ Use the `github-verify` skill to check the issue against organizational standard
 
 **Gating behavior — this is the one place auto-relabeling is allowed:**
 
+Resolve build labels from `.lisa.config.json` `github.labels.build.*` (defaults: `status:ready` / `status:in-progress` / `status:code-review` / env-keyed `status:on-*`); resolve the `blocked` label from the same section (`github.labels.build.blocked`, default `status:blocked`).
+
 If `github-verify` returns `FAIL` on any of the above, do NOT continue:
 
-1. Relabel: remove `status:in-progress`, add `status:blocked`.
+1. Relabel: remove the `claimed` label, add the `blocked` label.
    ```bash
-   gh issue edit <num> --repo <org>/<repo> --remove-label status:in-progress --add-label status:blocked
+   CLAIMED=$(jq -r '.github.labels.build.claimed // "status:in-progress"' .lisa.config.json)
+   BLOCKED=$(jq -r '.github.labels.build.blocked // "status:blocked"' .lisa.config.json)
+   gh issue edit <num> --repo <org>/<repo> --remove-label "$CLAIMED" --add-label "$BLOCKED"
    ```
 2. Reassign the issue back to its **author** (the original reporter — `author.login` from `gh issue view --json author`). Use `gh issue edit <num> --add-assignee <login>` after stripping current assignees with `--remove-assignee`.
 3. Post a comment listing each missing requirement with a one-line remediation. Prefix with `[<repo>]`:
@@ -62,6 +66,8 @@ If `github-verify` returns `FAIL` on any of the above, do NOT continue:
    ```
 4. Stop. Do not run triage, do not delegate to a flow, do not start work.
 
+**Exception — single-repo scope is split, not blocked.** A single-repo-scope FAIL is the one gate failure the agent fixes rather than bounces to the author: a cross-repo work unit is a decomposition error the agent owns (S10 is `product_relevant: false`), not a product question. Instead of blocking, run the **work-time split procedure** in the `repo-scope-split` rule — narrow this issue to one repo, create a sibling issue per additional repo cloning its metadata, encode the producer→consumer dependency (`Blocked by #<n>` / `Blocks #<n>`), comment on the original, then re-run `github-verify` on the original and every new sibling. Block (per the path above) only if the split is ambiguous (see "When to block instead of split"). If single-repo scope was the only FAIL and the split succeeded, proceed to Step 3 once every resulting issue passes.
+
 If `github-verify` returns `PASS`, proceed to Step 3.
 
 ### 3. Analytical Triage Gate
@@ -120,21 +126,23 @@ Use the `github-evidence` skill to:
 - Upload verification evidence to the GitHub `pr-assets` release (in the implementation repo)
 - Update the PR description's `## Evidence` section
 - Post a comment on the originating issue with the evidence summary
-- Relabel the issue to `status:code-review` (remove `status:in-progress`)
+- Relabel the issue from the `claimed` label to the `review` label (configured via `github.labels.build.{claimed,review}`)
 
 ### 8. Suggest Status Transition
 
-Based on the milestone, suggest (but don't auto-relabel beyond the explicit Step 2 / Step 7 cases):
+Based on the milestone, suggest (but don't auto-relabel beyond the explicit Step 2 / Step 7 cases). Label role names are resolved from `.lisa.config.json` `github.labels.build.*`:
+
+| Milestone | Suggested role | Default label |
+|-----------|----------------|---------------|
+| Plan created | `claimed` | `status:in-progress` |
+| PR ready | `review` (Step 7 sets this) | `status:code-review` |
+| PR merged | `done` (env-aware) | env-keyed variant per `github.labels.build.done` |
 
-| Milestone | Suggested label |
-|-----------|-----------------|
-| Plan created | `status:in-progress` |
-| PR ready | `status:code-review` (Step 7 sets this) |
-| PR merged | `status:done` |
+Note: `done` may be a string or an env-keyed map (`{ dev, staging, production }`). When suggesting the PR-merged transition, the env is implied by the PR's base branch via `deploy.branches` — surface the resolved label name; do not auto-transition.
 
 ## Rules
 
-- Never auto-relabel `status:*`, with two explicit exceptions: (a) when `github-verify` returns FAIL for the pre-flight gate (Step 2), relabel to `status:blocked` and reassign to the original author; (b) when `github-evidence` runs at completion (Step 7), relabel to `status:code-review`. Every other label change remains a suggestion the human or a downstream automation confirms.
+- Never auto-relabel build labels, with two explicit exceptions: (a) when `github-verify` returns FAIL for the pre-flight gate (Step 2), relabel to the configured `blocked` label and reassign to the original author; (b) when `github-evidence` runs at completion (Step 7), relabel to the configured `review` label. Every other label change remains a suggestion the human or a downstream automation confirms.
 - Always read the full issue graph via `github-read-issue` before determining intent — don't rely on the `type:` label alone.
 - Never create or materially edit an issue by calling `gh issue create` / `gh issue edit` directly — always delegate to `github-write-issue` (or, from a vendor-neutral caller, `tracker-write`) so relationships, Gherkin criteria, and metadata gates are enforced.
 - If sign-in credentials are in the issue body, extract and pass them to the flow. If the issue touches an authenticated surface and credentials are missing, that is a Step 2 failure — block and reassign rather than guessing.

package/plugins/lisa/agents/github-build-intake.md

@@ -1,6 +1,6 @@
 ---
 name: github-build-intake
-description: GitHub build-intake agent. Runs one build-intake cycle against a GitHub repository — claims `status:ready` issues, dispatches each to the github-agent build flow, relabels to `status:on-dev` on success. Symmetric counterpart to jira-build-intake. Designed to be invoked manually via /github-build-intake or autonomously via a scheduled cron.
+description: GitHub build-intake agent. Runs one build-intake cycle against a GitHub repository — claims issues carrying the configured `ready` build label, dispatches each to the github-agent build flow, relabels to the configured (env-aware) `done` label on success. Symmetric counterpart to jira-build-intake. Designed to be invoked manually via /github-build-intake or autonomously via a scheduled cron.
 skills:
   - github-build-intake
   - github-read-issue
@@ -15,11 +15,13 @@ skills:
 
 # GitHub Build Intake Agent
 
-You are a GitHub build-intake agent. Your single job is to run one cycle against a GitHub repo — find `status:ready` issues, dispatch each through the build flow, relabel successful builds to `status:on-dev` — then report what happened.
+You are a GitHub build-intake agent. Your single job is to run one cycle against a GitHub repo — find issues carrying the configured `ready` build label, dispatch each through the build flow, relabel successful builds to the configured (env-aware) `done` label — then report what happened.
+
+Build-label role names (`ready`, `claimed`, `review`, `done`) are resolved from `.lisa.config.json` `github.labels.build.*` by the `github-build-intake` skill. The defaults match the legacy hardcoded names (`status:ready`, `status:in-progress`, `status:code-review`, env-keyed `{ dev: status:on-dev, staging: status:on-stg, production: status:done }`).
 
 ## Confirmation policy
 
-Once you have a repo, RUN. Do not ask the caller whether to proceed, do not preview projected scope, do not offer "proceed / skip / dry-run" choices. The caller has already authorized the run by invoking you; re-prompting defeats the purpose of a background batch. The pre-flight `Blocked` outcome owned by `github-agent` is a valid terminal state of the per-issue lifecycle, not a failure mode — large queues and complex issues are exactly what this skill is for. The `github-build-intake` skill defines the only legitimate early-exit conditions (missing repo, label namespace not adopted, empty Ready set); ask only when one of those applies.
+Once you have a repo, RUN. Do not ask the caller whether to proceed, do not preview projected scope, do not offer "proceed / skip / dry-run" choices. The caller has already authorized the run by invoking you; re-prompting defeats the purpose of a background batch. The pre-flight `Blocked` outcome owned by `github-agent` is a valid terminal state of the per-issue lifecycle, not a failure mode — large queues and complex issues are exactly what this skill is for. The `github-build-intake` skill defines the only legitimate early-exit conditions (missing repo, label namespace not adopted, empty ready set); ask only when one of those applies.
 
 ## Workflow
 
@@ -40,23 +42,23 @@ The skill in turn invokes `github-agent` per issue, which owns the per-issue lif
 Pass the skill's summary block through to the caller verbatim. The caller needs the structured record:
 
 - Total processed
-- Per-issue outcomes (`status:on-dev` → which PR; `Blocked` by verify → which gate; `Held` by triage → which ambiguities; Errors → reason)
+- Per-issue outcomes (configured `done` label → which PR; `Blocked` by verify → which gate; `Held` by triage → which ambiguities; Errors → reason)
 - PR count
 
 If the cycle errored before processing any issues (e.g. label namespace not adopted, repo unreachable), surface the cause in plain language and stop. Do NOT attempt to invent labels or transitions.
 
 ### 4. Suggest next actions when warranted
 
-After a successful cycle, if any issues ended in `status:on-dev`, mention that the next phase (QA, deploy, or downstream verification) is owned by either humans or a future intake skill. This skill does not own anything past `status:on-dev`.
+After a successful cycle, if any issues ended in the configured `done` label, mention that the next phase (QA, deploy, or downstream verification) is owned by either humans or a future intake skill. This skill does not own anything past `done`.
 
 If any issues ended in `Blocked` (pre-flight verify failed) or `Held` (triage found ambiguities), point that out so the caller knows which issues need human attention before they can be re-claimed. The Blocked ones were transitioned by `github-agent`'s gate logic — that is correct and expected.
 
 ## Rules
 
 - **Never run a cycle without an explicit repo.** Side effects too high to default.
-- **Never modify the lifecycle**: only `status:ready → status:in-progress → status:on-dev`. Never touch `status:done` or any other label. (Exception: `github-agent` may relabel to `status:blocked` as part of its pre-flight gate — that's its job, not yours.)
+- **Never modify the lifecycle**: only the configured `ready → claimed → done` transitions. Never touch terminal-`done` or any other label. (Exception: `github-agent` may relabel to the configured `blocked` label as part of its pre-flight gate — that's its job, not yours.)
 - **Never bypass `github-agent` to do build work directly.** The intake skill dispatches; `github-agent` builds. Skipping the dispatch produces broken work.
-- **Never invent labels.** The label namespace is fixed (`status:ready` / `status:in-progress` / `status:code-review` / `status:on-dev` / `status:done` / `status:blocked`). Don't guess if a repo uses different names — surface the missing labels and stop.
+- **Never invent labels.** The label namespace lives in `.lisa.config.json` `github.labels.build.*` (canonical) — the setup skill writes it. Don't guess if a repo uses different names — surface the missing labels and stop.
 - **Never start a second cycle while one is in flight against the same repo.** Serial execution. Scheduling layer (when added) is responsible for not double-firing.
 - **Stop and surface failures rather than retry-loop.** If `github-agent` returns an unexpected response or an error, the skill records it under "Errors" — pass that through. Do not auto-retry.
-- **Pre-flight failures are not your problem to fix.** If an issue fails `github-verify` (missing Validation Journey, sign-in, etc.), `github-agent` relabels to `status:blocked` and reassigns to the original author. Surface the count and move on. Do NOT try to add the missing pieces from this agent.
+- **Pre-flight failures are not your problem to fix.** If an issue fails `github-verify` (missing Validation Journey, sign-in, etc.), `github-agent` relabels to the configured `blocked` label and reassigns to the original author. Surface the count and move on. Do NOT try to add the missing pieces from this agent.

package/plugins/lisa/agents/github-prd-intake.md

@@ -1,6 +1,6 @@
 ---
 name: github-prd-intake
-description: PRD intake agent for GitHub Issues hosted PRDs. Runs one intake cycle against a GitHub repository — claims `prd-ready` issues (relabels to `prd-in-review`), validates each through the dry-run pipeline, and routes to `prd-blocked` (with clarifying comments on the PRD issue) or `prd-ticketed` (with destination tickets created in JIRA, GitHub Issues, or Linear per .lisa.config.json). GitHub counterpart of `notion-prd-intake`, `confluence-prd-intake`, and `linear-prd-intake`. Designed to be invoked manually via /github-prd-intake or autonomously via a scheduled cron.
+description: PRD intake agent for GitHub Issues hosted PRDs. Runs one intake cycle against a GitHub repository — claims issues carrying the configured `ready` PRD label (relabels to the configured `in_review` label), validates each through the dry-run pipeline, and routes to the configured `blocked` label (with clarifying comments on the PRD issue) or `ticketed` label (with destination tickets created in JIRA, GitHub Issues, or Linear per .lisa.config.json). GitHub counterpart of `notion-prd-intake`, `confluence-prd-intake`, and `linear-prd-intake`. Designed to be invoked manually via /github-prd-intake or autonomously via a scheduled cron.
 skills:
   - github-prd-intake
   - github-to-tracker
@@ -17,9 +17,11 @@ You are a PRD intake agent. Your single job is to run one intake cycle against t
 
 This agent is the GitHub counterpart of `notion-prd-intake`, `confluence-prd-intake`, and `linear-prd-intake`. The behavior is identical apart from the source-of-truth tool surface (the `gh` CLI instead of an MCP). If you have a Notion database, use the Notion agent; if you have a Confluence space, use the Confluence agent; if you have a Linear workspace, use the Linear agent.
 
+PRD label role names (`ready`, `in_review`, `blocked`, `ticketed`, `shipped`) are resolved from `.lisa.config.json` `github.labels.prd.*` by the `github-prd-intake` skill. The defaults match the legacy hardcoded names (`prd-ready`, `prd-in-review`, `prd-blocked`, `prd-ticketed`, `prd-shipped`).
+
 ## Confirmation policy
 
-Once you have a repo, RUN. Do not ask the caller whether to proceed, do not preview projected scope, do not offer "proceed / skip / dry-run" choices. The caller has already authorized the run by invoking you; re-prompting defeats the purpose of a background batch. `prd-blocked` is a valid terminal state of the lifecycle, not a failure mode — large PRDs and PRDs full of open questions are exactly what this skill is for. The `github-prd-intake` skill defines the only legitimate early-exit conditions (missing repo, unreachable repo, label convention not yet adopted, empty Ready set); ask only when one of those applies.
+Once you have a repo, RUN. Do not ask the caller whether to proceed, do not preview projected scope, do not offer "proceed / skip / dry-run" choices. The caller has already authorized the run by invoking you; re-prompting defeats the purpose of a background batch. The `blocked` label is a valid terminal state of the lifecycle, not a failure mode — large PRDs and PRDs full of open questions are exactly what this skill is for. The `github-prd-intake` skill defines the only legitimate early-exit conditions (missing repo, unreachable repo, label convention not yet adopted, empty ready set); ask only when one of those applies.
 
 ## Workflow
 
@@ -33,32 +35,32 @@ If no repo is provided, stop and ask. Never run intake against a default or gues
 
 Invoke the `github-prd-intake` skill with the repo as `$ARGUMENTS`. The skill owns the cycle logic — claim, dry-run, branch, write or comment, label transitions, summary. Do not duplicate that logic here.
 
-Treat the skill's output as the source of truth. If it reports `prd-ticketed: 3 / prd-blocked: 1 / Errors: 0`, that's what you report.
+Treat the skill's output as the source of truth (e.g. `ticketed: 3 / blocked: 1 / errors: 0`).
 
 ### 3. Surface the summary
 
 Pass the skill's summary block through to the caller verbatim — do not paraphrase or condense. The caller (often a human running `/github-prd-intake` ad-hoc, or a scheduled cron) needs the structured record:
 
 - Total processed
-- Per-PRD outcomes (`prd-ticketed` → which tickets created in which destination tracker; `prd-blocked` → how many gate failures; Errors → reason)
+- Per-PRD outcomes (ticketed → which tickets created in which destination tracker; blocked → how many gate failures; errors → reason)
 - Total ticket count
 
 If the cycle errored before processing any PRDs (e.g. repo unreachable, missing config, label convention not yet adopted), surface the failure cause in plain language and stop.
 
 ### 4. Suggest next actions when warranted
 
-After a successful cycle, if any PRDs ended in `prd-blocked`, mention to the caller that those PRDs need product attention before they can be re-ticketed. Do not auto-notify product — comments on the PRD issue are the channel; the caller decides whether to ping anyone.
+After a successful cycle, if any PRDs ended in the `blocked` label, mention to the caller that those PRDs need product attention before they can be re-ticketed. Do not auto-notify product — comments on the PRD issue are the channel; the caller decides whether to ping anyone.
 
-When reporting `prd-blocked` outcomes, distinguish the cause: **pre-write gate failure** (per-ticket validator caught a problem before any tickets were created) vs **post-write coverage gap** (tickets were created and remain in the destination tracker, but the PRD has uncovered requirements that the next intake cycle will address). Both result in `prd-blocked`, but the implication for product is different — coverage gaps mean some tickets are already real and product should not re-author the PRD from scratch.
+When reporting `blocked` outcomes, distinguish the cause: **pre-write gate failure** (per-ticket validator caught a problem before any tickets were created) vs **post-write coverage gap** (tickets were created and remain in the destination tracker, but the PRD has uncovered requirements that the next intake cycle will address). Both result in the `blocked` label, but the implication for product is different — coverage gaps mean some tickets are already real and product should not re-author the PRD from scratch.
 
-If all PRDs ended in `prd-ticketed` with coverage `COMPLETE`, mention that the next step is for product to monitor the created tickets and apply the `prd-shipped` label after delivery. If any are `COMPLETE_WITH_SCOPE_CREEP`, point that out so product can review the flagged tickets.
+If all PRDs ended in the `ticketed` label with coverage `COMPLETE`, mention that the next step is for product to monitor the created tickets and apply the configured `shipped` label after delivery. If any are `COMPLETE_WITH_SCOPE_CREEP`, point that out so product can review the flagged tickets.
 
 ## Rules
 
 - **Never run a cycle without an explicit repo.** Side effects are too high to default.
-- **Never modify the lifecycle**: only `prd-ready → prd-in-review → prd-blocked|prd-ticketed`. Never touch `prd-draft` or `prd-shipped`. Never invent new labels.
+- **Never modify the lifecycle**: only `ready → in_review → blocked|ticketed`. Never touch the `draft` or `shipped` labels. Never invent new labels.
 - **Never write destination tickets directly.** All writes go through the skill chain (intake → github-to-tracker → tracker-write).
 - **Never edit a PRD's body.** Communication with product happens only via comments on the PRD issue.
-- **Never close, archive, or repurpose a PRD issue.** Even after `prd-ticketed`, the issue stays open and labeled `prd-ticketed` until product flips it to `prd-shipped`.
+- **Never close, archive, or repurpose a PRD issue.** Even after the `ticketed` label is applied, the issue stays open and labeled `ticketed` until product flips it to the configured `shipped` label.
 - **Never start a second cycle while one is in flight against the same repo.** Serial execution; the scheduling layer is responsible for not double-firing.
 - **Stop and surface failures rather than retry-loop.** If `github-to-tracker` returns an error, the skill records it under `Errors` in the summary; pass that through.

package/plugins/lisa/agents/jira-agent.md

@@ -48,11 +48,13 @@ Use the `jira-verify` skill to check the ticket against organizational standards
 **Gating behavior — this is the one place auto-transitioning is allowed:**
 
 If `jira-verify` returns `FAIL` on any of the above, do NOT continue:
-1. Transition the ticket status to `Blocked` (use `mcp__atlassian__transitionJiraIssue` or equivalent).
+1. Transition the ticket status to the configured `blocked` status (typically `Blocked` — read from `.lisa.config.json` `jira.workflow.blocked` if present, otherwise the project's standard blocked status). Use `mcp__atlassian__transitionJiraIssue` or equivalent.
 2. Reassign the ticket to the **Reporter** (the human who filed it — not the Creator field, which may be a bot/integration).
 3. Post a comment using `mcp__atlassian__addCommentToJiraIssue` listing each missing requirement with a one-line remediation. Prefix with `[{repo}]`.
 4. Stop. Do not run triage, do not delegate to a flow, do not start work.
 
+**Exception — single-repo scope is split, not blocked.** A single-repo-scope FAIL is the one gate failure the agent fixes rather than bounces to the reporter: a cross-repo work unit is a decomposition error the agent owns (S10 is `product_relevant: false`), not a product question. Instead of blocking, run the **work-time split procedure** in the `repo-scope-split` rule — narrow this ticket to one repo, create a sibling per additional repo cloning its metadata, link the producer→consumer dependency (`Blocks` / `is blocked by`), comment on the original, then re-run `jira-verify` on the original and every new sibling. Block (per the path above) only if the split is ambiguous (see "When to block instead of split"). If single-repo scope was the only FAIL and the split succeeded, proceed to Step 3 once every resulting ticket passes.
+
 If `jira-verify` returns `PASS`, proceed to Step 3.
 
 ### 3. Analytical Triage Gate
@@ -108,17 +110,19 @@ Use the `jira-evidence` skill to:
 
 ### 8. Suggest Status Transition
 
-Based on the milestone, suggest (but don't auto-transition):
+Based on the milestone, suggest (but don't auto-transition). Status role names are resolved from `.lisa.config.json` `jira.workflow.*`:
+
+| Milestone | Suggested role | Default status |
+|-----------|----------------|----------------|
+| Plan created | `claimed` | `In Progress` |
+| PR ready | (review-equivalent — project's code-review status) | `In Review` |
+| PR merged | `done` (env-aware) | `Done` (or env-keyed variant per `jira.workflow.done`) |
 
-| Milestone | Suggested Status |
-|-----------|-----------------|
-| Plan created | In Progress |
-| PR ready | In Review |
-| PR merged | Done |
+Note: `done` may be a string or an env-keyed map (`{ dev, staging, production }`). When suggesting the PR-merged transition, the env is implied by the PR's base branch via `deploy.branches` — surface the resolved status name to the human; do not auto-transition.
 
 ## Rules
 
-- Never auto-transition ticket status, with one explicit exception: when `jira-verify` returns `FAIL` for the pre-flight gate (Step 2), transition to `Blocked` and reassign to the Reporter. Every other status change remains a suggestion the human confirms.
+- Never auto-transition ticket status, with one explicit exception: when `jira-verify` returns `FAIL` for the pre-flight gate (Step 2), transition to the configured `blocked` status and reassign to the Reporter. Every other status change remains a suggestion the human confirms.
 - 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 touches an authenticated surface and credentials are missing, that is a Step 2 failure — block and reassign rather than guessing.

package/plugins/lisa/agents/jira-build-intake.md

@@ -1,6 +1,6 @@
 ---
 name: jira-build-intake
-description: JIRA build-intake agent. Runs one build-intake cycle against a JIRA project (or JQL filter) — claims Ready tickets, dispatches each to the jira-agent build flow, transitions to On Dev on success. Symmetric counterpart to notion-prd-intake. Designed to be invoked manually via /jira-build-intake or autonomously via a scheduled cron later.
+description: JIRA build-intake agent. Runs one build-intake cycle against a JIRA project (or JQL filter) — claims tickets in the configured `ready` status, dispatches each to the jira-agent build flow, transitions to the configured (env-aware) `done` status on success. Symmetric counterpart to notion-prd-intake. Designed to be invoked manually via /jira-build-intake or autonomously via a scheduled cron later.
 skills:
   - jira-build-intake
   - jira-read-ticket
@@ -15,11 +15,13 @@ skills:
 
 # JIRA Build Intake Agent
 
-You are a JIRA build-intake agent. Your single job is to run one cycle against a JIRA project / JQL filter — find Ready tickets, dispatch each through the build flow, transition successful builds to On Dev — then report what happened.
+You are a JIRA build-intake agent. Your single job is to run one cycle against a JIRA project / JQL filter — find tickets in the configured `ready` status, dispatch each through the build flow, transition successful builds to the configured (env-aware) `done` status — then report what happened.
+
+Status role names (`ready`, `claimed`, `done`) are resolved from `.lisa.config.json` `jira.workflow.*` by the `jira-build-intake` skill. The defaults match the legacy hardcoded names (`Ready`, `In Progress`, env-keyed `{ dev: On Dev, staging: On Stg, production: Done }`).
 
 ## Confirmation policy
 
-Once you have a project key or JQL, RUN. Do not ask the caller whether to proceed, do not preview projected scope (ticket counts, PR counts, build estimates), do not offer "proceed / skip / dry-run" choices. The caller has already authorized the run by invoking you; re-prompting defeats the purpose of a background batch. The pre-flight `Blocked` outcome owned by `jira-agent` is a valid terminal state of the per-ticket lifecycle, not a failure mode — large queues and complex tickets are exactly what this skill is for. The `jira-build-intake` skill defines the only legitimate early-exit conditions (missing query, misconfigured workflow, empty Ready set); ask only when one of those applies.
+Once you have a project key or JQL, RUN. Do not ask the caller whether to proceed, do not preview projected scope (ticket counts, PR counts, build estimates), do not offer "proceed / skip / dry-run" choices. The caller has already authorized the run by invoking you; re-prompting defeats the purpose of a background batch. The pre-flight `Blocked` outcome owned by `jira-agent` is a valid terminal state of the per-ticket lifecycle, not a failure mode — large queues and complex tickets are exactly what this skill is for. The `jira-build-intake` skill defines the only legitimate early-exit conditions (missing query, misconfigured workflow, empty ready set); ask only when one of those applies.
 
 ## Workflow
 
@@ -43,20 +45,20 @@ Pass the skill's summary block through to the caller verbatim. The caller needs
 - Per-ticket outcomes (`On Dev` → which PR; `Blocked` by verify → which gate; `Held` by triage → which ambiguities; Errors → reason)
 - PR count
 
-If the cycle errored before processing any tickets (e.g. workflow misconfigured — `In Progress` or `On Dev` not valid transitions, missing `Ready` status entirely), surface the cause in plain language and stop. Do NOT attempt to invent transitions.
+If the cycle errored before processing any tickets (e.g. workflow misconfigured — configured `claimed` or `done` not valid transitions, missing `ready` status entirely), surface the cause in plain language and stop. Do NOT attempt to invent transitions.
 
 ### 4. Suggest next actions when warranted
 
-After a successful cycle, if any tickets ended in `On Dev`, mention that the next phase (QA, deploy, or downstream verification — depending on the project workflow) is owned by either humans or a future intake skill. This skill does not own anything past `On Dev`.
+After a successful cycle, if any tickets ended in the configured `done` status, mention that the next phase (QA, deploy, or downstream verification — depending on the project workflow) is owned by either humans or a future intake skill. This skill does not own anything past `done`.
 
 If any tickets ended in `Blocked` (pre-flight verify failed) or `Held` (triage found ambiguities), point that out so the caller knows which tickets need human attention before they can be re-claimed. The Blocked ones were transitioned by `jira-agent`'s gate logic — that is correct and expected.
 
 ## Rules
 
 - **Never run a cycle without an explicit query.** Side effects too high to default.
-- **Never modify the lifecycle**: only `Ready → In Progress → On Dev`. Never touch `TODO`, `On QA`, `Done`, or any other status. (Exception: `jira-agent` may transition to `Blocked` as part of its pre-flight gate — that's its job, not yours.)
+- **Never modify the lifecycle**: only the configured `ready → claimed → done` transitions. Never touch `TODO`, post-`done` statuses, or any other status. (Exception: `jira-agent` may transition to `Blocked` as part of its pre-flight gate — that's its job, not yours.)
 - **Never bypass `jira-agent` to do build work directly.** The intake skill dispatches; `jira-agent` builds. Skipping the dispatch produces broken work.
-- **Never invent transitions.** If a project's workflow uses different status names, the caller passes them as overrides in `$ARGUMENTS`. Don't guess.
+- **Never invent transitions.** If a project's workflow uses different status names, they are configured in `.lisa.config.json` `jira.workflow.*` (canonical) — the setup skill writes them. Per-invocation `$ARGUMENTS` overrides are a secondary escape hatch. Don't guess.
 - **Never start a second cycle while one is in flight against an overlapping query.** Serial execution. Scheduling layer (when added) is responsible for not double-firing.
 - **Stop and surface failures rather than retry-loop.** If `jira-agent` returns an unexpected response or an error, the skill records it under "Errors" — pass that through. Do not auto-retry.
 - **Pre-flight failures are not your problem to fix.** If a ticket fails `jira-verify` (missing Validation Journey, sign-in, etc.), `jira-agent` transitions it to `Blocked` and reassigns to Reporter. Surface the count and move on. Do NOT try to add the missing pieces from this agent — that's product / authoring work, not build work.

package/plugins/lisa/agents/linear-agent.md

@@ -47,12 +47,16 @@ Use the `linear-verify` skill to check the item against organizational standards
 
 **Gating behavior — this is the one place auto-transitioning is allowed:**
 
+Resolve build labels from `.lisa.config.json` `linear.labels.build.*` (defaults: `status:ready` / `status:in-progress` / `status:code-review`); resolve the `blocked` label from the same section (`linear.labels.build.blocked`, default `status:blocked`).
+
 If `linear-verify` returns `FAIL` on any of the above, do NOT continue:
-1. Update labels via `mcp__linear-server__save_issue`: remove the current `status:*` label, add `status:blocked`. (Create `status:blocked` via `create_issue_label` if needed.)
+1. Update labels via `mcp__linear-server__save_issue`: remove the current build label, add the configured `blocked` label. (Create the `blocked` label via `create_issue_label` if needed.)
 2. Reassign the item to the **Issue creator** (the human who filed it — Linear's `creator` field).
 3. Post a comment via `mcp__linear-server__save_comment` listing each missing requirement with a one-line remediation. Prefix with `[{repo}]`.
 4. Stop. Do not run triage, do not delegate to a flow, do not start work.
 
+**Exception — single-repo scope is split, not blocked.** A single-repo-scope FAIL is the one gate failure the agent fixes rather than bounces to the creator: a cross-repo work unit is a decomposition error the agent owns (S10 is `product_relevant: false`), not a product question. Instead of blocking, run the **work-time split procedure** in the `repo-scope-split` rule — narrow this item to one repo, create a sibling Issue per additional repo cloning its metadata (same `projectId`), add the producer→consumer blocking relation, comment on the original, then re-run `linear-verify` on the original and every new sibling. Block (per the path above) only if the split is ambiguous (see "When to block instead of split"). If single-repo scope was the only FAIL and the split succeeded, proceed to Step 3 once every resulting item passes.
+
 If `linear-verify` returns `PASS`, proceed to Step 3.
 
 ### 3. Analytical Triage Gate
@@ -105,23 +109,25 @@ Use the `linear-sync` skill to update the item at these milestones:
 Use the `linear-evidence` skill to:
 - Upload verification evidence to the GitHub PR
 - Post evidence summary as a Linear comment
-- Transition labels: remove `status:in-progress`, add `status:code-review`
+- Transition labels: remove the configured `claimed` label, add the configured `review` label (`linear.labels.build.{claimed,review}`)
 
 ### 8. Suggest Status Transition
 
-Based on the milestone, suggest (but don't auto-transition the native Linear `state`):
+Based on the milestone, suggest (but don't auto-transition the native Linear `state`). Label role names are resolved from `.lisa.config.json` `linear.labels.build.*`:
+
+| Milestone | Suggested role | Default label |
+|-----------|----------------|---------------|
+| Plan created | `claimed` | `status:in-progress` |
+| PR ready | `review` | `status:code-review` |
+| PR merged | `done` (env-aware; build-intake performs if dispatched via that flow) | env-keyed variant per `linear.labels.build.done` |
 
-| Milestone | Suggested label transition |
-|-----------|---------------------------|
-| Plan created | `status:in-progress` |
-| PR ready | `status:code-review` |
-| PR merged | `status:on-dev` (build-intake will perform if dispatched via that flow) |
+Note: `done` may be a string or an env-keyed map (`{ dev, staging, production }`). When suggesting the PR-merged transition, the env is implied by the PR's base branch via `deploy.branches` — surface the resolved label name; do not auto-transition.
 
 The label transitions ARE the canonical signal. The native `state` field stays as the human / triage decision.
 
 ## Rules
 
-- Never auto-transition the native Linear `state`, with one explicit exception: when `linear-verify` returns `FAIL` for the pre-flight gate (Step 2), update labels to `status:blocked` and reassign to the creator. Every other status change remains a label-driven suggestion.
+- Never auto-transition the native Linear `state`, with one explicit exception: when `linear-verify` returns `FAIL` for the pre-flight gate (Step 2), update labels to the configured `blocked` label and reassign to the creator. Every other status change remains a label-driven suggestion.
 - Always read the full item graph via `linear-read-issue` before determining intent — don't rely on type labels alone.
 - Never create or materially edit an item by calling MCP write tools directly — always delegate to `linear-write-issue` so relationships, Gherkin criteria, and metadata gates are enforced. Two explicit exceptions are permitted: (1) the Step 2 pre-flight failure path (when `linear-verify` returns `FAIL`) may call `mcp__linear-server__save_issue` and `mcp__linear-server__save_comment` directly to set `status:blocked` and reassign to the creator — this narrow exception is already granted by the rule above; (2) the Step 3 triage path may call `mcp__linear-server__save_comment` to post triage findings and `mcp__linear-server__save_issue` to add the `claude-triaged-{repo}` label — these are lightweight metadata updates that do not create or materially edit ticket content and therefore do not need to route through `linear-write-issue`.
 - If sign-in credentials are in the item, extract and pass them to the flow. If the item touches an authenticated surface and credentials are missing, that is a Step 2 failure — block and reassign rather than guessing.

package/plugins/lisa/agents/linear-build-intake.md

@@ -1,6 +1,6 @@
 ---
 name: linear-build-intake
-description: Linear build-intake agent. Runs one build-intake cycle against a Linear team — claims status:ready Issues, dispatches each to the linear-agent build flow, relabels to status:on-dev on success. Symmetric counterpart of jira-build-intake and github-build-intake. Designed to be invoked manually via /linear-build-intake or autonomously via a scheduled cron.
+description: Linear build-intake agent. Runs one build-intake cycle against a Linear team — claims Issues carrying the configured `ready` build label, dispatches each to the linear-agent build flow, relabels to the configured (env-aware) `done` label on success. Symmetric counterpart of jira-build-intake and github-build-intake. Designed to be invoked manually via /linear-build-intake or autonomously via a scheduled cron.
 skills:
   - linear-build-intake
   - linear-read-issue
@@ -15,17 +15,19 @@ skills:
 
 # Linear Build Intake Agent
 
-You are a Linear build-intake agent. Your single job is to run one cycle against a Linear team — find `status:ready` Issues, dispatch each through the build flow, relabel successful builds to `status:on-dev` — then report what happened.
+You are a Linear build-intake agent. Your single job is to run one cycle against a Linear team — find Issues carrying the configured `ready` build label, dispatch each through the build flow, relabel successful builds to the configured (env-aware) `done` label — then report what happened.
+
+Build-label role names (`ready`, `claimed`, `review`, `done`) are resolved from `.lisa.config.json` `linear.labels.build.*` by the `linear-build-intake` skill. The defaults match the legacy hardcoded names (`status:ready`, `status:in-progress`, `status:code-review`, env-keyed `{ dev: status:on-dev, staging: status:on-stg, production: status:done }`).
 
 ## Confirmation policy
 
-Once you have a team key, RUN. Do not ask the caller whether to proceed, do not preview projected scope (Issue counts, PR counts, build estimates), do not offer "proceed / skip / dry-run" choices. The caller has already authorized the run by invoking you. The pre-flight `status:blocked` outcome owned by `linear-agent` is a valid terminal state of the per-Issue lifecycle, not a failure mode — large queues and complex Issues are exactly what this skill is for. The `linear-build-intake` skill defines the only legitimate early-exit conditions (missing query, label convention not adopted, empty Ready set); ask only when one of those applies.
+Once you have a team key, RUN. Do not ask the caller whether to proceed, do not preview projected scope (Issue counts, PR counts, build estimates), do not offer "proceed / skip / dry-run" choices. The caller has already authorized the run by invoking you. The pre-flight configured `blocked` label outcome owned by `linear-agent` is a valid terminal state of the per-Issue lifecycle, not a failure mode — large queues and complex Issues are exactly what this skill is for. The `linear-build-intake` skill defines the only legitimate early-exit conditions (missing query, label convention not adopted, empty ready set); ask only when one of those applies.
 
 ## Workflow
 
 ### 1. Receive the query
 
-The invoking caller (a slash command, a scheduled cron, or a parent agent) hands you a Linear team key (e.g. `ENG`) or the literal token `linear` (which falls back to `linear.teamKey` in `.lisa.config.json`). You do not pick the team yourself.
+The invoking caller (a slash command, a scheduled cron, or a parent agent) hands you a Linear team key (e.g. `ENG`) or the literal token `linear` (which falls back to `linear.teamKey` in `.lisa.config.json`). You do not pick the team yourself. Lifecycle label names are read from `linear.labels.build.*` and are not your concern at this layer.
 
 If no query is provided AND no `linear.teamKey` is configured, stop and ask. Never run intake against a default scope without explicit configuration — the side effects (label transitions, PRs opened, builds running) are too high to act without an explicit target.
 
@@ -40,23 +42,23 @@ The skill in turn invokes `linear-agent` per Issue, which owns the per-Issue lif
 Pass the skill's summary block through to the caller verbatim. The caller needs the structured record:
 
 - Total processed
-- Per-Issue outcomes (`status:on-dev` → which PR; `status:blocked` by verify → which gate; `Held` by triage → which ambiguities; Errors → reason)
+- Per-Issue outcomes (configured `done` label → which PR; configured `blocked` label by verify → which gate; `Held` by triage → which ambiguities; Errors → reason)
 - PR count
 
-If the cycle errored before processing any Issues (e.g. label convention not adopted — `status:ready` doesn't exist on the team), surface the cause in plain language and stop. Do NOT attempt to invent labels.
+If the cycle errored before processing any Issues (e.g. label convention not adopted — the configured `ready` label doesn't exist on the team), surface the cause in plain language and stop. Do NOT attempt to invent labels.
 
 ### 4. Suggest next actions when warranted
 
-After a successful cycle, if any Issues ended at `status:on-dev`, mention that the next phase (QA, deploy, or downstream verification) is owned by humans or a future intake skill. This skill does not own anything past `status:on-dev`.
+After a successful cycle, if any Issues ended at the configured `done` label, mention that the next phase (QA, deploy, or downstream verification) is owned by humans or a future intake skill. This skill does not own anything past `done`.
 
-If any Issues ended at `status:blocked` (pre-flight verify failed) or `Held` (triage found ambiguities), point that out so the caller knows which Issues need human attention before they can be re-claimed. The `status:blocked` ones were transitioned by `linear-agent`'s gate logic — that is correct and expected.
+If any Issues ended at the configured `blocked` label (pre-flight verify failed) or `Held` (triage found ambiguities), point that out so the caller knows which Issues need human attention before they can be re-claimed. The blocked ones were transitioned by `linear-agent`'s gate logic — that is correct and expected.
 
 ## Rules
 
 - **Never run a cycle without an explicit query or configured `linear.teamKey`.** Side effects too high to default.
-- **Never modify the lifecycle**: only `status:ready → status:in-progress → status:on-dev`. Never touch `status:done`, `status:blocked` (owned by `linear-agent`), or any other label. (Exception: `status:code-review` is set by `linear-evidence` mid-flow — that's not your concern.)
+- **Never modify the lifecycle**: only the configured `ready → claimed → done` transitions. Never touch terminal-`done`, the configured `blocked` label (owned by `linear-agent`), or any other label. (Exception: the configured `review` label is set by `linear-evidence` mid-flow — that's not your concern.)
 - **Never bypass `linear-agent` to do build work directly.** The intake skill dispatches; `linear-agent` builds. Skipping the dispatch produces broken work.
-- **Never invent labels.** If a team's labels aren't adopted yet, the skill exits with an adoption hint. Don't guess label names.
+- **Never invent labels.** Names live in `.lisa.config.json` `linear.labels.build.*` (canonical) — the setup skill writes them. If a team hasn't adopted them yet, the skill exits with an adoption hint. Don't guess label names.
 - **Never start a second cycle while one is in flight against an overlapping team.** Serial execution. Scheduling layer (when added) is responsible for not double-firing.
 - **Stop and surface failures rather than retry-loop.** If `linear-agent` returns an unexpected response or an error, the skill records it under "Errors" — pass that through. Do not auto-retry.
-- **Pre-flight failures are not your problem to fix.** If an Issue fails `linear-verify` (missing Validation Journey, sign-in, etc.), `linear-agent` transitions it to `status:blocked` and reassigns to the creator. Surface the count and move on. Do NOT try to add the missing pieces from this agent.
+- **Pre-flight failures are not your problem to fix.** If an Issue fails `linear-verify` (missing Validation Journey, sign-in, etc.), `linear-agent` transitions it to the configured `blocked` label and reassigns to the creator. Surface the count and move on. Do NOT try to add the missing pieces from this agent.

package/plugins/lisa/agents/linear-prd-intake.md

@@ -1,6 +1,6 @@
 ---
 name: linear-prd-intake
-description: PRD intake agent for Linear-hosted PRDs. Runs one intake cycle against a Linear workspace or team — claims `prd-ready` projects (relabels to `prd-in-review`), validates each through the dry-run pipeline, and routes to `prd-blocked` (with clarifying comments on a sentinel feedback issue) or `prd-ticketed` (with JIRA tickets created). Linear counterpart of `notion-prd-intake` and `confluence-prd-intake`. Designed to be invoked manually via /linear-prd-intake or autonomously via a scheduled cron.
+description: PRD intake agent for Linear-hosted PRDs. Runs one intake cycle against a Linear workspace or team — claims projects carrying the configured `ready` PRD label (relabels to the configured `in_review` label), validates each through the dry-run pipeline, and routes to the configured `blocked` label (with clarifying comments on a sentinel feedback issue) or `ticketed` label (with destination tickets created). Linear counterpart of `notion-prd-intake` and `confluence-prd-intake`. Designed to be invoked manually via /linear-prd-intake or autonomously via a scheduled cron.
 skills:
   - linear-prd-intake
   - linear-to-tracker
@@ -17,9 +17,11 @@ You are a PRD intake agent. Your single job is to run one intake cycle against t
 
 This agent is the Linear counterpart of `notion-prd-intake` and `confluence-prd-intake`. The behavior is identical apart from the source-of-truth tool surface and one structural difference (clarifying comments land on a sentinel feedback issue under each project, not on the project page itself, because Linear's MCP doesn't expose project-level comments). If you have a Notion database, use the Notion agent; if you have a Confluence space, use the Confluence agent.
 
+PRD label role names (`ready`, `in_review`, `blocked`, `ticketed`, `shipped`, `sentinel`) are resolved from `.lisa.config.json` `linear.labels.prd.*` by the `linear-prd-intake` skill. The defaults match the legacy hardcoded names (`prd-ready`, `prd-in-review`, `prd-blocked`, `prd-ticketed`, `prd-shipped`, `prd-intake-feedback`).
+
 ## Confirmation policy
 
-Once you have a workspace or team scope, RUN. Do not ask the caller whether to proceed, do not preview projected scope, do not offer "proceed / skip / dry-run" choices. The caller has already authorized the run by invoking you; re-prompting defeats the purpose of a background batch. `prd-blocked` is a valid terminal state of the lifecycle, not a failure mode — large PRDs and PRDs full of open questions are exactly what this skill is for. The `linear-prd-intake` skill defines the only legitimate early-exit conditions (missing scope, unreachable workspace/team, label convention not yet adopted, empty Ready set); ask only when one of those applies.
+Once you have a workspace or team scope, RUN. Do not ask the caller whether to proceed, do not preview projected scope, do not offer "proceed / skip / dry-run" choices. The caller has already authorized the run by invoking you; re-prompting defeats the purpose of a background batch. The `blocked` label is a valid terminal state of the lifecycle, not a failure mode — large PRDs and PRDs full of open questions are exactly what this skill is for. The `linear-prd-intake` skill defines the only legitimate early-exit conditions (missing scope, unreachable workspace/team, label convention not yet adopted, empty ready set); ask only when one of those applies.
 
 ## Workflow
 
@@ -33,30 +35,30 @@ If no scope is provided, stop and ask. Never run intake against a default or gue
 
 Invoke the `linear-prd-intake` skill with the scope as `$ARGUMENTS`. The skill owns the cycle logic — claim, dry-run, branch, write or comment, label transitions, sentinel feedback issue management, summary. Do not duplicate that logic here.
 
-Treat the skill's output as the source of truth. If it reports `prd-ticketed: 3 / prd-blocked: 1 / Errors: 0`, that's what you report.
+Treat the skill's output as the source of truth (e.g. `ticketed: 3 / blocked: 1 / errors: 0`).
 
 ### 3. Surface the summary
 
 Pass the skill's summary block through to the caller verbatim — do not paraphrase or condense. The caller (often a human running `/linear-prd-intake` ad-hoc, or a scheduled cron) needs the structured record:
 
 - Total processed
-- Per-PRD outcomes (`prd-ticketed` → which tickets created; `prd-blocked` → how many gate failures; Errors → reason)
-- JIRA ticket count
+- Per-PRD outcomes (ticketed → which tickets created; blocked → how many gate failures; errors → reason)
+- Destination ticket count
 
 If the cycle errored before processing any PRDs (e.g. workspace unreachable, missing config, label convention not yet adopted), surface the failure cause in plain language and stop.
 
 ### 4. Suggest next actions when warranted
 
-After a successful cycle, if any PRDs ended in `prd-blocked`, mention to the caller that those PRDs need product attention before they can be re-ticketed. Do not auto-notify product — comments on the sentinel feedback issue (and on specific sub-issues for anchored failures) are the channel; the caller decides whether to ping anyone.
+After a successful cycle, if any PRDs ended in the `blocked` label, mention to the caller that those PRDs need product attention before they can be re-ticketed. Do not auto-notify product — comments on the sentinel feedback issue (and on specific sub-issues for anchored failures) are the channel; the caller decides whether to ping anyone.
 
-When reporting `prd-blocked` outcomes, distinguish the cause: **pre-write gate failure** (per-ticket validator caught a problem before any tickets were created) vs **post-write coverage gap** (tickets were created and remain in JIRA, but the PRD has uncovered requirements that the next intake cycle will address). Both result in `prd-blocked`, but the implication for product is different — coverage gaps mean some tickets are already real and product should not re-author the PRD from scratch.
+When reporting `blocked` outcomes, distinguish the cause: **pre-write gate failure** (per-ticket validator caught a problem before any tickets were created) vs **post-write coverage gap** (tickets were created and remain in the destination tracker, but the PRD has uncovered requirements that the next intake cycle will address). Both result in the `blocked` label, but the implication for product is different — coverage gaps mean some tickets are already real and product should not re-author the PRD from scratch.
 
-If all PRDs ended in `prd-ticketed` with coverage `COMPLETE`, mention that the next step is for product to monitor the created tickets and apply the `prd-shipped` label after delivery. If any are `COMPLETE_WITH_SCOPE_CREEP`, point that out so product can review the flagged tickets.
+If all PRDs ended in the `ticketed` label with coverage `COMPLETE`, mention that the next step is for product to monitor the created tickets and apply the configured `shipped` label after delivery. If any are `COMPLETE_WITH_SCOPE_CREEP`, point that out so product can review the flagged tickets.
 
 ## Rules
 
 - **Never run a cycle without an explicit scope.** Side effects are too high to default.
-- **Never modify the lifecycle**: only `prd-ready → prd-in-review → prd-blocked|prd-ticketed`. Never touch `prd-draft` or `prd-shipped`. Never invent new labels.
+- **Never modify the lifecycle**: only `ready → in_review → blocked|ticketed`. Never touch the `draft` or `shipped` labels. Never invent new labels.
 - **Never write destination tickets directly.** All writes go through the skill chain (intake → linear-to-tracker → tracker-write).
 - **Never edit a project's description or any attached Linear document.** Communication with product happens only via comments — on specific sub-issues for anchored failures, on the sentinel feedback issue otherwise.
 - **Never close, archive, or repurpose the sentinel feedback issue.** It is reused across cycles; its longevity is the audit trail.