@stigmer/plugin-package 3.35.0 → 3.36.0

package/src/__tests__/fixtures/cursor-plugins/thermos/skills/thermo-nuclear-code-quality-review/SKILL.md

@@ -1,192 +0,0 @@
----
-name: thermo-nuclear-code-quality-review
-description: Run an extremely strict maintainability review for abstraction quality, giant files, and spaghetti-condition growth. Use for a thermo-nuclear code quality review, thermonuclear review, deep code quality audit, or especially harsh maintainability review.
-disable-model-invocation: true
----
-
-# Thermo-Nuclear Code Quality Review
-
-Use this skill for an unusually strict review focused on implementation quality, maintainability, abstraction quality, and codebase health.
-
-Above all, this skill should push the reviewer to be **ambitious** about code structure. Do not merely identify local cleanup opportunities. Actively search for "code judo" moves: restructurings that preserve behavior while making the implementation dramatically simpler, smaller, more direct, and more elegant.
-
-## Core Prompt
-
-Start from this baseline:
-
-> Perform a deep code quality audit of the current branch's changes.
-> Rethink how to structure / implement the changes to meaningfully improve code quality without impacting behavior.
-> Work to improve abstractions, modularity, reduce Spaghetti code, improve succinctness and legibility.
-> Be ambitious, if there is a clear path to improving the implementation that involves restructuring some of the codebase, go for it.
-> Be extremely thorough and rigorous. Measure twice, cut once.
-
-## Non-Negotiable Additional Standards
-
-Apply the baseline prompt above, plus these explicit review rules:
-
-0. **Be ambitious about structural simplification.**
-   - Do not stop at "this could be a bit cleaner."
-   - Look for opportunities to reframe the change so that whole branches, helpers, modes, conditionals, or layers disappear entirely.
-   - Prefer the solution that makes the code feel inevitable in hindsight.
-   - Assume there is often a "code judo" move available: a re-organization that uses the existing architecture more effectively and makes the change dramatically simpler and more elegant.
-   - If you see a path to delete complexity rather than rearrange it, push hard for that path.
-
-1. **Do not let a PR push a file from under 1k lines to over 1k lines without a very strong reason.**
-   - Treat this as a strong code-quality smell by default.
-   - Prefer extracting helpers, subcomponents, modules, or local abstractions instead of letting a file sprawl past 1000 lines.
-   - If the diff crosses that threshold, explicitly ask whether the code should be decomposed first.
-   - Only waive this if there is a compelling structural reason and the resulting file is still clearly organized.
-
-2. **Do not allow random spaghetti growth in existing code.**
-   - Be highly suspicious of new ad-hoc conditionals, scattered special cases, or one-off branches inserted into unrelated flows.
-   - If a change adds "weird if statements in random places", treat that as a design problem, not a stylistic nit.
-   - Prefer pushing the logic into a dedicated abstraction, helper, state machine, policy object, or separate module instead of tangling an existing path.
-   - Call out changes that make the surrounding code harder to reason about, even if they technically work.
-
-3. **Bias toward cleaning the design, not just accepting working code.**
-   - If behavior can stay the same while the structure becomes meaningfully cleaner, push for the cleaner version.
-   - Do not rubber-stamp "it works" implementations that leave the codebase messier.
-   - Strongly prefer simplifications that remove moving pieces altogether over refactors that merely spread the same complexity around.
-
-4. **Prefer direct, boring, maintainable code over hacky or magical code.**
-   - Treat brittle, ad-hoc, or "magic" behavior as a code-quality problem.
-   - Be skeptical of generic mechanisms that hide simple data-shape assumptions.
-   - Flag thin abstractions, identity wrappers, or pass-through helpers that add indirection without buying clarity.
-
-5. **Push hard on type and boundary cleanliness when they affect maintainability.**
-   - Question unnecessary optionality, `unknown`, `any`, or cast-heavy code when a clearer type boundary could exist.
-   - Prefer explicit typed models or shared contracts over loosely-shaped ad-hoc objects.
-   - If a branch relies on silent fallback to paper over an unclear invariant, ask whether the boundary should be made explicit instead.
-
-6. **Keep logic in the canonical layer and reuse existing helpers.**
-   - Call out feature logic leaking into shared paths or implementation details leaking through APIs.
-   - Prefer existing canonical utilities/helpers over bespoke one-offs.
-   - Push code toward the right package, service, or module instead of normalizing architectural drift.
-
-7. **Treat unnecessary sequential orchestration and non-atomic updates as design smells when the cleaner structure is obvious.**
-   - If independent work is serialized for no good reason, ask whether the flow should run in parallel instead.
-   - If related updates can leave state half-applied, push for a more atomic structure.
-   - Do not over-index on micro-optimizations, but do flag avoidable orchestration complexity that makes the implementation more brittle.
-
-## Primary Review Questions
-
-For every meaningful change, ask:
-
-- Is there a "code judo" move that would make this dramatically simpler?
-- Can this change be reframed so fewer concepts, branches, or helper layers are needed?
-- Does this improve or worsen the local architecture?
-- Did the diff add branching complexity where a better abstraction should exist?
-- Did a previously cohesive module become more coupled, more stateful, or harder to scan?
-- Is this logic living in the right file and layer?
-- Did this change enlarge a file or component past a healthy size boundary?
-- Are there repeated conditionals that signal a missing model or missing helper?
-- Is the implementation direct and legible, or does it rely on special cases and incidental control flow?
-- Is this abstraction actually earning its keep, or is it just a wrapper?
-- Did the diff introduce casts, optionality, or ad-hoc object shapes that obscure the real invariant?
-- Is this logic living in the canonical layer, or did the diff leak details across a boundary?
-- Is this orchestration more sequential or less atomic than it needs to be?
-
-## What to Flag Aggressively
-
-Escalate findings when you see:
-
-- A complicated implementation where a cleaner reframing could delete whole categories of complexity.
-- Refactors that move code around but fail to reduce the number of concepts a reader must hold in their head.
-- A file crossing 1000 lines due to the PR, especially if the new code could be split out.
-- New conditionals bolted onto unrelated code paths.
-- One-off booleans, nullable modes, or flags that complicate existing control flow.
-- Feature-specific logic leaking into general-purpose modules.
-- Generic "magic" handling that hides simple structure and makes the code harder to reason about.
-- Thin wrappers or identity abstractions that add indirection without simplifying anything.
-- Unnecessary casts, `any`, `unknown`, or optional params that muddy the real contract.
-- Copy-pasted logic instead of extracted helpers.
-- Narrow edge-case handling implemented in the middle of an already busy function.
-- Refactors that technically pass tests but make the code less modular or less readable.
-- "Temporary" branching that is likely to become permanent debt.
-- Bespoke helpers where the codebase already has a canonical utility for the job.
-- Logic added in the wrong layer/package when it should live somewhere more central.
-- Sequential async flow where obviously independent work could stay simpler and clearer with parallel execution.
-- Partial-update logic that leaves state less atomic than necessary.
-
-## Preferred Remedies
-
-When you identify a code-quality problem, prefer suggestions like:
-
-- Delete a whole layer of indirection rather than polishing it.
-- Reframe the state model so conditionals disappear instead of getting centralized.
-- Change the ownership boundary so the feature becomes a natural extension of an existing abstraction.
-- Turn special-case logic into a simpler default flow with fewer exceptions.
-- Extract a helper or pure function.
-- Split a large file into smaller focused modules.
-- Move feature-specific logic behind a dedicated abstraction.
-- Replace condition chains with a typed model or explicit dispatcher.
-- Separate orchestration from business logic.
-- Collapse duplicate branches into a single clearer flow.
-- Delete wrappers that do not meaningfully clarify the API.
-- Reuse the existing canonical helper instead of introducing a near-duplicate.
-- Make type boundaries more explicit so the control flow gets simpler.
-- Move the logic to the package/module/layer that already owns the concept.
-- Parallelize independent work when that also simplifies the orchestration.
-- Restructure related updates into a more atomic flow when partial state would be harder to reason about.
-
-Do not be satisfied with "maybe rename this" feedback when the real issue is structural.
-Do not be satisfied with a merely cleaner version of the same messy idea if there is a plausible path to a much simpler idea.
-
-## Review Tone
-
-Be direct, serious, and demanding about quality.
-Do not be rude, but do not soften major maintainability issues into mild suggestions.
-If the code is making the codebase messier, say so clearly.
-If the implementation missed an opportunity for a dramatic simplification, say that clearly too.
-
-Good phrases:
-
-- `this pushes the file past 1k lines. can we decompose this first?`
-- `this adds another special-case branch into an already busy flow. can we move this behind its own abstraction?`
-- `this works, but it makes the surrounding code more spaghetti. let's keep the behavior and restructure the implementation.`
-- `this feels like feature logic leaking into a shared path. can we isolate it?`
-- `this abstraction seems unnecessary. can we just keep the direct flow?`
-- `why does this need a cast / optional here? can we make the boundary more explicit instead?`
-- `this looks like a bespoke helper for something we already have elsewhere. can we reuse the canonical one?`
-- `i think there's a code-judo move here that makes this much simpler. can we reframe this so these branches disappear?`
-- `this refactor moves complexity around, but doesn't really delete it. is there a way to make the model itself simpler?`
-
-## Output Expectations
-
-Prioritize findings in this order:
-
-1. Structural code-quality regressions
-2. Missed opportunities for dramatic simplification / code-judo restructuring
-3. Spaghetti / branching complexity increases
-4. Boundary / abstraction / type-contract problems that make the code harder to reason about
-5. File-size and decomposition concerns
-6. Modularity and abstraction issues
-7. Legibility and maintainability concerns
-
-Do not flood the review with low-value nits if there are larger structural issues.
-Prefer a smaller number of high-conviction comments over a long list of cosmetic notes.
-
-## Approval Bar
-
-Do not approve merely because behavior seems correct.
-The bar for approval is:
-
-- no clear structural regression
-- no obvious missed opportunity to make the implementation dramatically simpler when such a path is visible
-- no unjustified file-size explosion
-- no obvious spaghetti-growth from special-case branching
-- no obviously hacky or magical abstraction that makes the code harder to reason about
-- no unnecessary wrapper/cast/optionality churn obscuring the real design
-- no clear architecture-boundary leak or avoidable canonical-helper duplication
-- no missed opportunity for an obvious decomposition that would materially improve maintainability
-
-Treat these as presumptive blockers unless the author can justify them clearly:
-
-- the PR preserves a lot of incidental complexity when there is a plausible code-judo move that would delete it
-- the PR pushes a file from below 1000 lines to above 1000 lines
-- the PR adds ad-hoc branching that makes an existing flow more tangled
-- the PR solves a local problem by scattering feature checks across shared code
-- the PR adds an unnecessary abstraction, wrapper, or cast-heavy contract that makes the design more indirect
-- the PR duplicates an existing helper or puts logic in the wrong layer when there is a clear canonical home
-
-If those conditions are not met, leave explicit, actionable feedback and push for a cleaner decomposition.

