@codyswann/lisa 2.189.7 → 2.189.9

package/plugins/lisa/skills/parity-sentry-seer/agents/openai.yaml

@@ -1,4 +0,0 @@
-display_name: "Parity Sentry Seer"
-short_description: "AI debugging — given an error message, stack trace, or failing test, analyze the signal, form ranked hypotheses, locate the root cause in…"
-default_prompt:
-  - "Use $parity-sentry-seer: AI debugging — given an error message, stack trace, or failing test, analyze the signal, form ranked hypotheses, locate the root cause in…."

package/plugins/lisa/skills/parity-skill-creator/SKILL.md

@@ -1,149 +0,0 @@
----
-name: parity-skill-creator
-description: "Author a new Lisa skill end-to-end — scaffold the SKILL.md frontmatter (name/description/allowed-tools), write the pass-through command, follow hyphen naming, place files under plugins/src/base, and rebuild plugins. Lisa-native reimplementation of the upstream skill-creator plugin. NO drift pin: upstream publishes no semver, so it is not drift-trackable."
-allowed-tools: ["Read", "Edit", "Write", "Bash"]
----
-
-# Skill Creator
-
-Author a new, working Lisa skill (and its pass-through command) from a one-line
-description. This is the Lisa-native equivalent of the upstream
-`skill-creator@claude-plugins-official` plugin, reimplemented from scratch
-against Lisa's conventions so the same capability is available to the Codex,
-agy, and Copilot runtimes (Cursor reads `.claude-plugin/` natively).
-
-## Not drift-trackable
-
-This skill intentionally carries **no `synced-from` pin**. The upstream
-`skill-creator` plugin publishes **no semver** (its cache version resolves to
-`unknown`), so a `@unknown` pin would be unparseable and meaningless to
-`scripts/plugin-parity-drift.mjs`. **Drift is tracked manually** — re-review the
-upstream plugin by hand whenever the curated plugin set is refreshed. Do **not**
-add a `synced-from` line to skills generated by this skill unless they
-reimplement a semver-versioned upstream plugin.
-
-## When to use
-
-- A reusable workflow, checklist, or piece of domain knowledge keeps recurring
-  and deserves a named, invokable skill.
-- You are reimplementing an upstream third-party plugin command/skill for
-  cross-agent parity (see `analyze-plugin` / `implement-plugin-parity`).
-- The user asks to "create a skill", "add a command", or "scaffold a skill".
-
-If the knowledge is narrow or one-off, prefer a rule in `.claude/rules/` instead
-— skills are for broad, repeatable capabilities. When unsure whether content
-warrants a skill, run it past the `skill-evaluator` agent first.
-
-## Where skills live
-
-Lisa skills are **build output** for downstream projects. The source of truth is
-`plugins/src/`, never the generated `plugins/lisa*` artifacts:
-
-| Source directory | Builds artifact | Use for |
-| --- | --- | --- |
-| `plugins/src/base/` | `plugins/lisa` | Skills that ship to **every** stack |
-| `plugins/src/<stack>/` | `plugins/lisa-<stack>` | Stack-specific (typescript, expo, nestjs, cdk, harper-fabric, rails) |
-
-Lisa-repo-only skills (parity tooling, wiki ingestion, `lisa-*` meta-skills) live
-at the **root** `.claude/skills/` and `.claude/commands/`, NOT under
-`plugins/src` — they are not relevant to downstream projects. Decide placement
-first:
-
-- Ships to downstream projects → `plugins/src/base/skills/<name>/SKILL.md`
-- Only meaningful inside the Lisa monorepo → `.claude/skills/<name>/SKILL.md`
-
-## Naming
-
-- Use **hyphen-separated** names: `git-commit`, `tracker-write`,
-  `parity-sentry-seer`. No spaces, no camelCase, no underscores.
-- The directory name, the frontmatter `name`, and the command filename must all
-  match exactly.
-- Commands map to colon-separated UI names via directory nesting:
-  `commands/git/commit.md` → `/lisa:git:commit`; a flat
-  `commands/plan.md` → `/lisa:plan`.
-
-## SKILL.md frontmatter
-
-Skills support **only** these frontmatter keys (they do **not** support
-`argument-hint` or `$ARGUMENTS` substitution — those belong on the command):
-
-```yaml
----
-name: my-skill                       # required — matches the directory name
-description: "One or two sentences."  # required — when to use + what it does
-allowed-tools: ["Read", "Edit", "Write", "Bash"]  # optional — least privilege
-synced-from: <plugin>@<marketplace>@<version>      # ONLY for semver upstream reimplementations
----
-```
-
-- **`name`** — the hyphen identifier, byte-identical to the directory.
-- **`description`** — write it so the model knows *when* to reach for the skill,
-  not just what it does. Lead with the trigger. This is the single most
-  important field for discoverability.
-- **`allowed-tools`** — grant the minimum set. A read-only review skill needs no
-  `Write`/`Edit`. Omit the key entirely to inherit the caller's tools.
-- **`synced-from`** — add **only** when the skill reimplements an upstream plugin
-  that publishes a real semver. Grammar: `name@marketplace@version`
-  (e.g. `sentry@claude-plugins-official@1.0.0`). Omit for upstreams with no
-  semver (note that in the body instead, as this skill does).
-
-## The command pass-through pattern
-
-Every skill should have a thin command that is the user-facing entry point.
-Commands support `description`, `argument-hint`, and `$ARGUMENTS`; they delegate
-straight to the skill:
-
-```markdown
----
-description: "Same human-facing summary as the skill, phrased for the picker."
-argument-hint: "<what the user should type after the command>"
----
-
-Use the /lisa:my-skill skill to <do the thing>. $ARGUMENTS
-```
-
-The command carries the `argument-hint` and forwards `$ARGUMENTS`; the SKILL.md
-carries the actual logic. Keep the two descriptions consistent.
-
-## Scaffolding walkthrough
-
-1. **Decide placement** — downstream (`plugins/src/base`) vs. Lisa-only
-   (`.claude`). For base, both a skill and a command directory entry are needed.
-2. **Pick the name** — hyphenated, unique. Check it does not collide:
-   `ls plugins/src/base/skills/` and `ls plugins/src/base/commands/`.
-3. **Create the skill** at
-   `plugins/src/base/skills/<name>/SKILL.md` with the frontmatter above and a
-   body that follows house style — see `plugins/src/base/skills/quality-review/SKILL.md`
-   for the canonical shape (title, "When to use", numbered checklist/steps,
-   explicit "Rules"/"Output" sections). Write real, actionable guidance, not
-   TODOs.
-4. **Create the command** at `plugins/src/base/commands/<name>.md` (or a nested
-   `commands/<namespace>/<name>.md` for a colon-namespaced command) using the
-   pass-through template.
-5. **Rebuild the artifacts** so the generated plugins match source:
-   ```bash
-   bun run build:plugins
-   ```
-   Then commit **both** `plugins/src/...` and the regenerated `plugins/lisa*`.
-   The `🧩 Plugins Sync` CI check (and `bun run check:plugins` locally) fails if
-   artifacts drift from source — never hand-edit `plugins/lisa*`.
-6. **Verify discoverability** — confirm the skill appears in the skill list and
-   the command resolves to `/lisa:<name>`.
-
-## Body house style
-
-- Open with an `#` H1 title in Title Case.
-- Add a `## When to use` section that names the triggers.
-- Use numbered steps for procedures, checklists for review-style skills.
-- End with an explicit `## Rules` (hard constraints) and/or `## Output` section.
-- Write in plain, imperative English. Prefer concrete examples over abstraction.
-- Reference sibling skills by their hyphen name (e.g. "delegate to `git-commit`").
-
-## Rules
-
-- Never edit `plugins/lisa*` directly — edit `plugins/src/` and rebuild.
-- Skill frontmatter must not contain `argument-hint` or `$ARGUMENTS`.
-- The directory name, `name` field, and command filename must match exactly.
-- Add `synced-from` **only** for semver-versioned upstream reimplementations.
-- Do not include `/coding-philosophy` in task `skills` metadata — it auto-loads.
-- One skill, one responsibility. If a skill grows two jobs, split it.

