@crouton-kit/crouter 0.1.9 → 0.2.2

package/dist/builtin-skills/.crouter-plugin/plugin.json

@@ -0,0 +1,5 @@
+{
+  "name": "crtr",
+  "version": "0.2.0",
+  "description": "Builtin crouter skills — authoring guidance shipped with the binary"
+}

package/dist/builtin-skills/skills/crouter-development/marketplaces/SKILL.md

@@ -0,0 +1,157 @@
+---
+name: crouter-development/marketplaces
+type: playbook
+description: How to author a crtr marketplace — marketplace.json index, plugin entries, symlink-based install, auto-bump CI, dual-publishing. Use when creating a marketplace or contributing plugins to one.
+keywords: [marketplace, marketplace.json, plugin, index, publishing]
+---
+
+# Authoring crtr marketplaces
+
+A **marketplace** is a git repo that indexes multiple plugins. Users register it once, then `crtr marketplace install <mkt>:<plugin>` symlinks any plugin from it. One `crtr marketplace update` pulls updates for every installed plugin at once.
+
+Audience: LLM agents creating a marketplace or adding plugins to an existing one.
+
+## When you need a marketplace (vs a single-plugin repo)
+
+A solo plugin ships from any git URL via `crtr plugin install <url>` — no marketplace needed.
+
+Reach for a marketplace when:
+- You want to publish ≥3 plugins under one brand or theme.
+- Users should install selectively without cloning each plugin's repo.
+- You want centralized version-bump automation across many plugins.
+
+If you have one plugin, ship it standalone. Promote to a marketplace later.
+
+## Directory layout
+
+```
+<marketplace-repo>/
+├── .crouter-marketplace/
+│   └── marketplace.json              # marketplace manifest — required
+└── plugins/
+    ├── plugin-a/
+    │   ├── .crouter-plugin/plugin.json
+    │   └── skills/...
+    └── plugin-b/
+        └── ...
+```
+
+Each entry under `plugins/` is a complete plugin (see [[crouter-development/plugins]]). The marketplace adds an index on top.
+
+## The manifest
+
+`.crouter-marketplace/marketplace.json`:
+
+```json
+{
+  "name": "my-marketplace",
+  "version": "0.3.0",
+  "owner": { "name": "Your Name", "email": "you@example.com" },
+  "plugins": [
+    {
+      "name": "plugin-a",
+      "version": "0.2.1",
+      "source": "https://github.com/<owner>/<repo>",
+      "description": "One sentence."
+    },
+    { "name": "plugin-b", "version": "0.1.0", "source": "…", "description": "…" }
+  ]
+}
+```
+
+| Field | Required | Notes |
+|---|---|---|
+| `name` | yes | Lowercase kebab. |
+| `version` | yes | Semver. Bumps when any plugin bumps or when the marketplace manifest itself changes. |
+| `owner` | optional | |
+| `plugins` | yes | Array. Each entry: `name`, `version`, `source`, `description`. |
+
+The `plugins[]` array IS the index — what's installable. A plugin on disk but not in the index won't resolve. A plugin in the index but missing from disk errors on install.
+
+## Install mechanics — symlinks, not clones
+
+When a user runs `crtr marketplace install my-marketplace:plugin-a`:
+1. Crouter looks up `plugin-a` in the marketplace's manifest.
+2. **Symlinks** `<marketplace-clone>/plugins/plugin-a/` → `<user-scope>/plugins/plugin-a/`.
+3. Records the install in the scope config with `source_marketplace: my-marketplace`.
+
+Therefore one `crtr marketplace update my-marketplace` (which does `git pull` in the marketplace clone) updates every installed plugin from it — no per-plugin re-install, no second clone.
+
+## Version-bump automation (recommended)
+
+Bumping N plugin manifests + the index by hand is error-prone. The canonical pattern is a GitHub Actions workflow that bumps versions from commit subjects (conventional commits):
+
+| Commit subject | Bump |
+|---|---|
+| `feat!: …` or `BREAKING CHANGE` in body | major |
+| `feat: …` | minor |
+| anything else (`fix:`, `chore:`, `docs:`, …) | patch |
+
+Per commit:
+- For each plugin folder touched, both `plugins/<name>/.crouter-plugin/plugin.json` and the matching entry in `marketplace.json` get bumped.
+- Top-level `marketplace.json` version bumps when any plugin bumps OR the manifest itself was edited directly.
+- Newly-added plugins are skipped — they keep the version you committed.
+- Commits whose subject starts with `chore: release` are skipped to avoid loops.
+
+If you adopt this: **never edit `version` fields by hand**. CI will overwrite. Document this in the marketplace's CLAUDE.md.
+
+The crouter-official-marketplace repo's `.github/workflows/auto-bump.yml` is the reference implementation. Copy it.
+
+## Adding a plugin to a marketplace
+
+```bash
+cd <marketplace-repo>
+
+# Create the plugin (see [[crouter-development/plugins]] for plugin layout)
+mkdir -p plugins/my-new-plugin/.crouter-plugin plugins/my-new-plugin/skills
+$EDITOR plugins/my-new-plugin/.crouter-plugin/plugin.json
+
+# Add at least one skill
+crtr skill new my-new-plugin:first-skill --type playbook --description "Use when …"
+
+# Add the plugin to the marketplace index
+$EDITOR .crouter-marketplace/marketplace.json
+# (append to plugins[] with name, initial version, source, description)
+
+# Validate
+crtr doctor
+
+# Commit — CI bumps versions if you've wired up auto-bump
+git add -A
+git commit -m "feat: add my-new-plugin"
+git push
+```
+
+Existing users pick it up on their next `crtr marketplace update <marketplace-name>` (or on the next auto-update tick if they've set `auto_update.content: "apply"`).
+
+## Updating an existing plugin
+
+Edit content under `plugins/<name>/`. Commit with a conventional-commit subject. CI bumps the plugin manifest and the marketplace index entry together. No manual sync.
+
+## Removing a plugin
+
+Delete the plugin's directory AND its entry in `marketplace.json` → `plugins[]`. Commit with `feat!: remove <plugin>` to signal a major bump (the marketplace's contract changed for anyone depending on that plugin).
+
+## Marketplace registration scopes
+
+A marketplace itself registers per-scope:
+
+| Scope | Path | Use case |
+|---|---|---|
+| user | `~/.crouter/marketplaces/<name>/` | Private to your machine — your personal subscriptions |
+| project | `<project>/.crouter/marketplaces/<name>/` | Checked into the repo — anyone cloning gets the same marketplace pinned |
+
+`crtr marketplace add <git-url> --scope user` is the default. Use `--scope project` when the marketplace is integral to how the repo expects to be developed.
+
+## Validation
+
+`crtr doctor` checks marketplaces:
+- `marketplace.json` is valid JSON.
+- Every entry in `plugins[]` corresponds to a real directory under `plugins/`.
+- Each plugin under `plugins/` passes plugin-level validation.
+
+A plugin on disk but missing from the manifest is a **warning** (probably forgotten); a plugin in the manifest but missing on disk is an **error** (install would break).
+
+## Cross-publishing with Claude Code
+
+Some marketplaces ship a parallel `.claude-plugin/` tree so plugins can load directly into Claude Code without crtr. Optional. Sync the two manifests if you adopt it.

