@codyswann/lisa 2.21.1 → 2.23.0

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

@@ -1,6 +1,6 @@
 ---
 name: github-build-intake
-description: "GitHub counterpart to lisa:jira-build-intake. Scans a GitHub repository for issues labeled `status:ready`, claims each by relabeling to `status:in-progress`, runs the implementation/build flow via lisa:github-agent, and relabels to `status:on-dev` on completion. The `status:ready` label is the human-flipped signal that an issue is truly ready for development — mirroring how Notion PRDs work product Draft → Ready → (us) In Review → Blocked|Ticketed."
+description: "GitHub counterpart to lisa:jira-build-intake. Scans a GitHub repository for issues carrying the configured `ready` build label, claims each by relabeling to the configured `claimed` label, runs the implementation/build flow via lisa:github-agent, and relabels to the configured `done` label on completion. The `ready` label is the human-flipped signal that an issue is truly ready for development — mirroring how Notion PRDs work product Draft → Ready → (us) In Review → Blocked|Ticketed."
 allowed-tools: ["Skill", "Bash"]
 ---
 
@@ -12,11 +12,64 @@ allowed-tools: ["Skill", "Bash"]
 2. A full GitHub repo URL (e.g., `https://github.com/acme/frontend-v2`).
 3. The literal token `github` — falls back to `.lisa.config.json` (`github.org` / `github.repo`).
 
-Run one build-intake cycle. Each `status:ready` issue is claimed, built via the `lisa:github-agent` flow, and relabeled to `status:on-dev` (or the equivalent next-label for that repo). The cycle is the symmetric mirror of `lisa:notion-prd-intake`: humans flip `status:ready`, agents pick up and progress.
+Run one build-intake cycle. Each issue in the configured `ready` build label is claimed, built via the `lisa:github-agent` flow, and relabeled to the configured `done` label (env-aware — see Workflow resolution). The cycle is the symmetric mirror of `lisa:notion-prd-intake`: humans flip the `ready` label, agents pick up and progress.
+
+## Workflow resolution
+
+Build-queue label names are read from `.lisa.config.json` `github.labels.build.*`, 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 ".github.labels.build.${role} // empty" .lisa.config.local.json 2>/dev/null)
+  global_v=$(jq -r ".github.labels.build.${role} // empty" .lisa.config.json 2>/dev/null)
+  echo "${local_v:-${global_v:-$default}}"
+}
+
+READY=$(read_role ready "status:ready")
+CLAIMED=$(read_role claimed "status:in-progress")
+REVIEW=$(read_role review "status:code-review")
+```
+
+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).
+3. If `done` is a **string** in config, use it directly regardless of env.
+4. If `done` is a **map** and env cannot be resolved, **fail loudly** — do not pick arbitrarily.
+
+```bash
+TARGET_ENV="${target_env:-}"
+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_TYPE=$(jq -r '.github.labels.build.done | type' .lisa.config.json 2>/dev/null)
+if [ "$DONE_TYPE" = "string" ]; then
+  DONE=$(jq -r '.github.labels.build.done' .lisa.config.json)
+elif [ "$DONE_TYPE" = "object" ]; then
+  [ -z "$TARGET_ENV" ] && { echo "ERROR: github.labels.build.done is env-keyed but env not resolvable"; exit 1; }
+  DONE=$(jq -r --arg e "$TARGET_ENV" '.github.labels.build.done[$e] // empty' .lisa.config.json)
+  [ -z "$DONE" ] && { echo "ERROR: github.labels.build.done has no entry for env '$TARGET_ENV'"; exit 1; }
+else
+  case "$TARGET_ENV" in
+    dev) DONE="status:on-dev" ;;
+    staging) DONE="status:on-stg" ;;
+    production) DONE="status:done" ;;
+    *) echo "ERROR: cannot resolve done label without env"; exit 1 ;;
+  esac
+fi
+```
+
+In prose below, the role names refer to the resolved labels: e.g. "the `ready` label" means whatever `github.labels.build.ready` resolves to (default: `status:ready`).
 
 ## Confirmation policy
 
-Do NOT ask the caller whether to proceed. Once invoked with a repo, run the cycle to completion — claim, dispatch each issue through `lisa:github-agent`, relabel successful builds to `status: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 repo, run the cycle to completion — claim, dispatch each issue through `lisa:github-agent`, relabel 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:
 
@@ -28,28 +81,30 @@ Specifically forbidden:
 The only legitimate reasons to stop early:
 
 - Missing repo or required configuration. Surface the missing value and exit.
