plugins/lisa-cursor/skills/linear-verify/SKILL.md
Verifies a Linear work item meets organizational standards by fetching the live item and running it through lisa:linear-validate-issue. Catches anything dropped or reformatted on write — same gates as the pre-write check, but applied to what Linear actually stored. Read-only.
npx skillsauth add codyswanngt/lisa linear-verifyInstall 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.
Fetch the live Linear work item and run it through lisa:linear-validate-issue. This catches any field that was dropped or reformatted between the pre-write spec and what Linear stored.
This skill is the destination of the lisa:tracker-verify shim when tracker = "linear". Read-only — never writes.
Reads linear.workspace, linear.teamKey from .lisa.config.json (with .local override).
$ARGUMENTS is a Linear identifier:
ENG-123)https://linear.app/<workspace>/project/<slug>-<id>)If $ARGUMENTS is not parseable, stop and report.
linear.workspace, linear.teamKey from .lisa.config.json (with .local override).mcp__linear-server__list_teams({query: <teamKey>}).<TEAM>-<n> → Issue/project/<slug>-<id> → ProjectCall mcp__linear-server__get_issue (for Issues) or mcp__linear-server__get_project (for Projects). Capture every field, label, relation, comment, milestone, and project membership.
Pass the fetched item to lisa:linear-validate-issue (in identifier mode — let it derive the spec from the live state). The validator runs both Specification AND Feasibility gates against what Linear actually stored.
Return the validator's report verbatim — same structured format as lisa:linear-validate-issue. Callers (especially lisa:linear-write-issue Phase 7) parse the verdict to decide whether to declare success.
If the verdict is FAIL, the caller should fix the item and re-run verify. Never declare success on a FAIL verdict.
get_issue / get_project returns an access error, surface it and exit — don't pretend the item is fine.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.