@codyswann/lisa 4.72.1 → 4.72.2

package/plugins/lisa/.codex-plugin/skills/lisa-pull-request-review/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-pull-request-review
 description: "address and resolve the code…"
 allowed-tools: ["Read", "Bash", "Edit", "Write", "Glob", "Grep", "Skill"]
 ---
+This skill should be used to address and resolve the code review feedback on a pull request — human and bot (CodeRabbit, etc.). It fetches every unresolved review thread with its resolution state via GraphQL, triages each one, implements valid feedback (commit + push), replies to invalid/not-applicable feedback explaining why, and resolves every handled thread via the GraphQL resolveReviewThread mutation so branch-protection thread-resolution gates clear. Composable and chainable — runnable standalone via /lisa:pull-request:review or invoked inline by other skills (drive-pr-to-merge, verify) via the Skill tool.
+
 
 # Address & Resolve PR Review Comments
 

package/plugins/lisa/.codex-plugin/skills/lisa-quality-review/SKILL.md

@@ -2,6 +2,8 @@
 name: lisa-quality-review
 description: "Code quality review checklist"
 ---
+Code quality review checklist. Correctness, coding philosophy compliance, test coverage, documentation quality. Findings ranked by severity in plain English.
+
 
 # Quality Review
 

package/plugins/lisa/.codex-plugin/skills/lisa-queue-status/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-queue-status
 description: "Read-only operator surface for…"
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
+Read-only operator surface for the current project's PRD and build backlog health. Resolves the configured PRD source and build tracker from the same Lisa contract used by intake and repair, summarizes lifecycle-role counts, distinguishes idle queues from setup problems, and highlights actionable blocked, in-review, claimed, or shipped work.
+
 
 # Queue Status: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-remote-dispatch/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-remote-dispatch
 description: "Route one unit of work to a…"
 allowed-tools: ["Bash", "Read", "Skill"]
 ---
+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.
+
 
 # Remote Dispatch: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-repair-intake/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-repair-intake
 description: "Vendor-agnostic repair scanner…"
 allowed-tools: ["Skill", "Bash", "Read", "Write", "Edit"]
 ---
