@codyswann/lisa 4.72.1 → 4.72.3

package/package.json

@@ -189,7 +189,7 @@
     "qs": "^6.16.0"
   },
   "name": "@codyswann/lisa",
-  "version": "4.72.1",
+  "version": "4.72.3",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {
@@ -345,7 +345,7 @@
     "test": "tests"
   },
   "types": "./dist/index.d.ts",
-  "lisaReleaseCommit": "d66dbfd4f3d4846f25e4473eba6e72e92a011c8b",
-  "gitHead": "d66dbfd4f3d4846f25e4473eba6e72e92a011c8b",
-  "lisaReleaseTag": "v4.72.1"
+  "lisaReleaseCommit": "6aa53989b5ac02e12de038c42a47ada07a57e853",
+  "gitHead": "6aa53989b5ac02e12de038c42a47ada07a57e853",
+  "lisaReleaseTag": "v4.72.3"
 }

package/plugins/lisa/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "4.72.1",
+  "version": "4.72.3",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "4.72.1",
+  "version": "4.72.3",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/.codex-plugin/skills/lisa-acceptance-criteria/SKILL.md

@@ -2,6 +2,8 @@
 name: lisa-acceptance-criteria
 description: "Acceptance criteria definition"
 ---
+Acceptance criteria definition. Gherkin user flows (Given/When/Then), error states, UX concerns, and empirical verification from the user perspective.
+
 
 # Acceptance Criteria
 

package/plugins/lisa/.codex-plugin/skills/lisa-agent-design-best-practices/SKILL.md

@@ -2,6 +2,8 @@
 name: lisa-agent-design-best-practices
 description: "Best practices for designing…"
 ---
