@codyswann/lisa 4.74.8 → 4.75.0

package/plugins/lisa-devin/skills/lisa-github-claim/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: lisa-github-claim
+description: "Idempotently claims one live GitHub leaf issue for direct Lisa work. Reuses github-build-intake Phase 3b semantics: configured ready-to-claimed relabel, assign-only-if-unassigned, stable managed comment, and post-write verification."
+allowed-tools: ["Bash", "Skill", "Read"]
+---
+
+# Claim GitHub Issue: $ARGUMENTS
+
+Claim exactly one canonical `org/repo#<number>` reference. This is the reusable direct-session counterpart of `lisa-github-build-intake` Phase 3b.
+
+1. Resolve merged `.github.org`, `.github.repo`, optional `.github.queueRepo`, and `github.labels.build` values from local-over-global config. Resolve current-repository identity independently using `repo-scope-split` / `config-resolution` (`.repo` -> `.github.repo` -> `git remote get-url origin` basename). The queue repository defaults to `<github.org>/<github.repo>`; it is only the tracker storage/scan target and never replaces current-repository identity. Resolve the ready and claimed roles from config (defaults `status:ready` and `status:in-progress`); do not hardcode lifecycle decisions.
+2. Require the ref's `org/repo` to equal the resolved queue repository. Invoke `lisa-github-read-issue <ref>` immediately before mutation. When the queue repository differs from the current repository, require exactly the current-repository scope (`repo:<current>`); reject an unlabeled issue, `repo:<other>`, or an ambiguous multi-repo leaf. Also reject a closed issue, an active blocker, any issue with open child work, or a childless Epic per `repo-scope-split` and `leaf-only-lifecycle`.
+3. Inspect the live build lifecycle labels:
+   - Already claimed, review, environment-done, or another configured later non-terminal role -> preserve it and set `claim_outcome: reused`.
+   - Ready or no build lifecycle label -> run `gh issue edit <number> --repo <org>/<repo>`, remove ready when present, and add claimed. This is the idempotency lock.
+   - Terminal label/state -> reject; completed work cannot be rebound as new work.
+4. If and only if the issue is unassigned, add `@me`; leave every existing assignee untouched.
+5. Post the stable marker comment once, deduped against all existing comments:
+
+   ```text
+   [lisa-tracker-claim] Claimed by Lisa. Starting implementation.
+   ```
+
+6. Invoke `lisa-github-read-issue <ref>` again. Success requires the issue to remain open, leaf/current-repo (including the explicit `repo:<current>` proof for an umbrella queue), and in claimed or a later non-terminal role. If the relabel or verification fails, return failure and do not authorize a binding.
+7. Return `tracker_provider: github`, canonical `work_item_ref: <org>/<repo>#<number>`, `claim_outcome: claimed|reused`, assignee outcome, and the post-write status evidence.
+
+Never create an issue here. Never call GitHub for a configured Jira or Linear project.

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

