@codyswann/lisa 2.176.12 → 2.178.0

package/plugins/lisa-copilot/skills/linear-sync/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: linear-sync
 description: "Syncs plan progress to a linked Linear Issue. Posts plan contents, progress updates, branch links, and PR links at key milestones. Use this skill throughout the plan lifecycle to keep Linear Issues in sync. The Linear counterpart of lisa:jira-sync and lisa:github-sync."
-allowed-tools: ["Bash", "Skill", "mcp__linear-server__list_teams", "mcp__linear-server__get_issue", "mcp__linear-server__list_issues", "mcp__linear-server__save_comment", "mcp__linear-server__list_issue_labels", "mcp__linear-server__create_issue_label", "mcp__linear-server__save_issue"]
+allowed-tools: ["Bash", "Skill"]
 ---
 
 # Sync Plan to Linear: $ARGUMENTS
@@ -37,7 +37,7 @@ This skill **suggests** transitions but does not auto-transition the native Line
 
 1. If `$ARGUMENTS` includes an identifier, parse it.
 2. Else search for the active plan file (most recent file under `plans/`) and extract the linked Linear Issue identifier from its frontmatter.
-3. Fetch the Issue via `mcp__linear-server__get_issue` to confirm it exists.
+3. Fetch the Issue via `lisa:linear-access operation: get-issue` to confirm it exists.
 
 ## Phase 2 — Compose Milestone Comment
 
@@ -65,7 +65,7 @@ Next: implementation begins. Suggested status: **Todo** (label: `status:ready`).
 
 ## Phase 3 — Post Comment
 
-Call `mcp__linear-server__save_comment({issueId: <id>, body: <comment>})`.
+Call `lisa:linear-access operation: save-comment({issueId: <id>, body: <comment>})`.
 
 ## Phase 3b — Ensure PR Backlink
 
@@ -79,14 +79,14 @@ The PR branch/title/body identifier is the PR -> Linear side. This phase is the
 
 ## Phase 4 — Update Status Label (when caller requests)
 
-If the caller passes `--update-label`, update the `status:*` label set via `mcp__linear-server__save_issue`:
+If the caller passes `--update-label`, update the `status:*` label set via `lisa:linear-access operation: save-issue`:
 
 - `plan-created` → add `status:ready`
 - `implementation-in-progress` → remove `status:ready`, add `status:in-progress`
 - `pr-ready` → remove `status:in-progress`, add `status:code-review`
 - `pr-merged` → remove `status:code-review`, add `status:done`
 
-If the requested label doesn't exist on the team, create it via `mcp__linear-server__create_issue_label`.
+If the requested label doesn't exist on the team, create it via `lisa:linear-access operation: create-issue-label`.
 
 Verify exactly one `status:*` label remains after the update — having two simultaneously breaks the build-queue invariant.
 
@@ -96,7 +96,7 @@ Without `--update-label`, this skill posts the comment only and does NOT touch l
 
 When the caller passes `--rollup`, this skill **derives a parent/container's `status:*` label from the roll-up of its children** instead of acting on a leaf. A **Project** (the Epic equivalent) rolls up from its Issues; an **Issue** rolls up from its sub-Issues. This implements the Linear child-issue-status arm of the **Parent status rollup (the state machine)** section of the `leaf-only-lifecycle` rule — cite that rule, do not restate the policy.
 
-**Resolve the child set the same way `lisa:linear-read-issue` does** — `mcp__linear-server__list_issues({project: <id>})` for a Project's Issues, or `mcp__linear-server__get_issue` per child for an Issue's sub-Issues (via `parentId`). Capture each child's `status:*` label. If the item has **no** children it is a leaf — rollup is N/A; behave as a normal milestone sync.
+**Resolve the child set the same way `lisa:linear-read-issue` does** — `lisa:linear-access operation: list-issues({project: <id>})` for a Project's Issues, or `lisa:linear-access operation: get-issue` per child for an Issue's sub-Issues (via `parentId`). Capture each child's `status:*` label. If the item has **no** children it is a leaf — rollup is N/A; behave as a normal milestone sync.
 
 **Evaluate the required children over the env ladder `in-progress < dev < staging < production` (the ordered keys of the Linear env-keyed `done` map, e.g. `status:on-dev < status:on-stg < status:done`) and take the first match** (canonical roles from `config-resolution`; Linear label map is `status:blocked`, `status:in-progress`, `status:code-review`, env-keyed `done`):
 
@@ -115,7 +115,7 @@ When the caller passes `--rollup`, this skill **derives a parent/container's `st
 
 **Single-environment collapse (this repo).** The env rungs resolve via the env-keyed `done` logic in `config-resolution`. In this repo `deploy.branches` declares only `production: main`, so `done` collapses to the single `status:done` label, the only env rung is production, and the lifecycle is `status:ready → status:in-progress → status:code-review → status:done` with **no** dev/staging promotion hops; the rollup never resolves a dev or staging `done`. Multi-environment projects keep the env-keyed map and roll a parent up to intermediate env labels (`status:on-dev`/`status:on-stg`).
 
-**Apply the derived label** via `mcp__linear-server__save_issue` (Project or Issue), removing the parent's existing `status:*` and adding the derived one so exactly one `status:*` label remains. Post an idempotent rollup comment naming the derived state and the child tally. The native Linear `state` is **not** auto-transitioned — only the `status:*` label, mirroring the `--update-label` rule. **Safe default:** if the derived terminal cannot be resolved (ambiguous required-set or unresolvable env `done`), do not guess — post the derived suggestion as a comment and leave the parent's label untouched.
+**Apply the derived label** via `lisa:linear-access operation: save-issue` (Project or Issue), removing the parent's existing `status:*` and adding the derived one so exactly one `status:*` label remains. Post an idempotent rollup comment naming the derived state and the child tally. The native Linear `state` is **not** auto-transitioned — only the `status:*` label, mirroring the `--update-label` rule. **Safe default:** if the derived terminal cannot be resolved (ambiguous required-set or unresolvable env `done`), do not guess — post the derived suggestion as a comment and leave the parent's label untouched.
 
 ## Rules
 

