@codyswann/lisa 2.119.0 → 2.121.0

package/plugins/lisa-cursor/skills/setup-notion/SKILL.md

@@ -0,0 +1,316 @@
+---
+name: setup-notion
+description: "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\"`."
+allowed-tools: ["Bash", "Read", "Write", "Edit", "Skill", "AskUserQuestion"]
+---
+
+# Setup Notion: $ARGUMENTS
+
+Provision Notion access for this project. After this skill runs, `.lisa.config.json` contains `notion.workspaceId` and `notion.prdDatabaseId`, and the OS keychain has a `lisa-notion` entry keyed by the workspaceId.
+
+## Workflow
+
+### Step 0 — Pick a setup path
+
+Ask via `AskUserQuestion`:
+
+> How do you want lisa to talk to Notion for this project?
+>
+> 1. **MCP-only (simplest)** — authenticate the Notion MCP once via browser OAuth; lisa uses it for every operation. Best for: single-workspace developers on a personal laptop. New developers onboard with one OAuth flow, no token sharing, no rotation pain when someone leaves. Skip the rest of this setup.
+> 2. **MCP + internal-integration token (recommended for teams)** — MCP for interactive dev, internal-integration token in keychain for headless / CI / multi-workspace. Continue through token-create steps.
+> 3. **Token-only (headless / CI)** — store a workspace-scoped internal-integration token in the OS keychain; lisa uses curl for everything. Best for: CI pipelines, headless containers. Continue through token-create steps.
+
+If the user picks (1) and the MCP is already authenticated to the right workspace (verify by attempting to fetch the configured `prdDatabaseId` via the MCP — success means identity match), write only `notion.workspaceId`, `notion.prdDatabaseId`, and `notion.statusProperty` into `.lisa.config.json` and skip to Step 8 (top-level source offer). If the MCP isn't authed yet, instruct the user to run `mcp__claude_ai_Notion__authenticate` (or the plugin equivalent) and complete the OAuth flow, then re-verify. The PRD database still needs to be shared with the OAuth-granted access — Notion's per-page sharing model applies to OAuth identities the same way it does to internal-integration tokens.
+
+If the user picks (2) or (3), continue through the rest of the steps; the token gets stored in addition to (or instead of) the MCP session.
+
+### Step 1 — Open the Notion integration page
+
+```bash
+case "$(uname -s)" in
+  Darwin) open "https://www.notion.so/profile/integrations" ;;
+  Linux)  xdg-open "https://www.notion.so/profile/integrations" 2>/dev/null ;;
+  MINGW*|MSYS*|CYGWIN*) start "https://www.notion.so/profile/integrations" ;;
+esac
+```
+
+Print instructions for the user:
+
+```
+1. Click "New integration".
+2. Name it: lisa-<project-name>  (e.g., lisa-gemini, lisa-acme — pick something descriptive).
+3. Associated workspace: pick the workspace your PRDs live in.
+4. Type: "Internal integration".
+5. Capabilities: leave defaults (Read content, Update content, Insert content). No comment / user-info capabilities needed.
+6. Click Save.
+7. On the integration's detail page, click "Show" next to "Internal Integration Token".
+8. Copy the token — starts with `ntn_`. Atlassian-style scoped tokens have a `=<CRC>` suffix; Notion's do NOT, but tokens are still 50+ chars. Watch for clipboard-truncation in some terminals.
+```
+
+### Step 2 — Identify the workspace
+
+The user picks a stable identifier for this workspace. Two options:
+
+- **Workspace name** (human-readable, e.g., `Gemini Sports`). Easy to recognize, can be ambiguous if a workspace is renamed in Notion. Recommended.
+- **Workspace UUID** (returned by Notion's API). Stable but opaque.
+
+Default to the workspace name. After the user stores the token (Step 4), Step 5's `/users/me` call surfaces the actual `bot.workspace_name`; if it differs from what the user typed (capitalization, trailing whitespace), prompt to confirm.
+
+```bash
+WORKSPACE=$(jq -r '.notion.workspaceId // empty' .lisa.config.json 2>/dev/null)
+if [ -z "$WORKSPACE" ]; then
+  # Prompt the user — accept any non-empty string. They pick the slug; we just store it.
+  read -p "Workspace identifier (any stable slug, e.g. 'gemini-sports'): " WORKSPACE
+fi
+```
+
+### Step 3 — Share the PRD database with the integration
+
+This is **non-optional**. Notion's permission model is share-based — the integration cannot see any pages or databases until the user explicitly grants access.
+
+Print instructions:
+
+```
+1. In Notion, navigate to your PRD database (or the parent page containing it).
+2. Click the "..." menu in the top right of the database.
+3. Click "Connections".
+4. Find "lisa-<project>" in the list and click "Connect".
+5. Confirm any prompts about granting access.
+
+The connection cascades to all child pages of the database by default. New PRDs added under the database automatically inherit access.
+```
+
+If `--database=<uuid>` was passed in `$ARGUMENTS`, use it; otherwise prompt:
+
+```bash
+DATABASE_ID=$(jq -r '.notion.prdDatabaseId // empty' .lisa.config.json 2>/dev/null)
+if [ -z "$DATABASE_ID" ]; then
+  cat <<EOF
+Paste the PRD database URL or ID:
+  - URL form: https://notion.so/<workspace>/<database-id>?v=...
+  - ID form:  32-char UUID with or without dashes
+EOF
+  read -p "Database: " DB_INPUT
+  # Extract UUID from URL if needed.
+  DATABASE_ID=$(echo "$DB_INPUT" | grep -oE '[0-9a-f]{8}-?[0-9a-f]{4}-?[0-9a-f]{4}-?[0-9a-f]{4}-?[0-9a-f]{12}' | head -1)
+  if [ -z "$DATABASE_ID" ]; then
+    echo "Error: could not extract a UUID from '$DB_INPUT'." >&2
+    exit 1
+  fi
+fi
+```
+
+### Step 4 — Store the token via OS keychain (token never enters chat)
+
+Same security posture as `setup-atlassian`. Print a platform-specific clipboard-pipe command for the user to run **in their own terminal**:
+
+```bash
+case "$(uname -s)" in
+  Darwin)
+    cat <<EOF
+1. Copy the integration token from the Notion page.
+2. Run this single line in your terminal (leading space keeps it out of zsh history):
+
+    security delete-generic-password -s lisa-notion -a "$WORKSPACE" 2>/dev/null;  TOK="\$(pbpaste)"; security add-generic-password -U -s lisa-notion -a "$WORKSPACE" -w "\$TOK"; unset TOK
+
+The token is piped from clipboard straight to keychain — never enters the prompt or chat.
+EOF
+    ;;
+  Linux)
+    if command -v secret-tool >/dev/null 2>&1; then
+      if   command -v wl-paste >/dev/null 2>&1; then CLIP=wl-paste
+      elif command -v xclip    >/dev/null 2>&1; then CLIP="xclip -selection clipboard -o"
+      elif command -v xsel     >/dev/null 2>&1; then CLIP="xsel --clipboard --output"
+      else CLIP="cat"
+      fi
+      cat <<EOF
+1. Copy the integration token.
+2. Run this in your terminal:
+
+   secret-tool clear service lisa-notion account "$WORKSPACE" 2>/dev/null; printf '%s' "\$($CLIP)" | secret-tool store --label="Lisa Notion ($WORKSPACE)" service lisa-notion account "$WORKSPACE"
+
+(If no clipboard tool is installed: the command reads from stdin — paste, Ctrl-D.)
+EOF
+    else
+      cat <<EOF
+libsecret / secret-tool not installed. Options:
+  1. Install: sudo apt install libsecret-tools  (then re-run /lisa:setup:notion).
+  2. Env-var fallback (headless / CI / Docker):
+       export NOTION_API_TOKEN_$(echo "$WORKSPACE" | tr '[:upper:]-' '[:lower:]_')="<paste-token>"
+     Plaintext on disk — only acceptable on ephemeral / CI environments.
+EOF
+    fi
+    ;;
+  MINGW*|MSYS*|CYGWIN*)
+    cat <<EOF
+PowerShell:
+
+  \$tok = Get-Clipboard; cmdkey /generic:"lisa-notion-$WORKSPACE" /user:"$WORKSPACE" /pass:"\$tok"; Remove-Variable tok
+EOF
+    ;;
+esac
+```
+
+**Never accept the token via chat or stdin into this skill.** Wait for the user to confirm storage.
+
+### Step 5 — Verify the token + workspace match
+
+Use the same lookup ladder `notion-access` uses:
+
+```bash
+read_notion_token() {
+  local workspace="$1"
+  [ -n "$NOTION_API_TOKEN" ] && { echo "$NOTION_API_TOKEN"; return; }
+  local slug=$(echo "$workspace" | tr '[:upper:]-' '[:lower:]_')
+  local varname="NOTION_API_TOKEN_${slug}"
+  [ -n "${!varname}" ] && { echo "${!varname}"; return; }
+  case "$(uname -s)" in
+    Darwin)  security find-generic-password -s lisa-notion -a "$workspace" -w 2>/dev/null ;;
+    Linux)   command -v secret-tool >/dev/null && secret-tool lookup service lisa-notion account "$workspace" 2>/dev/null ;;
+    MINGW*|MSYS*|CYGWIN*)
+      # `cmdkey /generic ... /pass:` stores the secret in Windows Credential Manager, but
+      # `cmdkey /list` never prints stored passwords (by design). Read the CredentialBlob
+      # back via the Win32 CredRead API through PowerShell; pass the target name via an env
+      # var to dodge nested quoting, and strip the CRLF powershell.exe appends.
+      LISA_CRED_TARGET="lisa-notion-${workspace}" powershell.exe -NoProfile -NonInteractive -Command '
+Add-Type -TypeDefinition @"
+using System;
+using System.Runtime.InteropServices;
+public static class LisaCred {
+  [StructLayout(LayoutKind.Sequential)]
+  private struct CREDENTIAL {
+    public int Flags; public int Type; public IntPtr TargetName; public IntPtr Comment;
+    public System.Runtime.InteropServices.ComTypes.FILETIME LastWritten;
+    public int CredentialBlobSize; public IntPtr CredentialBlob; public int Persist;
+    public int AttributeCount; public IntPtr Attributes; public IntPtr TargetAlias; public IntPtr UserName;
+  }
+  [DllImport("advapi32.dll", CharSet=CharSet.Unicode, SetLastError=true)]
+  private static extern bool CredRead(string target, int type, int flags, out IntPtr credential);
+  [DllImport("advapi32.dll")] private static extern void CredFree(IntPtr cred);
+  public static string Read(string target) {
+    IntPtr p;
+    if (!CredRead(target, 1, 0, out p)) { return null; }
+    try {
+      CREDENTIAL c = (CREDENTIAL)Marshal.PtrToStructure(p, typeof(CREDENTIAL));
+      if (c.CredentialBlobSize == 0) { return String.Empty; }
+      return Marshal.PtrToStringUni(c.CredentialBlob, c.CredentialBlobSize / 2);
+    } finally { CredFree(p); }
+  }
+}
+"@
+[LisaCred]::Read($env:LISA_CRED_TARGET)' 2>/dev/null | tr -d '\r' ;;
+  esac
+}
+
+TOKEN=$(read_notion_token "$WORKSPACE")
+if [ -z "$TOKEN" ]; then
+  echo "Error: token not retrievable after store. Re-run Step 4." >&2
+  exit 1
+fi
+
+# Notion tokens — sanity length check. Internal-integration tokens are ~50+ chars; if drastically shorter, a paste truncation happened.
+if [ ${#TOKEN} -lt 40 ]; then
+  echo "Warning: token is ${#TOKEN} chars — Notion tokens are typically 50+. Possible truncation." >&2
+fi
+
+ME=$(curl -s -H "Authorization: Bearer $TOKEN" \
+            -H "Notion-Version: 2022-06-28" \
+            "https://api.notion.com/v1/users/me")
+ME_WORKSPACE=$(echo "$ME" | jq -r '.bot.workspace_name // empty')
+
+if [ -z "$ME_WORKSPACE" ]; then
+  echo "Error: token failed Notion /users/me probe. Response: $ME" >&2
+  exit 1
+fi
+
+# If the user typed a workspace name that differs from what Notion returns, prompt to align.
+if [ "$ME_WORKSPACE" != "$WORKSPACE" ]; then
+  cat <<EOF
+The token belongs to workspace '$ME_WORKSPACE', but you provided '$WORKSPACE' as the identifier.
+Use the Notion-returned name for consistency? (recommended — connection-match check uses this string)
+EOF
+  # AskUserQuestion: replace WORKSPACE with $ME_WORKSPACE? recommended yes
+fi
+
+# Verify database visibility too (Notion's share model means the token sees only what's been shared).
+DB_PROBE=$(curl -s -o /tmp/setup-notion-db -w "%{http_code}" \
+  -H "Authorization: Bearer $TOKEN" -H "Notion-Version: 2022-06-28" \
+  "https://api.notion.com/v1/databases/$DATABASE_ID")
+if [ "$DB_PROBE" != "200" ]; then
+  cat >&2 <<EOF
+Error: integration cannot see database $DATABASE_ID (HTTP $DB_PROBE).
+The most likely cause is that you skipped Step 3 — sharing the database with the integration.
+Open the database in Notion → "..." → Connections → add 'lisa-<project>' → retry.
+EOF
+  exit 1
+fi
+
+echo "Token validated. Workspace: $ME_WORKSPACE. Database visible."
+```
+
+### Step 6 — Detect lifecycle value names
+
+Read the database schema and find the `Status` property's value list. Compare to lisa defaults and prompt for overrides if names differ.
+
+```bash
+DB_SCHEMA=$(curl -s -H "Authorization: Bearer $TOKEN" -H "Notion-Version: 2022-06-28" \
+  "https://api.notion.com/v1/databases/$DATABASE_ID")
+STATUS_PROP=$(jq -r '.properties | to_entries[] | select(.value.type == "status" or .value.type == "select") | .key' <<<"$DB_SCHEMA" | head -1)
+STATUS_VALUES=$(jq -r --arg p "$STATUS_PROP" '.properties[$p] | (.status.options // .select.options) | .[].name' <<<"$DB_SCHEMA")
+```
+
+For each lisa role (`draft`, `ready`, `in_review`, `blocked`, `ticketed`, `shipped`, `verified`), check if its default name (`Draft`, `Ready`, etc.; `Verified` for `verified`) appears in `$STATUS_VALUES`. If a role's default is missing but a similar-looking value exists, prompt the user to map it via `AskUserQuestion`. If a role has no plausible match, prompt to either create the value in Notion or accept that the lifecycle stage is unrepresented. This find-or-create-or-accept path is idempotent per role: a value already present (default or mapped) is reused untouched, so re-running never duplicates a status option.
+
+`verified` is the terminal lifecycle state after `shipped` (the `verified` role from the `config-resolution` rule, #591): `/lisa:verify-prd` transitions a Notion PRD into it once the shipped product has been empirically verified against the PRD. Notion models the PRD lifecycle as `Status` (or `select`) property options rather than labels, so `verified` is mapped or created through the exact same path as every other role above — and, like them, persisted to `notion.values.verified` when the workspace uses a non-default option name.
+
+Collect overrides as a partial values map. Only write keys that differ from defaults — `verified` included, so a non-default `Verified` option name lands in `notion.values.verified`.
+
+### Step 7 — Write `.lisa.config.json`
+
+```bash
+jq --arg ws "$WORKSPACE" --arg db "$DATABASE_ID" --arg sp "$STATUS_PROP" --argjson values "$VALUES_JSON" '
+  .notion = ((.notion // {})
+    | .workspaceId = $ws
+    | .prdDatabaseId = $db
+    | (if $sp != "" then .statusProperty = $sp else . end)
+    | (if $values != {} then .values = $values else . end))
+' .lisa.config.json > .lisa.config.json.tmp \
+   && mv .lisa.config.json.tmp .lisa.config.json
+```
+
+`VALUES_JSON` is `{}` if all roles use the default names; otherwise contains only the overrides.
+
+### Step 8 — Offer to set top-level `source`
+
+If `.source` is unset or differs from `"notion"`, ask via `AskUserQuestion`:
+
+> Notion is configured. Set top-level `source: "notion"` so `/lisa:intake` (with no args) scans this database for PRDs?
+
+If yes:
+
+```bash
+jq '.source = "notion"' .lisa.config.json > .lisa.config.json.tmp \
+   && mv .lisa.config.json.tmp .lisa.config.json
+```
+
+### Step 9 — Verify
+
+```bash
+jq -e '.notion.workspaceId and .notion.prdDatabaseId' .lisa.config.json >/dev/null
+echo "Token validated (${#TOKEN} chars). Workspace: $ME_WORKSPACE. Database: $DATABASE_ID."
+```
+
+Report success with the resolved workspace, database, status property name, and value overrides (if any), confirming all lifecycle roles — including the terminal `verified` — were detected, mapped, or flagged for creation. Direct the user to `/lisa:intake` to test.
+
+## Idempotency
+
+- Re-running this skill replaces fields in the `notion` section without disturbing others. The keychain entry update in Step 4 is the user's manual action — they re-run the same `security` / `secret-tool` / `cmdkey` command.
+- If `notion.workspaceId` and `notion.prdDatabaseId` already exist in config, skip the prompts in Steps 2–3 and go straight to verification.
+
+## Rules
+
+- Never write the token to `.lisa.config.json`. Tokens stay in keychain or env.
+- Never accept a token via this skill's stdin. Always go through the platform's clipboard-pipe pattern so the value never enters the LLM context.
+- Never auto-create the Notion integration via API — Notion offers no programmatic creation flow, and adding one would require building lisa as a public OAuth app (out of scope here).
+- Never proceed past Step 5 with an unverified token + workspace. Silent cross-workspace operations are exactly the multi-account hazard this design exists to prevent.
+- If the user has multiple Notion accounts, each project's `.lisa.config.local.json` `notion.workspaceId` is the sole disambiguator. There is no "active workspace" concept on the Notion side — the token IS the workspace binding.

package/plugins/lisa-cursor/skills/spec-conformance/SKILL.md

@@ -0,0 +1,159 @@
+---
+name: spec-conformance
+description: "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."
+allowed-tools: ["Read", "Glob", "Grep", "Bash", "Skill", "mcp__atlassian__getJiraIssue", "mcp__atlassian__searchJiraIssuesUsingJql", "mcp__atlassian__getAccessibleAtlassianResources"]
+---
+
+# Spec Conformance: $ARGUMENTS
+
+Compare shipped work against its spec section-by-section. This is the "accountant lens" — did the work ship exactly what was written, nothing more, nothing less? It is NOT UX review (that's `product-specialist`) and it is NOT empirical system verification (that's `verification-specialist`). Run it alongside those, not instead of them.
+
+## Phase 1 — Resolve Spec Source
+
+Determine the source of truth for this work. Check in this order:
+
+1. **Explicit spec argument** — plan file path (e.g. `.claude/plans/<name>.md`), JIRA key (e.g. `PROJ-123`), Linear key, GitHub issue URL, or PRD path passed as `$ARGUMENTS`.
+2. **Linked JIRA ticket** — if the current branch or PR body references a JIRA key, use it.
+3. **PR body** — if the PR description contains a "Spec" or "Ticket" link, follow it.
+4. **Plan file on disk** — check `.claude/plans/` for an active plan matching the branch name.
+
+If none of the above resolves, stop. Do not guess what the spec was. Report: "No spec source found — pass a plan file, ticket key, or PR URL."
+
+Based on the source, load the full spec:
+
+| Source | How to Load |
+|--------|-------------|
+| Plan file (`.md`) | `Read` the file |
+| JIRA key, GitHub issue ref, or Linear identifier | Invoke `/tracker-read <ref>` (vendor-neutral; dispatches to `/jira-read-ticket`, `/github-read-issue`, or `/linear-read-issue` per `.lisa.config.json` `tracker`) to get the full context bundle (primary item + epic / project / parent + linked items) |
+| PRD | `Read` the file or fetch via Notion / Confluence MCP, or `gh issue view` for a GitHub PRD |
+
+## Phase 2 — Extract Requirements
+
+Parse the spec into a structured requirement list. Do NOT skip sections — every requirement becomes a row in the coverage matrix.
+
+Sections to extract:
+
+| Section | What to Extract | Classification |
+|---------|-----------------|----------------|
+| Acceptance Criteria | Each Gherkin scenario or bullet | `acceptance` |
+| Out of Scope | Each excluded item | `excluded` (flags scope creep) |
+| Technical Approach | Each concrete implementation commitment (not narrative) | `technical` |
+| Validation Journey Assertions | Each `Assertion:` bullet | `assertion` |
+| Deliverables | Each explicit deliverable (migration, doc, endpoint, script) | `deliverable` |
+| Plan file tasks | Each task marked complete in the plan | `task` |
+| Linked blocker resolutions | Each `is blocked by` that required work in this ticket | `blocker` |
+
+If an acceptance criterion is not in Gherkin, still extract it as a requirement — but flag it as `LOW_SPECIFICITY` so the verdict downgrades.
+Downgrade rule: if any `LOW_SPECIFICITY` requirement exists, the maximum possible verdict is `PARTIAL` unless the spec is tightened and re-evaluated.
+
+Skip narrative prose (Context / Business Value) — it isn't directly verifiable. Reference it only when explaining a miss.
+
+## Phase 3 — Inspect Shipped Work
+
+Gather evidence of what was actually shipped:
+
+1. **Diff scope** — the commits on the current branch vs. the default branch:
+   ```bash
+   BASE_BRANCH="$(git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@')"
+   git log "${BASE_BRANCH}"..HEAD --oneline
+   git diff "${BASE_BRANCH}"...HEAD --stat
+   ```
+2. **File-level changes** — per-file diff for each changed file:
+   ```bash
+   git diff "${BASE_BRANCH}"...HEAD -- <file>
+   ```
+3. **Test coverage** — which tests were added/changed for the requirements:
+   ```bash
+   git diff "${BASE_BRANCH}"...HEAD -- '**/*.test.*' '**/*.spec.*'
+   ```
+4. **Empirical evidence** — output of `verification-specialist` if available (proof artifacts, API captures, UI screenshots, DB queries). If that report isn't in context, ask the caller for it before proceeding — do not substitute reading code for running the system.
+5. **PR description** — `gh pr view --json title,body,files` if a PR exists.
+6. **Deployed state** — if the verification phase already hit a deployed environment, use those captures.
+
+Do NOT run the system yourself — that's the verification-specialist's job. Your job is to map their evidence to the spec.
+
+## Phase 4 — Build Coverage Matrix
+
+For every requirement extracted in Phase 2, produce one row:
+
+| Column | Value |
+|--------|-------|
+| Requirement ID | Stable identifier (e.g. `AC-1`, `OOS-2`, `ASSERT-3`) |
+| Classification | `acceptance` / `excluded` / `technical` / `assertion` / `deliverable` / `task` / `blocker` |
+| Requirement Text | Verbatim from spec |
+| Evidence | Specific pointer — file:line, test name, verification report section, PR file, screenshot name |
+| Status | `MATCH` / `PARTIAL` / `MISSING` / `SCOPE_CREEP_VIOLATION` |
+| Notes | One line — why partial, what's missing, or where evidence is thin |
+
+### Status definitions
+
+- **`MATCH`** — requirement is implemented AND there is empirical evidence it works (test + verification report).
+- **`PARTIAL`** — implementation exists but evidence is incomplete (e.g. code present, no test; or test present, no run-time verification).
+- **`MISSING`** — requirement has no corresponding implementation OR no evidence at all.
+- **`SCOPE_CREEP_VIOLATION`** — used for `excluded` classification only. An Out-of-Scope item appears to have been shipped anyway. This is a different failure than a miss — it means the agent exceeded the spec.
+
+### Scope creep detection
+
+Separately from the matrix, scan the diff for work NOT traceable to any requirement. For each such change:
+
+- Identify the file/module
+- Summarize the change in one line
+- Classify as `UNTRACEABLE_CHANGE` (not necessarily wrong — refactors often land here — but MUST be surfaced)
+
+Untraceable changes are not automatic failures. They become findings the human reviews.
+
+## Phase 5 — Verdict
+
+Produce exactly one verdict:
+
+- **`CONFORMS`** — every requirement is `MATCH`. No `SCOPE_CREEP_VIOLATION`. Untraceable changes, if any, are clearly refactors or test support.
+- **`PARTIAL`** — some requirements are `PARTIAL` but none are `MISSING` or `SCOPE_CREEP_VIOLATION`. Work is mostly there but evidence is thin.
+- **`DIVERGES`** — at least one requirement is `MISSING`, OR at least one `SCOPE_CREEP_VIOLATION` exists, OR there are substantive untraceable changes that materially alter behavior.
+
+A verdict of `PARTIAL` or `DIVERGES` blocks task completion. The caller must resolve the gaps (implement the miss, remove the creep, add the missing evidence) before re-running.
+
+## Phase 6 — Output
+
+Structure the report so it can be pasted into a PR comment or JIRA ticket:
+
+```text
+## Spec Conformance Report
+
+**Spec source:** <plan file / JIRA key / Linear / GitHub issue / PRD>
+**Shipped scope:** <N commits, M files, K tests on branch <branch> vs <default-branch>>
+
+### Coverage Matrix
+
+| ID | Class | Requirement | Evidence | Status | Notes |
+|----|-------|-------------|----------|--------|-------|
+| AC-1 | acceptance | [text] | [pointer] | MATCH | |
+| AC-2 | acceptance | [text] | — | MISSING | No corresponding code or test |
+| OOS-1 | excluded | [text] | src/foo.ts:42 | SCOPE_CREEP_VIOLATION | Added anyway |
+| ASSERT-1 | assertion | [text] | verification-report §2 | PARTIAL | Asserted in code, not run in verification |
+
+### Untraceable Changes
+- src/utils/helpers.ts — extracted shared regex constant (refactor, no behavior change)
+- src/auth/session.ts — added retry logic (NOT IN SPEC — verify intentional)
+
+### Verdict: CONFORMS | PARTIAL | DIVERGES
+
+**Matches:** N/Total
+**Partial:** N
+**Missing:** N
+**Scope creep violations:** N
+**Untraceable changes flagged for review:** N
+
+### Required Actions (if PARTIAL or DIVERGES)
+1. [specific action — implement X, remove Y, add test for Z, capture evidence for W]
+2. ...
+```
+
+## Rules
+
+- Never substitute "I read the code and it looks right" for empirical evidence. If verification-specialist hasn't run yet, request its report before producing a verdict.
+- Never mark a requirement `MATCH` based on the presence of code alone — evidence means test + runtime observation.
+- Always surface scope creep separately from misses. They are distinct failures.
+- Always surface untraceable changes — even benign refactors — so the human can confirm intent.
+- The Out of Scope section is load-bearing. If the spec has one, every item must appear in the matrix as `excluded`.
+- If the spec has no acceptance criteria, flag the spec itself as inadequate before running the matrix. The verdict is `DIVERGES` for spec inadequacy until criteria are added.
+- Do not invent requirements the spec didn't state. If the shipped work does something reasonable but unspecified, it becomes an untraceable change, not a match.

package/plugins/lisa-cursor/skills/task-decomposition/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: task-decomposition
+description: "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
+
+Break work into ordered, well-scoped tasks that can be independently implemented and verified.
+
+## Decomposition Process
+
+### 1. Identify Units of Work
+
+- Break the work into the smallest units that are independently valuable
+- Each unit should produce a verifiable outcome (a passing test, a working endpoint, observable behavior)
+- Avoid tasks that are too large to complete in a single session
+- Avoid tasks that are too small to be meaningful (e.g., "add an import statement")
+
+### 1.5. Preserve Cross-Repo Containers, Split Leaf Work by Repository
+
+Start from the right shape:
+
+- A source PRD may span multiple repositories.
+- Coordination containers may also span multiple repositories.
+- Buildable leaf work units must be implementable inside exactly one repository.
+
+That last point is a hard invariant — downstream validators (`jira-validate-ticket`, `github-validate-issue`, `linear-validate-issue`) gate writes on it, so a cross-repo leaf will fail to be created.
+
+Apply this rule by layer:
+
+| Layer | Repo scope |
+|-------|------------|
+| **PRD / source initiative** | MAY span repos — it describes the full initiative |
+| **Epic, Story, Spike** | MAY span repos — these are coordination containers |
+| **Task, Bug, Sub-task, Improvement** | MUST name exactly one repo — these are buildable leaf work units |
+
+If a candidate work unit naturally touches multiple repos (e.g., "add field to backend API and consume it in mobile app"), do not write it as one ticket. Instead:
+
+1. Split it into one work unit per repo (e.g., `[backend-api] Add field to /users endpoint`, `[mobile-app] Display new field on profile screen`).
+2. Group the per-repo units under a single parent Story (or Epic, if the parent Story already exists). The parent stays cross-repo; the children do not.
+3. Encode the order via `Dependencies` in step 4 — typically the producing repo (backend) blocks the consuming repo (frontend/mobile).
+4. Tag each work unit with `[repo-name]` as a summary prefix so the repo is visible in tracker lists at a glance.
+
+Reject any work unit whose acceptance criteria reference behavior in a different repo from the one it's scoped to. If you find yourself writing "and the frontend should also...", that's a signal to split.
+
+This is the **decomposition-time** strategy (greenfield — you are creating the tickets now, so a cross-repo PRD can stay whole, its Epic/Story/Spike containers can stay cross-repo, and a parent Story + per-repo children is the natural shape). It is distinct from the **work-time** strategy in the `repo-scope-split` rule, which applies when an agent picks up an *already-existing leaf ticket* to implement and discovers it spans repos: there it narrows the original in place and spins off sibling work units rather than introducing a new parent. Use the phase-appropriate one; do not mix them.
+
+### 2. Define Acceptance Criteria
+
+For each task, define what "done" looks like:
+
+- Be specific and measurable -- avoid vague criteria like "works correctly"
+- Include both positive cases (what should work) and negative cases (what should be rejected)
+- Reference exact behavior: error messages, status codes, output format, performance thresholds
+- If a task modifies existing behavior, state both the before and after
+
+### 3. Assign Verification Type
+
+Each task must have a verification method. Choose the most appropriate:
+
+| Verification Type | When to Use |
+|-------------------|-------------|
+| **Unit test** | Pure logic, data transformations, utility functions |
+| **Integration test** | Cross-module interactions, database operations, API contracts |
+| **E2E test** | User-facing workflows, multi-service interactions |
+| **Manual verification** | UI/UX behavior, visual correctness, one-time infrastructure changes |
+| **Build verification** | Compilation, type checking, linting, bundle size |
+| **Deploy verification** | Service health checks, smoke tests, monitoring dashboards |
+
+### 4. Map Dependencies
+
+- Identify which tasks must complete before others can start
+- Order tasks so that each builds on a stable foundation
+- Prefer independent tasks that can run in parallel where possible
+- Flag external dependencies (other teams, services, permissions, data) that may block progress
+
+### 5. Determine Execution Order
+
+- Place foundational tasks first (types, schemas, interfaces, shared utilities)
+- Follow with implementation tasks (business logic, handlers, services)
+- Then integration tasks (wiring, configuration, API routes)
+- Finish with verification tasks (test suites, documentation, cleanup)
+
+### 6. Assign Required Skills
+
+Map each task to the skills needed to complete it. This enables delegation to specialized agents or helps identify what expertise is required.
+
+## Output Format
+
+```
+## Task Breakdown
+
+### Task 1: [[repo-name] imperative description]
+- **Repository:** [single repo name, or N/A for Epic/Story/Spike]
+- **Acceptance criteria:**
+  - [specific, measurable criterion]
+  - [specific, measurable criterion]
+- **Verification:** [type] -- [how to verify]
+- **Dependencies:** [none | task IDs that must complete first]
+- **Skills:** [list of skills needed]
+
+### Task 2: [[repo-name] imperative description]
+- **Repository:** [single repo name, or N/A for Epic/Story/Spike]
+- **Acceptance criteria:**
+  - [specific, measurable criterion]
+- **Verification:** [type] -- [how to verify]
+- **Dependencies:** [Task 1]
+- **Skills:** [list of skills needed]
+
+### Execution Order
+1. [Task 1, Task 3] (parallel -- no dependencies)
+2. [Task 2] (depends on Task 1)
+3. [Task 4] (depends on Task 2, Task 3)
+
+### External Dependencies
+- [dependency] -- [who owns it] -- [current status]
+```
+
+## Rules
+
+- Every task must have at least one acceptance criterion that can be empirically verified
+- Do not create tasks that cannot be verified -- if you cannot define how to prove it is done, the task is not well-scoped
+- Every Task / Bug / Sub-task / Improvement is scoped to exactly one repo -- if the work spans repos, split into per-repo work units under a shared parent Story (see step 1.5)
+- Keep tasks ordered so that no task references work that has not been completed by a prior task
+- Flag any task that requires access, permissions, or external input not yet available
+- Prefer more small tasks over fewer large tasks -- smaller tasks are easier to verify and less risky to fail
+- Do not create placeholder or "TODO" tasks -- every task should describe concrete work

package/plugins/lisa-cursor/skills/task-triage/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: task-triage
+description: "8-step task triage and implementation workflow. Ensures tasks have clear requirements, dependencies, and verification plans before implementation begins."
+---
+
+# Task Triage
+
+Follow this 8-step triage process before implementing any task. Do not skip triage.
+
+## Triage Steps
+
+1. Verify you have all information needed to implement this task (acceptance criteria, design specs, environment information, dependencies, etc.). Do not make assumptions. If anything is missing, stop and ask before proceeding.
+2. Verify you have a clear understanding of the expected behavior or outcome when the task is complete. If not, stop and clarify before starting.
+3. Identify all dependencies (other tasks, services, APIs, data) that must be in place before you can complete this task. If any are unresolved, stop and raise them before starting implementation.
+4. Verify you have access to the tools, environments, and permissions needed to deploy and verify this task (e.g. CI/CD pipelines, deployment targets, logging/monitoring systems, API access, database access). If any are missing or inaccessible, stop and raise them before starting implementation.
+5. Define the tests you will write to confirm the task is implemented correctly and prevent regressions.
+6. Define the documentation you will create or update to explain the "how" and "what" behind this task so another developer understands it.
+7. If you can verify your implementation before deploying to the target environment (e.g. start the app, invoke the API, open a browser, run the process, check logs), do so before deploying.
+8. Define how you will verify the task is complete beyond a shadow of a doubt (e.g. deploy to the target environment, invoke the API, open a browser, run the process, check logs).
+
+## Implementation
+
+Use the output of the triage steps above as your guide. Do not skip triage.