@codyswann/lisa 2.189.6 → 2.189.8

package/plugins/lisa-cursor/commands/doctor.md

@@ -1,6 +0,0 @@
----
-description: "Audit whether the current repository is ready to use Lisa. Runs grouped read-only readiness checks for config, runtime surfaces, tracker/source access, automation prerequisites, and optional GitHub Project/wiki coordination, then reports PASS/WARN/FAIL/SKIP results plus an overall verdict."
-argument-hint: "[--fix=false]"
----
-
-Use the /lisa:doctor skill to audit whether the current repository is ready to use Lisa, report grouped PASS/WARN/FAIL/SKIP checks, and emit an overall readiness verdict. $ARGUMENTS

package/plugins/lisa-cursor/commands/exploratory-qa.md

@@ -1,7 +0,0 @@
----
-description: "Run a first-time-user exploratory QA pass on any product type (DOM web app, HTTP/API backend, canvas game, CLI/library, IaC/CDK): experience the product the way a brand-new end user would by 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 is never mutated by accident, and explores through the project's personas when defined), finding anything confusing, broken, or hard to use, and filing each finding (bug or usability issue) as a tracked work item via lisa:tracker-write. Static scans, HTTP fetches, screenshots alone, or console/network checks alone are not sufficient. The optional ready flag marks tickets build-ready (auto-picked-up by lisa:intake) or leaves them in the backlog for human triage (default). For gaps in the automated test suite, use the e2e-coverage-gaps skill if your stack provides one."
-allowed-tools: ["Skill"]
-argument-hint: "[target-url | env] [ready=true|false]"
----
-
-Use the lisa:exploratory-qa skill to experience the product the way a brand-new first-time end user would — driving its real consumer-facing interface via the use-the-product core (product-type detection, per-environment mutation policy, and persona-lensed exploration), finding anything confusing, broken, or hard to use, and filing each finding (bugs, usability/clarity issues) as a tracked work item via lisa:tracker-write, build-ready or in triage per the ready flag (default: triage). Static scans, HTTP fetches, screenshots alone, or console/network checks alone are not enough. For automated test-coverage gaps, use the e2e-coverage-gaps skill if your stack provides one. $ARGUMENTS

package/plugins/lisa-cursor/commands/fix/linter-error.md

@@ -1,7 +0,0 @@
----
-description: "Fix all violations of one or more ESLint rules across the codebase"
-allowed-tools: ["Skill"]
-argument-hint: "<rule-1> [rule-2] [rule-3] ..."
----
-
-Use the /lisa:fix-linter-error skill to fix linter errors. $ARGUMENTS

package/plugins/lisa-cursor/commands/generate-claude-remote-build-script.md

@@ -1,6 +0,0 @@
----
-description: "Generate the setup/build script and environment-variable template to paste into a Claude Code remote routine environment so this repo runs in the cloud. Runs /lisa:analyze-claude-remote, then writes an idempotent, detect-before-install bash script that installs the required package manager and CLIs for Lisa and the host project, plus a commented env-var template (names only) and a domain allowlist. Cloud-proxy aware and fits the environment-cache time budget."
-argument-hint: "[--out=<path>] [--include-optional] [--print]"
----
-
-Use the /lisa:generate-claude-remote-build-script skill to generate the cloud-environment setup script and env-var template for running this repo as a Claude Code remote routine. $ARGUMENTS

package/plugins/lisa-cursor/commands/git/commit.md

@@ -1,7 +0,0 @@
----
-description: "Create conventional commits for current changes"
-allowed-tools: ["Skill"]
-argument-hint: "[commit-message-hint]"
----
-
-Use the /lisa:git-commit skill to create conventional commits for current changes. $ARGUMENTS

package/plugins/lisa-cursor/commands/git/prune.md

@@ -1,6 +0,0 @@
----
-description: "Prune local branches that have been deleted on remote"
-allowed-tools: ["Skill"]
----
-
-Use the /lisa:git-prune skill to prune local branches that have been deleted on remote.

package/plugins/lisa-cursor/commands/git/submit-pr.md

@@ -1,7 +0,0 @@
----
-description: "Push changes and create or update a pull request"
-allowed-tools: ["Skill"]
-argument-hint: "[pr-title-or-description-hint]"
----
-
-Use the /lisa:git-submit-pr skill to push changes and create or update a pull request. $ARGUMENTS

package/plugins/lisa-cursor/commands/implement.md