+Vendor-agnostic repair scanner — the recovery counterpart to lisa-intake. Finds work that got stuck or was left half-closed across the same queues lisa-intake serves (Notion / Confluence / Linear / GitHub PRDs; JIRA / GitHub / Linear build queues): items left in `blocked`, work stalled in an in-progress role (build `claimed`, PRD `in_review`), terminal-labeled items still natively open, and rollups whose children are all terminal. Repairs every actionable candidate up to `max_candidates`: resumes stalled work in place (diagnosing a stalled build's PR/deploy state first — merged PRs get the missed env transition, behind-base PRs are re-synced, unmergeable PRs or failed deploys get a build-ready fix ticket + `blocked`), re-validates blocked PRDs and build items whose blockers cleared, performs terminal native closure, and reconciles parent rollups to their derived state. Idempotent and loop-protected; never mutates `draft`/`verified` or `ready` leaves. A /schedule cron target alongside lisa-intake.
+
 
 # Repair Intake: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-reproduce-bug/SKILL.md

@@ -2,6 +2,8 @@
 name: lisa-reproduce-bug
 description: "How to reproduce a bug reliably…"
 ---
+How to reproduce a bug reliably and on the real path — choosing a reproduction method from the symptom, distinguishing prerequisites from behaviour-substituting scaffolding, and reporting the observed failure rate instead of rounding it.
+
 
 # Reproduce Bug
 

package/plugins/lisa/.codex-plugin/skills/lisa-research/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-research
 description: "Research a problem space and…"
 allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep"]
 ---
+Research a problem space and create a PRD in the configured PRD source. Investigates the codebase, defines user flows, assesses technical feasibility, synthesizes the spec, then creates it in the source (Notion / Confluence / GitHub / Linear per .lisa.config.json `source`) via lisa-prd-source-write — there is no loose document artifact. Vendor-agnostic. Accepts an optional `prd_ready` flag (default false → the PRD is created in the `draft` role; true → created `ready` so lisa-intake auto-claims it) and an optional dedupe `marker`/`dedupe_key` (used when invoked by lisa-project-ideation) so re-runs reference the existing PRD instead of duplicating it.
+
 
 # Research
 

package/plugins/lisa/.codex-plugin/skills/lisa-review-implementation/SKILL.md

@@ -2,6 +2,8 @@
 name: lisa-review-implementation
 description: "comparing a project's…"
 ---
+This skill should be used when comparing a project's Lisa-managed files against Lisa's source templates to identify drift. It reads the project manifest, locates source templates, generates diffs for drifted files, and offers to upstream improvements back to Lisa.
+
 
 # Lisa Implementation Review
 

package/plugins/lisa/.codex-plugin/skills/lisa-review-local/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-review-local
 description: "performing a code review on…"
 disable-model-invocation: false
 ---
+This skill should be used when performing a code review on local changes on the current branch compared to the main branch. It uses multiple parallel agents to check for bugs, CLAUDE.md compliance, git history context, previous PR comments, and code comment adherence, then scores and filters findings by confidence level.
+
 
 Provide a code review for the local changes on the current branch compared to the main branch.
 

package/plugins/lisa/.codex-plugin/skills/lisa-rework-triage/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-rework-triage
 description: "Rework detection and…"
 allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep"]
 ---
+Rework detection and agent-failure classification. When a claimed ticket turns out to be rework — previously implemented work bounced back from QA/staging — this skill detects it, classifies WHY the previous agent attempt failed (decomposition infidelity, PRD defect, missing tool access, implementation defect, environment/data, verification gap), posts a structured triage comment, and routes each cause to its hardening destination — including upstream Lisa issues so the harness itself gets fixed and the same mistake structurally cannot repeat. Vendor-neutral: consumes the lisa-tracker-read context bundle; invoked automatically by lisa-ticket-triage Phase 2.5 and runnable standalone.
+
 
 # Rework Triage: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-root-cause-analysis/SKILL.md

@@ -2,6 +2,8 @@
 name: lisa-root-cause-analysis
 description: "Prove what causes a defect…"
 ---
+Prove what causes a defect: hypotheses written down before evidence is gathered, positive confirmation by execution rather than by surviving a disproof, a symptom-keyed technique menu including git bisect, and a declared stopping point that escalates an unresolved verdict instead of drifting.
+
 
 # Root Cause Analysis
 

package/plugins/lisa/.codex-plugin/skills/lisa-secrets-access/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-secrets-access
 description: "Vendor-neutral access layer for…"
 allowed-tools: ["Bash", "Read", "Skill"]
 ---
+Vendor-neutral access layer for secrets. Every skill and script that needs an API key MUST resolve it through this skill rather than reading a keychain, an .env file, or a provider CLI directly. Models two independent axes — the provider a secret lives in (Bitwarden, 1Password, AWS Secrets Manager, Doppler, Vault) and the surface the code runs on (local, GitHub Actions, Codex Cloud) — resolving environment first, then a materialized file where the surface has one, then the provider by exact key name. Enforces one store per secret, fails closed on duplicate names, reads usage metadata from the provider's own note field, and never writes. Rotating credentials route through the separate rotate-secret writer, and copying one into a second store (Bitwarden → GitHub Actions) routes through the separate sync-secret-to-ci propagator.
+
 
 # Secrets Access: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-security-review/SKILL.md

@@ -2,6 +2,8 @@
 name: lisa-security-review
 description: "Security review methodology"
 ---
+Security review methodology. STRIDE threat modeling, OWASP Top 10 vulnerability checks, auth/validation/secrets handling review, and mitigation recommendations.
+
 
 # Security Review
 

package/plugins/lisa/.codex-plugin/skills/lisa-security-zap-scan/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-security-zap-scan
 description: "Run an OWASP ZAP baseline…"
 allowed-tools: ["Bash", "Read"]
 ---
+Run an OWASP ZAP baseline security scan locally using Docker. Checks for the ZAP baseline script, executes the scan, and summarizes findings by risk level with remediation recommendations.
+
 
 # OWASP ZAP Baseline Security Scan
 

package/plugins/lisa/.codex-plugin/skills/lisa-sentry-access/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-sentry-access
 description: "Vendor-neutral access layer for…"
 allowed-tools: ["Bash", "Read", "Skill"]
 ---
+Vendor-neutral access layer for Sentry. Sentry-oriented skills MUST delegate through this skill rather than calling Sentry MCP tools, sentry-cli, or REST directly. Per the credential-substrate-precedence contract, resolves SENTRY_AUTH_TOKEN (REST, or sentry-cli authenticated from the same token) first when present and identity-matched to the configured org/project, then falls back to the Sentry MCP.
+
 
 # Sentry Access: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-setup-atlassian/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-setup-atlassian
 description: "Configure Atlassian access for…"
 allowed-tools: ["Bash", "Read", "Write", "Edit", "Skill", "AskUserQuestion"]
 ---
+Configure Atlassian access for this project. Installs acli if missing, runs the OAuth or API-token login, optionally enables the Atlassian MCP, resolves the cloudId for the active site, and writes the `atlassian` section into `.lisa.config.json`. Prerequisite for /lisa:setup:jira and /lisa:setup:confluence (both need atlassian.cloudId). Idempotent — re-running updates the existing section rather than duplicating it.
+
 
 # Setup Atlassian: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-setup-automations/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-setup-automations
 description: "Set up the recurring Lisa…"
 allowed-tools: ["Skill", "Bash", "Read", "Write", "Edit"]
 ---
+Set up the recurring Lisa automations on the local workstation using the CURRENT runtime's native scheduler — Codex automations (the native automations / automation_update mechanism) or, on Claude, /schedule. This skill is a declarative specification: it states WHICH automations to create, how often, and with which parameters; it does not template schedule files or run scheduling code itself — the runtime's native automation mechanism does the creating. Creates six default automations: intake-repair (every 60 min), intake PRD (every 60 min), intake tickets (every 10 min), exploratory-bugs (once a day), exploratory-prds (once a day), monitor (once a day) — plus opt-in learnings-audit (once a week, the gardener). Three flags: auto-start-prds and auto-start-tickets control whether ideated PRDs / filed bug tickets are created auto-pickup-ready (prd_ready / ready, default true) or left for human review; learnings-audit (default false) opts into the weekly gardener loop. Tear down with /tear-down-automations.
+
 
 # Set up Lisa automations: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-setup-confluence/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-setup-confluence
 description: "Configure Confluence as the PRD…"
 allowed-tools: ["Bash", "Read", "Write", "Edit", "Skill", "AskUserQuestion"]
 ---
+Configure Confluence as the PRD source for this project. Writes `confluence.spaceKey` and/or `confluence.parentPageId` into `.lisa.config.json` and offers to set top-level `source: "confluence"`. Depends on /lisa:setup:atlassian — atlassian.cloudId must already be present. Idempotent.
+
 
 # Setup Confluence: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-setup-github/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-setup-github
 description: "Configure GitHub Issues as the…"
 allowed-tools: ["Bash", "Read", "Write", "Edit", "Skill", "AskUserQuestion"]
 ---
+Configure GitHub Issues as the destination tracker and/or the PRD source for this project. Verifies the gh CLI is installed and authenticated, resolves `org/repo`, scaffolds the build-queue label namespace (`status:*`) when GitHub is the tracker and/or the PRD-lifecycle label namespace (`prd-*` + sentinel) when GitHub is the PRD source, writes the `github` section into `.lisa.config.json`, and offers to set top-level `tracker: "github"` and/or `source: "github"`. Idempotent — re-running updates the existing section and reuses existing labels rather than duplicating. No /lisa:setup:atlassian prerequisite (GitHub auth is standalone).
+
 
 # Setup GitHub: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-setup-github-repo/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-setup-github-repo
 description: "Apply Lisa's GitHub repository…"
 allowed-tools: ["Bash", "Read", "Edit", "AskUserQuestion"]
 ---
+Apply Lisa's GitHub repository governance baseline to the current project's repo: repository settings (merge-only, auto-merge, delete-branch-on-merge, update-branch suggestions, wiki off, secret scanning where available), branch + tag rulesets from Lisa templates (base PR gate with CodeRabbit/GitGuardian/Quality Checks, prevent delete, protect tags, stack overlays), a write-access deploy key + DEPLOY_KEY secret so release workflows can push version bumps through the rulesets' DeployKey bypass, and optional deployment environments with human-approval gates (required reviewers) from the github.environments block in .lisa.config.json. Idempotent — re-running updates settings, rulesets, and environments in place and skips an already-configured deploy key.
+
 
 # Setup GitHub Repository Governance
 

package/plugins/lisa/.codex-plugin/skills/lisa-setup-jira/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-setup-jira
 description: "Configure JIRA as the…"
 allowed-tools: ["Bash", "Read", "Write", "Edit", "Skill", "AskUserQuestion"]
 ---
+Configure JIRA as the destination tracker for this project. Writes `jira.project` into `.lisa.config.json` and offers to set top-level `tracker: "jira"`. Depends on /lisa:setup:atlassian — atlassian.cloudId must already be present, otherwise this skill stops and instructs the user to run setup-atlassian first. Idempotent.
+
 
 # Setup JIRA: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-setup-kane/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-setup-kane
 description: "Configure TestMu Kane CLI as an…"
 allowed-tools: ["Bash", "Read", "Write", "Edit", "AskUserQuestion"]
 ---
+Configure TestMu Kane CLI as an optional Lisa empirical-browser provider. Performs the exterior human approval gate for mandatory cloud uploads, verifies the pinned CLI version, provisions local/CI authentication, selects a Test Manager project/folder, runs a disposable synthetic check, and writes only non-secret policy identifiers to Lisa config.
+
 
 # Setup Kane CLI
 

package/plugins/lisa/.codex-plugin/skills/lisa-setup-linear/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-setup-linear
 description: "Configure Linear as the…"
 allowed-tools: ["Bash", "Read", "Write", "Edit", "Skill", "AskUserQuestion", "mcp__linear-server__authenticate", "mcp__linear-server__complete_authentication"]
 ---
+Configure Linear as the destination tracker and/or the PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in OS keychain), resolves the workspace slug and team key, scaffolds the build-queue **workflow states** (`linear.workflow`) when Linear is the tracker and/or the PRD-lifecycle project-label namespace (`prd-*`) when Linear is the PRD source, writes the `linear` section into `.lisa.config.json`, and offers to set top-level `tracker: "linear"` and/or `source: "linear"`. Idempotent — re-running updates the existing section and reuses existing labels. No /lisa:setup:atlassian prerequisite.
+
 
 # Setup Linear: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-setup-local-env/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-setup-local-env
 description: "Bring a developer's machine in…"
 allowed-tools: ["Bash", "Read", "Skill"]
 ---