package/src/__tests__/fixtures/cursor-plugins/thermos/skills/thermo-nuclear-review/SKILL.md

@@ -1,51 +0,0 @@
----
-name: thermo-nuclear-review
-description: Comprehensive security and correctness audit of a branch's changes. Use for thermo nuclear, thermonuclear, or deep review requests, or branch/PR diff audits focused on bugs, breaking changes, security issues, devex regressions, and feature-gate leaks.
-disable-model-invocation: true
----
-
-# Thermo Nuclear Review
-
-Use this skill for a comprehensive security and correctness audit of a checked-out branch.
-
-## Prompt
-
-You are a security expert performing a comprehensive review of a checked out branch. Audit this branch and its changes extremely thoroughly for bugs, changes that break existing features/functionality, and security vulnerabilities. Be EXTREMELY thorough, rigorous, careful, ambitious, and attentive. NOTHING can slip through.
-
-# Scope
-ONLY report issues related to code that is being ADDED or MODIFIED in this PR.
-Focus on changes in the diff.
-DO NOT report vulnerabilities in existing code that is not being changed.
-
-# Guidelines
-
-## Breaking Functionality Guidelines
-This is a complex codebase, with many cross-package/module dependencies. Often simple code changes in one place have subtle interactions that break functionality elsewhere. You MUST be extremely thorough in tracing through possible side effects of the changes.
-
-## Breaking Devex Guidelines
-It can be easy to break developers' ability to run / build the code locally. You MUST catch changes that will impact users' developer experience. Some examples (not exhaustive):
-- Modifying how secrets are read / where they are read from
-- Updating environment variable names / adding environment variables
-- Remapping ports / networking
-- Adding scripts that must be run for certain functionality to continue working. Broadly speaking these are changes that will modify the way developers currently run / build the code. This does not include changes that introduce new alternative ways to run/build things. Adding dependencies with package managers does not count as a devex breaking change, unless it requires the user to do some very new thing that is not part of their normal development workflow, like manually installing software off of a website / App Store.
-
-## Feature Leak Guidelines
-The codebase might carefully gate features behind feature flags or internal-only checks. You MUST NOT allow any features that are meant to be behind a feature gate leak. These leaks are often subtle. Be VERY careful and thorough.
-
-## Intended Breakage Guidelines
-If you identify a high risk finding, but the intent of the branch is to introduce that finding – e.g. break some functionality, remove a feature flag, remove a safeguard – AND the scope of the change is well constrained, you SHOULD NOT waste the author's time by reporting the issue to them. However, if you believe it is likely that they are not aware of the full implications of their change, or you are worried that they are under-weighting the negative impacts (extreme example: a developer pushes a PR titled "Delete the database"), or you are worried that the change is actually malicious, you should still report the finding.
-
-## Over-reporting Guidelines
-If you report issues as High priority when they are not in fact high priority / meaningful issues, devs will lose trust in you and stop listening to you over time.
-NEVER misreport the priority / importance of issues. Be extremely thorough in tracing issues end-to-end to gain complete, and total confidence before reporting.
-
-# Final Response
-IF you have medium-to-high priority / risk findings, and there is a PR for this branch, then check the PR/MR discussion using gh/glab cli to see if there are comments from BugBot or others present.
-If so, take their findings into account. If they found issues you missed, evaluate them to determine if they are valid and include them in your report. If they found some of the same issues you did, see if there is anything from their findings that are worth incorporating into your response.
-Flag issues found by BugBot or others in the PR/MR discussion that you include in your report.
-
-
-# Critical Rules
-- NEVER present issues with unfinished research. E.g. Never say something like, "The client has issue X, but if handled in the backend then this is ok." if you have access to the backend code and can check for yourself.
-- You MUST wait to check the PR/MR discussion until AFTER you have performed your audit. This way you have fresh eyes while you review.
-- Be EXTREMELY thorough, rigorous, careful, ambitious, and attentive. NOTHING can slip through.