-- Label namespace not adopted (no issue carries any of `status:ready` / `status:in-progress` / `status:code-review` / `status:on-dev` / `status:done`). Surface a label-convention error and exit (this is setup, not a normal idle cycle — see "Adoption" at the bottom).
-- Empty `status:ready` set. Exit cleanly with `"No GitHub issues labeled status:ready in <org>/<repo>. Nothing to do."`
+- Label namespace not adopted (no issue carries any of `$READY` / `$CLAIMED` / `$REVIEW` / `$DONE`). Surface a label-convention error and exit (this is setup, not a normal idle cycle — see "Adoption" at the bottom).
+- Empty ready set. Exit cleanly with `"No GitHub issues labeled $READY in <org>/<repo>. Nothing to do."`
 
 ## Lifecycle assumed
 
 The GitHub Issues build lifecycle uses **labels** (we deliberately do NOT key off open/closed alone — closed issues aren't always the right post-build state):
 
 ```text
-status:ready → status:in-progress → status:code-review → status:on-dev → status:done
-   (human)       (us claim)            (us / PR opens)        (us done; PR ready)   (downstream / merge)
+ready → claimed → review → done(env-keyed) (downstream merge / archive)
+(human)  (us claim)  (us / PR opens)  (us done; PR ready)
 ```
 
+(Defaults: `status:ready` / `status:in-progress` / `status:code-review` / `status:on-dev`/`status:on-stg`/`status:done`.)
+
 This skill ONLY transitions:
 
-- `status:ready` → `status:in-progress` (claim)
-- `status:in-progress` → `status:on-dev` (build complete, PR ready)
+- `$READY` → `$CLAIMED` (claim)
+- `$CLAIMED` → `$DONE` (build complete, PR ready)
 
-It never touches `status:code-review` (set by the agent / PR open hook), `status:done` (set by merge automation or PM), or any other status.
+It never touches `$REVIEW` (set by the agent / PR open hook), `status:done`-as-terminal (set by merge automation or PM), or any other status.
 
-A "transition" means: remove the old `status:*` label and add the new one, in two `gh issue edit` calls (`--remove-label` + `--add-label`) or one combined call. The skill MUST verify exactly one `status:*` label is present after the update — having two simultaneously breaks idempotency.
+A "transition" means: remove the old role label and add the new one, in two `gh issue edit` calls (`--remove-label` + `--add-label`) or one combined call. The skill MUST verify exactly one build-lifecycle label (from the resolved `$READY`/`$CLAIMED`/`$REVIEW`/`$DONE` set) is present after the update — having two simultaneously breaks idempotency.
 
-**Pre-flight check**: at the start of each cycle, confirm at least one of the `status:*` labels exists on the repo via `gh label list --repo <org>/<repo> --json name`. If none exist, the convention has not been adopted — surface the label-convention error and exit.
+**Pre-flight check**: at the start of each cycle, confirm at least one of the resolved role labels (`$READY`, `$CLAIMED`, `$REVIEW`, or any `$DONE` value) exists on the repo via `gh label list --repo <org>/<repo> --json name`. If none exist, the convention has not been adopted — surface the label-convention error and exit.
 
 ## Phases
 
@@ -62,30 +117,32 @@ A "transition" means: remove the old `status:*` label and add the new one, in tw
 2. Confirm `gh auth status` succeeds.
 3. Confirm the repo is reachable: `gh repo view <org>/<repo> --json name --jq '.name'`.
 
-### Phase 2 — Find Ready issues
+### Phase 2 — Find ready issues
 
 ```bash
-gh issue list --repo <org>/<repo> --label status:ready --state open --json number,title,labels,assignees,milestone,createdAt --limit 100
+gh issue list --repo <org>/<repo> --label "$READY" --state open --json number,title,labels,assignees,milestone,createdAt --limit 100
 ```
 
 If empty, run a secondary check to distinguish a genuinely empty queue from an unconfigured repo:
 
 ```bash
-gh label list --repo <org>/<repo> --json name --jq '.[] | select(startswith("status:")) | .name'
+gh label list --repo <org>/<repo> --json name \
+  | jq -r --arg r "$READY" --arg c "$CLAIMED" --arg v "$REVIEW" --arg d "$DONE" \
+      '[.[] | .name | select(. == $r or . == $c or . == $v or . == $d)] | length'
 ```
 
-If no `status:*` labels exist → label namespace not adopted, surface a setup error and exit. If `status:*` labels exist but none are `status:ready` on any open issue → genuinely empty queue, exit cleanly with `"No GitHub issues labeled status:ready. Nothing to do."`
+If none of the configured role labels exist on the repo → label convention not adopted, surface a setup error and exit. If the role labels exist but none are `$READY` on any open issue → genuinely empty queue, exit cleanly with `"No GitHub issues labeled $READY. Nothing to do."`
 
-### Phase 3 — Process each Ready issue (serial)
+### Phase 3 — Process each ready issue (serial)
 
 #### 3a. Claim
 
 ```bash
-gh issue edit <number> --repo <org>/<repo> --remove-label status:ready --add-label status:in-progress
+gh issue edit <number> --repo <org>/<repo> --remove-label "$READY" --add-label "$CLAIMED"
 gh issue comment <number> --repo <org>/<repo> --body "[claude-build-intake] Claimed by Claude. Starting build."
 ```
 
-This is the idempotency lock — a re-entrant cycle's `--label status:ready` filter will not see this issue again.
+This is the idempotency lock — a re-entrant cycle's `--label $READY` filter will not see this issue again.
 
 If the relabel fails (permission, race), log under "Errors" in the cycle summary and skip this issue. **Do not invoke the build flow on an issue you didn't successfully claim.**
 
@@ -102,24 +159,26 @@ Invoke `lisa:github-agent` (the per-issue lifecycle agent) with the issue ref. `
 Wait for `lisa:github-agent` to return. Capture its outcome:
 
 - **Success** — PR is ready (open or merged); evidence posted; ready for next status.
-- **Blocked by github-verify pre-flight gate** — `lisa:github-agent` itself relabels the issue to `status:blocked` (or removes `status:in-progress` and reassigns to the original author). This is correct and expected — let it stand. Record and move on.
-- **Blocked by ticket-triage ambiguities** — `lisa:github-agent` posts findings and stops. The issue stays in `status:in-progress`. Surface to human; do not auto-relabel. Record under "Errors".
-- **Errored** — exception, missing config, etc. Leave the issue in `status:in-progress` for human investigation. Record under "Errors".
+- **Blocked by github-verify pre-flight gate** — `lisa:github-agent` itself relabels the issue to `status:blocked` (or removes `$CLAIMED` and reassigns to the original author). This is correct and expected — let it stand. Record and move on.
+- **Blocked by ticket-triage ambiguities** — `lisa:github-agent` posts findings and stops. The issue stays in `$CLAIMED`. Surface to human; do not auto-relabel. Record under "Errors".
+- **Errored** — exception, missing config, etc. Leave the issue in `$CLAIMED` for human investigation. Record under "Errors".
 
-#### 3c. Transition to On Dev (only on Success)
+#### 3c. Transition to $DONE (only on Success)
 
 If `lisa:github-agent` returned Success:
 
+1. Resolve `$DONE` for this issue'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.
+
 ```bash
-gh issue edit <number> --repo <org>/<repo> --remove-label status:in-progress --add-label status:on-dev
-gh issue comment <number> --repo <org>/<repo> --body "[claude-build-intake] Build complete. PR <URL>. Transitioned to status:on-dev."
+gh issue edit <number> --repo <org>/<repo> --remove-label "$CLAIMED" --add-label "$DONE"
+gh issue comment <number> --repo <org>/<repo> --body "[claude-build-intake] Build complete. PR <URL>. Transitioned to $DONE."
 ```
 
-For any non-Success outcome, do NOT transition. The issue sits in `status:in-progress` (or wherever `lisa:github-agent` left it) — humans take it from there.
+For any non-Success outcome, do NOT transition. The issue sits in `$CLAIMED` (or wherever `lisa:github-agent` left it) — humans take it from there.
 
 #### 3d. Continue
 
-Move to the next Ready issue. One issue failing does not stop others.
+Move to the next ready issue. One issue failing does not stop others.
 
 ### Phase 4 — Summary report
 
@@ -131,7 +190,7 @@ Cycle started: <ISO timestamp>
 Cycle completed: <ISO timestamp>
 
 Issues processed: <n>
-- status:on-dev (build complete, PR ready): <n>
+- $DONE (build complete, PR ready): <n>
   - <org>/<repo>#<number> <title> → PR <URL>
 - Blocked (pre-flight verify failed): <n>
   - <org>/<repo>#<number> <title> — see issue comments
@@ -145,11 +204,12 @@ Total PRs opened: <n>
 
 ## Idempotency & safety
 
-- **Claim-first ordering**: `status:in-progress` set BEFORE `lisa:github-agent` invocation — no double-pickup.
-- **No writes outside the lifecycle**: this skill only relabels `status:ready → status:in-progress` and `status:in-progress → status:on-dev`. Every other label change is owned by `lisa:github-agent`.
+- **Claim-first ordering**: `$CLAIMED` set BEFORE `lisa:github-agent` invocation — no double-pickup.
+- **No writes outside the lifecycle**: this skill only relabels `$READY → $CLAIMED` and `$CLAIMED → $DONE`. Every other label change is owned by `lisa:github-agent`.
 - **Failure isolation**: per-issue exceptions caught and recorded; the cycle continues.
 - **Single cycle per repo**: do not run two `lisa:github-build-intake` cycles in parallel against the same repo — concurrent claims could race. The scheduling layer is responsible for serialization.
 - **Single-label invariant**: after every transition, verify exactly one `status:*` label is present on the issue. If two are present (rare race), surface as an Error and skip — do NOT auto-resolve.
+- **Never pick an arbitrary env for `$DONE`**. If `done` is a map and env is ambiguous, fail loudly.
 
 ## Configuration
 
@@ -157,23 +217,26 @@ Total PRs opened: <n>
 |----------|---------|---------|
 | `.lisa.config.json` `github.org` | (from `$ARGUMENTS`) | GitHub org for the default queue |
 | `.lisa.config.json` `github.repo` | (from `$ARGUMENTS`) | GitHub repo for the default queue |
-| Label: queue | `status:ready` | The label that signals "human says this is buildable" |
-| Label: claim | `status:in-progress` | The label set on pickup |
-| Label: done | `status:on-dev` | The label set after a successful build |
+| `.lisa.config.json` `github.labels.build.ready` | `status:ready` | The label that signals "human says this is buildable" |
+| `.lisa.config.json` `github.labels.build.claimed` | `status:in-progress` | The label set on pickup |
+| `.lisa.config.json` `github.labels.build.review` | `status:code-review` | The label set when the PR opens (owned by `lisa:github-evidence`) |
+| `.lisa.config.json` `github.labels.build.done` | env-keyed map or string | The label set after a successful build; env-aware |
+| `.lisa.config.json` `deploy.branches` | — | Reverse-lookup map for env inference from PR base branch |
 
-If the repo has not adopted the `status:*` label namespace, this skill cannot run. The remediation is to create the labels — `gh label create status:ready --color FBCA04 --description "Ready for build"` and similar — typically a one-time setup.
+If the repo has not adopted the `status:*` label namespace, this skill cannot run. The remediation is to create the labels — `gh label create status:ready --color FBCA04 --description "Ready for build"` and similar — typically a one-time setup. See "Adoption" below for the full command set using the defaults; if your project overrides the role names, substitute accordingly.
 
 ## Rules
 
-- Never relabel an issue the cycle didn't claim. The `status:in-progress` label is the signature of cycle ownership.
+- Never relabel an issue the cycle didn't claim. The `$CLAIMED` label is the signature of cycle ownership.
 - Never bypass `lisa:github-agent` to do build work directly. `lisa:github-agent` owns the per-issue lifecycle.
-- Never auto-transition past `status:on-dev`. Downstream labels (`status:done`, etc.) are owned by QA / PM / merge automation.
+- Never auto-transition past `$DONE`. Downstream labels (terminal `status:done`, etc.) are owned by QA / PM / merge automation.
 - If the issue has no Validation Journey or no sign-in credentials, `lisa:github-agent`'s pre-flight verify will catch it — **don't try to fix the issue from here**.
 - On any unexpected response from `lisa:github-agent` (status it doesn't claim, missing PR URL on success), 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.
 
 ## Adoption (one-time per repo)
 
-Before this skill can run, the repo must adopt the `status:*` label namespace:
+Before this skill can run, the repo must adopt the `status:*` label namespace. Using the defaults:
 
 1. Create the labels:
    ```bash
@@ -183,6 +246,7 @@ Before this skill can run, the repo must adopt the `status:*` label namespace:
    gh label create status:on-dev --color 1D76DB --description "Built, deployed to dev" --repo <org>/<repo>
    gh label create status:done --color 0E8A16 --description "Shipped" --repo <org>/<repo>
    ```
-2. Apply `status:ready` to issues that are ready for development.
-3. Reserve `status:in-progress`, `status:on-dev` for this skill — humans should not set them manually except to recover from an error.
-4. PRD-source labels (`prd-ready`, `prd-in-review`, etc.) are a SEPARATE namespace owned by `lisa:github-prd-intake`. Don't conflate.
+   If your project overrides any `github.labels.build.*` role name in config, substitute the actual label names you configured.
+2. Apply the `$READY` label to issues that are ready for development.
+3. Reserve `$CLAIMED`, `$DONE` for this skill — humans should not set them manually except to recover from an error.
+4. PRD-source labels (defaults: `prd-ready`, `prd-in-review`, etc.) are a SEPARATE namespace owned by `lisa:github-prd-intake`. Don't conflate.

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

@@ -1,6 +1,6 @@
 ---
 name: github-evidence
-description: "Upload text evidence to the GitHub `pr-assets` release, update PR description, post a GitHub Issue comment with code blocks, and relabel the issue to `status:code-review`. Reusable by any skill that captures evidence and generates evidence/comment.md (and optionally evidence/comment.txt). The GitHub counterpart of lisa:jira-evidence."
+description: "Upload text evidence to the GitHub `pr-assets` release, update PR description, post a GitHub Issue comment with code blocks, and relabel the issue to the configured `review` label (default `status:code-review`). Reusable by any skill that captures evidence and generates evidence/comment.md (and optionally evidence/comment.txt). The GitHub counterpart of lisa:jira-evidence."
 allowed-tools: ["Bash"]
 ---
 
@@ -8,6 +8,23 @@ allowed-tools: ["Bash"]
 
 Upload captured evidence and generated templates to the GitHub PR description and the originating GitHub Issue. This skill is the posting step — it assumes evidence files and a comment template already exist in the evidence directory.
 
+## Workflow resolution
+
+The `claimed` and `review` build labels are read from `.lisa.config.json` `github.labels.build.*`, falling back to the defaults documented in the `config-resolution` rule (`status:in-progress` and `status:code-review`).
+
+```bash
+read_role() {
+  local role="$1" default="$2"
+  local local_v global_v
+  local_v=$(jq -r ".github.labels.build.${role} // empty" .lisa.config.local.json 2>/dev/null)
+  global_v=$(jq -r ".github.labels.build.${role} // empty" .lisa.config.json 2>/dev/null)
+  echo "${local_v:-${global_v:-$default}}"
+}
+
+CLAIMED=$(read_role claimed "status:in-progress")
+REVIEW=$(read_role review "status:code-review")
+```
+
 ## Arguments
 
 `$ARGUMENTS`: `<ISSUE_REF> <EVIDENCE_DIR> <PR_NUMBER>`
@@ -75,15 +92,15 @@ Upload captured evidence and generated templates to the GitHub PR description an
    gh issue comment <issue-number> --repo <issue-org>/<issue-repo> --body-file "$EVIDENCE_DIR/comment.md"
    ```
 
-6. **Relabel the issue to `status:code-review`**
+6. **Relabel the issue to the configured `review` label**
 
    ```bash
    gh issue edit <issue-number> --repo <issue-org>/<issue-repo> \
-     --remove-label status:in-progress \
-     --add-label status:code-review
+     --remove-label "$CLAIMED" \
+     --add-label "$REVIEW"
    ```
 
-   If the current label is already `status:code-review`, skip. If neither `status:in-progress` nor `status:code-review` is present, log a warning and continue without changing labels — the issue may have been hand-managed.
+   If the current label is already `$REVIEW`, skip. If neither `$CLAIMED` nor `$REVIEW` is present, log a warning and continue without changing labels — the issue may have been hand-managed.
 
 ## Evidence Naming Convention
 

package/plugins/lisa/skills/github-prd-intake/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: github-prd-intake
-description: "Scans a GitHub repository for issues labeled `prd-ready` and runs each one through the dry-run validation pipeline. PRDs that pass every gate get tickets written (to whatever destination tracker is configured — JIRA, GitHub Issues itself, or Linear) and the label flipped to `prd-ticketed`; PRDs that fail get clarifying-question comments and the label flipped to `prd-blocked`. The GitHub counterpart of lisa:notion-prd-intake / lisa:confluence-prd-intake / lisa:linear-prd-intake. Composes existing skills (github-to-tracker, tracker-validate, tracker-source-artifacts, product-walkthrough)."
+description: "Scans a GitHub repository for issues carrying the configured `ready` PRD label and runs each one through the dry-run validation pipeline. PRDs that pass every gate get tickets written (to whatever destination tracker is configured — JIRA, GitHub Issues itself, or Linear) and the label flipped to the configured `ticketed` label; PRDs that fail get clarifying-question comments and the label flipped to the configured `blocked` label. The GitHub counterpart of lisa:notion-prd-intake / lisa:confluence-prd-intake / lisa:linear-prd-intake. Composes existing skills (github-to-tracker, tracker-validate, tracker-source-artifacts, product-walkthrough)."
 allowed-tools: ["Skill", "Bash"]
 ---
 
@@ -8,56 +8,81 @@ allowed-tools: ["Skill", "Bash"]
 
 `$ARGUMENTS` is one of:
 
-- A GitHub `org/repo` token (e.g., `acme/product-prds`) — scans the repo for issues labeled `prd-ready`.
+- A GitHub `org/repo` token (e.g., `acme/product-prds`) — scans the repo for issues carrying the configured `ready` PRD label.
 - A full GitHub repo URL (e.g., `https://github.com/acme/product-prds`).
 - The literal token `github` — falls back to `.lisa.config.json` (`github.org` / `github.repo`).
 
-Run one intake cycle against that repo. Each issue with the `prd-ready` label is claimed, validated, and routed to either `prd-blocked` (with clarifying comments) or `prd-ticketed` (with destination tickets created).
+Run one intake cycle against that repo. Each issue with the `ready` label is claimed, validated, and routed to either the `blocked` label (with clarifying comments) or the `ticketed` label (with destination tickets created).
+
+## Workflow resolution
+
+PRD label names are read from `.lisa.config.json` `github.labels.prd.*`, 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 ".github.labels.prd.${role} // empty" .lisa.config.local.json 2>/dev/null)
+  global_v=$(jq -r ".github.labels.prd.${role} // empty" .lisa.config.json 2>/dev/null)
+  echo "${local_v:-${global_v:-$default}}"
+}
+
+READY=$(read_role ready "prd-ready")
+IN_REVIEW=$(read_role in_review "prd-in-review")
+BLOCKED=$(read_role blocked "prd-blocked")
+TICKETED=$(read_role ticketed "prd-ticketed")
+SHIPPED=$(read_role shipped "prd-shipped")
+```
+
+In prose below, the role names refer to the resolved labels: e.g. "the `ready` label" means whatever `github.labels.prd.ready` resolves to (default: `prd-ready`).
 
 This skill is the GitHub counterpart of `lisa:notion-prd-intake`, `lisa:confluence-prd-intake`, and `lisa:linear-prd-intake`. Phases, gates, comment templates, and rules are identical — the only differences are (1) the lifecycle is encoded as **issue labels** (mirroring Linear's project labels and Confluence's page labels), (2) the fetch / update tools are the `gh` CLI, and (3) clarifying-question comments land directly on the source PRD issue (because GitHub Issues *do* have native comments — no sentinel issue required, unlike Linear). Keep all four skills behaviorally aligned: when changing intake logic, change them together.
 
 ## Confirmation policy
 
-Do NOT ask the caller whether to proceed. Once invoked with a repo, run the cycle to completion — claim, validate, branch to `prd-blocked` or `prd-ticketed`, write the summary. The caller 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 repo, run the cycle to completion — claim, validate, branch to `$BLOCKED` or `$TICKETED`, write the summary. The caller has already authorized the run by invoking the skill; re-prompting defeats the purpose of a background batch.
 
 Specifically forbidden:
 
 - Previewing projected scope and asking whether to continue.
 - Offering A/B/C-style choices like "proceed / skip / dry-run only" — the documented behavior IS the default.
-- Pausing because a PRD looks large, has many open questions, or is likely to end in `prd-blocked`. `prd-blocked` is a valid terminal state of this lifecycle, not a failure mode.
+- Pausing because a PRD looks large, has many open questions, or is likely to end in `$BLOCKED`. The `blocked` label is a valid terminal state of this lifecycle, not a failure mode.
 - Pausing because the dry-run validation looks expensive.
 
 The only legitimate reasons to stop early:
 
 - Missing repo argument or required configuration. Surface and exit.
-- Repo unreachable, or the labelling convention not yet adopted (no issue carries any of `prd-ready` / `prd-in-review` / `prd-blocked` / `prd-ticketed`). Surface and exit.
-- Empty `prd-ready` set. Exit cleanly with `"No GitHub issues labeled prd-ready in <org>/<repo>. Nothing to do."`
+- Repo unreachable, or the labelling convention not yet adopted (no issue carries any of `$READY` / `$IN_REVIEW` / `$BLOCKED` / `$TICKETED`). Surface and exit.
+- Empty ready set. Exit cleanly with `"No GitHub issues labeled $READY in <org>/<repo>. Nothing to do."`
 
 ## Lifecycle assumed
 
 The PRD lifecycle is encoded as **issue labels**:
 
 ```text