+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.
+
 
 # Setup Local Environment: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-setup-notion/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-setup-notion
 description: "Configure Notion as the PRD…"
 allowed-tools: ["Bash", "Read", "Write", "Edit", "Skill", "AskUserQuestion"]
 ---
+Configure Notion as the PRD source for this project. Walks the user through creating an internal integration in the target workspace, sharing the PRD database with it, stores the resulting `ntn_*` token in OS keychain (multi-workspace-safe — keyed by workspaceId), validates against the Notion API, and writes `notion.workspaceId`, `notion.prdDatabaseId`, and `notion.values` into `.lisa.config.json`. Idempotent — re-runs update the existing section rather than duplicating it. Offers to set top-level `source: "notion"`.
+
 
 # Setup Notion: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-setup-remote-aws/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-setup-remote-aws
 description: "Install and validate Lisa's…"
 allowed-tools: ["Bash", "Read", "Write", "Glob", "Grep"]
 ---
+Install and validate Lisa's drop-in AWS CLI bootstrap for remote coding environments. Supports Claude, Codex, Cursor, GitHub Copilot, Antigravity on user-managed hosts, OpenCode on user-managed hosts, and future Linux remote agents through one capability contract. Writes no secrets; it installs the common setup script, merges native Cursor/Copilot adapters, and emits exact operator guidance for the selected platform.
+
 
 # Set up remote-agent AWS access: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-setup-remote-env/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-setup-remote-env
 description: "Provision and verify a remote…"
 allowed-tools: ["Bash", "Read", "Write", "Edit", "Skill"]
 ---
