@codyswann/lisa 2.176.12 → 2.178.0

package/plugins/src/base/skills/sentry-access/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: sentry-access
+description: "Vendor-neutral access layer for Sentry. Sentry-oriented skills MUST delegate through this skill rather than calling Sentry MCP tools, sentry-cli, or REST directly. Resolves Sentry MCP/CLI first when available, then falls back to SENTRY_AUTH_TOKEN + Sentry REST API."
+allowed-tools: ["Bash", "Read", "Skill"]
+---
+
+# Sentry Access: $ARGUMENTS
+
+Single chokepoint for Sentry operations. Caller skills MUST NOT call
+`mcp__sentry__*`, `sentry-cli`, or `https://sentry.io/api/` directly.
+
+## Invocation Contract
+
+```text
+operation: list-issues org:<ORG> project:<PROJECT> query:<QUERY> [environment:<ENV>]
+operation: get-issue issue_id:<ID>
+operation: events org:<ORG> project:<PROJECT> query:<QUERY>
+operation: releases org:<ORG> project:<PROJECT>
+```
+
+Return parsed JSON in a `<result>` block.
+
+## Substrate Selection
+
+Probe in order:
+
+1. Sentry MCP, if available and authenticated.
+2. `sentry-cli`, if installed and authenticated to the requested org/project.
+3. `SENTRY_AUTH_TOKEN` bearer token against Sentry REST.
+
+Sentry documents API auth tokens for REST API calls. The headless REST tier uses:
+
+```bash
+sentry_api() {
+  local path="$1"
+  [ -n "$SENTRY_AUTH_TOKEN" ] || {
+    echo "Error: SENTRY_AUTH_TOKEN is not set." >&2
+    return 1
+  }
+  curl -sS "https://sentry.io/api/0${path}" \
+    -H "Authorization: Bearer $SENTRY_AUTH_TOKEN"
+}
+```
+
+If neither tier works, fail with:
+
+```text
+Error: no Sentry access substrate available. Authenticate Sentry MCP/CLI or set SENTRY_AUTH_TOKEN.
+```
+
+## Invariants
+
+- Fallback is gated on `SENTRY_AUTH_TOKEN`.
+- Org/project come from `.sentryclirc`, `.lisa.config.json`, or explicit
+  operation args; never infer by searching all accessible orgs.
+- Consumer skills do not embed Sentry REST paths.

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

@@ -1,7 +1,7 @@
 ---
 name: setup-linear
 description: "Configure Linear as the destination tracker and/or the PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in OS keychain), resolves the workspace slug and team key, scaffolds the build-queue issue-label namespace (`status:*`) when Linear is the tracker and/or the PRD-lifecycle project-label namespace (`prd-*` + issue-level sentinel) when Linear is the PRD source, writes the `linear` section into `.lisa.config.json`, and offers to set top-level `tracker: \"linear\"` and/or `source: \"linear\"`. Idempotent — re-running updates the existing section and reuses existing labels. No /lisa:setup:atlassian prerequisite."
-allowed-tools: ["Bash", "Read", "Write", "Edit", "Skill", "AskUserQuestion", "mcp__linear-server__authenticate", "mcp__linear-server__complete_authentication", "mcp__linear-server__list_teams", "mcp__linear-server__list_issue_labels", "mcp__linear-server__create_issue_label", "mcp__linear-server__list_project_labels", "mcp__linear-server__create_project_label"]
+allowed-tools: ["Bash", "Read", "Write", "Edit", "Skill", "AskUserQuestion", "mcp__linear-server__authenticate", "mcp__linear-server__complete_authentication"]
 ---
 
 # Setup Linear: $ARGUMENTS
@@ -40,7 +40,7 @@ The role answer drives Step 3 (which label namespaces to scaffold) and whether `
 Verify the Linear MCP is authenticated to the right workspace by listing teams:
 
 ```text