@@ -1,6 +0,0 @@
----
-description: "Implement a single work item end-to-end. Vendor-agnostic: given a work-item URL/key (JIRA, Linear, GitHub Issues) or description, reads it, determines work type (Build/Fix/Improve/Investigate), assembles an agent team, runs the full lifecycle through PR + evidence. For batch processing of all Status=Ready tickets in a queue, use /lisa:intake instead."
-argument-hint: "<single-work-item-url | key | description>"
----
-
-Use the /lisa:implement skill to take the work item from spec to shipped: read the source, determine work type, assemble an agent team, and run the full lifecycle through PR creation, code review, deploy, and empirical verification. $ARGUMENTS

package/plugins/lisa-cursor/commands/improve/code-complexity.md

@@ -1,6 +0,0 @@
----
-description: "Reduce the cognitive complexity threshold by 2 and fix all violations"
-allowed-tools: ["Skill"]
----
-
-Use the /lisa:improve-code-complexity skill to lower code complexity.

package/plugins/lisa-cursor/commands/improve/max-lines-per-function.md

@@ -1,7 +0,0 @@
----
-description: "Reduce max lines per function threshold and fix violations"
-allowed-tools: ["Skill"]
-argument-hint: "<max-lines-per-function-value>"
----
-
-Use the /lisa:improve-max-lines-per-function skill to reduce max function lines. $ARGUMENTS

package/plugins/lisa-cursor/commands/improve/max-lines.md

@@ -1,7 +0,0 @@
----
-description: "Reduce max file lines threshold and fix violations"
-allowed-tools: ["Skill"]
-argument-hint: "<max-lines-value>"
----
-
-Use the /lisa:improve-max-lines skill to reduce max lines. $ARGUMENTS

package/plugins/lisa-cursor/commands/improve/test-coverage.md

@@ -1,7 +0,0 @@
----
-description: "Increase test coverage to a specified threshold percentage"
-allowed-tools: ["Skill"]
-argument-hint: "<threshold-percentage>"
----
-
-Use the /lisa:improve-test-coverage skill to increase test coverage. $ARGUMENTS

package/plugins/lisa-cursor/commands/improve/tests.md

@@ -1,7 +0,0 @@
----
-description: "Improve test quality by analyzing and strengthening weak, brittle, or poorly-written tests"
-allowed-tools: ["Skill"]
-argument-hint: "<target-description>"
----
-
-Use the /lisa:improve-tests skill to improve test quality. $ARGUMENTS

package/plugins/lisa-cursor/commands/intake-explain.md

@@ -1,31 +0,0 @@
----
-description: "Inspect one PRD or build item, explain how Lisa classifies it right now, and report the exact intake or repair gate affecting it. Read-only by default."
-argument-hint: "<item-ref>"
----
-
-Use the /lisa:intake-explain skill to inspect a single repo-scoped PRD or build item, explain its current lifecycle role, and report whether Lisa would intake it, repair it, hold it, skip it, or leave it product-owned. $ARGUMENTS
-
-Common operator usage:
-
-- `/lisa:intake-explain https://github.com/acme/repo/issues/123`
-- `/lisa:intake-explain PRD-456`
-- `/lisa:intake-explain https://linear.app/acme/issue/ENG-123/example`
-
-The diagnosis uses stable verdicts:
-
-- `ELIGIBLE_FOR_INTAKE`: run `/lisa:intake <queue>` when normal pickup is the next move.
-- `ELIGIBLE_FOR_REPAIR`: run `/lisa:repair-intake <queue>` when Lisa-owned stuck work is actionable.
-- `WAITING_ON_STALENESS`: wait and re-check after the configured freshness window.
-- `HELD_BY_BLOCKERS`: clear the listed dependency or blocker before rerunning intake.
-- `NON_LEAF_CONTAINER`: decompose the item or move build-ready status to leaf work.
-- `PRODUCT_OWNED_STATE`: finish product clarification, promotion, or verification first.
-- `MISCONFIGURED`: fix lifecycle labels, repo scope, or queue configuration before relying on automation.
-
-Use it for these operator workflows:
-
-- Intake triage: confirm whether one item would be picked up by `/lisa:intake` right now.
-- Repair triage: decide whether a blocked or in-progress item is stale enough for `/lisa:repair-intake`.
-- Product follow-up: distinguish product-owned draft/shipped/verified states from Lisa-owned work.
-- Queue cleanup: identify leaf-only, repo-scope, dependency, or lifecycle-adoption fixes without mutating the item.
-
-This surface is read-only in v1. It never claims, relabels, comments on, repairs, or decomposes the item; it only reports the item facts, verdict, decisive gate, and smallest useful next action before an operator chooses `/lisa:intake`, `/lisa:repair-intake`, `/lisa:queue-status`, or a tracker-native fix.

package/plugins/lisa-cursor/commands/intake.md