+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.
+
 
 # Setup Remote Environment: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-setup-sonar/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-setup-sonar
 description: "Configure the official…"
 allowed-tools: ["Bash", "Read", "Write", "Edit", "AskUserQuestion", "Skill"]
 ---
+Configure the official SonarQube plugin + MCP as Lisa's single Sonar substrate across every supported coding agent. Installs/updates the SonarQube CLI, authenticates (browser login on a dev machine, or SONARQUBE_CLI_TOKEN headless), selects the Test Manager target, runs `sonar integrate <agent>` for each supported agent (Claude, Codex, Cursor, Copilot, Antigravity) and wires the MCP for OpenCode, then writes only non-secret policy to .lisa.config.json. Separate from the CI SonarCloud scan gate, which is unchanged.
+
 
 # Set up SonarQube (official plugin + MCP)
 

package/plugins/lisa/.codex-plugin/skills/lisa-setup-workstation/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-setup-workstation
 description: "Prepare a machine — a fresh…"
 allowed-tools: ["Bash", "Read", "Skill"]
 ---
+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.
+
 
 # Setup Workstation: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-sonarcloud-access/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-sonarcloud-access
 description: "Vendor-neutral access layer for…"
 allowed-tools: ["Bash", "Read", "Skill"]
 ---
+Vendor-neutral access layer for SonarQube Cloud/Server. Sonar triage skills MUST delegate through this skill rather than calling the SonarQube MCP tools directly. Preferred substrate: the official SonarQube MCP server (mcp__sonarqube__*), authenticated headlessly from SONARQUBE_CLI_TOKEN (+ SONARQUBE_CLI_ORG for Cloud, SONARQUBE_CLI_SERVER for Server); the Sonar Web API, authenticated with the same token, is the sanctioned fallback when the MCP is not wired on this surface.
+
 
 # SonarCloud Access: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-spec-conformance/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-spec-conformance
 description: "Verifies that shipped work…"
 allowed-tools: ["Read", "Glob", "Grep", "Bash", "Skill"]
 ---
