codyswanngt/linear-evidence
plugins/lisa/skills/linear-evidence/SKILL.md
Uploads text evidence to the GitHub `pr-assets` release, updates the PR description, posts a comment on the originating Linear Issue with code blocks, and transitions the Issue from the configured `claimed` label to the configured `review` label. Reusable by any skill that captures evidence and generates evidence/comment.txt + evidence/code-blocks.md. Linear counterpart of lisa:jira-evidence and lisa:github-evidence.
$ install --global
skillsauthnpx skillsauth add codyswanngt/lisa linear-evidenceInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: May 27, 2026, 4:15 AM178.6s2 files scanned
SKILL.md
- name:
- linear-evidence
- description:
- Uploads text evidence to the GitHub `pr-assets` release, updates the PR description, posts a comment on the originating Linear Issue with code blocks, and transitions the Issue from the configured `claimed` label to the configured `review` label. Reusable by any skill that captures evidence and generates evidence/comment.txt + evidence/code-blocks.md. Linear counterpart of lisa:jira-evidence and lisa:github-evidence.
- allowed-tools:
- ["Bash", "Skill", "mcp__linear-server__list_teams", "mcp__linear-server__get_issue", "mcp__linear-server__save_issue", "mcp__linear-server__save_comment", "mcp__linear-server__list_issue_labels", "mcp__linear-server__create_issue_label"]
Linear Evidence: $ARGUMENTS
Post verification evidence to a Linear Issue and transition it from the configured claimed build label to the configured review build label. This skill is the destination of the lisa:tracker-evidence shim when tracker = "linear".
$ARGUMENTS is the Linear Issue identifier (e.g. ENG-123) and the path to the evidence directory. Caller passes both: <IDENTIFIER> <evidence-dir>.
Workflow resolution
The claimed and review build labels are read from .lisa.config.json linear.labels.build.*, falling back to the defaults documented in the config-resolution rule (status:in-progress and status:code-review).
read_role() {
local role="$1" default="$2"
local local_v global_v
local_v=$(jq -r ".linear.labels.build.${role} // empty" .lisa.config.local.json 2>/dev/null)
global_v=$(jq -r ".linear.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")
Configuration
Reads linear.workspace, linear.teamKey, and linear.labels.build.* from .lisa.config.json (with .local override).
Inputs (in <evidence-dir>)
The caller must produce:
evidence/comment.txt— the human-readable comment body posted on the Linear Issue.evidence/code-blocks.md— fenced code blocks (test outputs, command output, log excerpts) appended to the comment.evidence/files/(optional) — any text files that should be uploaded to the GitHubpr-assetsrelease for permalink-style references.
If any of these are missing, stop and report.
Phase 1 — Resolve Linear Issue
- Parse the identifier from
$ARGUMENTS. - Fetch via
mcp__linear-server__get_issueto confirm it exists and capture its current state, label set, and Project membership.
Phase 2 — Upload Evidence Files (optional)
If evidence/files/ is non-empty, upload each text file to the GitHub pr-assets release on the current repo via gh release upload. The release is the permalink store — keeps the Linear comment lightweight while preserving large outputs.
For each uploaded file, capture the public release URL.
Phase 3 — Update PR Description
If a PR is open on the current branch (gh pr view --json url,number,body 2>/dev/null), append an "Evidence" section to its description with:
- The Linear identifier and URL (constructed as
https://linear.app/<workspace>/issue/<IDENTIFIER>). - Links to any uploaded evidence files.
- A short summary line (first 2 lines of
evidence/comment.txt).
If no PR is open, skip this phase.
Phase 4 — Post Linear Comment
Call mcp__linear-server__save_comment({issueId: <id>, body: <body>}) where <body> is:
[<comment.txt contents verbatim>]
<details>
<summary>Evidence</summary>
[<code-blocks.md contents verbatim>]
</details>
[<bullet list of uploaded evidence file URLs, if any>]
Linear comments support markdown including <details> collapsibles, fenced code, and links — preserve the formatting.
Phase 5 — Transition Status
Update labels via mcp__linear-server__save_issue to remove $CLAIMED and add $REVIEW. Resolve label IDs first via mcp__linear-server__list_issue_labels (create the label via create_issue_label if it doesn't exist on the team).
The native Linear state field is also updated to the team's "In Review" state if one exists — but the label remains the source of truth for cross-team consistency.
Phase 6 — Report
Return:
- Linear Issue URL with new label state
- PR URL (if updated)
- List of uploaded evidence file URLs
Rules
- Never modify the Issue description as part of evidence posting — comments only. Description edits go through
lisa:linear-write-issue. - Never skip the label transition. The build queue is keyed off the configured
linear.labels.build.*labels; an item that ships without transitioning is invisible to monitoring. - If
mcp__linear-server__save_commentfails, retry once. If it fails again, surface the error — don't pretend the comment was posted. - Do not delete prior comments. The history is the audit trail.
Related Skills
codyswanngt/lisa-wiki-onboard-me
documentation
VerifiedTrustedCommunity
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.
1SKILL.mdUpdated Jun 5, 2026
codyswanngt/lisa-wiki-migrate
documentation
VerifiedTrustedCommunity
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.
1SKILL.mdUpdated Jun 5, 2026
codyswanngt/lisa-wiki-lint
development
VerifiedTrustedCommunity
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.
1SKILL.mdUpdated Jun 5, 2026
codyswanngt/lisa-wiki-ingest
testing
VerifiedTrustedCommunity
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.
1SKILL.mdUpdated Jun 5, 2026