-prd-draft → prd-ready → prd-in-review → prd-blocked | prd-ticketed → prd-shipped
-            (product)    (us)            (us)                          (product)
+draft → ready → in_review → blocked | ticketed → shipped
+        (product)  (us)      (us)                  (product)
 ```
 
+(Defaults: `prd-draft` / `prd-ready` / `prd-in-review` / `prd-blocked` / `prd-ticketed` / `prd-shipped`.)
+
 Exactly one of these labels is expected on a PRD issue at any time.
 
 This skill ONLY transitions:
 
-- `prd-ready` → `prd-in-review` (claim)
-- `prd-in-review` → `prd-blocked` (gate failures or coverage gaps)
-- `prd-in-review` → `prd-ticketed` (success)
-- `prd-ticketed` → `prd-blocked` (post-write coverage gaps from Phase 3e)
+- `$READY` → `$IN_REVIEW` (claim)
+- `$IN_REVIEW` → `$BLOCKED` (gate failures or coverage gaps)
+- `$IN_REVIEW` → `$TICKETED` (success)
+- `$TICKETED` → `$BLOCKED` (post-write coverage gaps from Phase 3e)
 
-It never adds, removes, or touches `prd-draft` or `prd-shipped`. Those labels are owned by product.
+It never adds, removes, or touches the `draft` or `shipped` labels. Those labels are owned by product.
 
 A "transition" means: remove the old lifecycle label and add the new one (`gh issue edit <num> --remove-label <old> --add-label <new>`). The skill MUST verify exactly one lifecycle label is present after the update.
 
-If the repo has not yet adopted `prd-*` labels, this skill cannot run. See "Adoption" at the bottom.
+If the repo has not yet adopted these labels, this skill cannot run. See "Adoption" at the bottom.
 
-**Label namespace separation:** the PRD lifecycle uses the `prd-*` namespace. The build-queue lifecycle (used by `lisa:github-build-intake`) uses the `status:*` namespace. The two never overlap. When the destination tracker is also GitHub Issues (self-host case), the same repo can host both — but a single issue is either a PRD (carrying a `prd-*` label) or a build ticket (carrying a `status:*` label), never both.
+**Label namespace separation:** the PRD lifecycle uses the configured PRD labels (defaults `prd-*`). The build-queue lifecycle (used by `lisa:github-build-intake`) uses the configured build labels (defaults `status:*`). The two never overlap. When the destination tracker is also GitHub Issues (self-host case), the same repo can host both — but a single issue is either a PRD (carrying a PRD lifecycle label) or a build ticket (carrying a build label), never both.
 
 ## Phases
 
@@ -69,40 +94,42 @@ If the repo has not yet adopted `prd-*` labels, this skill cannot run. See "Adop
    - Literal `github` → resolve from `.lisa.config.json`; error if not set.
 2. Confirm `gh auth status` succeeds.
 3. Confirm the repo is reachable: `gh repo view <org>/<repo> --json name`.
-4. Verify the `prd-*` label set exists:
+4. Verify the PRD label set exists:
    ```bash