+Best practices for designing Claude Code agent files (.claude/agents/*.md). This skill should be used when writing or reviewing agent markdown files to ensure proper design with focused domains, correct tool access, reusable definitions, and separation of capabilities from lifecycle. Combines Anthropic's official guidance with battle-tested patterns from agent team usage.
+
 
 # Agent Design Best Practices
 

package/plugins/lisa/.codex-plugin/skills/lisa-agent-ready/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-agent-ready
 description: "Make a brownfield project…"
 allowed-tools: ["Skill", "Bash", "Read", "Write", "Edit", "Glob", "Grep", "WebFetch"]
 ---
+Make a brownfield project agent-ready: build the initial knowledge wiki from read-only, redacted ingestion of every inventoried source (repository, git history, connected trackers, docs, observability), then write wiki/gaps.md — the questions only a human can answer before agents can operate the project autonomously. Iterative convergence: humans answer the gaps inline, a fresh session re-runs the skill, verified answers are absorbed into wiki pages, and the loop repeats until every source is complete, zero open gaps remain, and the project is declared agent-ready. This is the knowledge half of brownfield onboarding; standards adoption (applying Lisa's lint rules, guardrails, and thresholds, then refactoring to conform without changing behavior) follows it.
+
 
 # Agent-Ready Onboarding: $ARGUMENTS
 

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

@@ -3,6 +3,8 @@ name: lisa-analyze-claude-remote
 description: "Audit whether the current…"
 allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep"]
 ---
+Audit whether the current repository can run as a Claude Code remote routine (cloud session). Read-only analysis that inventories what Lisa AND the host project need to configure or build in the cloud environment — external CLIs/binaries to install, environment variables and secrets to set, startup hooks and their headless-safety, MCP server scope/transport/auth, user-scoped config and auto-memory gaps that don't replicate to the cloud, and platform constraints (bun proxy, IP allowlist, network tier, no interactivity). Reads `.lisa.config.json` `tracker`/`source` to determine which tracker/PRD-source integrations are active, resolves each to its headless-viable substrate (CLI/curl + token, never browser-OAuth MCP, never OS-keychain), and spells out the exact secret env vars, where to obtain each token, and the precise access scope required — without guessing. Emits grouped findings plus a machine-readable inventory that /lisa:generate-claude-remote-build-script consumes.
+
 
 # Analyze Claude Remote: $ARGUMENTS
 

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

@@ -3,6 +3,8 @@ name: lisa-atlassian-access
 description: "Vendor-neutral access layer for…"
 allowed-tools: ["Bash", "Read", "Skill"]
 ---
+Vendor-neutral access layer for Atlassian (JIRA + Confluence). Every jira-* and confluence-* skill MUST delegate through this skill rather than calling Atlassian directly. Per the credential-substrate-precedence contract, resolves a substrate per operation with the ATLASSIAN_API_TOKEN curl path first for reads and writes alike whenever the token is present and identity-matched — binding JIRA writes to the configured cloudId — then acli, then the Atlassian MCP as fallbacks. acli is used when installed and switchable to a profile matching the configured site; mismatched active profiles are skipped only after switch plus re-verification fails, and acli writes are a guarded fallback with post-write tenant assertions.
+
 
 # Atlassian Access: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-attribute-failure/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-attribute-failure
 description: "Event-triggered root-cause…"
 allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep"]
 ---
+Event-triggered root-cause attribution for an arbitrary failure: decide, with cited evidence, whether the defect is Lisa's fault or the project's. Accepts a failure event (defect description, implicated files, rule/skill/hook in play) and returns a verdict of lisa | project | ambiguous plus the evidence relied on. Read-only — it never files, writes, or remediates; callers (lisa-doctor findings, the learning judgment gate, rework triage) consume the verdict. Extracted from lisa-doctor's upstream Lisa change-history diagnosis (#1494) so the same attribution procedure can run on ANY failure event, not only doctor config-audit findings.
+
 
 # Attribute Failure
 

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

@@ -3,6 +3,8 @@ name: lisa-automation-status
 description: "Read-only operator surface for…"
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
+Read-only operator surface for the current project's Lisa automation fleet. Resolves the expected recurring jobs from the same setup-automations contract Lisa uses to create them, inspects the active runtime scheduler (Codex automations or Claude /schedule), compares live command/cadence/queue arguments against the expected contract, and reports grouped fleet health such as healthy, missing, unsupported, drifted, stale, or failing with remediation guidance.
+
 
 # Automation Status: $ARGUMENTS
 

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

@@ -2,6 +2,8 @@
 name: lisa-bug-triage
 description: "8-step bug triage and…"
 ---
+8-step bug triage and implementation workflow. Ensures bugs are reproducible, root-caused, and fixable before implementation begins.
+
 
 # Bug Triage
 

package/plugins/lisa/.codex-plugin/skills/lisa-capability-drift/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-capability-drift
 description: "Detect the fleet getting worse…"
 allowed-tools: ["Read", "Grep", "Glob", "Bash"]
 ---
+Detect the fleet getting worse when nobody changed anything — sample the evaluation suite against a recorded baseline on a cadence, decide whether a decline is real given run-to-run variance, and attribute it to a vendor-side change, accumulated local change, or a broken harness.
+
 
 # Capability Drift
 

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

@@ -2,6 +2,8 @@
 name: lisa-codebase-research
 description: "Codebase exploration and…"
 ---
+Codebase exploration and architecture analysis. Read files, trace data flow, identify modification points, map dependencies, find reusable code, evaluate design patterns.
+
 
 # Codebase Research
 

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

@@ -3,6 +3,8 @@ name: lisa-codify-verification
 description: "Convert empirical verification…"
 allowed-tools: ["Bash", "Read", "Edit", "Write", "Glob", "Grep", "Skill"]
 ---
+Convert empirical verification into a regression test so it never has to be re-proven manually. Runs after a verification passes — picks the appropriate test framework for the verification type (Playwright for UI/browser, integration test for API/DB/auth, benchmark for performance, etc.), generates the test, wires it into the project's test runner, and confirms it executes. Mandatory step in the verification lifecycle and in the Build/Fix/Improve flows.
+
 
 # Codify Verification: $ARGUMENTS
 

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

@@ -3,6 +3,8 @@ name: lisa-confluence-prd-intake
 description: "Scans a Confluence space (or a…"
 allowed-tools: ["Skill", "Bash"]
 ---
+Scans a Confluence space (or a parent page) for PRD pages currently parented under the configured `ready` lifecycle page and runs the first eligible one through the dry-run validation pipeline. A PRD that passes every gate gets tickets written and is re-parented under the `ticketed` lifecycle page; a PRD that fails gets clarifying-question comments and is re-parented under the `blocked` lifecycle page. Confluence counterpart of `lisa-notion-prd-intake` — the workflow is identical; only the source-of-truth tools and the state encoding differ (parent-page re-parenting instead of a status property). Composes existing skills (confluence-to-tracker, tracker-validate, tracker-source-artifacts, product-walkthrough).
+
 
 # Confluence PRD Intake: $ARGUMENTS
 

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

@@ -3,6 +3,8 @@ name: lisa-confluence-to-tracker
 description: "Break down a Confluence PRD…"
 allowed-tools: ["Skill", "Bash"]
 ---
+Break down a Confluence PRD page into Epics, Stories, and Sub-tasks in the configured destination tracker (JIRA, GitHub Issues, or Linear per .lisa.config.json). Use this skill whenever the user shares a Confluence PRD URL and wants it converted into tracker tickets, or asks to "break down this Confluence spec", "create tickets from a Confluence page", "turn this Confluence doc into tickets", or similar. This skill mirrors `lisa-notion-to-tracker` for projects whose PRDs live in Confluence — the workflow, gates, dry-run mode, and validation rules are identical; only the source-of-truth tool surface differs (Confluence MCP instead of Notion MCP).
+
 
 # Confluence PRD to Tracker Breakdown
 

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

@@ -3,6 +3,8 @@ name: lisa-confluence-write-prd
 description: "Creates or idempotently updates…"
 allowed-tools: ["Skill", "Bash"]
 ---
+Creates or idempotently updates a PRD as a Confluence page parented under the configured lifecycle parent page (the draft parent by default, or the ready parent when initial_role is ready so lisa-confluence-prd-intake auto-claims it). The Confluence PRD-source writer behind lisa-prd-source-write. Confluence models PRD state by PARENT PAGE (not labels), per config-resolution. Dedupes by a stable marker embedded in the page body, found via CQL (matched by marker, never by title). All Atlassian access goes through lisa-atlassian-access.
+
 
 # Write Confluence PRD: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-cross-pollinate/SKILL.md

@@ -4,6 +4,8 @@ description: "Detect a host project's…"
 allowed-tools: ["Bash", "Read", "Write", "Edit", "Glob", "Grep"]
 argument-hint: "[path] [--dry-run] [--write]"
 ---
+Detect a host project's locally-authored coding-agent definitions (skills, subagents, rules, commands, hooks, MCP) and make each available in the formats of the OTHER agents the project supports, as declared in .lisa.config.json. Any-to-any, provenance-tracked, idempotent, never clobbers hand-edited output.
+
 
 # Cross-Pollinate: $ARGUMENTS
 

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

@@ -3,6 +3,8 @@ name: lisa-debrief
 description: "Run the Debrief flow over a…"
 allowed-tools: ["Skill", "ToolSearch", "Bash", "Read", "Glob", "Grep", "TeamCreate"]
 ---
+Run the Debrief flow over a shipped initiative. Input: a PRD URL (Notion / Confluence / Linear / GitHub Issue / file), a JIRA epic key, or a GitHub epic issue URL. Output: a triage-ready learnings document covering every work item in the initiative — edge cases, gotchas, process friction, tooling gaps, convention drift — each with structured evidence and a human-disposition field. Persistence is deferred to lisa-debrief-apply.
+
 
 # Debrief: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-debrief-apply/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-debrief-apply
 description: "Apply human-marked dispositions…"
 allowed-tools: ["Skill", "Bash", "Read", "Edit", "Write", "Glob", "Grep"]
 ---
+Apply human-marked dispositions from a Debrief triage document. Reads the triage doc produced by lisa-debrief, parses each row's disposition (Accept / Reject / Defer), and routes Accepted items to their persistence destination. Deterministic and idempotent — safe to re-run if dispositions are added incrementally.
+
 
 # Debrief Apply: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-delivery-effectiveness/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-delivery-effectiveness
 description: "Measure whether the work the…"
 allowed-tools: ["Read", "Grep", "Glob", "Bash"]
 ---
+Measure whether the work the factory delivers was worth shipping — gate rejection, rework, escape, first-pass yield and cost per delivered item — so autonomy rate cannot stand alone as a success measure.
+
 
 # Delivery Effectiveness
 

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

@@ -3,6 +3,8 @@ name: lisa-design-intake
 description: "Design-handoff gate for a work…"
 allowed-tools: ["Skill", "Bash", "Read", "Write"]
 ---
+Design-handoff gate for a work item with a UI surface. Resolves the source of truth PER AXIS (colour, spacing, typography, radius, elevation, motion) by querying the published variable collections of the configured design source — never by asking a human — then judges the work item against the five objectively checkable block conditions of the `design-value-binding` rule. Values come from design variables where a variable system exists; visual measurement is supplemental there and the legitimate primary source where none exists. Blocks on UNBOUND, never on UNSURE: aesthetic uncertainty with everything bound is not a block. Escalates a block through the vendor-neutral tracker abstraction to the configured `design.escalation.assignee`, with a plain-language comment a non-technical operator can act on, and records every value derived in an untyped axis so the gaps in the variable system accumulate on their own.
+
 
 # Design Intake: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-detect-tooling/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-detect-tooling
 description: "Find the command-line tools a…"
 allowed-tools: ["Bash", "Read", "AskUserQuestion"]
 ---
+Find the command-line tools a project needs but never declares, and propose pinned manifest entries for them. Reads git hooks and npm scripts for what the project actually RUNS — discovering tools no list mentions — plus MCP servers, credential usage notes and quality configuration. Subtracts whatever remoteEnv.tools, node_modules and the workstation layer already cover, and prints proposals with evidence. Writes nothing and installs nothing — a tool reaches a machine only when a human has reviewed a pinned, checksummed entry. Invoked by lisa-setup-remote-env before provisioning, and runnable on its own.
+
 
 # Detect Tooling
 

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

@@ -3,6 +3,8 @@ name: lisa-doctor
 description: "Audit whether the current…"
 allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep"]
 ---
+Audit whether the current repository is ready to use Lisa. Runs grouped read-only checks across project detection, Lisa config, runtime distribution surfaces, tracker/source preflight access, automation prerequisites, optional GitHub Project coordination, and optional wiki delegation, then reports PASS/WARN/FAIL/SKIP results plus an overall readiness verdict (`READY`, `READY_WITH_WARNINGS`, or `NOT_READY`).
+
 
 # Doctor: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-drive-pr-to-merge/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-drive-pr-to-merge
 description: "drive a pull request all the…"
 allowed-tools: ["Bash", "Read", "Edit", "Write", "Grep", "Glob", "Skill"]
 ---
+This skill should be used to drive a pull request all the way to MERGED, handling ANYTHING that blocks the merge. It enables auto-merge when the repo supports it (direct-merge fallback otherwise), keeps the branch rebased/synced and resolves merge conflicts, fixes failing CI/deploy checks, addresses and resolves every human and bot review comment (CodeRabbit, etc.) — implementing valid feedback and replying-then-resolving invalid feedback — dismisses stale CHANGES_REQUESTED gates, and verifies the fix actually shipped — both merge ancestry and that a deploy/release run fired for the merge SHA (auto-merge race + zero-deploy-run check). Composable and inline — invoked by other skills (e.g. git-submit-pr, implement, sync-down) via the Skill tool, never as a standalone user command.
+
 
 # Drive PR to Merge
 

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

@@ -2,6 +2,8 @@
 name: lisa-epic-triage
 description: "9-step epic triage and 5-step…"
 ---
+9-step epic triage and 5-step implementation workflow. Ensures epics are fully scoped, broken down, and ordered before execution begins.
+
 
 # Epic Triage
 

package/plugins/lisa/.codex-plugin/skills/lisa-evaluation-suite/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-evaluation-suite
 description: "Build and maintain the entity's…"
 allowed-tools: ["Read", "Grep", "Glob", "Bash"]
 ---
+Build and maintain the entity's own task suite for qualifying agent, model, prompt and effort-level changes — drawn from real work, kept representative, protected from contamination, and checked for the discriminating power that makes a result mean something.
+
 
 # Evaluation Suite
 

package/plugins/lisa/.codex-plugin/skills/lisa-exploratory-qa/SKILL.md

@@ -2,6 +2,8 @@
 name: lisa-exploratory-qa
 description: "First-time-user exploratory QA…"
 ---
+First-time-user exploratory QA pass for ANY product type (DOM web app, HTTP/API backend, canvas game, CLI/library, IaC/CDK) that FEEDS THE LIFECYCLE. Use when asked to experience a product the way a brand-new end user would — driving its real consumer-facing interface via the `use-the-product` core (which detects the product type, resolves the per-environment mutation policy from .lisa.config.json so production data is never mutated by accident, and explores through the project's personas when it defines them) to find anything confusing, broken, or hard to use. Static route scans, HTTP fetches, screenshots alone, or console/network checks alone are not sufficient evidence. Instead of writing a report file, it files worthwhile findings as tracked work items via lisa-tracker-write. A `ready` parameter controls whether those tickets are created build-ready (auto-picked-up by lisa-intake) or left in the backlog for human triage (default). For gaps in the automated test suite, use e2e-coverage-gaps instead.
+
 
 # Exploratory QA
 

package/plugins/lisa/.codex-plugin/skills/lisa-fix-linter-error/SKILL.md

@@ -4,6 +4,8 @@ description: "fixing all violations of one or…"
 allowed-tools: ["Read", "Bash", "Glob", "Grep"]
 
 ---
+This skill should be used when fixing all violations of one or more ESLint rules across the codebase. It runs the linter, groups violations by rule and file, generates a brief with fix strategies, and creates a plan with tasks to implement the fixes.
+
 
 # Fix Linter Errors
 

package/plugins/lisa/.codex-plugin/skills/lisa-generate-claude-remote-build-script/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-generate-claude-remote-build-script
 description: "Generate the setup/build script…"
 allowed-tools: ["Skill", "Bash", "Read", "Write", "Glob", "Grep"]
 ---
+Generate the setup/build script (and env-var template) to paste into a Claude Code remote routine environment so this repo runs in the cloud. Runs /lisa:analyze-claude-remote to inventory needs, then writes an idempotent, detect-before-install bash script that installs the required CLIs/binaries and package manager for both Lisa and the host project, plus a commented environment-variable template (names only, never real secrets) and a list of custom domains to allowlist. The script is fast (fits the ~5-minute environment-cache budget), re-runnable, and cloud-proxy aware.
+
 
 # Generate Claude Remote Build Script: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-git-commit/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-git-commit
 description: "creating conventional commits…"
 allowed-tools: ["Bash"]
 ---
+This skill should be used when creating conventional commits for current changes. It groups related changes into logical commits, ensures all files are committed, and verifies the working directory is clean afterward.
+
 
 # Git Commit Workflow
 

package/plugins/lisa/.codex-plugin/skills/lisa-git-prune/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-git-prune
 description: "pruning local branches that…"
 allowed-tools: ["Bash"]
 ---
+This skill should be used when pruning local branches that have been deleted on the remote. It fetches remote changes, identifies stale local branches, and safely deletes them.
+
 
 # Git Prune Local Branches
 

package/plugins/lisa/.codex-plugin/skills/lisa-git-submit-pr/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-git-submit-pr
 description: "pushing changes and creating or…"
 allowed-tools: ["Bash", "Skill", "mcp__github__create_pull_request", "mcp__github__get_pull_request", "mcp__github__update_pull_request"]
 ---
+This skill should be used when pushing changes and creating or updating a pull request. It verifies the branch state, pushes to remote, creates or updates a PR with a comprehensive description, optionally coordinates the resulting Pull Request into the configured GitHub ProjectV2, and hands the PR to drive-pr-to-merge, which decides whether auto-merge may be armed. It never arms auto-merge itself.
+
 
 # Submit Pull Request Workflow
 

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

@@ -3,6 +3,8 @@ name: lisa-github-add-journey
 description: "Add a Validation Journey…"
 allowed-tools: ["Bash", "Skill"]
 ---
+Add a Validation Journey section to an existing GitHub Issue by analyzing the change type and generating appropriate verification steps with evidence markers. The GitHub counterpart of lisa-jira-add-journey.
+
 
 # Add Validation Journey to Existing GitHub Issue
 

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

@@ -3,6 +3,8 @@ name: lisa-github-build-intake
 description: "GitHub counterpart to…"
 allowed-tools: ["Skill", "Bash"]
 ---
+GitHub counterpart to lisa-jira-build-intake. Scans a GitHub repository for issues carrying the configured `ready` build label, processes the first eligible issue, runs leaf work via the github-agent workflow in-session (culminating in lisa-implement), relabels to the configured `done` label on completion, then exits. Enforces the claim-time arm of the `leaf-only-lifecycle` rule: a parent/container with open child work (or a childless Epic) that still carries a stale build-ready label is moved out of the ready pickup queue into the configured `claimed` label with a lifecycle-repair comment, never dispatched to the build lifecycle. The `ready` label is the human-flipped signal that an issue is truly ready for direct development pickup — mirroring how Notion PRDs work product Draft → Ready → (us) In Review → Blocked|Ticketed.
+
 
 # GitHub Build Intake: $ARGUMENTS
 

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

@@ -3,6 +3,8 @@ name: lisa-github-claim
 description: "Idempotently claims one live…"
 allowed-tools: ["Bash", "Skill", "Read"]
 ---
+Idempotently claims one live GitHub leaf issue for direct Lisa work. Reuses github-build-intake Phase 3b semantics: configured ready-to-claimed relabel, assign-only-if-unassigned, stable managed comment, and post-write verification.
+
 
 # Claim GitHub Issue: $ARGUMENTS
 

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

@@ -3,6 +3,8 @@ name: lisa-github-create
 description: "creating GitHub Issue Epics…"
 allowed-tools: ["Read", "Glob", "LS", "Skill", "Bash"]
 ---
+This skill should be used when creating GitHub Issue Epics, Stories, and Sub-tasks from code files or descriptions. It analyzes the provided input, determines the appropriate issue hierarchy, and creates issues with comprehensive quality requirements including test-first development and documentation. The GitHub counterpart of lisa-jira-create.
+
 
 # Create GitHub Issues from $ARGUMENTS
 

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

@@ -3,6 +3,8 @@ name: lisa-github-evidence
 description: "Upload text evidence to the…"
 allowed-tools: ["Bash"]
 ---
+Upload text evidence to the GitHub `pr-assets` release, update PR description, and post a GitHub Issue comment with code blocks. Reusable by any skill that captures evidence and generates evidence/comment.md (and optionally evidence/comment.txt). The GitHub counterpart of lisa-jira-evidence.
+
 
 # GitHub Evidence Posting
 

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

@@ -3,6 +3,8 @@ name: lisa-github-journey
 description: "Parse a GitHub Issue's…"
 allowed-tools: ["Bash", "Read", "Glob", "Grep", "Skill"]
 ---
+Parse a GitHub Issue's Validation Journey section, execute the verification steps using appropriate tools (curl, test commands, database queries), capture evidence at each marker, and post results via lisa-github-evidence. The GitHub counterpart of lisa-jira-journey.
+
 
 # GitHub Validation Journey
 

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

@@ -3,6 +3,8 @@ name: lisa-github-prd-intake
 description: "Scans a GitHub repository for…"
 allowed-tools: ["Skill", "Bash"]
 ---
+Scans a GitHub repository for issues carrying the configured `ready` PRD label and runs the first eligible one through the dry-run validation pipeline. A PRD that passes every gate gets tickets written (to whatever destination tracker is configured — JIRA, GitHub Issues itself, or Linear) and the label flipped to the configured `ticketed` label; a PRD that fails gets clarifying-question comments and the label flipped to the configured `blocked` label. The GitHub counterpart of lisa-notion-prd-intake / lisa-confluence-prd-intake / lisa-linear-prd-intake. Composes existing skills (github-to-tracker, tracker-validate, tracker-source-artifacts, product-walkthrough).
+
 
 # GitHub PRD Intake: $ARGUMENTS
 

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

@@ -3,6 +3,8 @@ name: lisa-github-project-v2
 description: "Shared GitHub ProjectV2…"
 allowed-tools: ["Bash", "Read", "Skill"]
 ---
+Shared GitHub ProjectV2 coordination utility. Every GitHub writer or linked pull request flow that needs Project membership MUST delegate through this skill instead of inlining GraphQL. Resolves the configured ProjectV2 id from `github.projects.v2`, validates namespace + access, adds Issue or Pull Request node ids to the Project, optionally updates Project field values, and returns exact failures with best-effort vs required-mode branching.
+
 
 # GitHub ProjectV2: $ARGUMENTS
 

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

@@ -3,6 +3,8 @@ name: lisa-github-read-issue
 description: "Fetches the full scope of a…"
 allowed-tools: ["Bash", "Skill"]
 ---
+Fetches the full scope of a GitHub Issue — metadata, body sections, all comments, native sub-issue parent and children, linked PRs, related issues parsed from `Blocks/Blocked by/Relates to/Duplicates/Cloned from` lines, and any cross-repo references. Produces a consolidated context bundle that downstream agents consume so they never act on an issue in isolation. The GitHub counterpart of lisa-jira-read-ticket.
+
 
 # Read GitHub Issue: $ARGUMENTS
 

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

@@ -3,6 +3,8 @@ name: lisa-github-sync
 description: "Syncs plan progress to a linked…"
 allowed-tools: ["Bash", "Read", "Glob", "Grep"]
 ---
+Syncs plan progress to a linked GitHub Issue. Posts plan contents, progress updates, branch links, and PR links at key milestones. Use this skill throughout the plan lifecycle to keep issues in sync. The GitHub counterpart of lisa-jira-sync.
+
 
 # GitHub Issue Sync
 

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

@@ -3,6 +3,8 @@ name: lisa-github-to-tracker
 description: "Break down a GitHub Issue PRD…"
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
+Break down a GitHub Issue PRD into Epics, Stories, and Sub-tasks in the configured destination tracker (JIRA via lisa-tracker-write → lisa-jira-write-ticket, or GitHub Issues itself via lisa-tracker-write → lisa-github-write-issue). Use this skill whenever the user shares a GitHub issue URL and wants it converted into tickets, or asks to "break down this GitHub PRD", "create tickets from a GitHub issue", or similar. This skill mirrors lisa-notion-to-tracker / lisa-confluence-to-tracker / lisa-linear-to-tracker for projects whose PRDs live in GitHub Issues — the workflow, gates, dry-run mode, and validation rules are identical; only the source-of-truth tool surface differs (the `gh` CLI instead of Notion / Confluence / Linear MCP).
+
 
 # GitHub PRD to Tracker Breakdown
 

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

@@ -3,6 +3,8 @@ name: lisa-github-validate-issue
 description: "Validates a proposed GitHub…"
 allowed-tools: ["Bash", "Read"]
 ---
+Validates a proposed GitHub Issue spec (or an existing issue) against the organizational quality gates without writing anything. Returns a structured PASS/FAIL report per gate with concrete remediation. The GitHub counterpart of lisa-jira-validate-ticket — same gate definitions, translated to the GitHub Issues data model. Single source of truth for what makes a valid GitHub Issue. Both the write path (github-write-issue runs it pre-write) and the dry-run path (github-to-tracker runs it during PRD intake) call this skill.
+
 
 # Validate GitHub Issue: $ARGUMENTS
 

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

@@ -3,6 +3,8 @@ name: lisa-github-verify
 description: "verifying that a GitHub Issue…"
 allowed-tools: ["Skill", "Bash"]
 ---
+This skill should be used when verifying that a GitHub Issue meets organizational standards for parent-sub-issue relationships and description quality. It fetches the live issue and delegates the gate checks to github-validate-issue so the bar matches what github-write-issue enforces pre-write. The GitHub counterpart of lisa-jira-verify.
+
 
 # Verify GitHub Issue: $ARGUMENTS
 

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

@@ -3,6 +3,8 @@ name: lisa-github-write-issue
 description: "Creates or updates a GitHub…"
 allowed-tools: ["Bash", "Skill", "Read"]
 ---
+Creates or updates a GitHub Issue following the same organizational best practices as lisa-jira-write-ticket — three-audience description, Gherkin acceptance criteria, parent sub-issue (Epic/Story hierarchy), explicit relationship discovery, remote links, labels for status/components/priority/story-points, Validation Journey, and optional GitHub ProjectV2 coordination through lisa-github-project-v2 while keeping the Issue as the lifecycle source of truth. Uses the `gh` CLI exclusively (no MCP). Rejects thin issues. The GitHub counterpart of lisa-jira-write-ticket.
+
 
 # Write GitHub Issue: $ARGUMENTS
 

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

@@ -3,6 +3,8 @@ name: lisa-github-write-prd
 description: "Creates or idempotently updates…"
 allowed-tools: ["Skill", "Bash"]
 ---
+Creates or idempotently updates a PRD as a GitHub Issue in the configured source repo, carrying exactly one PRD lifecycle label (`prd-draft` by default, or `prd-ready` when initial_role is ready so lisa-github-prd-intake auto-claims it). The GitHub PRD-source writer behind lisa-prd-source-write — the source-side counterpart of lisa-github-write-issue. Dedupes by a stable marker embedded in the issue body (matched by marker, never by title) so re-running ideation references the existing PRD instead of opening a duplicate, and when `github.projects.v2` is enabled it coordinates PRD issue membership through `lisa-github-project-v2` without replacing the issue as the lifecycle source of truth. Uses the `gh` CLI exclusively.
+
 
 # Write GitHub PRD: $ARGUMENTS
 

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

@@ -3,6 +3,8 @@ name: lisa-health
 description: "Run Lisa Health through one…"
 allowed-tools: ["Bash", "Read", "Write"]
 ---
+Run Lisa Health through one digest-bound current-harness review, persist exactly one final Health v1 result, and emit the persisted JSON verbatim. Use for Claude /lisa:health, Codex $lisa-health, Cursor /lisa:health, OpenCode /lisa:health, Antigravity /lisa:health, and Copilot /lisa:health.
+
 
 # Lisa Health: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-health-drift-cron/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-health-drift-cron
 description: "Scheduled health consumer"
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
+Scheduled health consumer. Runs Lisa Health headless, and for each check that has drifted files exactly one tracker ticket through lisa-tracker-write, deduped by a per-check marker across OPEN tickets only. Files nothing for a project in band. Use for the lisa-auto-<project>-health-drift automation registered when health.schedule is set.
+
 
 # Lisa Health Drift Cron: $ARGUMENTS
 

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

@@ -2,6 +2,8 @@
 name: lisa-implement
 description: "any non-trivial request —…"
 ---
+This skill should be used for any non-trivial request — features, bugs, stories, epics, spikes, or multi-step tasks. It accepts a ticket URL (Jira, Linear, GitHub), a file path containing a spec, or a plain-text prompt. It assembles an agent team, breaks the work into structured tasks, and manages the full lifecycle from research through implementation, code review, deploy, and empirical verification.
+
 
 # Implement: $ARGUMENTS
 

package/plugins/lisa/.codex-plugin/skills/lisa-improve-code-complexity/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-improve-code-complexity
 description: "reducing the cognitive…"
 allowed-tools: ["Read", "Bash", "Glob", "Grep"]
 ---
+This skill should be used when reducing the cognitive complexity threshold of the codebase. It lowers the threshold by 2, identifies functions that exceed the new limit, generates a brief with refactoring strategies, and creates a plan with tasks to fix all violations.
+
 
 # Lower Code Complexity
 

package/plugins/lisa/.codex-plugin/skills/lisa-improve-harness/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-improve-harness
 description: "Investigate ONE failed or…"
 allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep", "Edit", "Write"]
 ---
+Investigate ONE failed or expensive factory trajectory and prove whether a fix helped. Records the job contract, observes the baseline, locates the earliest failed handoff, classifies the gap as exactly one of context | capability | domain-ownership | authority | proof | feedback-delivery | worker-limitation, makes the smallest owning intervention at the authoritative owner (larger changes become a proposed-intervention ticket and the loop stops), verifies at both layers (native gates plus the operational journey), then reruns the same job class in a fresh session and isolated worktree behind a relevance gate — a rerun that never retrieved or invoked the intervention yields no-evidence-for-intervention, never retain. Terminates by posting a fingerprinted result record on the originating work item with decision retain, revise, remove, or test-without. Headless-safe, idempotent per trajectory, single-trajectory bounded claims only.
+
 
 # Improve Harness
 

package/plugins/lisa/.codex-plugin/skills/lisa-improve-max-lines/SKILL.md

@@ -4,6 +4,8 @@ description: "reducing the maximum file lines…"
 allowed-tools: ["Read", "Bash", "Glob", "Grep"]
 
 ---
+This skill should be used when reducing the maximum file lines threshold and fixing all violations. It updates the eslint threshold configuration, identifies files exceeding the new limit, generates a brief with refactoring strategies, and creates a plan with tasks to split oversized files.
+
 
 # Reduce Max Lines
 

package/plugins/lisa/.codex-plugin/skills/lisa-improve-max-lines-per-function/SKILL.md

@@ -4,6 +4,8 @@ description: "reducing the maximum lines per…"
 allowed-tools: ["Read", "Bash", "Glob", "Grep"]
 
 ---
+This skill should be used when reducing the maximum lines per function threshold and fixing all violations. It updates the eslint threshold configuration, identifies functions exceeding the new limit, generates a brief with refactoring strategies, and creates a plan with tasks to split oversized functions.
+
 
 # Reduce Max Lines Per Function
 

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

@@ -4,6 +4,8 @@ description: "increasing test coverage to a…"
 allowed-tools: ["Read", "Bash", "Glob", "Grep"]
 
 ---
+This skill should be used when increasing test coverage to a specified threshold percentage. It runs the coverage report, identifies files with the lowest coverage, generates a brief with coverage gaps, and creates a plan with tasks to add the missing tests.
+
 
 # Increase Test Coverage
 

package/plugins/lisa/.codex-plugin/skills/lisa-improve-tests/SKILL.md

@@ -3,6 +3,8 @@ name: lisa-improve-tests
 description: "improving test quality"
 allowed-tools: ["Read", "Bash", "Glob", "Grep"]
 ---
+This skill should be used when improving test quality. It scans the test suite for weak, brittle, or poorly-written tests, generates a brief with improvement opportunities, and creates a plan with tasks to strengthen the tests.
+
 
 # Improve Test Quality