-mcp__linear-server__list_teams({})
+lisa:linear-access operation: list-teams({})
 ```
 
 If it errors / returns nothing, run `mcp__linear-server__authenticate` and have the user complete OAuth in the browser, then `mcp__linear-server__complete_authentication`, then re-list. A non-empty team list confirms the MCP is authed to a readable workspace.
@@ -137,7 +137,7 @@ echo "Linear key validated. Org: $(echo "$VIEWER" | jq -r '.data.organization.ur
 ### Step 2 — Resolve workspace slug + team key
 
 - **Workspace slug**: honor `--workspace=<slug>`. Otherwise derive from the validated identity — the GraphQL `organization.urlKey` (API path) or the team list's workspace (MCP path). Confirm with the user; this slug is the keychain `account` key and the multi-workspace disambiguator.
-- **Team key** (required when Linear is the **tracker**): honor `--team=<KEY>`. Otherwise enumerate teams via `mcp__linear-server__list_teams({})` (or the GraphQL `teams` query) and present them via `AskUserQuestion` (label = team key, description = team name) for the user to pick the team that owns lisa's destination Issues. If Linear is source-only, `teamKey` is optional — skip unless the user wants to pin a team scope.
+- **Team key** (required when Linear is the **tracker**): honor `--team=<KEY>`. Otherwise enumerate teams via `lisa:linear-access operation: list-teams({})` (or the GraphQL `teams` query) and present them via `AskUserQuestion` (label = team key, description = team name) for the user to pick the team that owns lisa's destination Issues. If Linear is source-only, `teamKey` is optional — skip unless the user wants to pin a team scope.
 
 ### Step 3 — Scaffold the lifecycle label namespaces
 
@@ -154,7 +154,7 @@ read_role() {  # $1=namespace (build|prd) $2=role $3=default
 
 #### 3a. Build-queue labels — ISSUE labels (only if Linear is the tracker)
 
-Probe with `mcp__linear-server__list_issue_labels` (scoped to the team). For each role's resolved name, create it via `mcp__linear-server__create_issue_label` only if absent. The `done` role is env-keyed — create all three defaults; collapse to a single string in config later if the project's terminal state is env-independent.
+Probe with `lisa:linear-access operation: list-issue-labels` (scoped to the team). For each role's resolved name, create it via `lisa:linear-access operation: create-issue-label` only if absent. The `done` role is env-keyed — create all three defaults; collapse to a single string in config later if the project's terminal state is env-independent.
 
 | Role | Default | 
 |------|---------|
@@ -168,7 +168,7 @@ Probe with `mcp__linear-server__list_issue_labels` (scoped to the team). For eac
 
 #### 3b. PRD-lifecycle labels — PROJECT labels (only if Linear is the PRD source)
 
-Probe with `mcp__linear-server__list_project_labels`. Create missing ones via `mcp__linear-server__create_project_label`. This probe-then-create is find-or-create per label: a label already present is reused untouched, so re-running never duplicates `prd-*`. These are a **separate label kind** from issue labels — creating an issue label of the same name will NOT work for the PRD flow.
+Probe with `lisa:linear-access operation: list-project-labels`. Create missing ones via `lisa:linear-access operation: create-project-label`. This probe-then-create is find-or-create per label: a label already present is reused untouched, so re-running never duplicates `prd-*`. These are a **separate label kind** from issue labels — creating an issue label of the same name will NOT work for the PRD flow.
 
 `prd-verified` is the terminal lifecycle state after `prd-shipped` (the `verified` role from config-resolution, #591): `/lisa:verify-prd` transitions a Linear PRD project into it once the shipped product has been empirically verified against the PRD. Scaffold it through the same find-or-create path as every other `prd-*` row.
 

package/plugins/src/base/skills/sonarcloud-access/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: sonarcloud-access
+description: "Vendor-neutral access layer for SonarCloud/SonarQube Cloud. Sonar triage skills MUST delegate through this skill rather than calling Sonar MCP tools or REST directly. Resolves Sonar MCP first when available, then falls back to SONAR_TOKEN + SonarCloud Web API."
+allowed-tools: ["Bash", "Read", "Skill"]
+---
+
+# SonarCloud Access: $ARGUMENTS
+
+Single chokepoint for SonarCloud operations. Caller skills MUST NOT call
+`mcp__sonarqube__*` tools directly or curl `https://sonarcloud.io/api/`
+themselves.
+
+## Invocation Contract
+
+```text
+operation: gate-status project_key:<KEY> [branch:<BRANCH>] [pull_request:<N>]
+operation: issues project_key:<KEY> [branch:<BRANCH>] [pull_request:<N>] [types:<csv>] [severities:<csv>]
+operation: hotspots project_key:<KEY> [branch:<BRANCH>] [pull_request:<N>]
+operation: rule-detail key:<RULE_KEY>
+operation: source-snippet component:<COMPONENT_KEY> from:<N> to:<N>
+```
+
+Return parsed JSON in a `<result>` block.
+
+## Substrate Selection
+
+Probe in order:
+
+1. Sonar MCP, if available and authenticated.
+2. `SONAR_TOKEN` against the SonarCloud Web API.
+
+SonarCloud documents bearer-token authentication for the Web API. Use:
+
+```bash
+sonar_api() {
+  local path="$1"
+  [ -n "$SONAR_TOKEN" ] || {
+    echo "Error: SONAR_TOKEN is not set." >&2
+    return 1
+  }
+  curl -sS "https://sonarcloud.io/api${path}" \
+    -H "Authorization: Bearer $SONAR_TOKEN"
+}
+```
+
+If a host still requires the legacy token-as-basic-auth form, make that an
+explicit adapter branch in this skill; consumers do not choose auth style.
+
+If neither tier works, fail with:
+
+```text
+Error: no SonarCloud access substrate available. Authenticate the Sonar MCP or set SONAR_TOKEN.
+```
+
+## REST Dispatch
+
+| Operation | REST path |
+|---|---|
+| `gate-status` | `/qualitygates/project_status?projectKey=<KEY>[&branch=<BRANCH>][&pullRequest=<N>]` |
+| `issues` | `/issues/search?componentKeys=<KEY>[&branch=<BRANCH>][&pullRequest=<N>]...` |
+| `hotspots` | `/hotspots/search?projectKey=<KEY>[&branch=<BRANCH>][&pullRequest=<N>]` |
+| `rule-detail` | `/rules/show?key=<RULE_KEY>` |
+| `source-snippet` | `/sources/lines?key=<COMPONENT_KEY>&from=<N>&to=<N>` |
+
+## Invariants
+
+- Fallback is gated on `SONAR_TOKEN`.
+- SonarCloud host access requires `sonarcloud.io` in any custom remote network
+  allowlist.
+- Consumers ask for analysis data by operation name; this skill owns the Web API
+  path shape.

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