@@ -1,6 +0,0 @@
----
-description: "Vendor-agnostic batch scanner for Ready queues. Notion PRD database URL → finds Status=Ready PRDs and runs lisa:plan per item. Confluence space or parent-page URL → finds prd-ready PRDs and runs lisa:plan per item. Linear workspace or team URL → finds prd-ready Linear projects and runs lisa:plan per item. GitHub repo URL or org/repo token → finds prd-ready GitHub issues and runs lisa:plan per item (PRD-source mode), or finds status:ready issues and runs lisa:implement per item when tracker=github (build-queue mode). JIRA project key or JQL → finds Ready tickets and runs lisa:implement per item. Designed as the cron target for /schedule."
-argument-hint: "<Notion-PRD-database-URL | Confluence-space-URL | Confluence-parent-page-URL | Linear-workspace-URL | Linear-team-URL | GitHub-repo-URL | org/repo | JIRA-project-key | JQL-filter>"
----
-
-Use the /lisa:intake skill to scan the queue for Ready items and dispatch one eligible Ready item per invocation through the appropriate single-item lifecycle skill — and, on the PRD side, close the loop by dispatching /lisa:verify-prd for one shipped PRD per cycle (shipped → verified on pass, or re-opened to ticketed with build-ready fix tickets that auto-build and re-verify on fail — never blocked). $ARGUMENTS

package/plugins/lisa-cursor/commands/monitor.md

@@ -1,6 +0,0 @@
----
-description: "Monitor application health AND audit observability completeness for the current repo, then file build-ready tickets for anomalies and instrumentation gaps. Health/logs/errors/performance via the stack ops-specialist or stack-agnostic base probing; repo-scoped, idempotent, capped; files by default, --dry-run previews."
-argument-hint: "[environment] [--dry-run] [--report-only] [--all-gaps] [max_candidates=<n>]"
----
-
-Use the /lisa:monitor skill to check application health, logs, errors, and performance for the named environment, audit observability completeness, and file build-ready tickets for the anomalies and gaps it finds. Use `--dry-run` to preview without filing, `--report-only` for a health/audit summary with no filing, or `--all-gaps` to also file recommended-tier gaps (session replay, product analytics). $ARGUMENTS

package/plugins/lisa-cursor/commands/parity-code-review.md

@@ -1,6 +0,0 @@
----
-description: "Lisa-native code review of the current git diff — correctness bugs, security issues, and obvious defects, reported as severity-ranked findings with file:line references. Vendor-neutral cross-agent equivalent of the upstream code-review command."
-argument-hint: "[optional: path or scope hint]"
----
-
-Use the /lisa:parity-code-review skill to review the current branch and working-tree diff for correctness bugs, security issues, and obvious defects, and report findings ranked by severity with file:line references. $ARGUMENTS

package/plugins/lisa-cursor/commands/parity-code-simplifier.md

@@ -1,6 +0,0 @@
----
-description: "Behavior-preserving simplification of recently-changed code — dedup, reuse, readability, and dead-code removal, quality only (never a bug hunt). Vendor-neutral cross-agent equivalent of the upstream code-simplifier agent."
-argument-hint: "[optional: path or scope hint]"
----
-
-Use the /lisa:parity-code-simplifier skill to simplify the recently-changed code — removing duplication and dead code, reusing existing utilities, and improving readability — without altering behavior, then verify tests still pass. $ARGUMENTS

package/plugins/lisa-cursor/commands/parity-coderabbit.md

@@ -1,6 +0,0 @@
----
-description: "Thorough PR-style review of the full diff — bugs, security, performance, and maintainability — with concrete fixes and a structured summary. An independent Lisa-native review (does NOT call CodeRabbit's service); vendor-neutral cross-agent equivalent of the upstream coderabbit plugin."
-argument-hint: "[optional: PR number, path, or scope hint]"
----
-
-Use the /lisa:parity-coderabbit skill to run a thorough PR-style review of the full diff — flagging bugs, security, performance, and maintainability issues with concrete suggested fixes — and produce a structured summary with a verdict. $ARGUMENTS

package/plugins/lisa-cursor/commands/parity-safety-net-rules.md

@@ -1,6 +0,0 @@
----
-description: "View, set, and verify the custom guard rules enforced by Lisa's safety-net PreToolUse Bash hook — the cross-agent equivalent of the upstream safety-net plugin's set/verify-custom-rules skills."
-argument-hint: "[view | set <regex> | verify]"
----
-
-Use the /lisa:parity-safety-net-rules skill to view, set, or verify the project-local custom guard rules enforced by Lisa's safety-net Bash hook (`parity-safety-net.sh`). $ARGUMENTS

package/plugins/lisa-cursor/commands/parity-sentry-sdk-setup.md