package/plugins/lisa-copilot/skills/linear-to-tracker/SKILL.md

@@ -6,7 +6,7 @@ description: >
   "break down this Linear project", "create tickets from a Linear project", "turn this Linear PRD into tickets", or similar. This skill mirrors `lisa:notion-to-tracker` and `lisa:confluence-to-tracker` for projects
   whose PRDs live in Linear — the workflow, gates, dry-run mode, and validation rules are identical;
   only the source-of-truth tool surface differs (Linear MCP instead of Notion / Confluence MCP).
-allowed-tools: ["Skill", "Bash", "mcp__linear-server__get_project", "mcp__linear-server__list_projects", "mcp__linear-server__list_issues", "mcp__linear-server__get_issue", "mcp__linear-server__list_comments", "mcp__linear-server__list_documents", "mcp__linear-server__get_document", "mcp__linear-server__list_project_labels", "mcp__linear-server__list_teams"]
+allowed-tools: ["Skill", "Bash"]
 ---
 
 # Linear PRD to Tracker Breakdown
@@ -21,8 +21,8 @@ This skill is the Linear counterpart of `lisa:notion-to-tracker` and `lisa:confl
 Linear has no native "PRD" entity. This skill treats a **Linear Project** as the PRD container:
 
 - **Project description** (markdown) is the PRD body — equivalent to a Notion page body or a Confluence page body.
-- **Project documents** (Linear's long-form markdown docs attached to projects, fetched via `list_documents({projectId})` / `get_document`) are treated as additional spec content and merged into the analysis. A multi-document Linear PRD is the analog of a multi-page Confluence PRD.
-- **Project sub-issues** (`list_issues({project})`) act as the candidate set for epics and user stories — the same role child Epic pages play in a Notion/Confluence PRD.
+- **Project documents** (Linear's long-form markdown docs attached to projects, fetched via `list-documents({projectId})` / `get-document`) are treated as additional spec content and merged into the analysis. A multi-document Linear PRD is the analog of a multi-page Confluence PRD.
+- **Project sub-issues** (`list-issues({project})`) act as the candidate set for epics and user stories — the same role child Epic pages play in a Notion/Confluence PRD.
 - **Linear comments live on Issues, not on Projects.** This skill aggregates comments from every issue under the project to capture decisions and engineering notes. Project-level discussion that isn't reflected on an issue is invisible to this skill.
 
 ## Modes
@@ -127,10 +127,10 @@ If env vars are not available, ask the user to provide them explicitly before pr
 
 ### Phase 1: Fetch & Analyze the PRD
 
-1. **Resolve the project** via `mcp__linear-server__get_project` with the slug or ID, including milestones and resources (`includeMilestones: true`, `includeResources: true`). Capture the project title, description, state, labels, lead, dates, attached documents, attached links.
-2. **Fetch attached Linear documents** via `mcp__linear-server__list_documents({projectId})` then `get_document` per result. Treat each as additional PRD content. (A Linear PRD with a single rich project description and no attached documents is the common case; multi-document PRDs are valid too.)
-3. **Identify candidate epics and user stories** from project sub-issues via `mcp__linear-server__list_issues({project: <id>})`. Capture identifier, title, description, labels, state, parent issue, and `parentId` chain so the issue hierarchy is reproducible.
-4. **Fetch full comments per sub-issue** via `mcp__linear-server__list_comments({issueId})` for every issue surfaced in step 3. Walk thread parents/children — comments are threaded via `parentId` references on the comment object.
+1. **Resolve the project** via `lisa:linear-access operation: get-project` with the slug or ID, including milestones and resources (`includeMilestones: true`, `includeResources: true`). Capture the project title, description, state, labels, lead, dates, attached documents, attached links.
+2. **Fetch attached Linear documents** via `lisa:linear-access operation: list-documents({projectId})` then `lisa:linear-access operation: get-document` per result. Treat each as additional PRD content. (A Linear PRD with a single rich project description and no attached documents is the common case; multi-document PRDs are valid too.)
+3. **Identify candidate epics and user stories** from project sub-issues via `lisa:linear-access operation: list-issues({project: <id>})`. Capture identifier, title, description, labels, state, parent issue, and `parentId` chain so the issue hierarchy is reproducible.
+4. **Fetch full comments per sub-issue** via `lisa:linear-access operation: list-comments({issueId})` for every issue surfaced in step 3. Walk thread parents/children — comments are threaded via `parentId` references on the comment object.
 5. **Synthesize decisions and blockers** from the project description + every document + every issue comment:
    - Decisions already confirmed by the team (look for agreement in comment threads)
    - Open questions that need product/engineering input

package/plugins/lisa-copilot/skills/linear-validate-issue/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: linear-validate-issue
 description: "Validates a proposed Linear work item spec (Project, Issue, or sub-Issue) — or an existing Linear item — against the organizational quality gates without writing anything. Returns a structured PASS/FAIL report per gate with concrete remediation. Single source of truth for what makes a valid Linear item — both the write path (linear-write-issue runs it pre-write) and the dry-run path (linear-to-tracker runs it during PRD intake) call this skill so the bar can never drift."
-allowed-tools: ["Bash", "mcp__linear-server__list_teams", "mcp__linear-server__get_team", "mcp__linear-server__list_projects", "mcp__linear-server__get_project", "mcp__linear-server__list_issues", "mcp__linear-server__get_issue", "mcp__linear-server__list_issue_labels", "mcp__linear-server__list_project_labels"]
+allowed-tools: ["Skill", "Bash"]
 ---
 
 # Validate Linear Work Item: $ARGUMENTS
@@ -65,7 +65,7 @@ build_ready: true                 # caller asserts the build-ready role (status:
 child_refs: ["ENG-601", "ENG-602"]   # known child work (sub-issues / project-member issues / blocked_by parentage) — see S15
 ```
 
