plugins/lisa-agy/skills/github-evidence/SKILL.md
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.
npx skillsauth add codyswanngt/lisa github-evidenceInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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: <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.gh CLI authenticated (gh auth status).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.comment.txt — kept for parity with the JIRA path; not used here.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'.
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.
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"
Upload each evidence file
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.
Update the PR description
Replace or append the ## Evidence section in the PR body using comment.md:
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:
gh pr edit "$PR_NUMBER" --repo <impl-org>/<impl-repo> --body-file /tmp/pr-body.md
Post a comment on the originating issue
The issue may live in a different repo than the PR (cross-repo work):
gh issue comment <issue-number> --repo <issue-org>/<issue-repo> --body-file "$EVIDENCE_DIR/comment.md"
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/
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.
Check:
gh auth status succeeds.pr-assets release exists in the implementation repo.gh issue edit returns 404The 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.
lisa:jira-evidence — the evidence directory layout and comment.md content are identical so a single template generator can serve both vendors.## Evidence section is the canonical link for reviewers; the issue comment is for the PRD/PM thread.documentation
Onboard a user to the project via its LLM Wiki. Interviews the user about themselves in relation to the project, captures that to project-scoped memory only, then gives a guided tour of what the project is and sample questions they can ask. Use when someone is new to the project or asks to be onboarded. Read-mostly — it does not open PRs or write PII into the wiki.
documentation
Migrate an existing, hand-rolled wiki implementation onto the lisa-wiki kernel — phased and compatibility-first, with a strict no-loss guarantee. Use when adopting lisa-wiki in a repo that already has its own wiki/, ingest skills, docs, or roles. Renaming things into the canonical shape is fine; losing functionality or data is not. Ends by running /doctor.
development
Health-check the LLM Wiki. Reports orphan pages, contradictions, stale claims, broken internal links, missing index/log coverage, structure-manifest violations, and secret/tenant leaks. Use periodically or before hardening a wiki. Read-only — it reports findings, it does not fix them.
testing
Ingest source material into the LLM Wiki. With an argument (URL, file path, or prompt) it ingests that one source; with no argument it runs a full ingest across every enabled non-external-write source. Routes to the right connector, then runs the ordered pipeline (source note → synthesis → index → log → verify → state → commit/PR). Use whenever new knowledge should enter the wiki.