-   gh label list --repo <org>/<repo> --json name --jq '[.[] | select(startswith("prd-"))] | sort'
+   gh label list --repo <org>/<repo> --json name --jq '.[] | .name' \
+     | grep -xE "$READY|$IN_REVIEW|$BLOCKED|$TICKETED|$SHIPPED"
    ```
-   If none of `prd-ready` / `prd-in-review` / `prd-blocked` / `prd-ticketed` are present, surface a label-convention error and exit (see "Adoption").
+   If none of the configured PRD labels are present, surface a label-convention error and exit (see "Adoption").
 
-### Phase 2 — Find Ready PRDs
+### Phase 2 — Find ready PRDs
 
 ```bash
-gh issue list --repo <org>/<repo> --label prd-ready --state open --limit 100 \
+gh issue list --repo <org>/<repo> --label "$READY" --state open --limit 100 \
   --json number,title,body,labels,author,milestone,createdAt,updatedAt,url
 ```
 
-For each candidate, confirm exactly one lifecycle label is present (the `--label` filter selects `prd-ready` matches, but a PRD could have ended up with two labels by hand — that's a misconfiguration, not a normal queue entry).
+For each candidate, confirm exactly one lifecycle label is present (the `--label` filter selects `$READY` matches, but a PRD could have ended up with two labels by hand — that's a misconfiguration, not a normal queue entry).
 
 If empty, run a secondary check:
 
 ```bash