package/src/__tests__/fixtures/cursor-plugins/thermos/skills/thermos/SKILL.md

@@ -1,21 +0,0 @@
----
-name: thermos
-description: "Launch both thermo-nuclear review subagents in parallel, then synthesize their findings. Use for thermos, double thermo review, or combined bug/security and code-quality branch audits."
-disable-model-invocation: true
----
-
-# Thermos
-
-Run the two thermo review passes as async background subagents in parallel, then synthesize their results.
-
-## Workflow
-
-1. Determine the review scope from the user request, PR, current branch, or relevant changed files.
-2. Gather the diff and any file/context excerpts needed for reviewers to evaluate the change without guessing.
-3. Launch both subagents in the same message with `run_in_background: true`:
-   - `subagent_type: "thermo-nuclear-review-subagent"` for bugs, breakages, security, devex regressions, feature-flag leaks, and other branch-audit risks.
-   - `subagent_type: "thermo-nuclear-code-quality-review-subagent"` for maintainability, structure, file-size growth, spaghetti, abstractions, and codebase-health risks.
-4. Pass each subagent the same scoped diff/file context and ask it to return prioritized findings with file references and evidence.
-5. After both finish, synthesize the results with findings first, deduplicated across reviewers. Weight overlapping findings more heavily, resolve disagreements with your own judgment, and keep summaries brief.
-
-If individual background summaries are already visible to the user, do not restate them wholesale. Surface the unified verdict, the highest-signal findings, and any remaining uncertainty.