@@ -1,6 +0,0 @@
----
-description: "Install and configure the Sentry SDK for a project — detect the framework, add the right @sentry/<framework> package, init the client, wire the DSN via env, enable error + performance monitoring, and set up source maps. One consolidated skill covering react, nextjs, node, nestjs, python, react-native, and more."
-argument-hint: "[framework override, e.g. nextjs | node | python] (auto-detected if omitted)"
----
-
-Use the /lisa:parity-sentry-sdk-setup skill to detect the framework and install + configure the correct Sentry SDK with error and performance monitoring and source maps. $ARGUMENTS

package/plugins/lisa-cursor/commands/parity-sentry-seer.md

@@ -1,6 +0,0 @@
----
-description: "AI debugging — given an error, stack trace, or failing test, analyze it, form ranked hypotheses, locate the root cause in the codebase with file:line evidence, and propose a minimal fix. Lisa-native reimplementation of Sentry's seer workflow."
-argument-hint: "<error message | stack trace | failing test | Sentry issue URL>"
----
-
-Use the /lisa:parity-sentry-seer skill to root-cause the failure and propose an evidence-backed fix. $ARGUMENTS

package/plugins/lisa-cursor/commands/parity-skill-creator.md

@@ -1,6 +0,0 @@
----
-description: "Author a new Lisa skill end-to-end — scaffold the SKILL.md frontmatter, write the pass-through command, follow hyphen naming and placement under plugins/src, and rebuild plugins. Lisa-native equivalent of the upstream skill-creator plugin."
-argument-hint: "<skill-name and a one-line description of what it should do>"
----
-
-Use the /lisa:parity-skill-creator skill to scaffold a new Lisa skill and its pass-through command, following frontmatter, naming, placement, and build conventions. $ARGUMENTS

package/plugins/lisa-cursor/commands/plan.md

@@ -1,6 +0,0 @@
----
-description: "Plan work from a single PRD or specification. Decomposes into ordered work items in the configured tracker (JIRA, GitHub Issues, or Linear per .lisa.config.json). Source can be a Notion / Confluence / Linear / GitHub Issue URL, a JIRA epic key, a markdown file, or a free-form description. For batch scanning of all Ready PRDs in a queue, use /lisa:intake instead."
-argument-hint: "<single-PRD-url | GitHub-issue-url | @file | ticket-id-or-url | description>"
----
-
-Use the /lisa:plan skill to decompose the PRD/spec into ordered work items in the configured tracker. $ARGUMENTS

package/plugins/lisa-cursor/commands/plugin-sync-explain.md

@@ -1,8 +0,0 @@
----
-description: "Explain plugin source/generated drift and marketplace registration gaps without modifying the working tree."
-argument-hint: "[path]"
----
-
-Use the /lisa:plugin-sync-explain skill to inspect plugin source/generated synchronization for the current Lisa repo. $ARGUMENTS
-
-This command is read-only. It reports source-not-built edits, generated-only edits, marketplace registration drift, and the next source-first remediation step before an operator runs `bun run build:plugins` or `bun run check:plugins`.

package/plugins/lisa-cursor/commands/product-walkthrough.md

@@ -1,7 +0,0 @@
----
-description: "Walk through the live product via a real browser (Playwright MCP) to ground PRD evaluation or ticket creation in what exists today. Captures current behavior, design-vs-product divergence, reuse candidates, and behavioral surprises."
-allowed-tools: ["Skill"]
-argument-hint: "<route or feature area to walk>"
----
-
-Use the /lisa:product-walkthrough skill to walk through the live product, capture current state, and produce findings that ground PRD/ticket reasoning. $ARGUMENTS

package/plugins/lisa-cursor/commands/project-ideation.md

@@ -1,6 +0,0 @@
----
-description: "Generate persona-grounded, verifiable product ideas for the host project, then create PRDs for the selected build-ready ideas via lisa:research. First derives the personas the project actually serves (from its docs, code, data model, and releases — never invented), ideates per persona, and gates each idea on an obtainable data/source path and an empirical verification plan. Creates one PRD by default (top-ranked idea); max_prds widens the batch. prd_ready=true creates them prd-ready for auto-pickup by lisa:intake; default is draft for human review."
-argument-hint: "[target path | external product] [prd_ready=true|false] [max_prds=<n>|all]"
----
-
-Use the /lisa:project-ideation skill to derive evidence-grounded personas, ideate per persona, gate the ideas, and create PRDs for the selected build-ready ideas via lisa:research — in draft state by default, or prd-ready when prd_ready=true; one PRD by default, more with max_prds. $ARGUMENTS

package/plugins/lisa-cursor/commands/pull-request/review.md