-gh issue list --repo <org>/<repo> --state open --limit 100 --json number,labels --jq '[.[] | .labels[] | select(.name | startswith("prd-")) | .name] | unique'
+gh issue list --repo <org>/<repo> --state open --limit 100 --json number,labels \
+  --jq "[.[] | .labels[] | select(.name == \"$READY\" or .name == \"$IN_REVIEW\" or .name == \"$BLOCKED\" or .name == \"$TICKETED\") | .name] | unique"
 ```
 
-If no `prd-*` labels appear on any open issue → convention not adopted; surface error and exit. If `prd-*` labels exist but none are `prd-ready` → genuinely empty queue, exit cleanly with the idle message.
+If no PRD lifecycle labels appear on any open issue → convention not adopted; surface error and exit. If lifecycle labels exist but none are `$READY` → genuinely empty queue, exit cleanly with the idle message.
 
-### Phase 3 — Process each Ready PRD
+### Phase 3 — Process each ready PRD
 
 Process serially to keep label transitions auditable.
 
 #### 3a. Claim
 
 ```bash
-gh issue edit <num> --repo <org>/<repo> --remove-label prd-ready --add-label prd-in-review
+gh issue edit <num> --repo <org>/<repo> --remove-label "$READY" --add-label "$IN_REVIEW"
 ```
 
-This is the idempotency lock — a re-entrant cycle's `--label prd-ready` filter won't see this issue again.
+This is the idempotency lock — a re-entrant cycle's `--label $READY` filter won't see this issue again.
 
 If the relabel fails (permission, race), log and skip. Do not proceed to validation on a PRD you didn't successfully claim.
 
@@ -128,8 +155,8 @@ This call indirectly invokes `lisa:tracker-source-artifacts` (artifact extractio
    ```bash
    gh issue comment <prd-num> --repo <org>/<repo> --body-file /tmp/ticketed-comment.md
    ```
-   Lead with: `"Ticketed by Claude. Created N tickets in <destination> — see below. Add the prd-shipped label after the work is delivered."` The destination is named (JIRA / GitHub Issues) so product knows where to look.
-4. Transition labels: `gh issue edit <prd-num> --remove-label prd-in-review --add-label prd-ticketed`.
+   Lead with: `"Ticketed by Claude. Created N tickets in <destination> — see below. Add the $SHIPPED label after the work is delivered."` The destination is named (JIRA / GitHub Issues) so product knows where to look.
+4. Transition labels: `gh issue edit <prd-num> --remove-label "$IN_REVIEW" --add-label "$TICKETED"`.
 5. **Run Phase 3e (coverage audit)** before considering this PRD done.
 
 **If `FAIL`**:
@@ -160,7 +187,7 @@ Each comment template MUST contain these parts in this order, no exceptions:
 
 **Recommendation:** <validator's `recommendation` field, verbatim — must contain 1–3 concrete options, never a generic "please clarify">
 
-**Action:** Update this section in the PRD, then replace the `prd-blocked` label with `prd-ready` on the issue and Claude will re-run intake.
+**Action:** Update this section in the PRD, then replace the `$BLOCKED` label with `$READY` on the issue and Claude will re-run intake.
 ```
 
 If multiple failures share an anchor, render each as its own `**What's unclear:** ... **Recommendation:** ...` block within the same comment, separated by `---`. Keep the single `[Category badge]` heading at the top.