package/src/__tests__/fixtures/cursor-plugins/xero/.cursor-plugin/plugin.json

@@ -1,53 +0,0 @@
-{
-  "name": "xero",
-  "displayName": "Xero",
-  "version": "1.0.0",
-  "minClientVersions": {
-    "cursor": "3.13.0"
-  },
-  "description": "Read and write invoices, contacts, reports, and payroll.",
-  "author": {
-    "name": "Cursor",
-    "email": "plugins@cursor.com"
-  },
-  "homepage": "https://github.com/XeroAPI/xero-mcp-server",
-  "repository": "https://github.com/cursor/plugins",
-  "license": "MIT",
-  "logo": "assets/logo.png",
-  "keywords": [
-    "xero",
-    "accounting",
-    "invoices",
-    "payroll",
-    "bookkeeping",
-    "finance",
-    "mcp"
-  ],
-  "category": "integrations",
-  "tags": [
-    "xero",
-    "accounting",
-    "mcp",
-    "finance"
-  ],
-  "variables": {
-    "type": "object",
-    "properties": {
-      "XERO_CLIENT_ID": {
-        "type": "string",
-        "title": "Xero client ID",
-        "description": "Client ID of the Custom Connection you created at developer.xero.com. A Custom Connection is bound to a single Xero organisation."
-      },
-      "XERO_CLIENT_SECRET": {
-        "type": "string",
-        "title": "Xero client secret",
-        "description": "Client secret generated alongside the Custom Connection's client ID at developer.xero.com."
-      }
-    },
-    "required": [
-      "XERO_CLIENT_ID",
-      "XERO_CLIENT_SECRET"
-    ]
-  },
-  "mcpServers": "./mcp.json"
-}

