@codyswann/lisa 2.7.0 → 2.8.0

package/plugins/lisa/skills/{confluence-to-jira → confluence-to-tracker}/SKILL.md

@@ -1,21 +1,21 @@
 ---
-name: confluence-to-jira
+name: confluence-to-tracker
 description: >
-  Break down a Confluence PRD page into JIRA epics, stories, and sub-tasks. Use this skill whenever the
-  user shares a Confluence PRD URL and wants it converted into JIRA tickets, or asks to "break down
-  this Confluence spec", "create tickets from a Confluence page", "turn this Confluence doc into JIRA",
-  or similar. This skill mirrors `lisa:notion-to-jira` for projects whose PRDs live in Confluence —
+  Break down a Confluence PRD page into Epics, Stories, and Sub-tasks in the configured destination tracker (JIRA or GitHub Issues per .lisa.config.json). Use this skill whenever the
+  user shares a Confluence PRD URL and wants it converted into tracker tickets, or asks to "break down
+  this Confluence spec", "create tickets from a Confluence page", "turn this Confluence doc into tickets",
+  or similar. This skill mirrors `lisa:notion-to-tracker` for projects whose PRDs live in Confluence —
   the workflow, gates, dry-run mode, and validation rules are identical; only the source-of-truth tool
   surface differs (Confluence MCP instead of Notion MCP).
-allowed-tools: ["Skill", "Bash", "mcp__atlassian__getConfluencePage", "mcp__atlassian__getConfluencePageDescendants", "mcp__atlassian__getConfluencePageFooterComments", "mcp__atlassian__getConfluencePageInlineComments", "mcp__atlassian__getConfluenceCommentChildren", "mcp__atlassian__searchConfluenceUsingCql", "mcp__atlassian__getAccessibleAtlassianResources", "mcp__atlassian__getJiraIssueRemoteIssueLinks"]
+allowed-tools: ["Skill", "Bash", "mcp__atlassian__getConfluencePage", "mcp__atlassian__getConfluencePageDescendants", "mcp__atlassian__getConfluencePageFooterComments", "mcp__atlassian__getConfluencePageInlineComments", "mcp__atlassian__getConfluenceCommentChildren", "mcp__atlassian__searchConfluenceUsingCql", "mcp__atlassian__getAccessibleAtlassianResources"]
 ---
 
-# Confluence PRD to JIRA Breakdown
+# Confluence PRD to Tracker Breakdown
 
-Convert a Confluence PRD into a structured JIRA ticket hierarchy: Epics > Stories > Sub-tasks.
+Convert a Confluence PRD into a structured ticket hierarchy in the configured destination tracker (JIRA or GitHub Issues per .lisa.config.json): Epics > Stories > Sub-tasks.
 Each sub-task is scoped to exactly one repo and includes an empirical verification plan.
 
-This skill is the Confluence counterpart of `lisa:notion-to-jira`. The two skills share the same
+This skill is the Confluence counterpart of `lisa:notion-to-tracker`. The two skills share the same
 phases, gates, dry-run contract, and per-ticket validation logic. Only the PRD-side fetch / comment
 tools differ. When changing workflow logic, change BOTH skills together so the two source vendors
 stay behaviorally identical.
@@ -24,16 +24,16 @@ stay behaviorally identical.
 
 This skill supports two modes, controlled by a `dry_run` flag in `$ARGUMENTS`:
 
-- **`dry_run: false`** (default — full mode): run all phases, write tickets via `lisa:jira-write-ticket`, run the preservation gate, report.
-- **`dry_run: true`** (planning + validation only — no writes): run Phases 1, 1.5, 1.6, 2, 3, 4 to plan the hierarchy and draft each ticket spec, then call `lisa:jira-validate-ticket` (with `--spec-only`) on every drafted ticket. Aggregate the per-ticket validator reports into a single dry-run report. **Skip Phase 5 (sub-task creation), Phase 5.5 (preservation gate), and Phase 6 (results report)** — none of those make sense without writes. Return the dry-run report so the caller (e.g. `lisa:confluence-prd-intake`) can decide whether to proceed.
+- **`dry_run: false`** (default — full mode): run all phases, write tickets via `lisa:tracker-write`, run the preservation gate, report.
+- **`dry_run: true`** (planning + validation only — no writes): run Phases 1, 1.5, 1.6, 2, 3, 4 to plan the hierarchy and draft each ticket spec, then call `lisa:tracker-validate` (with `--spec-only`) on every drafted ticket. Aggregate the per-ticket validator reports into a single dry-run report. **Skip Phase 5 (sub-task creation), Phase 5.5 (preservation gate), and Phase 6 (results report)** — none of those make sense without writes. Return the dry-run report so the caller (e.g. `lisa:confluence-prd-intake`) can decide whether to proceed.
 