@@ -191,13 +218,13 @@ For unanchored failures (`prd_anchor: null`), post one rollup comment prefixed w
 
 ##### 3c.5 Label transition
 
-After all comments are posted, transition: `gh issue edit <num> --remove-label prd-in-review --add-label prd-blocked`. Do NOT write any tickets.
+After all comments are posted, transition: `gh issue edit <num> --remove-label "$IN_REVIEW" --add-label "$BLOCKED"`. Do NOT write any tickets.
 
 #### 3d. Continue
 
-Move to the next Ready PRD. One PRD failing does not affect others.
+Move to the next ready PRD. One PRD failing does not affect others.
 
-#### 3e. Coverage audit (mandatory after prd-ticketed)
+#### 3e. Coverage audit (mandatory after $TICKETED)
 
 Per-ticket gates prove each ticket is well-formed; they do NOT prove the *set* of tickets covers the *whole* PRD. Invoke `lisa:prd-ticket-coverage` to catch silent drops.
 
@@ -206,10 +233,10 @@ Per-ticket gates prove each ticket is well-formed; they do NOT prove the *set* o
 
    | Verdict | Action |
    |---------|--------|
-   | `COMPLETE` | Done. Leave label as `prd-ticketed`. Move to next PRD. |
-   | `COMPLETE_WITH_SCOPE_CREEP` | Post an advisory comment on the PRD issue naming the scope-creep tickets. Leave label as `prd-ticketed`. |
-   | `GAPS_FOUND` | The created ticket set is incomplete. (a) For each gap, post a comment using the same product-facing template as Phase 3c.2 — anchored when `prd_anchor` is non-null. (b) Post one summary comment listing the tickets that *were* successfully created. (c) Transition labels from `prd-ticketed` back to `prd-blocked`. |
-   | `NO_TICKETS_FOUND` | Should not happen if step 2 succeeded. Log as Error; leave label as `prd-ticketed` with a flag comment. |
+   | `COMPLETE` | Done. Leave label as `$TICKETED`. Move to next PRD. |
+   | `COMPLETE_WITH_SCOPE_CREEP` | Post an advisory comment on the PRD issue naming the scope-creep tickets. Leave label as `$TICKETED`. |
+   | `GAPS_FOUND` | The created ticket set is incomplete. (a) For each gap, post a comment using the same product-facing template as Phase 3c.2 — anchored when `prd_anchor` is non-null. (b) Post one summary comment listing the tickets that *were* successfully created. (c) Transition labels from `$TICKETED` back to `$BLOCKED`. |
+   | `NO_TICKETS_FOUND` | Should not happen if step 2 succeeded. Log as Error; leave label as `$TICKETED` with a flag comment. |
 
 3. The created tickets remain in the destination tracker regardless of the verdict. The audit only tells us whether *more* are needed.
 