+Verifies that shipped work matches its spec section-by-section — acceptance criteria, Out of Scope, Technical Approach, Validation Journey assertions, and any explicit deliverables. Builds a coverage matrix mapping each requirement to evidence, flags scope creep separately from misses, and produces a verdict (CONFORMS / PARTIAL / DIVERGES). Runs during the verification phase alongside empirical system verification.
+
 
 # Spec Conformance: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-starter-sync/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-starter-sync
 description: "Run one starter sync using…"
 allowed-tools: ["Bash", "Read", "Skill"]
 ---
+Run one starter sync using Lisa's existing engine and landing command. Also used by the opt-in daily starter-sync automation.
+
 
 # Sync the project's starter
 

package/plugins/lisa/.codex-plugin/skills/lisa-sync-down/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-sync-down
 description: "run a back-sync of an…"
 allowed-tools: ["Bash", "Read", "Edit", "Write", "Grep", "Glob"]
 ---
+This skill should be used to run a back-sync of an environment branch DOWN the deploy chain on demand — propagating merges (e.g. hotfixes) from a higher environment to every lower one. Given a source environment name or branch (e.g. `production`), it derives the source→target chain from `.lisa.config.json` `deploy.order` + `deploy.branches`, then for each downward hop creates a sync branch, merges, resolves conflicts, opens or updates a PR, and enables auto-merge. Runnable by a developer locally or by CI.
+
 
 # Sync Down Branches (on demand)
 

package/plugins/lisa/.codex-plugin/skills/lisa-task-decomposition/SKILL.md

@@ -2,6 +2,8 @@
 name: lisa-task-decomposition
 description: "Methodology for breaking work…"
 ---
+Methodology for breaking work into ordered tasks. Cross-repo source PRDs and coordination containers stay cross-repo; each buildable leaf task gets a single-repo scope, acceptance criteria, verification type, dependencies, and skills required.
+
 
 # Task Decomposition
 

package/plugins/lisa/.codex-plugin/skills/lisa-task-triage/SKILL.md

@@ -2,6 +2,8 @@
 name: lisa-task-triage
 description: "8-step task triage and…"
 ---
+8-step task triage and implementation workflow. Ensures tasks have clear requirements, dependencies, and verification plans before implementation begins.
+
 
 # Task Triage
 