package/plugins/lisa/skills/parity-skill-creator/agents/openai.yaml

@@ -1,4 +0,0 @@
-display_name: "Parity Skill Creator"
-short_description: "Author a new Lisa skill end-to-end — scaffold the SKILL.md frontmatter (name/description/allowed-tools), write the pass-through command…"
-default_prompt:
-  - "Use $parity-skill-creator: Author a new Lisa skill end-to-end — scaffold the SKILL.md frontmatter (name/description/allowed-tools), write the pass-through command…."

package/plugins/lisa/skills/performance-review/SKILL.md

@@ -1,94 +0,0 @@
----
-name: performance-review
-description: "Performance review methodology. N+1 queries, inefficient algorithms, memory leaks, missing indexes, unnecessary re-renders, bundle size issues. Evidence-based recommendations."
----
-
-# Performance Review
-
-Identify bottlenecks, inefficiencies, and scalability risks in code changes.
-
-## Analysis Process
-
-1. **Read affected files** -- understand data access patterns, algorithmic complexity, and resource usage
-2. **Identify N+1 queries** -- look for ORM calls inside loops, missing eager loading, unbatched database access
-3. **Check algorithmic complexity** -- nested loops over collections, repeated linear scans, unnecessary sorting
-4. **Evaluate memory usage** -- large object allocations, unbounded caches, retained references, memory leaks
-5. **Review database patterns** -- missing indexes, full table scans, unoptimized joins, excessive round trips
-6. **Check caching** -- missing cache layers, cache invalidation issues, redundant computations
-7. **Assess bundle/payload size** -- unnecessary imports, large dependencies, uncompressed responses
-8. **Review rendering performance** -- unnecessary re-renders, missing memoization, layout thrashing (frontend)
-
-## Output Format
-
-Structure findings as:
-
-```
-## Performance Analysis
-
-### Critical Issues
-Issues that will cause noticeable degradation at scale.
-
-- [issue] -- where in the code, why it matters, estimated impact
-
-### N+1 Query Detection
-| Location | Pattern | Fix |
-|----------|---------|-----|
-| file:line | Description of the N+1 | Eager load / batch / join |
-
-### Algorithmic Complexity
-| Location | Current | Suggested | Why |
-|----------|---------|-----------|-----|
-| file:line | O(n^2) | O(n) | Description |
-
-### Database Concerns
-- Missing indexes, unoptimized queries, excessive round trips
-
-### Memory Concerns
-- Unbounded growth, large allocations, retained references
-
-### Caching Opportunities
-- Computations or queries that could benefit from caching
-
-### Recommendations
-- [recommendation] -- priority (critical/warning/suggestion), estimated impact
-```
-
-## Common Patterns to Flag
-
-### N+1 Queries
-```typescript
-// Bad: N+1 -- one query per user inside loop
-const users = await userRepo.find();
-const profiles = await Promise.all(users.map(u => profileRepo.findOne({ userId: u.id })));
-
-// Good: Single query with join or batch
-const users = await userRepo.find({ relations: ["profile"] });
-```
-
-### Unnecessary Re-computation
-```typescript
-// Bad: Recomputes on every call
-const getExpensiveResult = () => heavyComputation(data);
-
-// Good: Compute once, reuse
-const expensiveResult = heavyComputation(data);
-```
-
-### Unbounded Collection Growth
-```typescript
-// Bad: Cache grows without limit
-const cache = new Map();
-const get = (key) => { if (!cache.has(key)) cache.set(key, compute(key)); return cache.get(key); };
-
-// Good: LRU or bounded cache
-const cache = new LRUCache({ max: 1000 });
-```
-
-## Rules
-
-- Focus on the specific changes proposed, not a full performance audit of the entire codebase
-- Flag only real performance risks -- do not micro-optimize code that runs once at startup
-- Quantify impact where possible (O(n) vs O(n^2), number of database round trips, estimated payload size)
-- Distinguish between critical issues (will degrade at scale) and suggestions (marginal improvement)
-- If the changes have no performance implications, report "No performance concerns" and explain why
-- Always consider the data scale -- an O(n^2) over 5 items is fine, over 10,000 is not