@@ -22,5 +22,5 @@ See the `config-resolution` rule for configuration and dispatch table.
 
 ## Rules
 
-- The journey content is identical across vendors; only the parser source differs (the JIRA vendor reads description via Atlassian MCP; the GitHub vendor reads body via `gh issue view --json body`; the Linear vendor reads description via `mcp__linear-server__get_issue`).
+- The journey content is identical across vendors; only the parser source differs (the JIRA vendor reads description via Atlassian MCP; the GitHub vendor reads body via `gh issue view --json body`; the Linear vendor reads description via `lisa:linear-access operation: get-issue`).
 - Evidence posting always goes through `lisa:tracker-evidence` — never bypass.

package/plugins/src/base/skills/verify-prd/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: verify-prd
 description: "Initiative-level PRD acceptance gate. Given a PRD ref/URL (GitHub Issue, Linear project/issue, Notion page, Confluence page, or JIRA issue), resolves the source vendor, reads the PRD body and its generated top-level child work set via the prd-lifecycle-rollup contract (native hierarchy first, machine-readable generated-work section fallback — never reimplementing child enumeration), and confirms every required generated top-level work item is terminal before any verification runs. If any required top-level child is non-terminal, it reports the incomplete child set and STOPS without verifying or transitioning the PRD. When the guard passes, it runs spec-conformance against the original PRD requirements (via the spec-conformance skill) plus empirical verification appropriate to the shipped surface (via verification-lifecycle). On a CONFORMS verdict with all empirical checks passing it runs the PASS path: transitions the PRD shipped → verified and posts verification evidence. On a PARTIAL/DIVERGES conformance verdict or any failing empirical check it runs the self-healing FAIL path: it re-opens the PRD shipped → ticketed (NEVER blocked), creates build-ready fix tickets (via tracker-write with build_ready: true) for each missing/incorrect/divergent behavior — registered as the PRD's generated work — and posts a product-readable failure report (with a verification-round count) naming which requirements/ACs failed with observed-vs-expected evidence. The fix tickets auto-build, rollup re-ships the PRD once they are terminal, and a later intake cycle re-verifies — the loop closes itself and never auto-halts. Re-runs are idempotent: evidence/failure-report comments are regenerated in place via a stable sentinel marker (never appended, round incremented), fix tickets are deduped by a stable PRD-ref + requirement marker (referenced/updated, never duplicated), and the lifecycle transition is a no-op when the PRD already carries the target role (exactly one lifecycle label/status remains) — per the prd-lifecycle-rollup idempotency dedupe key (match by stable ref, never by title)."