@@ -1,7 +0,0 @@
----
-description: "Address and resolve PR review comments (human + bot): implement valid feedback, reply to invalid, resolve every thread."
-allowed-tools: ["Skill"]
-argument-hint: "[github-pr-link-or-number]"
----
-
-Use the /lisa:pull-request-review skill to address and resolve the code review feedback on a pull request — implement valid comments, reply to invalid ones, and resolve every thread via GraphQL. $ARGUMENTS

package/plugins/lisa-cursor/commands/queue-status.md

@@ -1,34 +0,0 @@
----
-description: "Inspect the current project's PRD and build queues, summarize lifecycle counts, and surface actionable queue-health signals without mutating work."
----
-
-Use the /lisa:queue-status skill to inspect the current project's configured PRD source and build tracker, report queue-health verdicts, and highlight actionable backlog or stuck-state signals. $ARGUMENTS
-
-Common operator usage:
-
-- `/lisa:queue-status`
-- `/lisa:queue-status queue=prd`
-- `/lisa:queue-status queue=build`
-
-Use this when you need to answer:
-
-- Is the queue actually idle, or is Lisa misconfigured?
-- Which queue item is the most actionable next?
-- Should the next command be `/lisa:intake`, `/lisa:repair-intake`, `/lisa:automation-status`, or `/lisa:verify-prd`?
-
-This surface is read-only in v1. Use it to understand whether the repo's PRD and build queues are idle, healthy, attention-needed, or misconfigured before deciding whether to run `/lisa:intake`, `/lisa:repair-intake`, `/lisa:automation-status`, `/lisa:verify-prd`, or deeper tracker-native investigation.
-
-Quick interpretation guide:
-
-- `IDLE`: the queue resolved correctly and nothing actionable is waiting. No immediate Lisa action is required.
-- `HEALTHY`: the queue resolved correctly and normal work is present. Follow the highlighted next step, usually `/lisa:intake`.
-- `ATTENTION_NEEDED`: blocked, stalled, or aging work needs operator follow-up. Use the highlighted item and remediation hint to choose the next command, usually `/lisa:repair-intake`.
-- `MISCONFIGURED`: queue resolution or lifecycle adoption is broken. Fix config, labels/statuses, or scheduler drift before trusting queue state.
-
-Highlighted-item semantics:
-
-- A highlighted item is the single oldest or most actionable queue item for that section, not a full dump of all matching work.
-- `ready` highlights usually point to `/lisa:intake`.
-- `blocked`, stalled, or long-claimed highlights usually point to `/lisa:repair-intake`.
-- Shipped PRD highlights usually point to `/lisa:verify-prd`.
-- If queue behavior looks wrong for both PRD and build lanes, inspect `/lisa:automation-status` before assuming the queue itself is the problem.

package/plugins/lisa-cursor/commands/repair-intake.md

@@ -1,6 +0,0 @@
----
-description: "Repair counterpart to /lisa:intake. Vendor-agnostic batch scanner that finds stuck or half-closed work — items left in `blocked`, stalled in an in-progress role (build `claimed`, PRD `in_review`), terminal-labeled items still natively open, rollups whose children are all terminal, GitHub PRDs missing native child links, and GitHub issues missing official Lisa lifecycle labels — across the same queues /lisa:intake serves (Notion / Confluence / Linear / GitHub PRDs; JIRA / GitHub / Linear build issues). Repairs every materially actionable candidate inside the `max_candidates` cap: resumes stalled in-progress work in place — but for a stalled build it first diagnoses the PR/deploy state and, if the PR cannot merge (conflict, rebase, failing checks, unaddressed CodeRabbit/changes-requested) or a deploy failed, files a build-ready fix ticket and moves the item to `blocked` (blocked by it) instead of re-dispatching — re-validates blocked PRDs, re-dispatches blocked build items whose blockers have cleared, performs terminal native closure, repairs missing native GitHub PRD child links from generated-work fallback, reconciles parent rollups to their derived state (including the intermediate-env case — e.g. all children at `On Stg` → parent `On Stg` — and a container wrongly stuck in `ready`), normalizes missing GitHub lifecycle labels to the configured PRD/build `ready` label, and closes out completed rollups. Cron-safe and bounded; default GitHub intake_mode is both and default max_candidates is 100."
-argument-hint: "<Notion-PRD-database-URL | Confluence-space-URL | Confluence-parent-page-URL | Linear-workspace-URL | Linear-team-URL | GitHub-repo-URL | org/repo | JIRA-project-key | JQL-filter> [intake_mode=prd|build|both] [stale_after=2h] [max_candidates=100] [force=true]"
----
-
-Use the /lisa:repair-intake skill to scan the queue for stuck or half-closed items, repair GitHub PRDs whose generated top-level work is missing native child links, normalize GitHub issues missing official Lisa lifecycle labels into the configured PRD/build `ready` lane, and repair every materially actionable candidate inside `max_candidates` (default 100). For GitHub queues, default `intake_mode` to `both` when the caller omits it. $ARGUMENTS