@@ -223,9 +250,9 @@ Cycle started: <ISO timestamp>
 Cycle completed: <ISO timestamp>
 
 PRDs processed: <n>
-- prd-ticketed: <n>
+- $TICKETED: <n>
   - <issue-ref> "<title>" → <epic-ref> + <story-count> stories + <subtask-count> sub-tasks (coverage: COMPLETE | COMPLETE_WITH_SCOPE_CREEP)
-- prd-blocked: <n>
+- $BLOCKED: <n>
   - <issue-ref> "<title>" → <gate-failure-count> gate failures (pre-write) OR <gap-count> coverage gaps (post-write)
 - Errors (claim failed, etc): <n>
   - <issue-ref> "<title>" — <reason>
@@ -240,40 +267,48 @@ Print to the agent's output. Do not write this summary to GitHub.
 
 When the configured destination tracker is GitHub Issues AND the PRD repo is the same as the destination repo, both reads and writes hit the same place. Disambiguation rules:
 
-- A PRD issue carries a `prd-*` label. Built tickets carry a `type:*` + `status:*` label set, but never a `prd-*` label.
+- A PRD issue carries a PRD lifecycle label (configured under `github.labels.prd.*`). Built tickets carry a `type:*` + build-status label set (configured under `github.labels.build.*`), but never a PRD lifecycle label.
 - The "Ticketed by Claude" comment on the PRD links to the destination ticket numbers (which live in the same repo, so the links are simple `#<n>` refs).
 - `lisa:prd-ticket-coverage` filters out the source PRD itself when listing destination tickets — the PRD is never a ticket of its own work.
 
 ## Idempotency & safety
 