-If the caller passes only an identifier, fetch the item via `mcp__linear-server__get_issue` (Issue) or `mcp__linear-server__get_project` (Project), derive the same fields from the fetched data — including `build_ready` (label set contains `status:ready`) and `child_refs` (sub-issues, project-member issues, plus `blocked_by` parentage, resolved as in `lisa:linear-read-issue`) so S15 can classify the item — then run gates.
+If the caller passes only an identifier, fetch the item via `lisa:linear-access operation: get-issue` (Issue) or `lisa:linear-access operation: get-project` (Project), derive the same fields from the fetched data — including `build_ready` (label set contains `status:ready`) and `child_refs` (sub-issues, project-member issues, plus `blocked_by` parentage, resolved as in `lisa:linear-read-issue`) so S15 can classify the item — then run gates.
 
 ## Gates
 
@@ -235,28 +235,28 @@ Remediation: `"Build-ready (status:ready) is leaf-only per leaf-only-lifecycle.
 
 #### F1 — Issue type valid in team
 
-For Issue types: confirm the team supports the issue type via `mcp__linear-server__get_team`. Linear issue types are typically per-team; check that the requested type exists.
+For Issue types: confirm the team supports the issue type via `lisa:linear-access operation: get-team`. Linear issue types are typically per-team; check that the requested type exists.
 
 For Epic (Project): confirm the team allows projects.
 
 #### F2 — Project parent exists and is in same team
 
-When `parent_project_id` is set: fetch via `mcp__linear-server__get_project`, confirm it exists and belongs to the configured team.
+When `parent_project_id` is set: fetch via `lisa:linear-access operation: get-project`, confirm it exists and belongs to the configured team.
 
-When `parent_issue_id` is set (Sub-task case): fetch via `mcp__linear-server__get_issue`, confirm the issue is non-Sub-task and in the same team / project.
+When `parent_issue_id` is set (Sub-task case): fetch via `lisa:linear-access operation: get-issue`, confirm the issue is non-Sub-task and in the same team / project.
 
 #### F3 — Linked items exist
 
-For each entry in `relations`, call `mcp__linear-server__get_issue` to confirm the identifier resolves. Flag broken identifiers.
+For each entry in `relations`, call `lisa:linear-access operation: get-issue` to confirm the identifier resolves. Flag broken identifiers.
 
 #### F4 — Required labels exist (or can be created)
 
-For each label referenced (`status:*`, `component:<name>`, `prd-*`), confirm via `mcp__linear-server__list_issue_labels` (or `list_project_labels` for Project labels) that it exists OR is creatable. Linear labels are team-scoped or workspace-scoped; flag if the requested scope is wrong.
+For each label referenced (`status:*`, `component:<name>`, `prd-*`), confirm via `lisa:linear-access operation: list-issue-labels` (or `lisa:linear-access operation: list-project-labels` for Project labels) that it exists OR is creatable. Linear labels are team-scoped or workspace-scoped; flag if the requested scope is wrong.
 
 ## Execution
 
 1. Parse `$ARGUMENTS`. If it's an identifier, fetch the item and derive the spec from the fetched fields — including `build_ready` (label set contains `status:ready`) and `child_refs` (sub-issues, project-member issues, plus `blocked_by` parentage, resolved as in `lisa:linear-read-issue`) so S15 can classify the item. Otherwise parse the YAML spec.
-2. Resolve team ID via `mcp__linear-server__list_teams({query: <teamKey>})` if any feasibility gate will run.
+2. Resolve team ID via `lisa:linear-access operation: list-teams({query: <teamKey>})` if any feasibility gate will run.
 3. Run every Specification gate in order. Collect PASS / FAIL / N/A with a one-line reason.
 4. Unless the caller passed `--spec-only` (dry-run), run every Feasibility gate. Collect results.
 5. Emit the report below.

package/plugins/lisa-copilot/skills/linear-verify/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: linear-verify
 description: "Verifies a Linear work item meets organizational standards by fetching the live item and running it through lisa:linear-validate-issue. Catches anything dropped or reformatted on write — same gates as the pre-write check, but applied to what Linear actually stored. Read-only."
-allowed-tools: ["Bash", "Skill", "mcp__linear-server__list_teams", "mcp__linear-server__get_issue", "mcp__linear-server__get_project", "mcp__linear-server__list_issue_labels", "mcp__linear-server__list_project_labels"]
+allowed-tools: ["Bash", "Skill"]
 ---
 
 # Verify Linear Work Item: $ARGUMENTS
@@ -25,14 +25,14 @@ If `$ARGUMENTS` is not parseable, stop and report.
 ## Phase 1 — Resolve Context
 
 1. Read `linear.workspace`, `linear.teamKey` from `.lisa.config.json` (with `.local` override).
-2. Resolve team ID via `mcp__linear-server__list_teams({query: <teamKey>})`.
+2. Resolve team ID via `lisa:linear-access operation: list-teams({query: <teamKey>})`.
 3. Determine entity type from the identifier shape:
    - `<TEAM>-<n>` → Issue
    - URL containing `/project/<slug>-<id>` → Project
 
 ## Phase 2 — Fetch Live State
 
-Call `mcp__linear-server__get_issue` (for Issues) or `mcp__linear-server__get_project` (for Projects). Capture every field, label, relation, comment, milestone, and project membership.
+Call `lisa:linear-access operation: get-issue` (for Issues) or `lisa:linear-access operation: get-project` (for Projects). Capture every field, label, relation, comment, milestone, and project membership.
 
 ## Phase 3 — Delegate to Validator
 

package/plugins/lisa-copilot/skills/linear-write-issue/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: linear-write-issue
 description: "Creates or updates a Linear work item — Project (Epic), Issue (Story), or sub-Issue (Sub-task) — following organizational best practices. Polymorphic: dispatches internally on issue_type to save_project (Epic) or save_issue (Story / Sub-task). Enforces description quality (three audiences), Gherkin acceptance criteria, project-as-parent for Stories, parentId for Sub-tasks, explicit relationship discovery (blocks / is blocked by / relates to / duplicates), labels, components-as-labels, project milestones for fix versions, native priority and estimate fields, and Validation Journey. Rejects thin items — use this skill any time a Linear work item is created or significantly edited."
-allowed-tools: ["Bash", "Skill", "mcp__linear-server__list_teams", "mcp__linear-server__get_team", "mcp__linear-server__list_projects", "mcp__linear-server__get_project", "mcp__linear-server__save_project", "mcp__linear-server__list_issues", "mcp__linear-server__get_issue", "mcp__linear-server__save_issue", "mcp__linear-server__list_issue_labels", "mcp__linear-server__create_issue_label", "mcp__linear-server__list_project_labels", "mcp__linear-server__list_comments", "mcp__linear-server__save_comment"]
+allowed-tools: ["Bash", "Skill"]
 ---
 
 # Write Linear Work Item: $ARGUMENTS
@@ -25,11 +25,11 @@ Linear's data model maps Epic / Story / Sub-task to **different entity types**.
 
 | `issue_type` | Linear entity | MCP write tool | Parent field |
 |--------------|---------------|----------------|--------------|
-| `Epic` | **Project** | `mcp__linear-server__save_project` | (none — Projects are top-level within a team) |
-| `Story` / `Task` / `Improvement` | **Issue** | `mcp__linear-server__save_issue` | `projectId` (the Epic Project) |
-| `Sub-task` | **sub-Issue** | `mcp__linear-server__save_issue` | `parentId` (the Story Issue) |
-| `Bug` | **Issue** | `mcp__linear-server__save_issue` | `projectId` if part of an Epic; else top-level |
-| `Spike` | **Issue** | `mcp__linear-server__save_issue` | `projectId` if part of an Epic; else top-level |
+| `Epic` | **Project** | `lisa:linear-access operation: save-project` | (none — Projects are top-level within a team) |
+| `Story` / `Task` / `Improvement` | **Issue** | `lisa:linear-access operation: save-issue` | `projectId` (the Epic Project) |
+| `Sub-task` | **sub-Issue** | `lisa:linear-access operation: save-issue` | `parentId` (the Story Issue) |
+| `Bug` | **Issue** | `lisa:linear-access operation: save-issue` | `projectId` if part of an Epic; else top-level |
+| `Spike` | **Issue** | `lisa:linear-access operation: save-issue` | `projectId` if part of an Epic; else top-level |
 
 Status workflow uses **labels** (`status:ready`, `status:in-progress`, `status:on-dev`, `status:done`) for portability across teams — Linear's per-team workflow state names vary, but labels are workspace-scoped and stable. Native Linear `state` is set to the team's default `Todo` state on create.
 
@@ -40,7 +40,7 @@ Determine from `$ARGUMENTS` and context whether this is a CREATE or UPDATE:
 - **CREATE**: no existing identifier provided.
 - **UPDATE**: identifier provided (`<TEAM>-<n>` for Issue, project slug + short-id for Project) — call `/linear-read-issue <ref>` first to load the full current state. Never overwrite without reading.
 
-Resolve the team ID for `linear.teamKey` via `mcp__linear-server__list_teams({query: <teamKey>})`. Cache it.
+Resolve the team ID for `linear.teamKey` via `lisa:linear-access operation: list-teams({query: <teamKey>})`. Cache it.
 
 ## Phase 2 — Gather Required Inputs
 
@@ -129,7 +129,7 @@ If the parent is explicitly provided, use it. Otherwise:
 
 1. Search active Projects in the team:
    ```text