package/plugins/lisa/.codex-plugin/skills/lisa-tdd-implementation/SKILL.md

@@ -2,6 +2,8 @@
 name: lisa-tdd-implementation
 description: "Test-Driven Development…"
 ---
+Test-Driven Development implementation workflow. RED: write failing test, GREEN: minimum code to pass, REFACTOR: clean up. Includes task metadata requirements, verification, and atomic commit practices.
+
 
 # TDD Implementation
 

package/plugins/lisa/.codex-plugin/skills/lisa-tear-down-automations/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-tear-down-automations
 description: "Remove recurring Lisa…"
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
+Remove recurring Lisa automations that /setup-automations registered for this project — either the whole lisa-auto-<project>-* fleet by default, or one named loop registration when approving a policy-obsolete proposal — using the CURRENT runtime's native scheduler — Codex automations or, on Claude, /schedule. This skill is a declarative specification: it identifies WHICH automations to remove; it does not run teardown scripts. Carries no fixed list of loops for fleet teardown: the registration set is the roster. Removes only this project's Lisa automations — never other projects' automations or non-Lisa ones. Leaves checked-in runbook files on disk. The inverse of /setup-automations.
+
 
 # Tear down Lisa automations: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-test-strategy/SKILL.md

@@ -2,6 +2,8 @@
 name: lisa-test-strategy
 description: "Test strategy design"
 ---
+Test strategy design. Coverage matrix, edge cases, TDD sequence planning, test quality review. Behavior-focused testing over implementation details.
+
 
 # Test Strategy
 

package/plugins/lisa/.codex-plugin/skills/lisa-ticket-triage/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-ticket-triage
 description: "Analytical triage gate for…"
 allowed-tools: ["Read", "Glob", "Grep", "Bash"]
 ---
