@codyswann/lisa 2.21.0 → 2.23.0

package/plugins/src/base/skills/setup-jira/SKILL.md

@@ -0,0 +1,198 @@
+---
+name: setup-jira
+description: "Configure JIRA as the destination tracker for this project. Writes `jira.project` into `.lisa.config.json` and offers to set top-level `tracker: \"jira\"`. Depends on /lisa:setup:atlassian — atlassian.cloudId must already be present, otherwise this skill stops and instructs the user to run setup-atlassian first. Idempotent."
+allowed-tools: ["Bash", "Read", "Write", "Edit", "Skill", "AskUserQuestion"]
+---
+
+# Setup JIRA: $ARGUMENTS
+
+Set the JIRA project key and (optionally) make JIRA this project's destination tracker.
+
+## Workflow
+
+### Step 1 — Verify atlassian prerequisite
+
+```bash
+cloudid=$(jq -r '.atlassian.cloudId // empty' .lisa.config.json 2>/dev/null)
+if [ -z "$cloudid" ]; then
+  echo "Error: atlassian.cloudId not set. Run /lisa:setup:atlassian first." >&2
+  exit 1
+fi
+```
+
+If `atlassian` is missing, invoke `/lisa:setup-atlassian` via the Skill tool first, then resume.
+
+### Step 2 — Resolve the JIRA project key
+
+Honor any `--project=KEY` argument. Otherwise, list projects via the active access substrate:
+
+- CLI: `acli jira project list --output json`
+- MCP: `mcp__plugin_atlassian_atlassian__getVisibleJiraProjects` with `cloudId=$cloudid`
+
+If only one project is returned, pick it. If multiple, present them via `AskUserQuestion` (label = project key, description = project name) so the user picks the one this project should target.
+
+### Step 3 — Probe workflow & resolve role mapping
+
+Lisa's build lifecycle uses three role-keyed statuses (`ready` → `claimed` → `done[env]`). Defaults are `Ready`, `In Progress`, and `{dev: "On Dev", staging: "On Stg", production: "Done"}`. Probe the project's workflow to confirm these exist; prompt for overrides if not.
+
+```bash
+# Fetch a sample ticket's available transitions (or use a project-level workflow scheme query)
+# via lisa:atlassian-access operation: transitions key: <SAMPLE-KEY>
+# Collect the union of status names visible in the project.
+```
+
+For each role:
+
+1. If a status with the **default name** exists in the workflow → use the default; no config entry needed.
+2. If the default name is missing but a status with a similar role exists (e.g. `Resolved` instead of `Done`) → present the project's status list via `AskUserQuestion` and let the user pick which maps to the role.
+3. If nothing plausible exists → stop and tell the user to either add the missing status to their JIRA workflow (admin task) or pick a fallback that's close enough.
+
+Collect overrides as a partial workflow map. ONLY write keys that differ from defaults — don't bloat the config with redundant values.
+
+### Step 4 — Write `jira.project` + overrides
+
+```bash
+# Always write project key.
+jq --arg key "$PROJECT_KEY" \
+   '.jira = ((.jira // {}) | .project = $key)' \
+   .lisa.config.json > .lisa.config.json.tmp \
+   && mv .lisa.config.json.tmp .lisa.config.json
+
+# Conditionally write workflow overrides (only if any role differs from default).
+if [ -n "$WORKFLOW_OVERRIDES_JSON" ]; then
+  jq --argjson wf "$WORKFLOW_OVERRIDES_JSON" \
+     '.jira.workflow = $wf' \
+     .lisa.config.json > .lisa.config.json.tmp \
+     && mv .lisa.config.json.tmp .lisa.config.json
+fi
+```
+
+### Step 5 — Verify transition reachability (A → B → C cascade)
+
+Confirm every resolved role's status name is actually reachable in the JIRA workflow. **acli has no non-destructive workflow inspector** (the `workitem view --json` `transitions` key is always `null` because acli doesn't pass `expand=transitions`), so verification cascades through three modes, each more invasive than the last.
+
+#### Cache check (skip if unchanged)
+
+Hash the workflow-mapping object plus the project key:
+
+```bash
+WORKFLOW_HASH=$(jq -c '{project: .jira.project, workflow: .jira.workflow}' .lisa.config.json | shasum -a 256 | awk '{print $1}')
+CACHED=$(jq -r '.jira.verified_workflow_hash // empty' .lisa.config.local.json 2>/dev/null)
+if [ "$WORKFLOW_HASH" = "$CACHED" ]; then
+  echo "Workflow already verified; skipping probe."
+  # proceed to Step 6
+fi
+```
+
+The verification cache key lives in `.lisa.config.local.json` (per-developer, gitignored) because the workflow on disk might be stale relative to the user's local view of it.
+
+#### Mode A — Changelog inspection (non-destructive, fast)
+
+Aggregate every status name ever observed in the project's ticket histories:
+
+```bash
+acli jira workitem search --jql "project = $PROJECT" --paginate --json \
+  | jq -r '[.[].changelog.histories[]?.items[]? | select(.field == "status") | .fromString, .toString] | unique[]' \
+  | sort -u > /tmp/lisa-observed-statuses.txt
+```
+
+For each role (`ready`, `claimed`, `blocked`, each `done.<env>`), check whether the resolved status name appears in the observed set. Roles that match are **verified**. Roles that don't are **unverified** — but that doesn't yet mean they're missing; freshly-added statuses simply haven't accumulated history.
+
+If every role is verified, cache the hash and proceed to Step 6.
+
+#### Mode B — Create-probe-delete (synthetic ticket)
+
+For any role left unverified by Mode A, fall back to creating a throwaway ticket and walking it through.
+
+Prompt via `AskUserQuestion`:
+
+> Mode A could not verify these roles: `<list>`. Create a synthetic probe ticket to verify (recommended), or designate an existing ticket to use as the probe?
+
+If user picks synthetic:
+
+```bash
+# Create a probe ticket. Title makes its purpose obvious so a teammate doesn't act on it.
+PROBE_KEY=$(acli jira workitem create \
+  --project "$PROJECT" \
+  --type Task \
+  --summary "lisa-setup-probe (DELETE ME)" \
+  --description "Created by /lisa:setup:jira to verify workflow status reachability. Safe to delete." \
+  --json \
+  | jq -r '.key')
+
+trap 'acli jira workitem delete --key "$PROBE_KEY" --yes 2>/dev/null || acli jira workitem archive --key "$PROBE_KEY" --yes 2>/dev/null' EXIT
+
+# Walk through every unverified role's status in order.
+for status in $UNVERIFIED_STATUSES; do
+  if ! acli jira workitem transition --key "$PROBE_KEY" --status "$status" --yes 2>/dev/null; then
+    echo "Error: status '$status' is not reachable in the workflow from the probe ticket's current state." >&2
+    # Mark this role as missing; continue with remaining roles where possible (skip if transition is from a state we couldn't reach).
+    break
+  fi
+done
+
+# trap handles cleanup
+```
+
+If `acli jira workitem create` fails because the project has required fields, surface the field list and instruct the user to either (a) fill them in via `--field`/`--from-json`, (b) temporarily relax the required-fields configuration, or (c) fall through to Mode C.
+
+#### Mode C — Probe an existing ticket (last resort)
+
+If Mode B can't create a probe (mandatory fields, permission, etc.), prompt the user to designate a low-stakes existing ticket:
+
+> Provide a ticket key in `To Do` (or wherever you want to start the probe). I'll walk it through the unverified statuses and revert.
+
+Capture the ticket's starting status; walk through the unverified chain; revert to the starting status at the end. Use `trap` to ensure revert runs even on error.
+
+#### Outcome
+
+Once all roles are verified by some combination of A/B/C, cache the result:
+
+```bash
+jq --arg hash "$WORKFLOW_HASH" \
+   '.jira = ((.jira // {}) | .verified_workflow_hash = $hash)' \
+   .lisa.config.local.json > .lisa.config.local.json.tmp \
+   && mv .lisa.config.local.json.tmp .lisa.config.local.json
+```
+
+If any role is **unreachable** after all three modes, stop and surface a concrete admin-task message (which transition needs to be added, between which two statuses, in which workflow). Do not write a config that points at unreachable transitions.
+
+### Step 6 — Verify mid-build transition chain
+
+Independent of role reachability, confirm the lifecycle's required *transition graph* is intact: `ready → claimed`, `claimed → done.<env>` for each env. Mode A's changelog includes paired `(fromString, toString)` entries — count any pair that matches a required transition as verified. Modes B and C do this implicitly by walking the chain in order. If any required transition is missing (e.g., `claimed → done.staging` requires going through `review` first per the workflow), surface and stop with an admin remediation.
+
+### Step 7 — Offer to set top-level `tracker`
+
+If `.tracker` is unset or differs from `"jira"`, ask via `AskUserQuestion`:
+
+> JIRA project `<KEY>` written. Set top-level `tracker: "jira"` so all vendor-neutral skills target JIRA?
+
+Recommend "Yes" unless the project is using a different destination (e.g., GitHub Issues for build-queue but JIRA for read-only mirror — rare).
+
+If yes:
+
+```bash
+jq '.tracker = "jira"' .lisa.config.json > .lisa.config.json.tmp \
+   && mv .lisa.config.json.tmp .lisa.config.json
+```
+
+### Step 8 — Verify
+
+```bash
+jq -e '.jira.project' .lisa.config.json >/dev/null
+jq -e '.tracker' .lisa.config.json >/dev/null   # if user said yes in step 7
+```
+
+Report success with the resolved project key, the workflow mapping (defaults vs. overrides), and whether `tracker` was set.
+
+## Idempotency
+
+- Re-running replaces `jira.project` cleanly (jq merge, not append).
+- Re-running does not re-prompt for `tracker` if it's already `"jira"`.
+- Re-running with an unchanged workflow mapping skips the verification probe (Mode A/B/C) entirely via the `verified_workflow_hash` cache in `.lisa.config.local.json`. Editing any role name invalidates the cache and re-runs the probe.
+
+## Rules
+
+- Never invent a project key. If discovery fails (no projects visible), surface the error and ask the user to verify their JIRA permissions.
+- Never set `tracker` without explicit user confirmation — `tracker` is project-wide and switching it changes every downstream skill's behavior.
+- Never write env-level config (api tokens, server URLs) into `.lisa.config.json`.