-   mcp__linear-server__list_projects({team: <teamKey>, state: ["backlog", "planned", "started"]})
+   lisa:linear-access operation: list-projects({team: <teamKey>, state: ["backlog", "planned", "started"]})
    ```
    Match on keywords from the summary and description.
 2. If no matching Project exists, stop and ask the human to create or pick one. Do NOT orphan the item.
@@ -152,16 +152,16 @@ If the git search surfaces a PR or commit that relates to this work, capture the
 
 ```text
 # Open items in the same Project
-mcp__linear-server__list_issues({project: <projectId>, state_type: ["unstarted", "started"]})
+lisa:linear-access operation: list-issues({project: <projectId>, state_type: ["unstarted", "started"]})
 
 # Open items with overlapping keywords (workspace-wide)
-mcp__linear-server__list_issues({query: "<keyword>", state_type: ["unstarted", "started"]})
+lisa:linear-access operation: list-issues({query: "<keyword>", state_type: ["unstarted", "started"]})
 
 # Items with shared labels
-mcp__linear-server__list_issues({label: "<label>", updatedAt: ">-30d"})
+lisa:linear-access operation: list-issues({label: "<label>", updatedAt: ">-30d"})
 
 # Recently closed items in the same Project
-mcp__linear-server__list_issues({project: <projectId>, state_type: ["completed", "canceled"], updatedAt: ">-30d"})
+lisa:linear-access operation: list-issues({project: <projectId>, state_type: ["completed", "canceled"], updatedAt: ">-30d"})
 ```
 
 **Record the outcome.** Add a `## Relationship Search` subsection (or a comment if updating) listing the queries you ran and what they returned. If the searches yielded nothing, write that explicitly — "Searched git history for `<keywords>` and Linear for project=`X`, label=`Y`; no related work found." An item with zero relations and no documented search is rejected.