@@ -0,0 +1,105 @@
+---
+name: lisa-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-tracker-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-tracker-source-artifacts` inheritance rules) and walkthrough findings (under `## Current Product`).
+7. **Run the artifact preservation gate** (`lisa-tracker-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.
+
+When the issue needs to point at evidence owned by another work item, pass the exact non-claiming form `[EVIDENCE-REF: <work-item-ref> | <artifact-type>: <kebab-case-name>]` to the writer. Never quote the sibling's `[EVIDENCE: ...]` marker. A reference is informational only and does not replace the runtime-changing leaf's own S14 evidence marker.
+
+## 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-tracker-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` and explicit `build_ready: true`.
+
+- **Declare readiness on every leaf write.** Per the `ready-role-filing` rule an omitted `build_ready` is **not build-ready** on any tracker, so pass `build_ready: true` on each Sub-task (the leaf work units this skill plans) and never on the Epic or Stories, which are containers per `leaf-only-lifecycle`. A leaf that is deliberately held instead passes `human_gate: "<why a human must judge this first>"`. Filing a leaf with neither is an incomplete handoff and `lisa-github-write-issue` rejects it.
+
+### 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.

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

@@ -0,0 +1,120 @@
+---
+name: lisa-github-evidence
+description: "Upload text evidence to the GitHub `pr-assets` release, update PR description, and post a GitHub Issue comment with code blocks. 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"]
+---
+
+# GitHub Evidence Posting
+
+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.
+
+## Arguments
+
+`$ARGUMENTS`: `<ISSUE_REF> <EVIDENCE_DIR> <PR_NUMBER>`
+
+- `ISSUE_REF` (required): GitHub issue ref — `org/repo#<number>` or full GitHub issue URL.
+- `EVIDENCE_DIR` (required): Directory containing evidence and templates (e.g., `./evidence`).
+- `PR_NUMBER` (required): GitHub PR number to update description.
+
+## Prerequisites
+
+- `gh` CLI authenticated (`gh auth status`).
+- Evidence directory containing:
+  - `NN-name.txt` or `NN-name.json` text evidence files (e.g., `01-health-check.json`)
+  - `comment.md` — GitHub markdown body for both the issue comment and the PR description's `## Evidence` section.
+  - (Optional) `comment.txt` — kept for parity with the JIRA path; not used here.
+
+## Comment-body preflight (required)
+
+Before posting or updating anything, check the evidence body (`comment.md`, and `comment.txt` where this skill uses it):
+
+- It contains a `## Not established` heading. That heading is **never omitted and never blank** — when nothing is outstanding it still renders `None outstanding — reviewed`; otherwise it names, in plain operator language, what the verification did not prove.
+- The accompanying verdict carries `not_established_reviewed: true` (the list may be empty; the flag may never be omitted).
+- It contains a `## Artifact identity` heading carrying **values, not placeholders** — the repository, the `head_sha` the verification observed, the `environment`, and per artifact its `sha256` digest and `captured_at`. **Refuse to post** a body whose identity heading is absent or unpopulated, or whose recorded `artifact_head_sha` disagrees with the verdict's `artifact.head_sha` — report the evidence id and **both SHAs**. Definition: the `claim-evidence-mapping` rule.
+
+If either is missing, **refuse to post**: stop and report the missing Not-established review to the caller instead of publishing. Composing the body is `lisa-tracker-evidence`'s job (see its UI Evidence Checklist); this skill only refuses to publish one that omits the section. The section is defined by the `claim-evidence-mapping` rule and generalizes `lisa-improve-harness`'s required, never-empty `Known limits` field.
+
+## Workflow
+
+1. **Resolve refs**
+
+   Parse `ISSUE_REF` into `<issue-org>/<issue-repo>#<issue-number>`. Parse the local repo (where the PR lives) via `gh repo view --json nameWithOwner --jq '.nameWithOwner'`.
+
+2. **Ensure the `pr-assets` release exists in the IMPLEMENTATION repo**
+
+   The `pr-assets` release is the asset CDN for evidence files. Each PR's evidence is uploaded with the PR number prefix in the asset name to keep them addressable.
+
+   ```bash
+   gh release view pr-assets --repo <impl-org>/<impl-repo> >/dev/null 2>&1 \
+     || gh release create pr-assets --repo <impl-org>/<impl-repo> --title "PR Assets" --notes "CDN for PR evidence"
+   ```
+
+3. **Upload each evidence file**
+
+   ```bash
+   for f in "$EVIDENCE_DIR"/[0-9][0-9]-*.txt "$EVIDENCE_DIR"/[0-9][0-9]-*.json; do
+     [ -f "$f" ] || continue
+     name="pr-${PR_NUMBER}-$(basename "$f")"
+     gh release upload pr-assets --repo <impl-org>/<impl-repo> --clobber "$f#$name"
+   done
+   ```
+
+   The `#$name` syntax sets the asset name. `--clobber` lets re-runs overwrite.
+
+4. **Update the PR description**
+
+   Replace or append the `## Evidence` section in the PR body using `comment.md`:
+
+   ```bash
+   current_body=$(gh pr view "$PR_NUMBER" --repo <impl-org>/<impl-repo> --json body --jq '.body')
+   evidence_section=$(cat "$EVIDENCE_DIR/comment.md")
+   # Replace existing ## Evidence ... up to next ## or EOF; otherwise append.
+   ```
+
+   Use a Bash heredoc / temp file to compose the new body, then:
+
+   ```bash
+   gh pr edit "$PR_NUMBER" --repo <impl-org>/<impl-repo> --body-file /tmp/pr-body.md
+   ```
+
+5. **Post a comment on the originating issue**
+
+   The issue may live in a different repo than the PR (cross-repo work):
+
+   ```bash
+   gh issue comment <issue-number> --repo <issue-org>/<issue-repo> --body-file "$EVIDENCE_DIR/comment.md"
+   ```
+
+6. **Leave lifecycle labels unchanged**
+
+   GitHub evidence posting is evidence-only. The caller that owns the build lifecycle (`lisa-github-build-intake` / `lisa-github-agent`) transitions the issue from the configured `claimed` label directly to the configured `done` label after a successful build. Do not apply `status:code-review` here.
+
+## Evidence Naming Convention
+
+```text
+evidence/
+  01-health-check.json          uploaded
+  02-schema-after-migration.txt uploaded
+  03-rate-limit-response.txt    uploaded
+  comment.md                    used for issue comment + PR description
+```
+
+Asset names in the release are prefixed with `pr-<number>-` so multiple PRs' evidence coexists without collision.
+
+## Troubleshooting
+
+### Evidence not appearing in GitHub PR or issue
+
+Check:
+- `gh auth status` succeeds.
+- The PR / issue refs are correct.
+- The `pr-assets` release exists in the implementation repo.
+
+### `gh issue edit` returns 404
+
+The issue may live in a different repo than the PR — pass `--repo <issue-org>/<issue-repo>` explicitly. The implementation repo and the destination tracker repo can differ when `tracker = "github"` is set on a project that ships from a separate codebase.
+
+## Notes
+
+- This skill is symmetric with `lisa-jira-evidence` — the evidence directory layout and `comment.md` content are identical so a single template generator can serve both vendors.
+- The PR's `## Evidence` section is the canonical link for reviewers; the issue comment is for the PRD/PM thread.

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