+Analytical triage gate for tickets in the configured destination tracker (JIRA, GitHub Issues, or Linear). Detects requirement ambiguities, identifies edge cases from codebase analysis, plans verification methodology, and — via lisa-rework-triage in Phase 2.5 — detects rework bounced back from QA/staging and classifies why the previous agent attempt failed. Posts findings to the ticket and produces a verdict (DUPLICATE_ALREADY_FIXED/BLOCKED/PASSED_WITH_FINDINGS/PASSED) that gates whether implementation can proceed. Vendor-neutral: the caller (jira-agent or github-agent) is responsible for fetching the ticket via lisa-tracker-read, running the pre-flight gate via lisa-tracker-verify, and posting findings via the matching vendor comment tool.
+
 
 # Ticket Triage: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-track/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-track
 description: "Resolves exactly one live…"
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
+Resolves exactly one live configured-tracker leaf for durable project work, claims it idempotently, and persists its canonical reference in worktree-local state. Accepts an existing Jira/GitHub/Linear ref, a spec file, or plain text. Also accepts human_gate: <why a human must judge this first>, which files the leaf held — outside the build-ready lane, never claimed — instead of build-ready. Use directly to mention/create the related ticket, and as lisa-implement's mandatory input gate.
+
 
 # Track Work: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-tracker-add-journey/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-tracker-add-journey
 description: "Vendor-neutral wrapper for…"
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
+Vendor-neutral wrapper for appending a Validation Journey section to an existing ticket/issue. Reads the required `tracker` from .lisa.config.json and dispatches to lisa-jira-add-journey, lisa-github-add-journey, or lisa-linear-add-journey.
+
 
 # Tracker Add Journey: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-tracker-build-intake/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-tracker-build-intake
 description: "Vendor-neutral wrapper for the…"
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
+Vendor-neutral wrapper for the build-queue scanner. Reads the required `tracker` from .lisa.config.json and dispatches to lisa-jira-build-intake (JQL/project-key queue), lisa-github-build-intake (GitHub repo queue keyed off the `status:ready` label), or lisa-linear-build-intake (Linear team queue keyed off the configured `ready` workflow state). Every vendor scanner processes at most one eligible item per cycle and enforces the claim-time arm of the `leaf-only-lifecycle` rule — dispatch leaf work units only; move or safe-block a container with open child work (or a childless Epic) that carries a stale build-ready role according to the vendor's lifecycle semantics. Counterpart to lisa-intake's PRD-side dispatchers.
+
 
 # Tracker Build Intake: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-tracker-claim/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-tracker-claim
 description: "Vendor-neutral dispatcher for…"
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
+Vendor-neutral dispatcher for idempotently claiming one already live-validated leaf work item. Reads the required tracker from .lisa.config.json and delegates to lisa-jira-claim, lisa-github-claim, or lisa-linear-claim. The vendor skill owns the post-read leaf/open guard, ready-to-claimed mutation, attributable assignment, and post-write verification.
+
 
 # Tracker Claim: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-tracker-create/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-tracker-create
 description: "Vendor-neutral wrapper for…"
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
+Vendor-neutral wrapper for creating tickets/issues from code files or descriptions. Reads the required `tracker` from .lisa.config.json and dispatches to lisa-jira-create, lisa-github-create, or lisa-linear-create. Plans hierarchy structure (epic / story / sub-task), then delegates each individual write through the tracker-write shim.
+
 
 # Tracker Create: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-tracker-evidence/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-tracker-evidence
 description: "Vendor-neutral wrapper for…"
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
+Vendor-neutral wrapper for posting verification evidence. Reads the required `tracker` from .lisa.config.json and dispatches to lisa-jira-evidence, lisa-github-evidence, or lisa-linear-evidence. Uploads evidence to the GitHub `pr-assets` release, updates the PR description, posts a comment on the originating ticket/issue, and leaves workflow transitions to the tracker-specific lifecycle owner.
+
 
 # Tracker Evidence: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-tracker-journey/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-tracker-journey
 description: "Vendor-neutral wrapper for…"
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
+Vendor-neutral wrapper for executing a ticket/issue's Validation Journey end-to-end. Reads the required `tracker` from .lisa.config.json and dispatches to lisa-jira-journey, lisa-github-journey, or lisa-linear-journey. Parses the journey, satisfies prerequisites, executes the steps, captures evidence at each marker, and posts results via tracker-evidence.
+
 
 # Tracker Journey: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-tracker-read/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-tracker-read
 description: "Vendor-neutral wrapper for…"
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
+Vendor-neutral wrapper for fetching the full scope of a ticket/issue and its related graph. Reads the required `tracker` from .lisa.config.json and dispatches to lisa-jira-read-ticket, lisa-github-read-issue, or lisa-linear-read-issue. Returns a consolidated context bundle so downstream agents never act on a single ticket in isolation.
+
 
 # Tracker Read: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-tracker-source-artifacts/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-tracker-source-artifacts
 description: "Canonical, vendor-neutral…"
 allowed-tools: []
 ---
+Canonical, vendor-neutral taxonomy and rules for handling source artifacts (Figma, Lovable, Loom, screenshots, design docs, data samples) when generating or evaluating tracker tickets (JIRA, GitHub Issues, Linear). Defines: (1) artifact domains, (2) classification rules per tool, (3) source precedence (which artifact is authoritative for which question), (4) inheritance from epic to story to sub-task, (5) cross-axis conflict handling. Invoke this skill from any flow that extracts, attaches, or reasons about external design/UX/data artifacts so the rules don't drift across skills.
+
 
 # Tracker Source Artifact Taxonomy and Rules
 

package/plugins/lisa/.codex-plugin/skills/lisa-tracker-sync/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-tracker-sync
 description: "Vendor-neutral wrapper for…"
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
+Vendor-neutral wrapper for posting milestone updates to the linked ticket/issue. Reads the required `tracker` from .lisa.config.json and dispatches to lisa-jira-sync, lisa-github-sync, or lisa-linear-sync. Posts at: plan created, implementation in progress, PR ready, PR merged. Suggests (never auto-transitions) the next status.
+
 
 # Tracker Sync: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-tracker-validate/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-tracker-validate
 description: "Vendor-neutral wrapper for the…"
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
+Vendor-neutral wrapper for the pre-write quality gate. Reads the required `tracker` from .lisa.config.json and dispatches to lisa-jira-validate-ticket, lisa-github-validate-issue, or lisa-linear-validate-issue. Read-only — never writes to any tracker. Used by tracker-write Phase 5.5 (pre-write gate), tracker-verify (post-write checks), and the *-to-tracker dry-run paths. Output is structured PASS/FAIL per gate so callers can parse it.
+
 
 # Tracker Validate: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-tracker-verify/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-tracker-verify
 description: "Vendor-neutral wrapper for the…"
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
+Vendor-neutral wrapper for the post-write verification gate. Reads the required `tracker` from .lisa.config.json and dispatches to lisa-jira-verify, lisa-github-verify, or lisa-linear-verify. Fetches the live ticket/issue and runs the validator gates against the stored state — catches anything dropped or reformatted on write. Read-only.
+
 
 # Tracker Verify: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-tracker-write/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-tracker-write
 description: "Vendor-neutral wrapper for…"
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
+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.
+
 
 # Tracker Write: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-usage-accounting/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-usage-accounting
 description: "Shared usage-ledger utility for…"
 allowed-tools: ["Skill", "Read", "Bash"]
 ---