package/plugins/lisa-cursor/commands/research.md

@@ -1,6 +0,0 @@
----
-description: "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) via lisa:prd-source-write — no loose document. prd_ready=true creates it prd-ready for auto-pickup by lisa:intake; default is draft for the Plan flow / human review."
-argument-hint: "<problem-statement-or-feature-idea> [prd_ready=true|false]"
----
-
-Use the /lisa:research skill to research the problem and create a PRD in the configured source — in draft state by default, or prd-ready when prd_ready=true. $ARGUMENTS

package/plugins/lisa-cursor/commands/review/local.md

@@ -1,6 +0,0 @@
----
-description: "Review local branch changes compared to main"
-allowed-tools: ["Skill"]
----
-
-Use the /lisa:review-local skill to review local changes.

package/plugins/lisa-cursor/commands/security/zap-scan.md

@@ -1,6 +0,0 @@
----
-description: "Run an OWASP ZAP baseline security scan locally using Docker"
-allowed-tools: ["Skill"]
----
-
-Use the /lisa:security-zap-scan skill to run an OWASP ZAP baseline security scan.

package/plugins/lisa-cursor/commands/setup/atlassian.md

@@ -1,7 +0,0 @@
----
-description: "Set up Atlassian (cloudId + acli profile) for this project. Writes the `atlassian` section of `.lisa.config.json` and enables the Atlassian MCP and/or installs acli as needed. Prerequisite for /lisa:setup:jira and /lisa:setup:confluence."
-allowed-tools: ["Skill"]
-argument-hint: "[--site=<site>] [--email=<email>]"
----
-
-Use the /lisa:setup-atlassian skill to configure Atlassian access for this project. $ARGUMENTS

package/plugins/lisa-cursor/commands/setup/confluence.md

@@ -1,7 +0,0 @@
----
-description: "Set up Confluence as the PRD source for this project. Writes the `confluence` section of `.lisa.config.json` (spaceKey and/or parentPageId) and offers to set top-level `source: \"confluence\"`. Depends on /lisa:setup:atlassian."
-allowed-tools: ["Skill"]
-argument-hint: "[--space=<KEY>] [--parent=<pageId>]"
----
-
-Use the /lisa:setup-confluence skill to configure Confluence as the PRD source. $ARGUMENTS

package/plugins/lisa-cursor/commands/setup/github.md

@@ -1,7 +0,0 @@
----
-description: "Set up GitHub Issues as the tracker and/or PRD source for this project. Verifies the gh CLI, resolves org/repo, scaffolds the `status:*` (build) and/or `prd-*` (PRD) label namespaces, writes the `github` section of `.lisa.config.json`, and can document optional GitHub ProjectV2 coordination before offering top-level `tracker: \"github\"` / `source: \"github\"`. No /lisa:setup:atlassian prerequisite."
-allowed-tools: ["Skill"]
-argument-hint: "[--repo=<org/repo>]"
----
-
-Use the /lisa:setup-github skill to configure GitHub as the tracker and/or PRD source. $ARGUMENTS

package/plugins/lisa-cursor/commands/setup/jira.md

@@ -1,7 +0,0 @@
----
-description: "Set up JIRA as the tracker for this project. Writes `jira.project` and offers to set top-level `tracker: \"jira\"` in `.lisa.config.json`. Depends on /lisa:setup:atlassian (needs cloudId)."
-allowed-tools: ["Skill"]
-argument-hint: "[--project=<KEY>]"
----
-
-Use the /lisa:setup-jira skill to configure JIRA as the project tracker. $ARGUMENTS

package/plugins/lisa-cursor/commands/setup/linear.md

@@ -1,7 +0,0 @@
----
-description: "Set up Linear as the tracker and/or PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in keychain), resolves the workspace slug and team key, scaffolds the `status:*` issue-label (build) and/or `prd-*` project-label (PRD) namespaces, writes the `linear` section of `.lisa.config.json`, and offers to set top-level `tracker: \"linear\"` / `source: \"linear\"`. No /lisa:setup:atlassian prerequisite."
-allowed-tools: ["Skill"]
-argument-hint: "[--workspace=<slug>] [--team=<KEY>]"
----
-
-Use the /lisa:setup-linear skill to configure Linear as the tracker and/or PRD source. $ARGUMENTS

package/plugins/lisa-cursor/commands/setup/notion.md