-Dry-run output format is identical to `lisa:notion-to-jira`'s. Reuse the same fields, including
+Dry-run output format is identical to `lisa:notion-to-tracker`'s. Reuse the same fields, including
 `prd_anchor` and `prd_section`. The only difference: `prd_anchor` is the inline-comment anchor text
 that `createConfluenceInlineComment` accepts (typically the full selected substring; truncate if it
 exceeds the tool's max anchor length and emit `null` if no resolvable anchor exists).
 
 ```text
-## confluence-to-jira dry-run: <PRD title>
+## confluence-to-tracker dry-run: <PRD title>
 
 ### Planned hierarchy
 - Epic: <summary>
@@ -67,11 +67,11 @@ The dry-run mode never writes to JIRA and never calls `mcp__atlassian__createJir
 modifies the source Confluence page, never adds/removes labels, and never posts comments — that is the
 orchestrating skill's responsibility (`lisa:confluence-prd-intake`).
 
-## Hard Rule: All Writes Go Through `lisa:jira-write-ticket`
+## Hard Rule: All Writes Go Through `lisa:tracker-write`
 
-**Every JIRA ticket created by this skill — every epic, story, and sub-task — MUST be created by invoking the `lisa:jira-write-ticket` skill. Never call `mcp__atlassian__createJiraIssue`, `mcp__atlassian__editJiraIssue`, `mcp__atlassian__createIssueLink`, or any other Atlassian write tool directly from this skill or from any sub-agent it spawns.**
+**Every JIRA ticket created by this skill — every epic, story, and sub-task — MUST be created by invoking the `lisa:tracker-write` skill. Never call `mcp__atlassian__createJiraIssue`, `mcp__atlassian__editJiraIssue`, `mcp__atlassian__createIssueLink`, or any other Atlassian write tool directly from this skill or from any sub-agent it spawns.**
 
-`lisa:jira-write-ticket` enforces gates this skill does not:
+`lisa:tracker-write` enforces gates this skill does not:
 - 3-audience description (Context / Technical Approach / Acceptance Criteria)
 - Gherkin acceptance criteria
 - Epic parent validation
@@ -80,7 +80,7 @@ orchestrating skill's responsibility (`lisa:confluence-prd-intake`).
 - Sign-in account and target environment recorded in description
 - Post-create verification
 
-Bypassing `lisa:jira-write-ticket` produces thin tickets that the rest of the lifecycle (triage, ticket-verify, journey, evidence) treats as broken. The Atlassian read tools (`getJiraIssue`, `searchJiraIssuesUsingJql`, `getJiraIssueRemoteIssueLinks`, `getAccessibleAtlassianResources`, `getJiraProjectIssueTypesMetadata`, `getVisibleJiraProjects`, and the Confluence read endpoints listed in `allowed-tools` above) ARE allowed for context gathering and the Phase 5.5 preservation gate.
+Bypassing `lisa:tracker-write` produces thin tickets that the rest of the lifecycle (triage, ticket-verify, journey, evidence) treats as broken. The Atlassian read tools (`getJiraIssue`, `searchJiraIssuesUsingJql`, `getJiraIssueRemoteIssueLinks`, `getAccessibleAtlassianResources`, `getJiraProjectIssueTypesMetadata`, `getVisibleJiraProjects`, and the Confluence read endpoints listed in `allowed-tools` above) ARE allowed for context gathering and the Phase 5.5 preservation gate.
 
 ## Input
 
@@ -165,7 +165,7 @@ The existing-component reuse expectation is defined in `lisa:jira-source-artifac
 
 ### Phase 2: Codebase + Live Product Research
 
-Identical to `lisa:notion-to-jira` Phase 2. Two complementary inputs ground PRD analysis: the **code** (what's there to reuse / extend) and the **live product** (what users see today). Skipping either produces tickets that misjudge the change.
+Identical to `lisa:notion-to-tracker` Phase 2. Two complementary inputs ground PRD analysis: the **code** (what's there to reuse / extend) and the **live product** (what users see today). Skipping either produces tickets that misjudge the change.
 
 **2a. Codebase research.** If the session doesn't already have codebase context, explore the repos to understand what exists. Use Explore agents for repos not yet examined.
 
@@ -177,9 +177,9 @@ Walkthrough findings are attached to the originating Confluence PRD as a **foote
 
 ### Phase 3: Create Epics
 
-> **Mode guard**: In `dry_run: true` mode, do not invoke `lisa:jira-write-ticket` in this phase. Instead, draft the epic spec (summary, description_body, artifacts) and validate it with `lisa:jira-validate-ticket --spec-only`. Record the drafted spec (including a placeholder epic key like `DRY-RUN-EPIC-1`) for Phase 4 to use as parent references. In `dry_run: false` mode (default), proceed as described below.
+> **Mode guard**: In `dry_run: true` mode, do not invoke `lisa:tracker-write` in this phase. Instead, draft the epic spec (summary, description_body, artifacts) and validate it with `lisa:tracker-validate --spec-only`. Record the drafted spec (including a placeholder epic key like `DRY-RUN-EPIC-1`) for Phase 4 to use as parent references. In `dry_run: false` mode (default), proceed as described below.
 
-For each PRD epic, **invoke the `lisa:jira-write-ticket` skill** (do not call `createJiraIssue` directly). Pass it everything it needs to enforce its quality gates:
+For each PRD epic, **invoke the `lisa:tracker-write` skill** (do not call `createJiraIssue` directly). Pass it everything it needs to enforce its quality gates:
 
 - `project_key`: from `JIRA_PROJECT` config
 - `issue_type`: `Epic`
@@ -199,7 +199,7 @@ Capture the returned epic key — Phase 4 needs it as the parent for stories.
 
 ### Phase 4: Create Stories
 
-> **Mode guard**: In `dry_run: true` mode, do not invoke `lisa:jira-write-ticket` in this phase. Instead, draft each story spec and validate it with `lisa:jira-validate-ticket --spec-only`. Use placeholder keys (e.g. `DRY-RUN-STORY-1.1`) for any downstream references. In `dry_run: false` mode (default), proceed as described below.
+> **Mode guard**: In `dry_run: true` mode, do not invoke `lisa:tracker-write` in this phase. Instead, draft each story spec and validate it with `lisa:tracker-validate --spec-only`. Use placeholder keys (e.g. `DRY-RUN-STORY-1.1`) for any downstream references. In `dry_run: false` mode (default), proceed as described below.
 
 For each Epic, plan two kinds of stories:
 - **One "X.0 Setup" story** for data model and infrastructure prerequisites
@@ -207,13 +207,13 @@ For each Epic, plan two kinds of stories:
 
 **Story naming convention**: Prefix the summary with a short code derived from the PRD title (e.g., `[CU-1.1]` for "Contract Upload").
 
-For each story, **invoke `lisa:jira-write-ticket`** with:
+For each story, **invoke `lisa:tracker-write`** with:
 
 - `project_key`: from `JIRA_PROJECT` config
 - `issue_type`: `Story`
 - `epic_parent`: the Epic key captured in Phase 3 (mandatory)
 - `summary`: prefixed per the naming convention above
-- `description_body`: 3-audience description as in `lisa:notion-to-jira` Phase 4
+- `description_body`: 3-audience description as in `lisa:notion-to-tracker` Phase 4
 - `artifacts`: the Phase 1.5 artifacts filtered by domain per the inheritance table below
 
 | Story type | Inherits domains |
@@ -227,7 +227,7 @@ Capture each returned story key — Phase 5 needs it as the parent for sub-tasks
 
 ### Phase 5: Create Sub-tasks
 
-Delegate sub-task creation to **parallel agents** (one per epic or batch of stories) for efficiency. **Every spawned agent must invoke `lisa:jira-write-ticket` for each sub-task — no agent may call `createJiraIssue` directly.**
+Delegate sub-task creation to **parallel agents** (one per epic or batch of stories) for efficiency. **Every spawned agent must invoke `lisa:tracker-write` for each sub-task — no agent may call `createJiraIssue` directly.**
 
 Each sub-task MUST:
 1. **Be scoped to exactly ONE repo** — indicated in brackets in the summary: `[repo-name]`
@@ -241,9 +241,9 @@ Run the preservation gate defined in `lisa:jira-source-artifacts` §8 against th
 
 To run the gate, this skill must:
 
-1. Pull the remote links of every epic and story created in this run via `mcp__atlassian__getJiraIssueRemoteIssueLinks`.
+1. Pull the remote links of every epic and story created in this run via `lisa:tracker-read (vendor-neutral; dispatches to jira-read-ticket or github-read-issue)`.
 2. Apply the §8 preservation matrix and verdict rules.
-3. If the gate fails: list each dropped/misrouted artifact and either re-attach via `lisa:jira-write-ticket` (UPDATE mode) or stop and ask the human.
+3. If the gate fails: list each dropped/misrouted artifact and either re-attach via `lisa:tracker-write` (UPDATE mode) or stop and ask the human.
 4. If the gate passes: print the matrix compactly and proceed to Phase 6.
 
 This gate is not optional.
@@ -275,13 +275,13 @@ When delegating to agents, provide this context. **The "MUST invoke jira-write-t
 ```text
 Create JIRA sub-tasks in the [PROJECT] project at [CLOUD_ID].
 
-CRITICAL: For each sub-task, invoke the `lisa:jira-write-ticket` skill via the Skill tool.
-Do NOT call `mcp__atlassian__createJiraIssue` directly. The `lisa:jira-write-ticket` skill
+CRITICAL: For each sub-task, invoke the `lisa:tracker-write` skill via the Skill tool.
+Do NOT call `mcp__atlassian__createJiraIssue` directly. The `lisa:tracker-write` skill
 enforces required quality gates (Gherkin acceptance criteria, 3-audience description,
 single-repo scope, sign-in/environment fields, post-create verification). Bypassing it
 produces broken tickets that downstream skills (triage, journey, evidence) cannot use.
 
-For each sub-task, invoke `lisa:jira-write-ticket` with:
+For each sub-task, invoke `lisa:tracker-write` with:
 - issue_type: "Sub-task"
 - parent: the parent story key
 - project_key: [PROJECT]
@@ -297,9 +297,9 @@ For each sub-task, invoke `lisa:jira-write-ticket` with:
 Each sub-task must:
 1. Be scoped to ONE repo only — repo named in brackets in the summary
 2. Include the Empirical Verification Plan in the description
-3. Be created via `lisa:jira-write-ticket`, not via direct MCP calls
+3. Be created via `lisa:tracker-write`, not via direct MCP calls
 
-If `lisa:jira-write-ticket` rejects a sub-task, fix the input and re-invoke. Do NOT fall back
+If `lisa:tracker-write` rejects a sub-task, fix the input and re-invoke. Do NOT fall back
 to a direct `createJiraIssue` call to bypass the gate.
 
 Test user info: [credentials from config]

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

@@ -0,0 +1,114 @@
+---
+name: github-add-journey
+description: "Add a Validation Journey section to an existing GitHub Issue by analyzing the change type and generating appropriate verification steps with evidence markers. The GitHub counterpart of lisa:jira-add-journey."
+allowed-tools: ["Bash", "Skill"]
+---
+
+# Add Validation Journey to Existing GitHub Issue
+
+Read an existing GitHub Issue, analyze the change type, and append a `## Validation Journey` markdown section with appropriate verification steps based on the project's verification patterns.
+
+## Arguments
+
+`$ARGUMENTS`: `<ISSUE_REF>`
+
+- `ISSUE_REF` (required): GitHub issue ref — `org/repo#<number>` or full GitHub issue URL.
+
+## Prerequisites
+
+- `gh` CLI authenticated (`gh auth status`).
+
+## Workflow
+
+### Step 1: Read the Issue
+
+```bash
+gh issue view <number> --repo <org>/<repo> --json number,title,body,labels,assignees,milestone,url
+```
+
+Extract: title, body, type (from `type:` label), components (from `component:` labels), assignees, linked PRs.
+
+### Step 2: Check for Existing Journey
+
+Parse the body for an existing `## Validation Journey` heading. If present and the section contains at least one `[EVIDENCE: <name>]` marker, the issue already has a journey — report this to the user and stop.
+
+### Step 3: Analyze the Change Type
+
+Examine the body, acceptance criteria, and codebase to determine the change type:
+
+1. **API/GraphQL changes** — New or modified endpoints, request/response schemas
+2. **Database migration** — Schema changes, new tables/columns, indexes
+3. **Background job/queue** — New job processors, queue consumers, event handlers
+4. **Library/utility** — Exported functions, shared modules, npm package changes
+5. **Security fix** — Auth, authorization, input validation, OWASP vulnerabilities
+6. **Authentication/authorization** — Role-based access, session management, tokens
+
+Use Explore agents or read the codebase directly to understand which files are affected.
+
+### Step 4: Map Change Type to Verification Pattern
+
+| Change Type | Verification Approach |
+|---|---|
+| API/GraphQL | curl commands verifying endpoints, status codes, response schemas |
+| Database migration | Migration execution + schema verification + rollback check |
+| Background job/queue | Enqueue + process + state change verification |
+| Library/utility | Test execution + build verification + export check |
+| Security fix | Exploit reproduction pre-fix + exploit failure post-fix |
+| Auth/authz | Multi-role verification with explicit status codes |
+
+### Step 5: Draft the Validation Journey
+
+Compose the journey with `[EVIDENCE: name]` markers at key verification points:
+
+```markdown
+## Validation Journey
+
+### Prerequisites
+- List required services, database, env vars
+
+### Steps
+1. Verify current state before changes
+2. Apply the change
+3. Verify expected new state [EVIDENCE: state-name]
+4. Test error/edge cases [EVIDENCE: error-case]
+5. Verify rollback if applicable [EVIDENCE: rollback]
+
+### Assertions
+- Describe what must be true after verification
+```
+
+### Guidelines for Drafting
+
+1. **2–5 evidence markers** — Focus on proving the change works and handles errors.
+2. **Concrete, runnable steps** — `Run \`curl -s localhost:3000/health | jq .status\`` not "Check the endpoint".
+3. **Include environment setup** — Database connection, running services, env vars.
+4. **Evidence names in kebab-case** — `api-response`, `schema-check`, `rate-limit-hit`.
+5. **Assertions are measurable** — `Returns 200 with {status: ok}` not "API works correctly".
+6. **Cover happy path AND error path** — At minimum, one success and one failure marker.
+
+### Step 6: Present to User for Approval
+
+Display the drafted Validation Journey and ask for confirmation before appending it to the issue body. (If invoked from a parent skill running unattended — e.g., `lisa:github-write-issue` Phase 6 step 5 — proceed without the prompt.)
+
+### Step 7: Append to Issue Body
+
+After approval:
+
+```bash
+current_body=$(gh issue view <number> --repo <org>/<repo> --json body --jq '.body')
+# Compose new body: existing + "\n\n## Validation Journey\n..." (or replace if present)
+gh issue edit <number> --repo <org>/<repo> --body-file /tmp/updated-body.md
+```
+
+Preserve every other section verbatim — never re-render the body from parsed fields, since the issue may carry `extra_sections` we don't recognize.
+
+### Step 8: Verify
+
+Re-read the issue and confirm the `## Validation Journey` section is present and includes at least one `[EVIDENCE: <name>]` marker.
+
+## When to Use This Skill
+
+- Issue was created before the Validation Journey convention was established.
+- Issue was created manually without following `lisa:github-create` guidelines.
+- Issue needs a journey added or updated based on implementation progress.
+- Before starting work on an issue, to ensure verification steps are documented.

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

@@ -0,0 +1,188 @@
+---
+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."
+allowed-tools: ["Skill", "Bash"]
+---
+
+# GitHub Build Intake: $ARGUMENTS
+
+`$ARGUMENTS` is one of:
+
+1. A GitHub `org/repo` token (e.g., `acme/frontend-v2`).
+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.
+
+## 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.
+
+Specifically forbidden:
+
+- Previewing projected scope (issue count, projected PR count, build duration) and asking whether to continue.
+- Offering A/B/C-style choices like "proceed / skip a few / dry-run only".
+- Pausing because the queue is large, issues look complex, or issues are likely to be `Blocked` by `lisa:github-agent`'s pre-flight gate. Pre-flight `Blocked` is a valid terminal state of the per-issue lifecycle, not a failure mode.
+- Pausing because the build flow looks expensive.
+
+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."`
+
+## 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)
+```
+
+This skill ONLY transitions:
+
+- `status:ready` → `status:in-progress` (claim)
+- `status:in-progress` → `status:on-dev` (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.
+
+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.
+
+**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.
+
+## Phases
+
+### Phase 1 — Resolve the repo
+
+1. Parse `$ARGUMENTS`:
+   - `org/repo` token → use as-is.
+   - GitHub URL → extract `org` and `repo`.
+   - Literal `github` → resolve from `.lisa.config.json` (`github.org`, `github.repo`); error if not set.
+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
+
+```bash
+gh issue list --repo <org>/<repo> --label status: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'
+```
+
+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."`
+
+### 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 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.
+
+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.**
+
+#### 3b. Run the build flow
+
+Invoke `lisa:github-agent` (the per-issue lifecycle agent) with the issue ref. `lisa:github-agent` owns:
+- Reading the full issue graph (`lisa:github-read-issue`)
+- Running its own pre-flight quality gate (`lisa:github-verify`)
+- Running issue triage (`lisa:ticket-triage`)
+- Routing to the appropriate flow (Build / Fix / Investigate / Improve based on `type:` label)
+- Posting progress comments via `lisa:github-sync`
+- Posting evidence via `lisa:github-evidence`
+
+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".
+
+#### 3c. Transition to On Dev (only on Success)
+
+If `lisa:github-agent` returned Success:
+
+```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."
+```
+
+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.
+
+#### 3d. Continue
+
+Move to the next Ready issue. One issue failing does not stop others.
+
+### Phase 4 — Summary report
+
+```text
+## github-build-intake summary
+
+Repo: <org>/<repo>
+Cycle started: <ISO timestamp>
+Cycle completed: <ISO timestamp>
+
+Issues processed: <n>
+- status:on-dev (build complete, PR ready): <n>
+  - <org>/<repo>#<number> <title> → PR <URL>
+- Blocked (pre-flight verify failed): <n>
+  - <org>/<repo>#<number> <title> — see issue comments
+- Held (triage found ambiguities): <n>
+  - <org>/<repo>#<number> <title> — see issue comments
+- Errors: <n>
+  - <org>/<repo>#<number> <title> — <reason>
+
+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`.
+- **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.
+
+## Configuration
+
+| Variable | Default | Purpose |
+|----------|---------|---------|
+| `.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 |
+
+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.
+
+## Rules
+
+- Never relabel an issue the cycle didn't claim. The `status:in-progress` 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.
+- 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.
+
+## Adoption (one-time per repo)
+
+Before this skill can run, the repo must adopt the `status:*` label namespace:
+
+1. Create the labels:
+   ```bash
+   gh label create status:ready --color FBCA04 --description "Ready for build" --repo <org>/<repo>
+   gh label create status:in-progress --color 0E8A16 --description "Build in progress" --repo <org>/<repo>
+   gh label create status:code-review --color 5319E7 --description "PR open, awaiting review" --repo <org>/<repo>
+   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.

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

@@ -0,0 +1,101 @@
+---
+name: github-create
+description: This skill should be used when creating GitHub Issue Epics, Stories, and Sub-tasks from code files or descriptions. It analyzes the provided input, determines the appropriate issue hierarchy, and creates issues with comprehensive quality requirements including test-first development and documentation. The GitHub counterpart of lisa:jira-create.
+allowed-tools: ["Read", "Glob", "LS", "Skill", "Bash"]
+---
+
+# Create GitHub Issues from $ARGUMENTS
+
+Analyze the provided file(s) and plan a GitHub Issue hierarchy. **This skill plans structure only — every individual issue write is delegated to `lisa:github-write-issue` (which itself goes through the `lisa:tracker-write` shim when invoked from a vendor-neutral caller).** Do not call `gh issue create` from this skill; the necessary write invocations belong to the writer skill so the gates can never be bypassed.
+
+## Process
+
+1. **Analyze**: Read `$ARGUMENTS` to understand scope.
+2. **Extract source artifacts**: invoke the `lisa:jira-source-artifacts` skill (vendor-neutral), then enumerate every external URL, embed, attachment, or example payload in the input and classify each by domain per its rules. Build the `artifacts` map (one entry per artifact: url, title, domain, source page, classification reason).
+3. **Walk the live product** (when applicable): if the work touches existing user-facing surfaces, invoke the `lisa:product-walkthrough` skill.
+4. **Determine structure**:
+   - Epic needed if: multiple features, major changes, >3 related files.
+   - Direct Tasks if: bug fix, single file, minor change.
+5. **Plan hierarchy**:
+
+   ```text
+   Epic → Story → Sub-tasks (test, implement, document, cleanup)
+   ```
+
+6. **Delegate every write to `lisa:github-write-issue`** in dependency order (Epic first, then Stories with the Epic as parent sub-issue, then Sub-tasks with their Story as parent). Pass artifacts (filtered by domain per `lisa:jira-source-artifacts` inheritance rules) and walkthrough findings (under `## Current Product`).
+7. **Run the artifact preservation gate** (`lisa:jira-source-artifacts` §8): after all writes complete, build the preservation matrix and verify every extracted artifact is reachable from the created issues. Fail loudly if anything was dropped.
+
+## Mandatory for Every Code Issue
+
+**Test-First**: Write tests before implementation
+**Quality Gates**: All tests/checks must pass, no SonarCloud violations
+**Documentation**: Check existing, update/create new, remove obsolete
+**Cleanup**: Remove temporary code, scripts, dev configs
+
+## Validation Journey
+
+Issues that change runtime behavior should include a `## Validation Journey` section. This section is consumed by `lisa:github-journey` to automate verification. Use `lisa:github-add-journey` to draft + append the section after creation.
+
+## Source Artifacts
+
+If `$ARGUMENTS` references any external artifact — PRD, design doc, Figma URL, Lovable prototype, Loom walkthrough, screenshot, example payload — those references MUST be preserved as `## Links` and `## Source Artifacts` sections on the created issues. Silent artifact loss is the single most common quality failure in this pipeline.
+
+**Invoke `lisa:jira-source-artifacts`** for the canonical rules: domains, per-tool classification, source precedence, conflict handling under `## Open Questions`, inheritance from epic → story → sub-task, and the existing-component reuse expectation. This skill is vendor-neutral and used by both the JIRA and the GitHub paths.
+
+When delegating actual writes to `lisa:github-write-issue`, pass the extracted artifact list so its Phase 4c (Remote Links / Source Artifacts) step attaches them.
+
+## Live Product Walkthrough
+
+When the work touches existing user-facing surfaces, invoke `lisa:product-walkthrough` before drafting issues. The findings become inputs to the issue plan and surface under `## Current Product` on the resulting issues.
+
+## Issue Requirements
+
+Each issue must clearly communicate to:
+
+- **Coding Assistants**: Implementation requirements
+- **Developers**: Technical approach
+- **Stakeholders**: Business value
+
+Default repo: from `.lisa.config.json` `github.org` / `github.repo` (override via arguments).
+
+## Delegation to github-write-issue
+
+**Mandatory.** Every issue created by this skill MUST go through `lisa:github-write-issue`. This skill never calls `gh issue create` itself — that invocation belongs to the writer.
+
+`lisa:github-write-issue` enforces:
+- 3-audience description (Context / Technical Approach / Acceptance Criteria)
+- Gherkin acceptance criteria
+- Parent sub-issue validation (non-bug, non-epic types)
+- Explicit relationship discovery (`Blocks` / `Blocked by` / `Relates to` / `Duplicates` / `Cloned from`)
+- Remote links (PRs, Confluence, dashboards)
+- Single-repo scope check for Bug / Task / Sub-task
+- Sign-in account and target environment recorded in body
+- Post-create verification
+
+### Invocation order
+
+Issues must be created in parent-before-child order:
+
+1. Invoke `lisa:github-write-issue` for the Epic. Capture the returned issue number.
+2. For each Story, invoke `lisa:github-write-issue` with the Epic ref as `parent_ref`. Capture each Story number.
+3. For each Sub-task, invoke `lisa:github-write-issue` with the Story ref as `parent_ref`.
+
+### What to pass to each invocation
+
+For every delegated write, pass:
+- The summary, issue type, repo (org/repo), and priority you decided
+- The body with all sections drafted (Context / Technical Approach / Acceptance Criteria / Out of Scope / etc.)
+- Gherkin acceptance criteria
+- `parent_ref` (Epic ref for Stories; Story ref for Sub-tasks)
+- The artifact list extracted in "Source Artifacts", filtered by domain per the inheritance rules — `lisa:github-write-issue` Phase 4c attaches them
+- For runtime-behavior issues: instruct the writer to call `lisa:github-add-journey` after create
+
+### What this skill is responsible for
+
+- Deciding the *shape* of the hierarchy (what's an Epic vs. Story vs. Sub-task).
+- Drafting the body and acceptance criteria from the input.
+- Extracting and classifying source artifacts.
+- Threading parent refs through subsequent writes.
+- Running the preservation check after all writes complete.
+
+It does not own the actual `gh issue create` call — that's `lisa:github-write-issue`'s job.