-allowed-tools: ["Skill", "Bash", "Read", "mcp__claude_ai_Notion__notion-fetch", "mcp__claude_ai_Notion__notion-get-comments", "mcp__atlassian__getConfluencePage", "mcp__atlassian__getConfluencePageDescendants", "mcp__atlassian__getJiraIssue", "mcp__atlassian__searchJiraIssuesUsingJql", "mcp__atlassian__getAccessibleAtlassianResources", "mcp__linear-server__get_project", "mcp__linear-server__list_issues", "mcp__linear-server__get_issue", "mcp__linear-server__list_documents", "mcp__linear-server__get_document"]
+allowed-tools: ["Skill", "Bash", "Read", "mcp__claude_ai_Notion__notion-fetch", "mcp__claude_ai_Notion__notion-get-comments", "mcp__atlassian__getConfluencePage", "mcp__atlassian__getConfluencePageDescendants", "mcp__atlassian__getJiraIssue", "mcp__atlassian__searchJiraIssuesUsingJql", "mcp__atlassian__getAccessibleAtlassianResources"]
 ---
 
 # PRD-level Verification: $ARGUMENTS
@@ -38,7 +38,7 @@ Detect the vendor from `$ARGUMENTS` the same way `prd-ticket-coverage` / `prd-ba
 | Input shape | Vendor | Read surface |
 |---|---|---|
 | `github.com/<org>/<repo>/issues/<n>` or `<org>/<repo>#<n>` | **GitHub Issues** | `gh` CLI (Lisa uses the CLI exclusively for GitHub — no GitHub MCP) |
-| `linear.app/...` | **Linear** | `mcp__linear-server__get_project` / `get_issue` |
+| `linear.app/...` | **Linear** | `lisa:linear-access operation: get-project` / `lisa:linear-access operation: get-issue` |
 | `notion.so` / `notion.site` | **Notion** | `mcp__claude_ai_Notion__notion-fetch` (`include_discussions: true`) |
 | `*.atlassian.net/wiki/...` | **Confluence** | `mcp__atlassian__getConfluencePage` (+ descendants) |
 | JIRA issue key (e.g. `PROJ-123`) or `*.atlassian.net/browse/...` | **JIRA** | `mcp__atlassian__getJiraIssue` |

package/scripts/generate-codex-plugin-artifacts.mjs

@@ -191,12 +191,28 @@ const ACRONYMS = new Set([
   "llm",
 ]);
 
+/**
+ * Brand names whose mixed-case capitalization cannot be reproduced by the
+ * simple title-case or all-upper-case rules above.
+ *
+ * Keys are lower-cased token forms (as they appear split from a kebab skill
+ * name). Values are the canonical display spellings. Entries here take
+ * precedence over both {@link ACRONYMS} and the default title-case path so
+ * that `posthog-access` -> "PostHog Access" rather than "Posthog Access".
+ */
+const BRAND_NAMES = new Map([
+  ["posthog", "PostHog"],
+  ["sonarcloud", "SonarCloud"],
+]);
+
 /**
  * Humanize a kebab/snake/space-delimited token into a Title-Cased display name.
  *
  * Splits on `-`, `_`, and runs of whitespace, then title-cases each word —
- * except tokens in {@link ACRONYMS}, which are upper-cased. This is the rule the
- * PRD (#521) specifies for `display_name`: `exploratory-qa` -> "Exploratory QA".
+ * except tokens in {@link ACRONYMS}, which are upper-cased, and tokens in
+ * {@link BRAND_NAMES}, which are emitted with their canonical spelling.
+ * This is the rule the PRD (#521) specifies for `display_name`:
+ * `exploratory-qa` -> "Exploratory QA".
  * Pure: same input always yields the same output.
  *
  * @param {string} raw The raw skill/frontmatter name token.
@@ -206,11 +222,16 @@ function humanizeName(raw) {
   return raw
     .split(/[-_\s]+/)
     .filter(word => word.length > 0)
-    .map(word =>
-      ACRONYMS.has(word.toLowerCase())
-        ? word.toUpperCase()
-        : word.charAt(0).toUpperCase() + word.slice(1)
-    )
+    .map(word => {
+      const lower = word.toLowerCase();
+      if (BRAND_NAMES.has(lower)) {
+        return BRAND_NAMES.get(lower);
+      }
+      if (ACRONYMS.has(lower)) {
+        return word.toUpperCase();
+      }
+      return word.charAt(0).toUpperCase() + word.slice(1);
+    })
     .join(" ");
 }