@@ -1,7 +0,0 @@
----
-description: "Set up Notion as the PRD source for this project. Walks the user through creating a workspace-scoped internal-integration token, sharing the PRD database with it, and stores the token in OS keychain. Writes `notion.workspaceId`, `notion.prdDatabaseId`, and `notion.values` into `.lisa.config.json`. Offers to set top-level `source: \"notion\"`."
-allowed-tools: ["Skill"]
-argument-hint: "[--database=<uuid>] [--workspace=<slug>]"
----
-
-Use the /lisa:setup-notion skill to configure Notion as the PRD source. $ARGUMENTS

package/plugins/lisa-cursor/commands/setup-automations.md

@@ -1,6 +0,0 @@
----
-description: "Set up the recurring Lisa automations on the local workstation using the runtime's native scheduler (Codex automations / Claude /schedule): intake-repair (60 min), intake PRD (60 min), intake tickets (10 min), exploratory-bugs (daily), exploratory-prds (daily). A declarative spec — it states what to schedule and how often; the runtime's native automation mechanism does the creating. auto-start-prds / auto-start-tickets control whether ideated PRDs / filed bug tickets are created auto-pickup-ready (default: left for human review)."
-argument-hint: "[auto-start-prds=true|false] [auto-start-tickets=true|false]"
----
-
-Use the /lisa:setup-automations skill to create the five recurring Lisa automations via this runtime's native scheduler (Codex automations / Claude /schedule), passing the auto-start-prds / auto-start-tickets flags through to the exploratory automations. $ARGUMENTS

package/plugins/lisa-cursor/commands/sync-down.md

@@ -1,7 +0,0 @@
----
-description: "Back-sync an environment branch down the deploy chain (hotfix propagation) on demand"
-allowed-tools: ["Skill"]
-argument-hint: "[source-env-or-branch]"
----
-
-Use the /lisa:sync-down skill to back-sync an environment branch down the deploy chain — deriving the source→target chain from `.lisa.config.json` `deploy.order` + `deploy.branches`, then merging, resolving conflicts, opening PRs, and enabling auto-merge for each downward hop. $ARGUMENTS

package/plugins/lisa-cursor/commands/tear-down-automations.md

@@ -1,6 +0,0 @@
----
-description: "Remove the recurring Lisa automations /setup-automations created for this project (the lisa-auto-<project>-* set) using the runtime's native scheduler (Codex automations / Claude /schedule). A declarative spec — it states which automations to remove; the runtime's native mechanism does the removing. Removes only this project's Lisa automations, never others."
-argument-hint: ""
----
-
-Use the /lisa:tear-down-automations skill to remove this project's lisa-auto-<project>-* automations via this runtime's native scheduler (Codex automations / Claude /schedule), leaving other projects' and non-Lisa automations untouched. $ARGUMENTS

package/plugins/lisa-cursor/commands/validate-tracker-mapping.md

@@ -1,15 +0,0 @@
----
-description: "Detect (and optionally repair) drift between a project's configured Lisa status/label mappings and the live tracker/source workflow names. Read-only by default; repairs the config to canonical live names with repair=true. Audits the current repo or sweeps many via projects=/workspaces=."
-argument-hint: "[projects=<glob> | workspaces=<file> [filter=<substr>]] [lane=build|prd|both] [repair=true]"
----
-
-Use the /lisa:validate-tracker-mapping skill to check whether the status/label names in `.lisa.config.json` still match the live tracker and PRD source — catching renames, deletions, and case drift (e.g. config `On Stg` vs live `ON STG`). Read-only by default; pass `repair=true` to rewrite the config to the canonical live names. $ARGUMENTS
-
-Common usage:
-
-- `/lisa:validate-tracker-mapping` — audit the current repo's mapping (read-only).
-- `/lisa:validate-tracker-mapping repair=true` — audit and repair config drift in the current repo.
-- `/lisa:validate-tracker-mapping projects=~/workspace/geminisportsai/projects/*` — sweep every Lisa project under a directory.
-- `/lisa:validate-tracker-mapping workspaces=~/workspace/lisa/.lisa.workspaces.json filter=geminisportsai` — sweep the projects in a workspaces file whose paths match a substring.
-
-Use this when you suspect a JIRA/GitHub/Linear/Notion status, label, or option was renamed or deleted out from under Lisa — the failure mode that leaves builds unable to find their completion transition and items silently stuck. Run it read-only (or on a schedule) to detect drift; run it with `repair=true` to fix the config. Repair only ever edits the config to match the live names — it never renames anything in the tracker.

package/plugins/lisa-cursor/commands/verify-prd.md

