plugins/lisa-cursor/skills/lisa-tracker-write/SKILL.md
Vendor-neutral wrapper for ticket creation and updates. Reads the required `tracker` from .lisa.config.json and dispatches to lisa-jira-write-ticket, lisa-github-write-issue, or lisa-linear-write-issue. Callers in vendor-neutral skills (notion-to-tracker, linear-to-tracker, confluence-to-tracker, github-to-tracker, implement, verify) MUST invoke this skill instead of the vendor-specific ones — that is what makes the tracker switchable per project. The Phase-5.5 validate-pre-write gate, post-write verify, and Phase-8 announce-comment behavior live in the vendor skills; this shim is dispatch only.
npx skillsauth add codyswanngt/lisa lisa-tracker-writeInstall 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.
Thin dispatcher. Resolves the configured destination tracker and delegates to the matching vendor write skill.
When the incoming description/body already contains the canonical ## Lisa Usage ledger, the vendor
writer must preserve that managed section on update and use the lisa-lisa-usage-accounting contract for any
body-vs-comment fallback. This shim only routes — it never edits tracker artifacts itself.
See the config-resolution rule for the full configuration schema and skill-mapping table.
Resolve tracker config
Read .lisa.config.local.json first (if present), then .lisa.config.json. Local overrides global on a per-key basis. Use jq — never hand-parse JSON.
local_tracker=$(jq -r '.tracker // empty' .lisa.config.local.json 2>/dev/null)
global_tracker=$(jq -r '.tracker // empty' .lisa.config.json 2>/dev/null)
tracker="${local_tracker:-$global_tracker}"
Validate the value
"No tracker configured in .lisa.config.json. Run /lisa:setup:jira, /lisa:setup:github, or /lisa:setup:linear first."jira → confirm atlassian.cloudId and jira.project are present. If either is missing, stop and report: "tracker=jira but atlassian.cloudId and jira.project are not set in .lisa.config.json." Continue to Step 3a.github → confirm github.org and github.repo are present. If either is missing, stop and report: "tracker=github but github.org and github.repo are not set in .lisa.config.json." Continue to Step 3b.linear → confirm linear.workspace and linear.teamKey are present. If either is missing, stop and report: "tracker=linear but linear.workspace and linear.teamKey are not set in .lisa.config.json." Continue to Step 3c."Unknown tracker '<value>' in .lisa.config.json. Expected 'jira', 'github', or 'linear'."Dispatch
lisa-jira-write-ticket via the Skill tool, passing $ARGUMENTS verbatim.lisa-github-write-issue via the Skill tool, passing $ARGUMENTS verbatim.lisa-linear-write-issue via the Skill tool, passing $ARGUMENTS verbatim.Surface the vendor skill's output unchanged. Do not paraphrase; downstream callers parse the structured response.
## Lisa Usage section in this shim.
Writer-specific preservation logic belongs in the vendor writers and follows the
lisa-lisa-usage-accounting contract.{jira, github, linear}.$ARGUMENTS between layers. The vendor skills define their own input contract.lisa-jira-validate-ticket / lisa-github-validate-issue / lisa-linear-validate-issue); this skill only routes.ready-role-filing rule, an omitted build_ready is not build-ready on every vendor, so a caller filing work it expects build-intake to pick up must pass build_ready: true, and a caller deliberately holding work outside the queue must pass a human_gate reason. This shim normalizes nothing — it forwards $ARGUMENTS verbatim and the vendor writers enforce the contract — which is exactly why the caller cannot rely on a vendor default here.development
Prepare a machine — a fresh laptop or a throwaway container — to run coding agents, before any repository exists. Detects which of Lisa's supported agents (Claude Code, Codex, Cursor, OpenCode, Antigravity, Copilot) are already installed, asks which credential manager the machine uses (Bitwarden, 1Password, Doppler, Vault, AWS, or none), and installs only what is missing, each by its vendor's own preferred method. Idempotent, headless by default, and emits a Dockerfile for a spin-up/spin-down environment. Run it on a new machine, in a container, or before cloning anything.
tools
Provision and verify a remote execution environment for a host project — Codex Cloud today, other remote surfaces as they are added. Generates a repository-owned setup script that installs the declared toolchain, materializes secrets through lisa-secrets-access, and runs the project's own hook. Provisions by API where one exists, by driving the vendor console where one does not, and by emitting exact config otherwise — then proves the result with the same read-back regardless of which tier did the work. Use before dispatching any work with executionEnv.
tools
Bring a developer's machine in line with the toolchain the project declares. Reports every tool in remoteEnv.tools that is missing, outdated, or unpinned for this platform, and installs the missing ones into ~/.local/bin from the same pinned, checksummed entries the remote surfaces use — but only when asked. Same manifest, same pins, same installers as lisa-setup-remote-env; what differs is consent and that the pin is a floor rather than an equality. Run it on a fresh checkout, after a manifest change, or when a tool fails at the moment of use.
tools
Route one unit of work to a remote execution surface. Reads the executionEnv parameter (local by default, codex-cloud or claude-web today), verifies the environment is provisioned and bound to this repository, submits a thin skill invocation, records the task identifier to .lisa/remote-dispatch.json, and exits without polling. Routing only — the remote runs the identical skill from the identical repository. Composable and inline: other skills invoke it via the Skill tool rather than users calling it directly.