@@ -229,7 +229,7 @@ The validator is the **single source of truth** for what makes a valid Linear wo
 If the validator reports `FAIL`:
 - Surface the failure list and the per-gate remediation to the user.
 - Do NOT proceed to Phase 6. Fix the spec (or stop and ask the human) and re-run validation.
-- Never call `mcp__linear-server__save_project` or `mcp__linear-server__save_issue` while the validator's verdict is FAIL.
+- Never call `lisa:linear-access operation: save-project` or `lisa:linear-access operation: save-issue` while the validator's verdict is FAIL.
 
 If the validator reports `PASS`, continue to Phase 6.
 
@@ -237,15 +237,15 @@ If the validator reports `PASS`, continue to Phase 6.
 
 ### CREATE — Epic (Project)
 
-1. Resolve any required Project labels (`prd-ticketed`, etc.) via `mcp__linear-server__list_project_labels` (create via `create_project_label` if missing).
-2. Call `mcp__linear-server__save_project` with: `name` (summary), `description` (markdown), `teamIds: [<teamId>]`, `labelIds`, `priority` (Linear Project priority is also 0–4), `state` (default `backlog`), milestones if dated.
+1. Resolve any required Project labels (`prd-ticketed`, etc.) via `lisa:linear-access operation: list-project-labels` (create via `lisa:linear-access operation: create-project-label` if missing).
+2. Call `lisa:linear-access operation: save-project` with: `name` (summary), `description` (markdown), `teamIds: [<teamId>]`, `labelIds`, `priority` (Linear Project priority is also 0–4), `state` (default `backlog`), milestones if dated.
 3. Capture the returned Project ID and slug — Phase 4 children need these.
 4. If the Project is the parent for downstream Stories, record the ID for `lisa:linear-to-tracker` Phase 4 to use.
 
 ### CREATE — Story / Task / Bug / Spike / Improvement (Issue with projectId)
 
-1. Resolve any required Issue labels (`component:<name>`, `prd-intake-feedback` only if this is a sentinel issue, etc.) via `mcp__linear-server__list_issue_labels` (create via `create_issue_label` if missing). Include `status:ready` in `labelIds` only for a **leaf** work unit and only when `build_ready` is not `false` (per the Build-ready control input) — omit it for a container, and for a `build_ready: false` leaf which then waits in the backlog for a human to promote it.
-2. Call `mcp__linear-server__save_issue` with: `team` (teamId), `title` (summary), `description` (markdown), `projectId` (the Epic Project), `priority` (0–4), `estimate`, `labelIds`, `assignee` if known.
+1. Resolve any required Issue labels (`component:<name>`, `prd-intake-feedback` only if this is a sentinel issue, etc.) via `lisa:linear-access operation: list-issue-labels` (create via `lisa:linear-access operation: create-issue-label` if missing). Include `status:ready` in `labelIds` only for a **leaf** work unit and only when `build_ready` is not `false` (per the Build-ready control input) — omit it for a container, and for a `build_ready: false` leaf which then waits in the backlog for a human to promote it.
+2. Call `lisa:linear-access operation: save-issue` with: `team` (teamId), `title` (summary), `description` (markdown), `projectId` (the Epic Project), `priority` (0–4), `estimate`, `labelIds`, `assignee` if known.
 3. Capture the returned identifier (e.g. `ENG-123`) — Phase 4 sub-tasks need it as `parentId`.
 4. Add relationships from Phase 4b via `save_issue` (relations field) or paired relation calls.
 5. If the item changes runtime behavior, invoke `lisa:linear-add-journey` to append the Validation Journey section.
@@ -253,13 +253,13 @@ If the validator reports `PASS`, continue to Phase 6.
 ### CREATE — Sub-task (Issue with parentId)
 
 1. Resolve labels as above.
-2. Call `mcp__linear-server__save_issue` with: `team` (teamId), `title` (`[<repo>] <summary>` prefix is mandatory), `description` (markdown), `parentId` (the Story Issue ID), `projectId` (inherit from parent), `priority`, `estimate`, `labelIds`.
+2. Call `lisa:linear-access operation: save-issue` with: `team` (teamId), `title` (`[<repo>] <summary>` prefix is mandatory), `description` (markdown), `parentId` (the Story Issue ID), `projectId` (inherit from parent), `priority`, `estimate`, `labelIds`.
 3. Capture identifier.
 4. Add relationships via Phase 4b.
 
 ### UPDATE
 
-1. Call `mcp__linear-server__save_project` or `mcp__linear-server__save_issue` with **only the fields being changed**. Do NOT resend fields that weren't in the change set — Linear treats the call as a full overwrite of the listed fields.
+1. Call `lisa:linear-access operation: save-project` or `lisa:linear-access operation: save-issue` with **only the fields being changed**. Do NOT resend fields that weren't in the change set — Linear treats the call as a full overwrite of the listed fields.
 2. Preserve description sections you are not editing — re-read via `/linear-read-issue` first, including any existing canonical managed `## Lisa Usage` section unless the caller intentionally supplied an updated canonical section. Use the shared `usage-accounting` serializer/merge path rather than freehand edits to ledger rows.
 
 ## Phase 7 — Verify