@@ -1,6 +0,0 @@
----
-description: "Initiative-level PRD acceptance gate. Reads a shipped PRD and its generated child work, confirms all generated top-level work is terminal, then runs spec-conformance against the PRD plus empirical verification of the shipped surface. On a CONFORMS verdict with all checks passing it transitions the PRD shipped → verified with evidence; on a conformance miss (PARTIAL/DIVERGES) or any failing empirical check it re-opens the PRD shipped → ticketed (never blocked), creates build-ready fix tickets for the gaps, and posts a failure report — the fix tickets auto-build, the PRD re-ships, and it re-verifies (a self-healing loop). Idempotent across re-runs."
-argument-hint: "<prd>"
----
-
-Use the /lisa:verify-prd skill to read the PRD, confirm its generated top-level work is terminal, run spec-conformance against the PRD and empirical verification of the shipped surface, then transition the PRD shipped → verified with evidence on a pass, or — on a fail — re-open it shipped → ticketed (never blocked) and create build-ready fix tickets that auto-build and trigger a re-verify. $ARGUMENTS

package/plugins/lisa-cursor/commands/verify.md

@@ -1,6 +0,0 @@
----
-description: "Ship and verify code. Commits, opens PR, handles review loop, merges, monitors deploy, and runs remote verification in target environment. Folds in /ship."
-argument-hint: "[commit-message-hint]"
----
-
-Use the /lisa:verify skill to commit, push, PR, merge, deploy, and verify in the target environment. $ARGUMENTS

package/plugins/lisa-cursor/commands/wiki/install.md

@@ -1,7 +0,0 @@
----
-description: "Enable the LLM Wiki kernel (lisa-wiki plugin) in this project so its setup skill becomes discoverable. Edits .claude/settings.json to enable lisa-wiki@lisa and confirm the CodySwannGT/lisa marketplace, then verifies the Codex overlay (.codex/skills/lisa) already carries the wiki kernel. Does NOT scaffold the wiki itself — after install, reload the runtime and run /setup:wiki (Claude) or $lisa-wiki-setup (Codex)."
-allowed-tools: ["Skill"]
-argument-hint: ""
----
-
-Use the /lisa:wiki-install skill to enable the lisa-wiki plugin in this project. $ARGUMENTS

package/plugins/lisa-cursor/skills/acceptance-criteria/SKILL.md

@@ -1,71 +0,0 @@
----
-name: acceptance-criteria
-description: "Acceptance criteria definition. Gherkin user flows (Given/When/Then), error states, UX concerns, and empirical verification from the user perspective."
----
-
-# Acceptance Criteria
-
-Evaluate changes from a non-technical user's perspective. Define acceptance criteria and verify behavior matches requirements.
-
-## Analysis Process
-
-1. **Understand the user goal** -- what problem does this solve for the end user?
-2. **Define user flows** -- step-by-step paths through the feature, including happy path and error paths
-3. **Write acceptance criteria** -- testable conditions from the user's perspective
-4. **Identify UX concerns** -- confusing interactions, missing feedback, accessibility issues
-5. **Map error states** -- what happens when things go wrong, and what the user sees
-6. **Run the feature** -- execute scripts, call APIs, or trigger the described behavior to verify empirically
-7. **Compare output to requirements** -- does actual behavior match expectations?
-
-## Output Format
-
-Structure findings as:
-
-```
-## Product Analysis
-
-### User Goal
-[1-2 sentence summary of what the user wants to accomplish]
-
-### User Flows (Gherkin)
-
-#### Happy Path
-Given [precondition]
-When [action]
-Then [expected outcome]
-
-#### Error Path: [description]
-Given [precondition]
-When [action that fails]
-Then [error handling behavior]
-
-### Acceptance Criteria
-- [ ] [criterion from user perspective]
-
-### UX Concerns
-- [concern] -- impact on user experience
-
-### Error Handling Requirements
-| Error Condition | User Sees | User Can Do |
-|----------------|-----------|-------------|
-
-### Verification Results
-For each acceptance criterion:
-- **Criterion:** [what was expected]
-- **Result:** Pass / Fail / Not Yet Testable
-- **Evidence:** [what was observed]
-
-### Out of Scope
-- [thing that might be expected but is not part of this work]
-```
-
-## Rules
-
-- Write acceptance criteria from the user's perspective, not the developer's
-- Every user flow must include at least one error path
-- Use Gherkin format (Given/When/Then) for user flows to enable direct translation into test cases
-- When verifying, always run the feature -- never review by only reading code
-- If you cannot run the feature (missing dependencies, services unavailable), report as a blocker -- do not guess
-- If the changes are purely internal (refactoring, config, tooling), report "No user-facing impact" and explain why
-- Do not propose UX changes beyond what was described -- flag scope concerns instead
-- Assume the reviewer has no technical background