@@ -0,0 +1,134 @@
+---
+name: lisa-github-journey
+description: "Parse a GitHub Issue's Validation Journey section, execute the verification steps using appropriate tools (curl, test commands, database queries), capture evidence at each marker, and post results via lisa-github-evidence. The GitHub counterpart of lisa-jira-journey."
+allowed-tools: ["Bash", "Read", "Glob", "Grep", "Skill"]
+---
+
+# GitHub Validation Journey
+
+Parse a GitHub Issue's Validation Journey, execute the verification steps using the appropriate tools for the change type, capture evidence at each canonical `[EVIDENCE: <artifact-type>: <name>]` marker (while still accepting the documented legacy untyped form), and post to the issue + GitHub PR.
+
+## Arguments
+
+`$ARGUMENTS`: `<ISSUE_REF> [PR_NUMBER]`
+
+- `ISSUE_REF` (required): GitHub issue ref — `org/repo#<number>` or full GitHub issue URL.
+- `PR_NUMBER` (optional): GitHub PR number for the implementation PR. If omitted, the skill auto-detects the PR from `lisa-github-read-issue`'s linked-PR list (preferring the most recent open PR).
+
+## Prerequisites
+
+- `gh` CLI authenticated.
+- Appropriate services running for the verification type (dev server, database, etc.).
+
+## Workflow
+
+### Step 1: Parse the Validation Journey
+
+```bash
+gh issue view <number> --repo <org>/<repo> --json body --jq '.body'
+```
+
+Extract the `## Validation Journey` section (plus its `### Prerequisites`, `### Steps`, and `### Assertions` sub-sections). Parse each step into a structured form: `{ index, text, evidence_marker (or null) }`.
+
+If the issue has no Validation Journey, stop and instruct the caller to run `/github-add-journey <issue-ref>` first.
+
+### Step 2: Satisfy Prerequisites
+
+Before starting the journey, verify each prerequisite:
+
+1. Check if required services are running (`curl localhost:<port>/health`, `pg_isready`, etc.).
+2. Verify database connectivity if the journey touches data.
+3. Ensure environment variables are set.
+4. Run any setup commands mentioned in `### Prerequisites`.
+
+### Step 3: Execute Steps and Capture Evidence
+
+Execute each step sequentially. Determine the verification approach based on the step text and the issue's change type (inferred from `type:` label, `component:` labels, and the body):
+
+- **API endpoints** → Run curl commands, capture HTTP response to `evidence/NN-name.txt` (or `.json`).
+- **Database changes** → Run psql/migration commands, capture schema output.
+- **Background jobs** → Trigger the job, check queue/state, capture logs.
+- **Library/utility changes** → Run tests, capture output.
+- **Security fixes** → Reproduce exploit attempt, verify fix, capture output.
+
+At each typed `[EVIDENCE: <artifact-type>: <name>]` marker, capture an artifact **of the declared type** — the type is the contract, not a suggestion:
+
+- `screenshot` / `recording` → an actual image/video file from the driven UI (Playwright, simulator), never a text description of what was seen
+- `http-transcript` → the exact request (curl command or client call) plus the full response
+- `cli-output` → the command plus stdout/stderr and exit code
+- `log-snippet` → the correlated log lines pulled from the running system
+- `db-query-output` → the query plus returned rows
+- `perf-trace` → the benchmark/frame-timing/profiler output with methodology (device profile, dataset size)
+- `test-run-log` → reporter output naming the spec and showing it ran and passed
+- `deploy-log` / `state-dump` → the deployment/health-check output or observed-state JSON
+
+A prose claim ("the error state rendered gracefully") satisfies no marker. Legacy untyped markers: infer the type from the step's action, capture accordingly, and note the inference. Write each artifact to a numbered file:
+
+Treat only exact `[EVIDENCE: ...]` markers (plus the legacy local `[SCREENSHOT: ...]` form) as capture instructions. Both the canonical `[EVIDENCE-REF: <work-item-ref> | <artifact-type>: <kebab-case-name>]` and the Lisa 2.223.0 legacy alias `[EVIDENCE-REF: <tracker-ref>: <artifact-type>: <kebab-case-name>]` point to another work item's artifact: preserve either as explanatory text, but do not capture it, assign it a sequence number, include it in duplicate-name checks, or count it as a local manifest entry. If a runtime-changing leaf has references but no local claiming marker, stop because S14 is unsatisfied.
+
+#### Evidence Naming Convention
+
+`{NN}-{evidence-name}.txt` (or `.json` for structured data):
+
+- `NN`: zero-padded sequential number (01, 02, 03...).
+- `evidence-name`: the `<name>` part of the typed marker (kebab-case).
+
+Example:
+
+```text
+evidence/
+  01-health-check.json
+  02-schema-after-migration.txt
+  03-rate-limit-response.txt
+  comment.md
+```
+
+### Step 4: Generate Evidence Templates
+
+Compose `evidence/comment.md` with:
+
+- The issue ref + title.
+- The PR ref.
+- Each evidence marker rendered as a GitHub markdown section with a fenced code block of the captured file.
+- An "Assertions verified" subsection mapping each `### Assertions` line to "PASS / FAIL".
+
+This template generator is shared with `lisa-jira-journey` (the JIRA path renders the same content as wiki markup). When the markdown comment is the canonical artifact, both vendors stay aligned.
+
+### Step 5: Post Evidence
+
+Use `lisa-github-evidence` to post everything:
+
+```bash
+# Equivalent of: bash scripts/post-evidence.sh — but invoked via the Skill tool
+```
+
+Invoke the skill with `<ISSUE_REF> ./evidence <PR_NUMBER>`. It uploads the files to the `pr-assets` release, edits the PR's `## Evidence` section, and posts a comment on the issue. The build-intake owner performs the direct `claimed` → `done` lifecycle transition after success.
+
+### Step 6: Verify
+
+Confirm:
+- Evidence files exist as release assets named `pr-<PR>-NN-name.{txt,json}`.
+- The PR description contains the `## Evidence` section with code-block embeds.
+- The issue has a new comment whose body matches `comment.md`.
+- The issue has the evidence comment, and the build-intake owner can transition it from `status:in-progress` directly to the configured `done` label.
+
+## Verification Patterns Reference
+
+| Change Type | Verification Method | Evidence Format |
+|---|---|---|
+| API endpoint | `curl -s localhost:PORT/endpoint` | JSON response |
+| Database migration | `psql -c "\d table"` or migration output | Schema text |
+| Background job | Trigger + check state | Log output |
+| Library/utility | `bun run test -- path/to/test` | Test output |
+| Security fix | Reproduce + verify fix | Request/response |
+| Auth/authz | Multi-role verification | Status codes per role |
+
+## Troubleshooting
+
+### Evidence file is empty
+
+Ensure the command succeeded and produced output. Use `2>&1` to capture both stdout and stderr.
+
+### Parser returns no steps
+
+The issue may not have a Validation Journey section — run `/github-add-journey <ISSUE_REF>` first.