+Shared usage-ledger utility for Lisa lifecycle flows and artifact writers. Delegates all direct-entry recording and rollup refreshes through one vendor-neutral contract so PRDs, tickets, evidence comments, PRs, and markdown artifacts preserve the canonical `## Lisa Usage` section instead of inventing per-flow formats.
+
 
 # Usage Accounting: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-use-the-product/SKILL.md

@@ -2,6 +2,8 @@
 name: lisa-use-the-product
 description: "Shared methodology for actually…"
 ---
+Shared methodology for actually USING a project's product the way its real end user would — across product types (DOM web app, HTTP/API backend, canvas game, CLI/library, IaC/CDK). Detects the product's consumer-facing interface, drives it as that consumer, gated by a per-environment mutation policy read from .lisa.config.json (so the agent never mutates production data by accident), and lensed through the project's personas/subagents when it defines them. Invoked by exploratory-qa (files defect/UX tickets) and product-walkthrough (grounds planning in the live product); rarely run standalone.
+
 
 # Use the Product
 

package/plugins/lisa/.codex-plugin/skills/lisa-validate-tracker-mapping/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-validate-tracker-mapping
 description: "Detect and repair drift between…"
 allowed-tools: ["Skill", "Bash", "Read", "Write", "Edit", "AskUserQuestion"]
 ---
+Detect and repair drift between a project's configured Lisa status/label mappings and the live tracker/source workflow. Compares every lifecycle role in `.lisa.config.json` (JIRA `jira.workflow` statuses, GitHub/Linear `labels.{build,prd}`, Notion `notion.values` select options, Confluence `confluence.parents`) against the authoritative live names the access layer reports — catching renames, deletions, and case drift (e.g. config `On Stg` vs live `ON STG`). Read-only by default; `repair=true` rewrites the config to the canonical live names (config is fixed, never the tracker). Also audits the vocabularies no config key declares: `repo:` scope, where an item scoped only by an alias is valid yet invisible to every `repo:<name>` scan (DRIFTED), and `type:`/`priority:`/`component:`/`points:` smells (advisory). Neither is auto-repaired. Audits the current repo by default, or sweeps a set of projects via `projects=<glob>` / `workspaces=<file>`. Safe to schedule for continuous drift detection.
+
 
 # Validate Tracker Mapping: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-verification-lifecycle/SKILL.md

@@ -2,6 +2,8 @@
 name: lisa-verification-lifecycle
 description: "Verification lifecycle: confirm…"
 ---
+Verification lifecycle: confirm quality gates, classify types, discover tools, fail fast, plan, execute, codify (turn each passing verification into a regression test), spec conformance (verify shipped work matches the spec), loop. Quality gates (tests/typecheck/lint) are prerequisites, NOT verification. Verification means running the actual system and observing results.
+
 
 # Verification Lifecycle
 

package/plugins/lisa/.codex-plugin/skills/lisa-verify/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-verify
 description: "Ship and verify code"
 allowed-tools: ["Skill", "Bash", "Read", "Grep", "Glob"]
 ---
+Ship and verify code. Commits any pending changes, opens or updates the PR, handles the review loop, merges when green, monitors the deploy, and runs remote verification (health checks, Validation Journey replay, Sentry/log inspection) in the target environment. Folds in the legacy /ship alias.
+
 
 # Verify: $ARGUMENTS