package/plugins/src/base/skills/setup-notion/SKILL.md

@@ -0,0 +1,283 @@
+---
+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 /list:"lisa-notion-${workspace}" 2>/dev/null | grep Password | awk '{print $NF}' ;;
+  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`), check if its default name (`Draft`, `Ready`, etc.) 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.
+
+Collect overrides as a partial values map. Only write keys that differ from defaults.
+
+### 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). 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/src/base/skills/task-decomposition/SKILL.md

@@ -36,6 +36,8 @@ If a candidate work unit naturally touches multiple repos (e.g., "add field to b
 
 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 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* 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:

package/plugins/src/base/skills/ticket-triage/SKILL.md

@@ -19,11 +19,14 @@ Before any analytical work, confirm the ticket carries the content an implemente
 - Validation Journey missing on a runtime-behavior ticket
 - Target backend environment missing on a runtime-behavior ticket
 - Sign-in credentials missing on a ticket that touches authenticated surfaces
-- Single-repo scope violated (Bug / Task / Sub-task spanning repos)
 - Relationship discovery missing (no links AND no documented git + tracker-search outcome)
 
+Single-repo scope is handled separately — see below.
+
 The caller (jira-agent or github-agent) is responsible for transitioning the ticket to `Blocked` (JIRA status) or relabeling to `status:blocked` (GitHub), reassigning to the **Reporter / original author**, and posting a comment listing the missing requirements. This skill only emits the verdict and the missing-requirements list.
 
+**Single-repo scope is split, not blocked.** A cross-repo leaf work unit (Bug / Task / Sub-task / Improvement spanning repos) is a decomposition error the agent owns, not a terminal BLOCKED. Do not emit BLOCKED for it. The caller runs the **work-time split procedure** in the `repo-scope-split` rule (narrow the original to one repo, spin off a sibling per additional repo, link the producer→consumer dependency), then re-runs `tracker-verify` and re-enters triage on the now single-repo ticket. Only fall back to BLOCKED if the split is ambiguous (see "When to block instead of split" in that rule).
+
 If `lisa:tracker-verify` returned `PASS` for all the above, proceed to Phase 1.
 
 ## Phase 1 -- Relevance Check

package/plugins/src/base/skills/tracker-evidence/SKILL.md

@@ -24,6 +24,7 @@ See the `config-resolution` rule for configuration and dispatch table.
 
 - The GitHub `pr-assets` release lives on the implementation repo (the one with the PR), regardless of which tracker hosts the ticket/issue. All vendor skills upload there.
 - Never post evidence to a different ticket than the one named — `$ARGUMENTS` is the source of truth.
+- **Evidence-manifest gate (leaf work units).** Before dispatching to a vendor skill that transitions the ticket, confirm `EVIDENCE_DIR` contains a non-empty artifact for every `[EVIDENCE: name]` marker declared in the ticket's Validation Journey. If any declared marker has no captured artifact (or only an empty one), stop and report the missing markers by name instead of posting — a leaf work unit (Bug / Task / Sub-task / Improvement) may not advance to its review/Done state with an unsatisfied manifest (see the "Per-Work-Unit Evidence Contract" in the `verification` rule). Epics / Stories / Spikes, and leaf units without a Validation Journey, are exempt.
 
 ## UI Evidence Checklist (when work is UI-visible)
 

package/plugins/src/base/skills/verification-lifecycle/SKILL.md

@@ -228,6 +228,7 @@ Agents must follow this sequence unless explicitly instructed otherwise:
 3. **If verification fails**: Fix and re-run, don't mark complete
 4. **If verification blocked** (missing tools, services, etc.): Mark as blocked, not complete
 5. **Must not be dependent on CI/CD** if necessary, you may use local deploy methods found in the project manifest, but the verification methods must be listed in the pull request and therefore cannot be dependent on CI/CD completing
+6. **Evidence manifest satisfied (leaf work units)**: For a leaf work unit (Bug / Task / Sub-task / Improvement) whose ticket carries a Validation Journey, do not mark the ticket complete or transition it out of in-progress until every `[EVIDENCE: name]` marker declared on the ticket has a corresponding captured, non-empty artifact attached to the ticket. A missing or empty artifact for any declared marker blocks completion exactly like a failed verification — fix and re-capture, or escalate; never close with an unsatisfied manifest. Epics / Stories / Spikes are exempt (coordination containers, not work units).
 
 ---
 
@@ -330,6 +331,7 @@ A task is done only when:
 - Required verification surfaces and tooling surfaces are used or explicitly unavailable
 - Proof artifacts are captured
 - Every passing empirical verification is codified as a regression test (or has an explicit, documented skip reason from the allowed set)
+- For a leaf work unit, every `[EVIDENCE: name]` marker declared in its Validation Journey has a captured, non-empty artifact attached to the ticket (the evidence manifest is fully satisfied)
 - Spec conformance verdict is `CONFORMS` (not `PARTIAL`, not `DIVERGES`)
 - Verification level is declared
 - Risks and gaps are documented

package/scripts/check-plugins-sync.sh

@@ -0,0 +1,45 @@
+#!/usr/bin/env bash
+# Fails if the generated plugin directories (plugins/lisa, plugins/lisa-*) are
+# out of sync with their source (plugins/src). This guards against editing the
+# build artifact directly: build-plugins.sh runs `rm -rf plugins/lisa && cp -r
+# plugins/src/base`, so any artifact-only edit is silently discarded on the next
+# build/release. Two real PRs (#471, #478) were wiped this way before this check
+# existed.
+#
+# The check is a reproducibility test: regenerate the artifacts from source and
+# assert the working tree is unchanged. A diff means either (a) someone edited
+# plugins/lisa** directly instead of plugins/src**, or (b) someone edited
+# plugins/src** but forgot to run `bun run build:plugins` and commit the result.
+set -euo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+ROOT_DIR="$(cd "$SCRIPT_DIR/.." && pwd)"
+cd "$ROOT_DIR"
+
+if [ -n "$(git status --porcelain -- plugins/ 2>/dev/null)" ]; then
+  echo "✗ plugins/ has uncommitted changes before the sync check could run." >&2
+  echo "  Commit or stash them, then re-run: bun run check:plugins" >&2
+  exit 1
+fi
+
+bun run build:plugins >/dev/null
+
+if ! git diff --quiet -- plugins/; then
+  echo "✗ Generated plugin artifacts are out of sync with plugins/src." >&2
+  echo "" >&2
+  echo "  Files that changed after rebuilding from source:" >&2
+  git --no-pager diff --name-only -- plugins/ | sed 's/^/    /' >&2
+  echo "" >&2
+  echo "  plugins/lisa and plugins/lisa-* are GENERATED from plugins/src by" >&2
+  echo "  'bun run build:plugins'. Never edit them directly — the next build" >&2
+  echo "  overwrites the change." >&2
+  echo "" >&2
+  echo "  Fix:" >&2
+  echo "    1. Make your edit under plugins/src/<base|stack>/..." >&2
+  echo "    2. Run: bun run build:plugins" >&2
+  echo "    3. Commit both plugins/src and the regenerated plugins/lisa*." >&2
+  # Leave the tree dirty so the diff is inspectable locally; CI fails on exit.
+  exit 1
+fi
+
+echo "✓ Plugin artifacts are in sync with plugins/src."