package/plugins/lisa/skills/performance-review/agents/openai.yaml

@@ -1,4 +0,0 @@
-display_name: "Performance Review"
-short_description: "Performance review methodology"
-default_prompt:
-  - "Use $performance-review: Performance review methodology."

package/plugins/lisa/skills/plan/SKILL.md

@@ -1,60 +0,0 @@
----
-name: plan
-description: "Decompose a single PRD or specification into ordered work items in the configured tracker. Vendor-agnostic — the source can be a Notion PRD URL, a Confluence PRD URL, a Linear project URL, a GitHub Issue URL, an existing JIRA epic key, a markdown file, or a free-form description; the destination tracker is whatever the project is configured to use via `.lisa.config.json` `tracker` (JIRA, GitHub Issues, or Linear). Single-PRD mode only — for batch scanning of all Ready PRDs in a queue, use the lisa:intake skill."
-allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep"]
----
-
-# Plan: $ARGUMENTS
-
-Decompose the PRD/spec at `$ARGUMENTS` into ordered work items with acceptance criteria, dependencies, and recommended skills/agents.
-
-## Orchestration: agent team
-
-If you are NOT already operating inside an agent team (no prior successful team-creation or subagent-delegation tool call in this session, not spawned into a team context), the very first thing you do is establish team orchestration.
-
-Use the team tool for the current runtime:
-
-- Claude: use `TeamCreate`. If `TeamCreate` has not been loaded yet, first use `ToolSearch` with `query: "select:TeamCreate"` to load its schema.
-- Codex: do not call `TeamCreate`; Codex does not expose that Claude tool. Use `tool_search` with a query like `multi-agent tools` to load `multi_agent_v1`, then use `multi_agent_v1.spawn_agent` for teammate delegation. Treat the first successful `spawn_agent` call as establishing team orchestration.
-- Other runtimes: use the current runtime's tool-discovery mechanism to discover and call the appropriate multi-agent/team tool.
-
-If no team creation or subagent delegation tool is available, explicitly state that team orchestration is unavailable in this runtime, continue as the lead agent, and preserve the workflow's review, verification, and task-tracking obligations locally.
-
-Until the team is established, the first Codex teammate has been spawned, or the no-team fallback has been declared, do NOT call any of: `Agent`, `TaskCreate`, `Skill`, MCP tools (Atlassian / Linear / GitHub / Notion), `Read`, `Write`, `Edit`, `Bash`, `Grep`, `Glob`. Reading the PRD, exploring the code, fetching context — all of those are tasks for the team you are about to create, not for the lead session before orchestration exists.
-
-If you ARE already inside an agent team (e.g., a teammate invoked this skill via the Skill tool), do NOT create a second team — many harnesses reject double-creates — and do NOT collapse the nested flow into a single inline worker. A nested team-first flow must still bring in the specialists it requires by adding them to the existing team, not by doing the work itself:
-
-- **Claude:** teams are flat and only the lead can add named teammates, so do NOT call `Agent` with a `name` from a teammate (the harness rejects it: *"Teammates cannot spawn other teammates — the team roster is flat"*). Send the team lead a message naming the specialist teammate(s) this flow needs, their task assignments, and completion criteria, then coordinate through the shared task list until they finish. An anonymous subagent (`Agent` with `name` omitted) is permitted only for bounded one-shot work whose result returns directly to you — it is not a substitute for the required lifecycle specialists.
-- **Codex:** do NOT call `TeamCreate`. If the lead/root agent is addressable (you were given its id/handle), send it a request to `multi_agent_v1.spawn_agent` the specialist agent(s), including each agent's prompt, ownership, and expected result. If no lead handle exists but `spawn_agent` is available to you, spawn only the bounded specialist agent(s) this flow needs, `wait_agent` for their results, and relay those results upward to the parent/lead.
-
-Treat the first successful lead-spawn request (or, on the Codex fallback, the first specialist spawn) as preserving team orchestration. Never satisfy a team-first lifecycle flow by doing all the work inline.
-
-## Source dispatch
-
-Detect the input type from `$ARGUMENTS` and route to the appropriate source skill:
-
-| If `$ARGUMENTS` is... | Hand off to |
-|------------------------|-------------|
-| A Notion **page** URL or page ID (single PRD) | `lisa:notion-to-tracker` (with the PRD URL; runs the full pipeline: extract artifacts → walk live product → validate → write tickets → coverage audit) |
-| A Notion **database** URL or database ID | Stop and report — single-PRD mode only. Direct the caller to `lisa:intake` for batch scanning of a database. |
-| A Confluence **page** URL containing `/wiki/spaces/<KEY>/pages/<ID>/...` (single PRD) | `lisa:confluence-to-tracker` (with the PRD URL; same full pipeline as the Notion path) |
-| A Confluence **space** URL (`/wiki/spaces/<KEY>` with no `/pages/...`) | Stop and report — single-PRD mode only. Direct the caller to `lisa:intake` for batch scanning of a space. |
-| A Linear **project** URL (`https://linear.app/<workspace>/project/<slug>-<id>`) | `lisa:linear-to-tracker` (with the project URL; same full pipeline as the Notion / Confluence paths). The Linear project's description, attached documents, and sub-issues form the PRD body. |
-| A Linear **workspace** URL (`https://linear.app/<workspace>` with no `/project/...`) or **team** URL | Stop and report — single-PRD mode only. Direct the caller to `lisa:intake` for batch scanning of a workspace or team. |
-| A JIRA ticket ID/URL of an Epic (existing epic *is* the spec) | `lisa:jira-agent` (read epic, decompose into stories/sub-tasks) |
-| A Linear Project URL of a Project that *is* the spec, when destination tracker = `linear` | `lisa:linear-agent` (read project, decompose into Issues / sub-Issues). Symmetric counterpart to the JIRA-Epic and GitHub-Epic branches. |
-| A GitHub **issue** URL (`https://github.com/<org>/<repo>/issues/<number>`) or `<org>/<repo>#<number>` token (single PRD) | `lisa:github-to-tracker` (with the issue ref; runs the full pipeline: extract artifacts → walk live product → validate → write tickets → coverage audit). The destination tracker is read from `.lisa.config.json` `tracker`. |
-| A GitHub **repository** URL or `<org>/<repo>` token (no issue number) | Stop and report — single-PRD mode only. Direct the caller to `lisa:intake` for batch scanning of a GitHub repo. |
-| A GitHub Issue URL of a build-side ticket (`type:Epic` / `type:Story` / etc., not `prd-*`-labelled) when `tracker = github` | `lisa:github-agent` (read issue, decompose into Sub-tasks). Symmetric counterpart to the JIRA-Epic branch above. |
-| A file path (`@plan.md`, `./spec.md`) | Read the file as the spec; run the Plan flow's core decomposition with the file content as input. |
-| A plain-text description | Use the description as the spec; run the Plan flow's core decomposition. |
-
-If no PRD or specification exists, suggest running the `lisa:research` skill first to produce one.
-
-## Flow
-
-Execute the **Plan** flow as defined in the `intent-routing` rule (loaded via the lisa plugin). The rule contains the canonical step sequence (gates, sub-flows, output structure). This skill does NOT restate flow steps — change them in the rule, propagate everywhere.
-
-## Output
-
-Work items in the configured tracker (JIRA, GitHub Issues, or Linear, per `.lisa.config.json` `tracker`) with acceptance criteria, dependencies, and recommended skills/agents per item. Ordered by dependency. Before finishing, route usage writes through `lisa:usage-accounting`: record the Plan run as a direct entry on the source PRD/spec artifact, attach a plan usage entry (or an explicit `source: unavailable` entry with nullable token/cost fields) to each created work item, and refresh the PRD rollup after `lisa:prd-backlink` regenerates the `## Tickets` child refs. Do not invent plan-specific ledger formats or omit missing usage silently. If the specification cannot be decomposed without further clarification, stop and report what is missing.