@@ -268,7 +268,7 @@ Call the `lisa:linear-verify` skill on the resulting item. `lisa:linear-verify`
 
 ## Phase 8 — Announce
 
-Post a creation comment via `mcp__linear-server__save_comment` (on the Issue, or on a sentinel issue under the Project for Epic-level announcements) with:
+Post a creation comment via `lisa:linear-access operation: save-comment` (on the Issue, or on a sentinel issue under the Project for Epic-level announcements) with:
 
 - `[<repo>]` prefix if the item is repo-scoped
 - Who the item is assigned to (if known)

package/plugins/lisa-copilot/skills/linear-write-prd/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: linear-write-prd
 description: "Creates or idempotently updates a PRD as a Linear Project carrying exactly one PRD lifecycle project-label (`prd-draft` by default, or `prd-ready` when initial_role is ready so lisa:linear-prd-intake auto-claims it). The Linear PRD-source writer behind lisa:prd-source-write. Dedupes by a stable marker embedded in the Project description (matched by marker, never by name). Uses the Linear MCP."
-allowed-tools: ["Skill", "Bash", "mcp__linear-server__list_teams", "mcp__linear-server__list_projects", "mcp__linear-server__get_project", "mcp__linear-server__save_project", "mcp__linear-server__list_project_labels", "mcp__linear-server__create_project_label"]
+allowed-tools: ["Skill", "Bash"]
 ---
 
 # Write Linear PRD: $ARGUMENTS