-- **Single-cycle scope**: this skill processes the `prd-ready` set as it exists at the start of Phase 2. New `prd-ready` issues added mid-cycle are picked up next run.
-- **No writes outside the lifecycle**: this skill only ever writes to the destination tracker via `lisa:github-to-tracker` (which delegates to `lisa:tracker-write`), only ever changes labels among `prd-in-review`, `prd-blocked`, `prd-ticketed`, only ever comments on the source PRD issue. It never edits PRD bodies, never touches `prd-draft` or `prd-shipped`, never closes or deletes PRD issues.
-- **Claim-first ordering**: the label flip to `prd-in-review` happens BEFORE validation runs.
-- **Failure isolation**: an exception processing one PRD must not stop the cycle. Catch, record under "Errors" in the summary, continue. The PRD that errored is left labeled `prd-in-review` — humans investigate from there.
+- **Single-cycle scope**: this skill processes the ready set as it exists at the start of Phase 2. New ready issues added mid-cycle are picked up next run.
+- **No writes outside the lifecycle**: this skill only ever writes to the destination tracker via `lisa:github-to-tracker` (which delegates to `lisa:tracker-write`), only ever changes labels among `$IN_REVIEW`, `$BLOCKED`, `$TICKETED`, only ever comments on the source PRD issue. It never edits PRD bodies, never touches `draft` or `shipped` labels, never closes or deletes PRD issues.
+- **Claim-first ordering**: the label flip to `$IN_REVIEW` happens BEFORE validation runs.
+- **Failure isolation**: an exception processing one PRD must not stop the cycle. Catch, record under "Errors" in the summary, continue. The PRD that errored is left labeled `$IN_REVIEW` — humans investigate from there.
 - **Single-label invariant**: after every transition, verify exactly one lifecycle label is present.
 
 ## Configuration
 
 Same configuration as `lisa:github-to-tracker`. See that skill for the full table. Key items:
 
-- **From `.lisa.config.json`**: `github.org` and `github.repo` (required for the source repo, and also for the destination repo when `tracker = "github"` — self-host case).
+- **From `.lisa.config.json`**: `github.org` and `github.repo` (required for the source repo, and also for the destination repo when `tracker = "github"` — self-host case), plus `github.labels.prd.*` for the lifecycle label vocabulary (all optional; defaults documented above).
 - **From environment variables**: `E2E_BASE_URL`, `E2E_TEST_PHONE`, `E2E_TEST_OTP`, `E2E_TEST_ORG`, `E2E_GRAPHQL_URL` (operational E2E test config).
 
 Destination tracker config (jira / github / linear) is consumed by `lisa:tracker-write` internally — this skill does NOT read it. If any required value is missing, surface and exit — never invent values.
 
+| Field | Default | Purpose |
+|-------|---------|---------|
+| `.lisa.config.json` `github.labels.prd.ready` | `prd-ready` | Label signalling "PRD ready for ticketing" |
+| `.lisa.config.json` `github.labels.prd.in_review` | `prd-in-review` | Label set on claim |
+| `.lisa.config.json` `github.labels.prd.blocked` | `prd-blocked` | Label set on validation failure |
+| `.lisa.config.json` `github.labels.prd.ticketed` | `prd-ticketed` | Label set on success |
+| `.lisa.config.json` `github.labels.prd.shipped` | `prd-shipped` | Label product sets after delivery |
+
 ## Rules
 
 - Never write to the destination tracker outside of `lisa:github-to-tracker` → `lisa:tracker-write`.
-- Never add or remove a label this skill doesn't own (`prd-in-review`, `prd-blocked`, `prd-ticketed`). Product owns `prd-draft`, `prd-ready`, `prd-shipped`.
+- Never add or remove a label this skill doesn't own (`$IN_REVIEW`, `$BLOCKED`, `$TICKETED`). Product owns the `draft`, `ready`, and `shipped` PRD labels.
 - Never edit a PRD's body. Communication with product happens only via comments.
 - Never post a single dump of all gate failures on one comment. One comment per `prd_anchor` group, plus one rollup for unanchored failures.
 - Never include a gate ID, internal skill name, or engineering shorthand in a comment body.
 - Never run more than one intake cycle concurrently against the same repo.
-- If `lisa:github-to-tracker` returns errors, treat them as gate failures: comment + `prd-blocked`. Don't silently fail.
+- If `lisa:github-to-tracker` returns errors, treat them as gate failures: comment + `$BLOCKED`. Don't silently fail.
 
 ## Adoption (one-time per repo)
 
-Before this skill can run, the repo must adopt the `prd-*` issue-label convention:
+Before this skill can run, the repo must adopt the PRD lifecycle issue-label convention. Using the defaults:
 
 1. Create the labels:
    ```bash
@@ -284,8 +319,9 @@ Before this skill can run, the repo must adopt the `prd-*` issue-label conventio
    gh label create prd-ticketed --color 0E8A16 --description "Tickets created — see comments" --repo <org>/<repo>
    gh label create prd-shipped --color 1D76DB --description "Work delivered (product owns)" --repo <org>/<repo>
    ```
-2. Apply `prd-ready` to issues that are ready for ticketing.
-3. Reserve `prd-in-review`, `prd-blocked`, `prd-ticketed` for this skill — humans should not set them manually except to recover from an error.
-4. Keep the `prd-*` namespace strictly separate from the build-queue `status:*` namespace owned by `lisa:github-build-intake`.
+   If your project overrides any `github.labels.prd.*` role name in config, substitute the actual label names you configured.
+2. Apply the `$READY` label to issues that are ready for ticketing.
+3. Reserve `$IN_REVIEW`, `$BLOCKED`, `$TICKETED` for this skill — humans should not set them manually except to recover from an error.
+4. Keep the PRD label namespace strictly separate from the build-queue label namespace owned by `lisa:github-build-intake`.
 
 If the repo hasn't adopted these labels, the first run exits with a label-convention error (not the idle empty-set message) — this distinguishes setup from a genuinely empty queue.