package/plugins/lisa/skills/plan/agents/openai.yaml

@@ -1,4 +0,0 @@
-display_name: "Plan"
-short_description: "Decompose a single PRD or specification into ordered work items in the configured tracker"
-default_prompt:
-  - "Use $plan: Decompose a single PRD or specification into ordered work items in the configured tracker."

package/plugins/lisa/skills/plugin-sync-explain/SKILL.md

@@ -1,53 +0,0 @@
----
-name: plugin-sync-explain
-description: "Read-only diagnostic for Lisa plugin source/generated drift. Compares plugins/src against generated plugins/lisa* status, reports source-not-built, generated-only, and marketplace registration drift, and preserves the working tree."
-allowed-tools: ["Bash", "Read"]
----
-
-# Plugin Sync Explain: $ARGUMENTS
-
-`/lisa:plugin-sync-explain` explains why the plugin sync gate would need attention without mutating the working tree.
-
-## Scope
-
-Inspect the current Lisa repository, or an optional path passed as `$ARGUMENTS`, using `scripts/plugin-sync-explain.mjs`.
-
-The diagnostic is **read-only**:
-
-- Do not run `bun run build:plugins`.
-- Do not run `bun run check:plugins`.
-- Do not edit source files, generated plugin artifacts, or `.claude-plugin/marketplace.json`.
-- Do not stash, commit, reset, or clean local changes.
-
-## What to Report
-
-Report a concise terminal-first summary with stable classifications:
-
-- `SOURCE_NOT_BUILT`: files under `plugins/src/**` changed without their generated `plugins/lisa*` counterpart.
-- `GENERATED_ONLY`: files under `plugins/lisa*` changed without their `plugins/src/**` source counterpart.
-- `MARKETPLACE_REGISTRATION_DRIFT`: a built plugin directory is missing from `.claude-plugin/marketplace.json`, or a marketplace source points at a missing built directory.
-- `OUT_OF_SYNC`: source and generated counterparts both changed and need human review.
-- `IN_SYNC`: no plugin source/generated or marketplace registration drift was detected.
-
-For every finding, include the evidence path and the smallest source-first next action. Prefer `bun run build:plugins` only after source edits are in the right place, and preserve `bun run check:plugins` as the final reproducibility gate.
-
-## Process
-
-1. Resolve the repo path from `$ARGUMENTS` or the current directory.
-2. Capture `git status --porcelain` before the diagnostic.
-3. Run:
-   ```bash
-   node plugins/lisa/scripts/plugin-sync-explain.mjs "$REPO_PATH"
-   ```
-   If running from the source tree before generated artifacts are rebuilt, use:
-   ```bash
-   node plugins/src/base/scripts/plugin-sync-explain.mjs "$REPO_PATH"
-   ```
-4. Capture `git status --porcelain` after the diagnostic and confirm it is unchanged.
-5. Surface the script output plus the read-only confirmation.
-
-## Rules
-
-- Keep this surface aligned with `scripts/check-plugins-sync.sh`; it explains the gate but does not replace it.
-- Treat `plugins/src/**` as the source of truth and `plugins/lisa*` as generated artifacts.
-- If the diagnostic cannot inspect git status or marketplace JSON, report the error plainly and do not guess.

package/plugins/lisa/skills/plugin-sync-explain/agents/openai.yaml

@@ -1,4 +0,0 @@
-display_name: "Plugin Sync Explain"
-short_description: "Read-only diagnostic for Lisa plugin source/generated drift"
-default_prompt:
-  - "Use $plugin-sync-explain: Read-only diagnostic for Lisa plugin source/generated drift."

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

@@ -1,60 +0,0 @@
----
-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/skills/posthog-access/agents/openai.yaml

@@ -1,4 +0,0 @@
-display_name: "PostHog Access"
-short_description: "Vendor-neutral access layer for PostHog"
-default_prompt:
-  - "Use $posthog-access: Vendor-neutral access layer for PostHog."