@@ -37,17 +37,17 @@ PROGRESSED=("$PRD_IN_REVIEW" "$PRD_BLOCKED" "$PRD_TICKETED" "$PRD_SHIPPED" "$PRD
 ```
 
 Resolve the target project-label from `initial_role`: `ready` → `$PRD_READY`, else `$PRD_DRAFT`.
-Resolve its label id via `mcp__linear-server__list_project_labels` (create via
-`mcp__linear-server__create_project_label` if missing).
+Resolve its label id via `lisa:linear-access operation: list-project-labels` (create via
+`lisa:linear-access operation: create-project-label` if missing).
 
 ## Phase 2 — Dedupe by marker (search before create)
 
 The `marker` is embedded in the Project description. Find an existing Project carrying it — match the
 marker, **never** the project name:
 
-1. `mcp__linear-server__list_projects` scoped to the team/workspace (filtered by the `prd-*` label
+1. `lisa:linear-access operation: list-projects` scoped to the team/workspace (filtered by the `prd-*` label
    set when supported), then inspect each candidate's description via
-   `mcp__linear-server__get_project` for the marker. If `source_ref` was passed, target it directly.
+   `lisa:linear-access operation: get-project` for the marker. If `source_ref` was passed, target it directly.
 2. If a Project with the marker exists → **update**; else → **create**.
 
 ## Phase 3 — Create or update
@@ -59,7 +59,7 @@ dedupe. If the live Project description already contains the canonical managed `
 section, preserve it verbatim unless the caller intentionally supplied an updated canonical section;
 use the shared `usage-accounting` serializer/merge path rather than hand-editing ledger rows.
 
-**CREATE:** `mcp__linear-server__save_project` with:
+**CREATE:** `lisa:linear-access operation: save-project` with:
 - `name`: `$TITLE`
 - `description`: the marker-normalized full PRD markdown
 - `teamIds`: `[<resolved team id>]`

package/plugins/lisa-copilot/skills/posthog-access/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: posthog-access
+description: "Vendor-neutral access layer for PostHog. PostHog skills and observability rules MUST delegate through this skill rather than calling PostHog MCP tools or REST directly. Resolves PostHog MCP first when available, then falls back to POSTHOG_PERSONAL_API_KEY bearer auth."
+allowed-tools: ["Bash", "Read", "Skill"]
+---
+
+# PostHog Access: $ARGUMENTS
+
+Single chokepoint for PostHog operations. Caller skills and rules MUST NOT call
+`mcp__posthog__*` tools or PostHog REST directly.
+
+## Invocation Contract
+
+```text
+operation: query project_id:<ID> payload:{...}
+operation: insights project_id:<ID>
+operation: persons project_id:<ID> [query:<QUERY>]
+operation: events project_id:<ID> [after:<ISO>] [before:<ISO>]
+```
+
+Return parsed JSON in a `<result>` block.
+
+## Substrate Selection
+
+Probe in order:
+
+1. PostHog MCP, if available and authenticated.
+2. `POSTHOG_PERSONAL_API_KEY` bearer token against the configured PostHog host.
+
+PostHog documents personal API keys and bearer authentication. The headless REST
+tier uses:
+
+```bash
+POSTHOG_HOST=${POSTHOG_HOST:-https://app.posthog.com}
+posthog_api() {
+  local path="$1"
+  local method="${2:-GET}"
+  local body="${3:-}"
+  [ -n "$POSTHOG_PERSONAL_API_KEY" ] || {
+    echo "Error: POSTHOG_PERSONAL_API_KEY is not set." >&2
+    return 1
+  }
+  local args=(-sS -X "$method" -H "Authorization: Bearer $POSTHOG_PERSONAL_API_KEY")
+  [ -n "$body" ] && args+=(-H "Content-Type: application/json" --data-binary "$body")
+  curl "${args[@]}" "${POSTHOG_HOST%/}/api${path}"
+}
+```
+
+If neither tier works, fail with:
+
+```text
+Error: no PostHog access substrate available. Authenticate the PostHog MCP or set POSTHOG_PERSONAL_API_KEY.
+```
+
+## Invariants
+
+- Fallback is gated on `POSTHOG_PERSONAL_API_KEY`.
+- `POSTHOG_HOST` defaults to PostHog Cloud but can point at a self-hosted
+  deployment.
+- Consumer skills do not embed PostHog REST paths.

package/plugins/lisa-copilot/skills/prd-backlink/SKILL.md

@@ -162,7 +162,7 @@ Linear models top-level grouping two ways, and the PRD's own entity type decides
 - **PRD is a Linear Project** (the common case — a PRD project groups its generated work). Generated top-level **Issues** are attached to the PRD by setting their `projectId` to the PRD Project's id. The Project *is* the native parent of its Issues; no separate parent-issue link is needed.
 - **PRD is a Linear Issue** (a parent issue, not a project). Generated top-level Issues are attached as native **sub-Issues** of the PRD Issue by setting their `parentId` to the PRD Issue's id.
 
-Either way the write surface is `mcp__linear-server__save_issue` with the single relevant field (`projectId` or `parentId`) — the same primitive `lisa:linear-write-issue` uses to set a Story's `projectId` (Epic Project) and a Sub-task's `parentId` (Story Issue). Send **only** that field on update; Linear treats `save_issue` as a full overwrite of the fields named (`lisa:linear-write-issue` Phase 6 UPDATE), so resending other fields would clobber them.
+Either way the write surface is `lisa:linear-access operation: save-issue` with the single relevant field (`projectId` or `parentId`) — the same primitive `lisa:linear-write-issue` uses to set a Story's `projectId` (Epic Project) and a Sub-task's `parentId` (Story Issue). Send **only** that field on update; Linear treats `save_issue` as a full overwrite of the fields named (`lisa:linear-write-issue` Phase 6 UPDATE), so resending other fields would clobber them.
 
 ### What gets linked — generated top-level work only
 
@@ -178,14 +178,14 @@ So if the PRD generated `Epic E1 (Project) → Story S1 (Issue) → Sub-task T1
 The dedupe key is **child-ref identity** — the Linear issue/project identifier (e.g. `TEAM-123`) or its UUID — per the `prd-lifecycle-rollup` idempotency rule. Before attaching any child, read the PRD's current children and skip any child already attached, so re-running `prd-backlink` never duplicates a relationship and is a no-op when everything is already attached.
 
 1. **Read the PRD's existing children** (the same reads `lisa:linear-read-issue` uses for Project members and sub-Issues):
-   - PRD-as-Project → `mcp__linear-server__list_issues({project: <prd_project_id>})` and collect each member Issue's identifier/UUID.
-   - PRD-as-Issue → `mcp__linear-server__get_issue({id: <prd_issue_id>})` and collect its sub-Issue identifiers/UUIDs.
+   - PRD-as-Project → `lisa:linear-access operation: list-issues({project: <prd_project_id>})` and collect each member Issue's identifier/UUID.
+   - PRD-as-Issue → `lisa:linear-access operation: get-issue({id: <prd_issue_id>})` and collect its sub-Issue identifiers/UUIDs.
 
    The resulting identifiers/UUIDs are the existing child-ref set.
 
 2. **For each generated top-level item** whose child-ref is **not** already in that set, attach it with a single-field `save_issue`:
-   - PRD-as-Project → `mcp__linear-server__save_issue({id: <child_id>, projectId: <prd_project_id>})`.
-   - PRD-as-Issue → `mcp__linear-server__save_issue({id: <child_id>, parentId: <prd_issue_id>})`.
+   - PRD-as-Project → `lisa:linear-access operation: save-issue({id: <child_id>, projectId: <prd_project_id>})`.
+   - PRD-as-Issue → `lisa:linear-access operation: save-issue({id: <child_id>, parentId: <prd_issue_id>})`.
 
    A child already in the existing-children set is a no-op — do not issue the `save_issue` call for it. Reading the child's current `projectId`/`parentId` and finding it already equal to the PRD's id is the same no-op (attaching to the value it already holds changes nothing).
 

package/plugins/lisa-copilot/skills/prd-ticket-coverage/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: prd-ticket-coverage
 description: "Verifies that every requirement in a PRD (Notion, Confluence, Linear, or GitHub Issues) is covered by at least one created destination ticket (JIRA, GitHub Issues, or Linear) — no silent drops. Parses the PRD into atomic items (goals, user stories, functional/non-functional requirements, acceptance criteria, important notes), maps each to the created tickets, and produces a coverage matrix and verdict (COMPLETE / COMPLETE_WITH_SCOPE_CREEP / GAPS_FOUND / NO_TICKETS_FOUND). Used by notion-prd-intake / confluence-prd-intake / linear-prd-intake / github-prd-intake post-write to gate the Ticketed transition; can also be invoked standalone for after-the-fact audits."
-allowed-tools: ["Skill", "Bash", "mcp__claude_ai_Notion__notion-fetch", "mcp__claude_ai_Notion__notion-get-comments", "mcp__atlassian__getConfluencePage", "mcp__atlassian__getConfluencePageDescendants", "mcp__atlassian__getConfluencePageFooterComments", "mcp__atlassian__getConfluencePageInlineComments", "mcp__atlassian__getConfluenceCommentChildren", "mcp__atlassian__getJiraIssue", "mcp__atlassian__searchJiraIssuesUsingJql", "mcp__atlassian__getAccessibleAtlassianResources", "mcp__linear-server__get_project", "mcp__linear-server__list_documents", "mcp__linear-server__get_document", "mcp__linear-server__list_issues", "mcp__linear-server__get_issue", "mcp__linear-server__list_comments"]
+allowed-tools: ["Skill", "Bash", "mcp__claude_ai_Notion__notion-fetch", "mcp__claude_ai_Notion__notion-get-comments", "mcp__atlassian__getConfluencePage", "mcp__atlassian__getConfluencePageDescendants", "mcp__atlassian__getConfluencePageFooterComments", "mcp__atlassian__getConfluencePageInlineComments", "mcp__atlassian__getConfluenceCommentChildren", "mcp__atlassian__getJiraIssue", "mcp__atlassian__searchJiraIssuesUsingJql", "mcp__atlassian__getAccessibleAtlassianResources"]
 ---
 
 # PRD Ticket Coverage Audit: $ARGUMENTS
@@ -15,7 +15,7 @@ The PRD URL can be a **Notion page URL**, a **Confluence page URL**, a **Linear
 
 - `notion.so` / `notion.site` → Notion. Fetch with `mcp__claude_ai_Notion__notion-fetch` (`include_discussions: true`) and `mcp__claude_ai_Notion__notion-get-comments`.
 - Atlassian Confluence host (e.g. `*.atlassian.net/wiki/...`) → Confluence. Fetch with `mcp__atlassian__getConfluencePage`, `mcp__atlassian__getConfluencePageDescendants` (for child epic pages), `mcp__atlassian__getConfluencePageFooterComments`, `mcp__atlassian__getConfluencePageInlineComments`, and `mcp__atlassian__getConfluenceCommentChildren` for nested replies.
-- `linear.app` host → Linear. Fetch with `mcp__linear-server__get_project` (capture description, labels, state, attached resources), `mcp__linear-server__list_documents({projectId})` + `mcp__linear-server__get_document` per attached document, `mcp__linear-server__list_issues({project})` for sub-issues that act as child epics / user stories, and `mcp__linear-server__list_comments({issueId})` per sub-issue for decisions and engineering notes. Comments do not exist on the project itself in the MCP surface — sub-issue comments are the substitute.
+- `linear.app` host → Linear. Fetch with `lisa:linear-access operation: get-project` (capture description, labels, state, attached resources), `lisa:linear-access operation: list-documents({projectId})` + `lisa:linear-access operation: get-document` per attached document, `lisa:linear-access operation: list-issues({project})` for sub-issues that act as child epics / user stories, and `lisa:linear-access operation: list-comments({issueId})` per sub-issue for decisions and engineering notes. Comments do not exist on the project itself in the MCP surface — sub-issue comments are the substitute.
 - `github.com` host → GitHub Issues. Fetch with the `gh` CLI (no GitHub MCP — Lisa uses the CLI exclusively for GitHub):
   - `gh issue view <number> --repo <org>/<repo> --json number,title,body,labels,milestone,assignees,author,createdAt,comments,url` for the PRD body and comments.
   - `gh api graphql` with the `subIssues` field for native sub-issue children (these stand in for child epic pages — see `lisa:github-read-issue` Phase 3 for the exact query).

package/plugins/lisa-copilot/skills/repair-intake/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: repair-intake
 description: "Vendor-agnostic repair scanner — the recovery counterpart to lisa:intake. Where intake claims `ready` work, repair-intake finds work that got stuck or was left half-closed: items left in `blocked`, stalled in an in-progress role (build `claimed`, PRD `in_review`), terminal-labeled items that are still natively open, and rollup/container items whose children are all terminal but whose parent is not closed out. Scans the same queues lisa:intake serves (Notion / Confluence / Linear / GitHub PRD databases; JIRA / GitHub / Linear build queues), enumerates candidates up to `max_candidates`, and repairs every materially actionable one in that bounded set: resumes stalled in-progress work IN PLACE (build → the vendor agent + the scanner's post-agent transition; PRD → the source `*-to-tracker` dry-run validate→route pipeline) — but for a stalled build it first diagnoses the PR/deploy state: a PR that already merged is recovered by applying the env transition build-intake never got to (no re-dispatch); a PR that is merely behind its base is re-synced in place via `gh pr update-branch` so the already-enabled auto-merge can land (a clean rebase needs no human); and only a PR that cannot merge for a non-mechanical reason (true conflict, failing checks, unaddressed CodeRabbit/changes-requested) or a failed deploy gets a build-ready leaf fix ticket with the item moved to `blocked` (blocked by that ticket) rather than re-dispatching, re-validates blocked PRDs when new clarifying answers exist, re-dispatches blocked build items whose `is blocked by` dependencies have since closed OR whose validation/quality-gate self-block now re-validates PASS (re-running `lisa:tracker-validate` against current content — the build mirror of PRD re-validation), performs terminal native closure for terminal-labeled items, reconciles parent rollups to their derived state per leaf-only-lifecycle — including the intermediate-env case (e.g. all children at `On Stg` → parent `On Stg`) and a container wrongly stuck in `ready` — and closes out rollups whose associated child work is fully terminal. Idempotent, loop-protected via a [lisa-repair-intake] marker + state fingerprint + backoff. Never mutates product-owned states (`draft`, `verified`) and never touches `ready` leaves (a container wrongly carrying `ready` is the one exception — it is rolled up from its children, since `ready` on a parent is an invariant violation, not intake's claim signal). Designed as a /schedule cron target running alongside lisa:intake."
-allowed-tools: ["Skill", "Bash", "Read", "Write", "Edit", "mcp__linear-server__list_teams", "mcp__linear-server__list_projects", "mcp__linear-server__get_project", "mcp__linear-server__save_project", "mcp__linear-server__list_project_labels", "mcp__linear-server__list_issues", "mcp__linear-server__get_issue", "mcp__linear-server__save_issue", "mcp__linear-server__list_comments", "mcp__linear-server__save_comment", "mcp__linear-server__list_issue_labels", "mcp__linear-server__create_issue_label"]
+allowed-tools: ["Skill", "Bash", "Read", "Write", "Edit"]
 ---
 
 # Repair Intake: $ARGUMENTS

package/plugins/lisa-copilot/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/lisa-copilot/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.