package/src/__tests__/fixtures/cursor-plugins/xero/CHANGELOG.md

@@ -1,9 +0,0 @@
-# Changelog
-
-All notable changes to this plugin will be documented here.
-
-## 1.0.0 — initial release
-
-- Added the `xero` MCP server, running `@xeroapi/xero-mcp-server` locally over stdio.
-- Auth uses a Xero Custom Connection client ID and secret supplied by the user.
-- Logo: Xero's official mark, from the `XeroAPI` GitHub organization.

package/src/__tests__/fixtures/cursor-plugins/xero/LICENSE

@@ -1,21 +0,0 @@
-MIT License
-
-Copyright (c) 2026 Cursor
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.

package/src/__tests__/fixtures/cursor-plugins/xero/README.md

@@ -1,79 +0,0 @@
-# Xero
-
-Cursor plugin that connects agents to [Xero](https://www.xero.com) through Xero's official [Model Context Protocol](https://modelcontextprotocol.io/) server, run locally by Cursor.
-
-Read and write a Xero organisation's accounting and payroll data — invoices, contacts, chart of accounts, payments, quotes, journals, reports, and timesheets.
-
-## Install
-
-1. Open **Cursor Settings → Plugins**.
-2. Search for **Xero**.
-3. Click **Install**, then set the Xero client ID and client secret (below).
-
-Or run `/add-plugin xero` in chat.
-
-## MCP
-
-```json
-{
-  "mcpServers": {
-    "xero": {
-      "type": "stdio",
-      "command": "npx",
-      "args": [
-        "-y",
-        "@xeroapi/xero-mcp-server@latest"
-      ],
-      "env": {
-        "XERO_CLIENT_ID": "${XERO_CLIENT_ID}",
-        "XERO_CLIENT_SECRET": "${XERO_CLIENT_SECRET}"
-      }
-    }
-  }
-}
-```
-
-Xero does not publish a hosted MCP endpoint. Its official server runs locally over stdio and authenticates with a **Custom Connection** — Xero's machine-to-machine OAuth 2.0 flow — so the plugin takes a client ID and secret rather than prompting for browser sign-in.
-
-## Before you connect
-
-1. Sign in at [developer.xero.com](https://developer.xero.com) and create an app with the **Custom Connection** option.
-2. Select the scopes up front. Connections created before 2026-04-29 use the bundled scope list; newer ones use the granular list. The server tries the bundled set first and falls back, so you usually do not need to set `XERO_SCOPES`.
-3. Authorize the connection from the email Xero sends, and pick the organisation to connect.
-4. Copy the **Client ID**, generate a **Client Secret**, and set both in **Dashboard → Plugins → Configure**.
-
-A Custom Connection is bound to a single Xero organisation and is a paid add-on per organisation. Payroll tools require an NZ or UK organisation.
-
-## What agents can do
-
-| Category | Capabilities |
-| --- | --- |
-| Accounts & contacts | Chart of accounts, contacts, and contact groups |
-| Sales & purchases | Invoices, quotes, credit notes, and payments |
-| Banking | Bank transactions and manual journals |
-| Items & tracking | Items and tracking categories |
-| Reports | Profit and loss, balance sheet, trial balance, and aged receivables/payables |
-| Payroll | Employees, leave, leave types, and timesheets (NZ and UK organisations) |
-
-The server is the source of truth for tool names and schemas.
-
-## Notes
-
-- This is a local stdio server, so `npx` has to be available on the machine running Cursor. It downloads `@xeroapi/xero-mcp-server` on first run.
-- Xero's own FAQ says the server works with any client supporting local stdio servers, and that its testing was done with Claude Desktop and Cursor.
-- Tool calls run with the scopes granted to the Custom Connection, against the one organisation it is bound to. To work with several organisations, create a connection per organisation.
-- To narrow the surface further, add a space-separated `XERO_SCOPES` value to the server's `env` — for example `accounting.invoices accounting.contacts accounting.settings`.
-- `xero-mcp` by john-zhang-dev is a community package, and JAX is Xero's in-product assistant. Neither is this server.
-
-## Docs
-
-- Xero MCP server: https://github.com/XeroAPI/xero-mcp-server
-- Xero AI and MCP: https://developer.xero.com/ai
-- Custom Connections: https://developer.xero.com/documentation/guides/oauth2/custom-connections/
-- npm package: https://www.npmjs.com/package/@xeroapi/xero-mcp-server
-
-Logo is Xero's official mark, from the `XeroAPI` GitHub organization.
-
-## License
-
-MIT

package/src/__tests__/fixtures/cursor-plugins/xero/mcp.json

@@ -1,16 +0,0 @@
-{
-  "mcpServers": {
-    "xero": {
-      "type": "stdio",
-      "command": "npx",
-      "args": [
-        "-y",
-        "@xeroapi/xero-mcp-server@latest"
-      ],
-      "env": {
-        "XERO_CLIENT_ID": "${XERO_CLIENT_ID}",
-        "XERO_CLIENT_SECRET": "${XERO_CLIENT_SECRET}"
-      }
-    }
-  }
-}

package/src/__tests__/fixtures.test.ts

@@ -1,198 +0,0 @@
-/**
- * The fixture suite: six real Cursor plugins, vendored from cursor/plugins
- * at c1c0a32 (see fixtures/cursor-plugins/NOTICE), read exactly as a user's
- * checkout would be. Every assertion names the field it pins; there are no
- * snapshot files, so a change in what the reader produces is a change
- * someone wrote down here.
- *
- * Between them the six cover: Cursor `variables` with `required` (github,
- * xero, salesforce), a `${VAR}` inside a header (github), stdio `env` as
- * `KEY: "${KEY}"` (xero), an entry with no `type` inferred to stdio
- * (playwright), a `${VAR}` url plus the undocumented `auth` block
- * (salesforce, the one refusal), two sub-agents and no server (thermos), a
- * sub-agent with an unmappable model and a `readonly` field plus hooks that
- * reference `${CURSOR_PLUGIN_ROOT}` and must never be read (advisor), skill
- * frontmatter with vendor keys, `minClientVersions`, a `references/` file
- * inside a skill, and image assets that are listed and never opened.
- */
-
-import { fileURLToPath } from "node:url";
-
-import { describe, expect, it } from "vitest";
-
-import { readPluginPackage } from "../read-plugin-package.js";
-import { directoryPluginFiles } from "../__test-utils__/directory-files.js";
-import { accepted, findingOf, kindsOf, refused } from "../__test-utils__/read.js";
-
-const FIXTURES = fileURLToPath(new URL("./fixtures/cursor-plugins/", import.meta.url));
-
-function readFixture(name: string) {
-  return readPluginPackage(directoryPluginFiles(`${FIXTURES}${name}`));
-}
-
-describe("thermos: skills and sub-agents, no server", () => {
-  const outcome = readFixture("thermos");
-
-  it("is accepted with no warnings", () => {
-    expect(kindsOf(outcome)).toEqual({ errors: [], warnings: [] });
-  });
-
-  it("carries the manifest identity", () => {
-    const plugin = accepted(outcome);
-    expect(plugin).toMatchObject({
-      name: "thermos",
-      version: "1.0.0",
-      license: "MIT",
-      dialect: "cursor",
-      manifestsFound: [".cursor-plugin/plugin.json"],
-      author: { name: "Cursor", email: "plugins@cursor.com" },
-      homepage: "https://github.com/cursor/plugins",
-    });
-    expect(plugin.keywords).toContain("thermo-nuclear");
-  });
-
-  it("reads the three skills with their descriptions and files", () => {
-    const plugin = accepted(outcome);
-    expect(plugin.skills.map((s) => s.name)).toEqual(["thermo-nuclear-code-quality-review", "thermo-nuclear-review", "thermos"]);
-    expect(plugin.skills[2]?.description).toMatch(/^Launch both thermo-nuclear review subagents/);
-    expect(plugin.skills[2]?.files).toEqual(["skills/thermos/SKILL.md"]);
-  });
-
-  it("reads the two sub-agents with the file body as instructions and no model hint", () => {
-    const plugin = accepted(outcome);
-    expect(plugin.subAgents.map((a) => a.name)).toEqual(["thermo-nuclear-code-quality-review-subagent", "thermo-nuclear-review-subagent"]);
-    const review = plugin.subAgents[1];
-    expect(review?.description).toMatch(/^Thermo-nuclear branch audit/);
-    expect(review?.instructions.length).toBeGreaterThan(1000);
-    expect(review?.modelHint).toBeUndefined();
-    expect(review?.path).toBe("agents/thermo-nuclear-review-subagent.md");
-  });
-
-  it("has no servers and no variables, and records only the logo", () => {
-    const plugin = accepted(outcome);
-    expect(plugin.mcpServers).toEqual([]);
-    expect(plugin.variables).toEqual([]);
-    expect(plugin.ignored).toEqual([
-      { kind: "assets", path: "assets/" },
-      { kind: "logo", path: ".cursor-plugin/plugin.json#logo" },
-    ]);
-  });
-});
-
-describe("github: an HTTP server with a token in a header", () => {
-  const outcome = readFixture("github");
-
-  it("is accepted with no warnings", () => {
-    expect(kindsOf(outcome)).toEqual({ errors: [], warnings: [] });
-  });
-
-  it("reads the server with the header reference on its env", () => {
-    expect(accepted(outcome).mcpServers).toEqual([
-      {
-        name: "github",
-        transport: "http",
-        url: "https://api.githubcopilot.com/mcp/",
-        headers: { Authorization: "Bearer ${GITHUB_PERSONAL_ACCESS_TOKEN}" },
-        env: ["GITHUB_PERSONAL_ACCESS_TOKEN"],
-      },
-    ]);
-  });
-
-  it("declares the required variable as a secret with the joined title and description", () => {
-    expect(accepted(outcome).variables).toEqual([
-      {
-        name: "GITHUB_PERSONAL_ACCESS_TOKEN",
-        description:
-          "GitHub personal access token: Fine-grained or classic PAT from https://github.com/settings/tokens with the repo scopes you want the agent to use.",
-        isSecret: true,
-        optional: false,
-        declaredBy: "cursor",
-      },
-    ]);
-  });
-
-  it("records minClientVersions and the logo as ignored", () => {
-    expect(accepted(outcome).ignored.map((c) => c.kind).sort()).toEqual(["assets", "logo", "min-client-versions"]);
-  });
-});
-
-describe("xero: a stdio server passing two secrets by name", () => {
-  const outcome = readFixture("xero");
-
-  it("is accepted with no warnings", () => {
-    expect(kindsOf(outcome)).toEqual({ errors: [], warnings: [] });
-  });
-
-  it("reads the npx command with its args and both env references", () => {
-    expect(accepted(outcome).mcpServers).toEqual([
-      {
-        name: "xero",
-        transport: "stdio",
-        command: "npx",
-        args: ["-y", "@xeroapi/xero-mcp-server@latest"],
-        env: ["XERO_CLIENT_ID", "XERO_CLIENT_SECRET"],
-      },
-    ]);
-  });
-
-  it("declares both variables as required secrets", () => {
-    expect(accepted(outcome).variables.map((v) => [v.name, v.isSecret, v.optional])).toEqual([
-      ["XERO_CLIENT_ID", true, false],
-      ["XERO_CLIENT_SECRET", true, false],
-    ]);
-  });
-});
-
-describe("playwright: a server with no type and no variables", () => {
-  const outcome = readFixture("playwright");
-
-  it("is accepted with no warnings and infers stdio from command", () => {
-    expect(kindsOf(outcome)).toEqual({ errors: [], warnings: [] });
-    expect(accepted(outcome).mcpServers).toEqual([
-      { name: "playwright", transport: "stdio", command: "npx", args: ["-y", "@playwright/mcp@latest"], env: [] },
-    ]);
-    expect(accepted(outcome).variables).toEqual([]);
-  });
-});
-
-describe("salesforce: a variable in the url is refused", () => {
-  const outcome = readFixture("salesforce");
-
-  it("is refused for the url alone, with the auth block warned", () => {
-    expect(kindsOf(outcome)).toEqual({ errors: ["mcp-server-url-variable"], warnings: ["mcp-server-auth-ignored"] });
-    expect(findingOf(refused(outcome), "mcp-server-url-variable").message).toBe(
-      "MCP server 'salesforce' in 'mcp.json' has a variable in its 'url'; Stigmer sends the URL as written, so write the URL out and put variables in 'headers'",
-    );
-  });
-});
-
-describe("advisor: a sub-agent with an unmappable model, and hooks that are never read", () => {
-  const outcome = readFixture("advisor");
-
-  it("is accepted with the model and the readonly field warned", () => {
-    expect(kindsOf(outcome)).toEqual({ errors: [], warnings: ["sub-agent-field-ignored", "sub-agent-model-unknown"] });
-    expect(findingOf(outcome.warnings, "sub-agent-model-unknown")).toMatchObject({ subject: "advisor-subagent", detail: "grok-4.6[effort=xhigh]" });
-    expect(findingOf(outcome.warnings, "sub-agent-field-ignored")).toMatchObject({ subject: "advisor-subagent", detail: "readonly" });
-  });
-
-  it("keeps the raw model text in the hint", () => {
-    expect(accepted(outcome).subAgents[0]?.modelHint).toEqual({ raw: "grok-4.6[effort=xhigh]", alias: "unknown" });
-  });
-
-  it("reads the skill with its references file and vendor frontmatter keys", () => {
-    const skill = accepted(outcome).skills[0];
-    expect(skill?.name).toBe("advisor");
-    expect(skill?.files).toEqual(["skills/advisor/SKILL.md", "skills/advisor/references/briefing-template.md"]);
-  });
-
-  it("records hooks as ignored without reading the ${CURSOR_PLUGIN_ROOT} inside them", () => {
-    const plugin = accepted(outcome);
-    expect(plugin.ignored).toEqual([
-      { kind: "assets", path: "assets/" },
-      { kind: "hooks", path: "hooks/" },
-      { kind: "logo", path: ".cursor-plugin/plugin.json#logo" },
-      { kind: "hooks", path: ".cursor-plugin/plugin.json#hooks" },
-    ]);
-    expect(plugin.mcpServers).toEqual([]);
-  });
-});