package/dist/builtin-skills/skills/crouter-development/plugins/SKILL.md

@@ -0,0 +1,156 @@
+---
+name: crouter-development/plugins
+type: playbook
+description: How to author a crtr plugin — plugin.json manifest, directory layout, scopes, install mechanics, versioning. Use when creating a new plugin, packaging skills for distribution, or debugging install/resolution.
+keywords: [plugin, plugin.json, manifest, install, scope]
+---
+
+# Authoring crtr plugins
+
+A **plugin** is a directory shipping skills (and, in future, other artifact types like commands and hooks). Plugins are how you package skills for sharing across machines, projects, and people.
+
+Audience: LLM agents creating or maintaining a crtr plugin.
+
+## When you need a plugin (vs scope-owned skills)
+
+Scope-owned skills live at `~/.crouter/skills/` (user) or `<project>/.crouter/skills/` (project). They're personal and per-machine/per-repo.
+
+Reach for a **plugin** when:
+- You want to share skills across multiple projects or with other people.
+- You want versioning + update mechanics (`crtr plugin update`).
+- You want a marketplace to index the work — see [[crouter-development/marketplaces]].
+
+If it's a one-off note for yourself, scope-owned skills are simpler. Promote to a plugin later.
+
+## Directory layout
+
+```
+<plugin-name>/
+├── .crouter-plugin/
+│   └── plugin.json                  # manifest — required
+└── skills/
+    └── <skill-name>/
+        └── SKILL.md
+```
+
+The `<plugin-name>` directory IS the plugin. The manifest's `name` field must match the directory name (install renames if needed). Future artifact types (`commands/`, `hooks/`, etc.) will be sibling dirs to `skills/`.
+
+## The manifest
+
+`.crouter-plugin/plugin.json`:
+
+```json
+{
+  "name": "my-plugin",
+  "version": "0.1.0",
+  "description": "One sentence — shown in `crtr plugin list`.",
+  "source": "https://github.com/<owner>/<repo>",
+  "owner": {
+    "name": "Your Name",
+    "email": "you@example.com"
+  }
+}
+```
+
+| Field | Required | Notes |
+|---|---|---|
+| `name` | yes | Must match the directory name. Lowercase kebab. |
+| `version` | yes | Semver. Marketplace CI may bump automatically — see marketplaces skill. |
+| `description` | yes | One sentence. |
+| `source` | recommended | Git URL where the plugin lives. Used by `crtr plugin update`. |
+| `owner` | optional | Author info. |
+
+## Scopes
+
+A plugin can live in either scope:
+
+| Scope | Path | Use case |
+|---|---|---|
+| user | `~/.crouter/plugins/<name>/` | Personal, available in all your projects |
+| project | `<project>/.crouter/plugins/<name>/` | Pinned to a specific repo — checked in or vendored |
+
+Project-scope plugins outrank user-scope on resolution. Both outrank marketplace-installed plugins. The builtin `crtr` plugin (ships with the CLI) sits at the bottom.
+
+## Install mechanics
+
+Three ways a plugin lands in a scope:
+
+1. **From a git URL** (`crtr plugin install <url> --scope user`):
+   - Clones into `<scope>/plugins/<name>/` using the manifest's name.
+   - `crtr plugin update <name>` does `git pull`.
+   - Independent of any marketplace.
+
+2. **From a marketplace** (`crtr marketplace install <mkt>:<name> --scope user`):
+   - **Symlinks** the marketplace's `plugins/<name>/` into `<scope>/plugins/<name>/`.
+   - One `crtr marketplace update <mkt>` pulls updates for every installed plugin from that marketplace.
+   - See [[crouter-development/marketplaces]].
+
+3. **Authored in place** (you're writing the plugin in a working repo):
+   - Symlink for tight dev loop: `ln -s $(pwd) ~/.crouter/plugins/<name>`.
+   - Or `crtr plugin install file://$(pwd) --scope project` to clone-install.
+
+## Local development loop
+
+```bash
+# Scaffold dir + manifest + first skill
+mkdir -p my-plugin/.crouter-plugin my-plugin/skills
+$EDITOR my-plugin/.crouter-plugin/plugin.json      # write the manifest
+cd my-plugin
+crtr skill new my-plugin:my-first-skill --type playbook --description "Use when …"
+
+# Symlink for fast iteration — no clone, edits land immediately
+ln -s $(pwd) ~/.crouter/plugins/my-plugin
+
+# Verify
+crtr plugin list                      # my-plugin appears
+crtr plugin show my-plugin            # lists its skills
+crtr skill list --plugin my-plugin
+crtr doctor                           # validates manifest + every skill
+```
+
+When ready to share: push to a git remote; anyone can `crtr plugin install <url>`.
+
+## Versioning
+
+Standard semver:
+
+| Change | Bump |
+|---|---|
+| Typo, wording polish | patch (0.1.0 → 0.1.1) |
+| New skill, new section, new example | minor (0.1.0 → 0.2.0) |
+| Removed skill, renamed skill, changed manifest schema | major (0.1.0 → 1.0.0) |
+
+`crtr plugin update <name>` reads the new version after pulling and updates the local config. Plugins published through a marketplace may have their `version` field bumped automatically by CI — see [[crouter-development/marketplaces]].
+
+## Enable/disable
+
+`crtr plugin disable <name>` flips the per-scope config without removing files. Disabled plugins are hidden from `crtr skill list` and don't resolve via `crtr skill show <name>`. Re-enable with `crtr plugin enable <name>`.
+
+Individual skills inside an enabled plugin can also be disabled: `crtr skill disable <plugin>:<skill>`.
+
+## What goes in a plugin
+
+Good plugin scope:
+- A coherent set of related skills (3–15 typical) sharing a theme.
+- All skills serve the same user persona or workflow.
+- Versioned together — a bump means a bump for the whole set.
+
+Bad plugin scope:
+- One mega-plugin with every skill you've ever written. Hard to install selectively, hard to version.
+- A plugin per single skill. No value-add over scope-owned skills.
+
+## Cross-plugin etiquette
+
+If your skill conceptually depends on another plugin's skill, link via `## Related` with `` `<plugin>/<skill>` `` (e.g., `crtr/crouter-development/skills` for the builtin format guide). Don't fork content; link it.
+
+## Validation
+
+`crtr doctor` checks every plugin:
+- Manifest exists and is valid JSON.
+- Manifest `name` matches the directory name.
+- Every skill under `skills/` passes the skill-validation contract (see [[crouter-development/skills]]).
+- Sibling artifact dirs (`commands/`, `hooks/`, etc.) — validated by their respective specs as those land.
+
+## Cross-publishing with Claude Code
+
+Some plugins also publish a `.claude-plugin/` manifest alongside `.crouter-plugin/` so they can be loaded directly into Claude Code without going through crtr. Optional. Only worth doing when your skills/commands meaningfully stand alone in the Claude Code surface. Keep manifests in sync if you do.

package/dist/builtin-skills/skills/crouter-development/skills/SKILL.md

@@ -0,0 +1,166 @@
+---
+name: crouter-development/skills
+type: playbook
+description: How to author a crtr skill — SKILL.md format, frontmatter, naming, nested skills, template types. Use when creating a new skill (plugin-owned or scope-owned) or auditing an existing one.
+keywords: [skill, SKILL.md, frontmatter, authoring, template]
+---
+
+# Authoring crtr skills
+
+A **skill** is a directory; `SKILL.md` is its entry file — the same role `index.html` plays for a web dir. The dir IS the skill: siblings (`reference.md`, scripts, examples) ride along, nested subdirs are themselves skills.
+
+Audience: LLM agents loading this to create or audit a skill. Decision-first.
+
+## Minimum viable skill
+
+**Plugin-owned:**
+```
+<plugin-root>/skills/<name>/SKILL.md
+```
+
+**Scope-owned** (no plugin, just your project or user scope):
+```
+~/.crouter/skills/<name>/SKILL.md              # user scope
+<project>/.crouter/skills/<name>/SKILL.md      # project scope
+```
+
+```markdown
+---
+name: <name>
+type: <type>
+description: <one sentence — used by the agent to decide whether to load this>
+keywords: [optional, list]
+---
+
+# Title
+
+Body in markdown. This is what `crtr skill show <name>` prints.
+```
+
+Drop the directory in place; `crtr skill list` picks it up. No build, no registry.
+
+## Template types
+
+Pick the type matching what the agent *does* after reading.
+
+| Type | Agent action | Source of truth | Example |
+|---|---|---|---|
+| `playbook` | Decides — applies judgment ("when X, do Y because Z") | The skill itself | this skill, cli-design |
+| `primer` | Navigates — learns architectural facts about a codebase | Code in repo | crtr-internals |
+| `reference` | Looks up — stable external facts | Docs/specs/protocols | semver-rules |
+| `runbook` | Executes — numbered procedure with rollback | The skill (steps fixed) | deploy-plugin |
+| `freeform` | None of the above | Varies | catch-all |
+
+### Picking the type
+
+- Agent needs to make a *judgment call*? → `playbook`. Lead with rules; show examples; state the *why* so edge cases resolve themselves.
+- Agent needs to *navigate code* that drifts over time? → `primer`. Point at `file:line`. Don't transcribe code; explain the *shape*.
+- Agent needs *stable facts* (semver, HTTP codes, protocol fields)? → `reference`. Tables, terse, no methodology.
+- Agent needs to *run a procedure* with known steps and failure modes? → `runbook`. Numbered. Include rollback per step.
+- None of the above → `freeform`. Try harder first — the other four catch ~95% of cases.
+
+### Anti-patterns by type
+
+- `playbook` that's mostly code listings → split code to siblings; keep judgment in SKILL.md.
+- `primer` that duplicates code it points to → just point; don't transcribe.
+- `reference` that contains methodology → split methodology into a `playbook` sibling.
+- `runbook` with no decision points → it's a script; ship a script.
+
+## The `name` rule
+
+`name:` MUST equal the skill's path under `skills/`. For `skills/cli-design/SKILL.md`, `name: cli-design`. For `skills/web/frontend/design-website/SKILL.md`, `name: web/frontend/design-website` — slashes and all.
+
+`crtr skill new <plugin>:<name>` (or `crtr skill new <name>` for scope-owned) scaffolds this correctly. `crtr doctor` flags drift.
+
+## Nested skills
+
+Nesting is directory nesting. No `parent:` field, no registry. The path IS the hierarchy.
+
+```
+skills/
+├── prompting-effectively/SKILL.md         # flat
+├── cli-design/                            # flat with sibling assets
+│   ├── SKILL.md
+│   └── reference.md
+└── web/
+    └── frontend/
+        └── design-website/SKILL.md        # name: web/frontend/design-website
+```
+
+Resolve nested with `crtr skill show web/frontend/design-website`.
+
+Intermediate dirs (`web/`, `web/frontend/`) can be purely organizational — no SKILL.md required at each level. Add one only if you want a primer for the whole nest.
+
+## Assets and references
+
+Anything sibling to `SKILL.md` is part of the skill. The `cli-design` shape — `SKILL.md` for prose, `reference.md` for tables you don't want inline — is canonical. Scripts, example configs, screenshots all live as siblings. Reference from `SKILL.md` with relative paths.
+
+Don't use a top-level `assets/` dir; the dir IS the skill, and grouping per skill keeps moves atomic.
+
+## Frontmatter fields
+
+| Field | Required | Notes |
+|---|---|---|
+| `name` | yes | Must equal path under `skills/`. Slashes for nested. |
+| `type` | yes | One of: `playbook` `primer` `reference` `runbook` `freeform`. |
+| `description` | yes | One sentence. Front-load the trigger ("Use when…"). The agent decides whether to load based on this. |
+| `keywords` | no | Array of strings. Improves `crtr skill grep` and search. |
+
+Descriptions: active and specific. "Guide to X" is weak; "Use when doing X — covers Y and Z" is strong.
+
+## The authoring loop
+
+```bash
+# 1. Scaffold — plugin-owned or scope-owned
+crtr skill new <plugin>:my-skill --type playbook --description "Use when …"
+crtr skill new my-skill --type playbook --description "Use when …"  # scope-owned
+
+# 2. Find and edit
+crtr skill path <plugin>:my-skill                # absolute path
+$EDITOR $(crtr skill path <plugin>:my-skill)
+
+# 3. Validate
+crtr doctor
+
+# 4. Preview as the agent sees it (includes auto-appended neighbors)
+crtr skill show my-skill
+```
+
+## Cross-skill links
+
+- Sibling and nested skills in the same plugin/scope auto-append in a `<neighbors>` XML block inside the `<skill>` wrapper. Don't hand-roll these.
+- `## Related` in the body is for **cross-plugin or distant** references only — not siblings.
+- Cross-plugin refs: `` `<plugin>/<name>` ``. Scope-direct: `` `<scope>:<name>` ``.
+- Suppress neighbors: `crtr skill show <name> --no-neighbors`.
+
+If `## Related` would only list siblings, delete the section.
+
+## What goes in the body
+
+Skills are reference + methodology for an agent. Good skills:
+- Lead with trigger conditions and a one-paragraph summary so the agent can decide whether to read further.
+- Use greppable headings (`## When to use`, `## Common pitfalls`).
+- Show concrete invocations — code blocks beat prose.
+- Link sibling assets: `see [reference.md](./reference.md)`.
+
+Bad skills:
+- Tell the agent what it already knows ("markdown uses `#` for headings").
+- Bury triggers under five paragraphs of motivation.
+- Pile related-but-distinct topics into one skill — split into nested sub-skills.
+
+Budget ~150 lines for `SKILL.md` bodies. If a section exceeds 20 lines without teaching judgment, move it to a sibling file.
+
+## Validation
+
+`crtr doctor` checks every skill:
+- Frontmatter parses as YAML.
+- `name` matches the directory path.
+- `SKILL.md` exists and is non-empty.
+- Referenced sibling files exist (best-effort from markdown links).
+- `type` is present and in the enum (fails if not).
+
+A skill failing doctor still loads — doctor is advisory — but `crtr skill list --json` flags it.
+
+## Collisions
+
+Skill names need only be unique *within a plugin*. Two plugins shipping the same name collide; resolution order (project plugin → user plugin → project marketplace → user marketplace → builtin) picks one, and `crtr` exits `4` for ambiguous lookups when explicitness is required. Disambiguate with `<plugin>:<skill>`: `crtr skill show crtr:crouter-development/skills`.

package/dist/commands/doctor.js

@@ -1,10 +1,12 @@
 import { join } from 'node:path';
+import { SKILL_TYPES, isSkillType } from '../types.js';
 import { out, jsonOut, handleError, stdoutColor } from '../core/output.js';
-import { scopeRoot, pluginsDir, marketplacesDir, listScopes } from '../core/scope.js';
+import { scopeRoot, pluginsDir, marketplacesDir, listScopes, builtinSkillsRoot } from '../core/scope.js';
 import { readConfig, updateConfig } from '../core/config.js';
 import { listInstalledPlugins, listSkillsInPlugin } from '../core/resolver.js';
-import { pathExists, listDirs, removePath } from '../core/fs-utils.js';
+import { pathExists, listDirs, removePath, readText } from '../core/fs-utils.js';
 import { readPluginManifest, readMarketplaceManifest } from '../core/manifest.js';
+import { parseFrontmatter } from '../core/frontmatter.js';
 import { lsRemote } from '../core/git.js';
 import { ExitCode } from '../types.js';
 function pass(scope, name, message) {
@@ -16,7 +18,46 @@ function fail(scope, name, message) {
 function warn(scope, name, message) {
     return { scope, name, status: 'warn', message };
 }
+function readRawTypeField(skillPath) {
+    const content = readText(skillPath);
+    const { raw } = parseFrontmatter(content);
+    if (!raw)
+        return undefined;
+    const m = raw.match(/^type:\s*(.+?)\s*$/m);
+    if (!m)
+        return undefined;
+    let v = m[1].trim();
+    if ((v.startsWith('"') && v.endsWith('"')) || (v.startsWith("'") && v.endsWith("'"))) {
+        v = v.slice(1, -1);
+    }
+    return v;
+}
+function runChecksForBuiltin() {
+    const root = builtinSkillsRoot();
+    const plugins = listInstalledPlugins('builtin');
+    if (plugins.length === 0) {
+        return [fail('builtin', 'builtin:crtr:root', `builtin-skills root missing or has no valid plugin.json: ${root}`)];
+    }
+    const results = [
+        pass('builtin', 'builtin:crtr:root', `builtin-skills root present: ${root}`),
+    ];
+    for (const plugin of plugins) {
+        results.push(pass('builtin', `builtin:${plugin.name}:manifest`, `manifest valid`));
+        const skills = listSkillsInPlugin(plugin);
+        for (const skill of skills) {
+            if (!skill.frontmatter.name) {
+                results.push(fail('builtin', `builtin:${plugin.name}:skill:${skill.name}:frontmatter`, `frontmatter missing or name field empty`));
+            }
+            else {
+                results.push(pass('builtin', `builtin:${plugin.name}:skill:${skill.name}:frontmatter`, `frontmatter valid`));
+            }
+        }
+    }
+    return results;
+}
 function runChecksForScope(scope, opts) {
+    if (scope === 'builtin')
+        return runChecksForBuiltin();
     const results = [];
     const root = scopeRoot(scope);
     if (!root)
@@ -138,6 +179,17 @@ function runChecksForScope(scope, opts) {
                     else {
                         results.push(pass(scope, `plugin:${name}:skill:${skill.name}:frontmatter`, `frontmatter valid`));
                     }
+                    const typeCheckName = `plugin:${name}:skill:${skill.name}:type`;
+                    const rawType = readRawTypeField(skill.path);
+                    if (rawType === undefined) {
+                        results.push(warn(scope, typeCheckName, `missing type field — add one of: ${SKILL_TYPES.join(' | ')}`));
+                    }
+                    else if (!isSkillType(rawType)) {
+                        results.push(fail(scope, typeCheckName, `invalid type "${rawType}" — valid: ${SKILL_TYPES.join(' | ')}`));
+                    }
+                    else {
+                        results.push(pass(scope, typeCheckName, `type: ${rawType}`));
+                    }
                 }
             }
             // Git remote check (slow, opt-in)

package/dist/commands/plugin.js

@@ -178,10 +178,13 @@ export function registerPluginCommands(program) {
         .option('--yes', 'skip confirmation in non-TTY mode')
         .action(async (name, opts) => {
         try {
+            if (name === 'crtr') {
+                throw usage(`cannot uninstall builtin plugin "crtr" — it ships with the binary`);
+            }
             if (!isTTY() && !opts.yes) {
                 throw usage(`uninstall requires --yes in non-TTY mode: crtr plugin uninstall ${name} --yes`);
             }
-            const scopes = listScopes(opts.scope);
+            const scopes = listScopes(opts.scope).filter((s) => s !== 'builtin');
             let removed = false;
             for (const scope of scopes) {
                 const pDir = pluginsDir(scope);