plugins/src/base/skills/linear-journey/SKILL.md
Parse a Linear Issue's Validation Journey section, execute the verification steps using appropriate tools (curl, test commands, database queries, Playwright), capture evidence at each [EVIDENCE: name] marker, and post to Linear + GitHub PR using the linear-evidence skill. Linear counterpart of lisa:jira-journey.
npx skillsauth add codyswanngt/lisa linear-journeyInstall 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.
Parse a Linear Issue's Validation Journey, execute the verification steps using the appropriate tools for the change type, capture evidence at each [EVIDENCE: name] marker, and post to Linear + GitHub PR.
This skill is the destination of the lisa:tracker-journey shim when tracker = "linear".
Reads linear.workspace, linear.teamKey from .lisa.config.json (with .local override).
$ARGUMENTS: <IDENTIFIER> [PR_NUMBER]
IDENTIFIER (required): Linear Issue identifier (e.g. ENG-123)PR_NUMBER (optional): GitHub PR number to update descriptiongh CLI authenticatedFetch the Issue via mcp__linear-server__get_issue and extract the ## Validation Journey section from the markdown description. Parse:
### Prerequisites — list of required services / env / setup### Steps — numbered steps, each potentially containing [EVIDENCE: name] markers### Assertions — what must be true after verificationIf the section is missing or has no steps, report "No Validation Journey on <IDENTIFIER>. Run /linear-add-journey first." and stop.
Before executing steps, verify each prerequisite:
Stop and report if any prerequisite is not satisfied.
Execute each step sequentially. Determine the verification approach based on the step text and change type:
evidence/NN-name.txt (or .json for structured data)At each [EVIDENCE: name] marker, capture stdout / stderr to a numbered file:
{NN}-{evidence-name}.{ext}
NN: zero-padded sequential number (01, 02, 03...)evidence-name: the value from [EVIDENCE: name]ext: .txt for plain output, .json for structured dataExample:
evidence/
01-health-check.json
02-schema-after-migration.txt
03-rate-limit-response.txt
comment.txt
code-blocks.md
After capturing all evidence, build:
evidence/comment.txt — human-readable summary of the verification (Linear comment body, markdown-supported)evidence/code-blocks.md — fenced code blocks containing the captured evidence outputs (appended below comment.txt inside a <details> block)Invoke lisa:linear-evidence with <IDENTIFIER> ./evidence to:
pr-assets release (if files present in evidence/files/).comment.txt + collapsible code-blocks.md).status:in-progress, add status:code-review.Confirm:
status:* label transitioned to code-review.Use patterns from the project's verification.md:
| 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 |
| UI / frontend | Playwright browser_* MCP tools | Screenshot + DOM |
Ensure the command succeeded and produced output. Use 2>&1 to capture both stdout and stderr.
The Issue may not have a Validation Journey section. Run /linear-add-journey <IDENTIFIER> to add one.
Ensure status:in-progress and status:code-review exist on the team. lisa:linear-evidence creates them on demand if missing.
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.