fix: update vendored skills to latest versions - #278
Merged
Merged
Conversation
pleaseai-release-bot
Bot
added
the
dependencies
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
PR author is in the excluded authors list. |
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 40 |
| Duplication | 2 |
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
|
🔍 Tessl Skill Review
|
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | The bulk is dense, earn-their-place command and flag reference tables, but a few explanatory asides (e.g., 'Cold starts - First request after idle may be slightly slower', 'Preview deployments create a unique URL') restate concepts Claude already knows and could be trimmed. |
| actionability | █████ 5/5 | Copy-paste-ready commands, complete flag tables, and concrete code examples cover the common deploy, env, database, and tunnel cases fully. |
| workflow clarity | █████ 5/5 | The deployment workflow is explicitly sequenced (Steps 1-4) with pre-flight validation (version check, config grep) and a clear feedback loop for startup-dependency failures (create --no-wait, provision DB, redeploy). |
| progressive disclosure | ████░ 4/5 | Clear overview with well-signaled one-level-deep references to eight real files in references/, but some detail (full env-var and database CLI tables) is inlined in SKILL.md where it could live in the existing reference files. |
Suggestions:
- Move the full 'Managing Variables via CLI' command list and 'Provisioning' detail into references/DATABASES.md or a new ENV_VARS.md, keeping only a quick example in SKILL.md to reduce inlined bulk.
- Trim widely-known asides such as the cold-start and preview-URL explanations; assume Claude's competence per the conciseness rubric.
- Add an explicit post-deploy verification step (e.g., 'deno deploy logs' or curling the production URL) to the Step 4 workflow.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete capabilities — 'deployment workflows, environment variables, KV database access, custom domains, the --tunnel flag for local development, and the deno deploy command reference' — giving comprehensive coverage rather than vague abstraction. |
| completeness | █████ 5/5 | Explicitly answers both what (the 'Covers ...' capability list) and when ('Use when deploying Deno apps to production, asking about Deno Deploy, or working with deno deploy CLI commands') with concrete trigger phrases. |
| trigger term quality | ████░ 4/5 | Strong natural terms ('deploying Deno apps to production', 'Deno Deploy', 'deno deploy CLI commands') that users would actually say, though a few synonymous phrasings are absent. |
| distinctiveness conflict risk | █████ 5/5 | The 'Deno Deploy' / 'deno deploy' niche is specific with distinct triggers, making conflict with unrelated deployment skills unlikely. |
plugins/deno/agent/skills/deno-frontend/SKILL.md
An efficient, highly actionable body that stays lean while providing executable commands and a clear two-path decision structure, with detail correctly deferred to real reference files. The only minor gap is the absence of explicit verification checkpoints, though none are required for these non-destructive workflows.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | █████ 5/5 | Lean throughout ('Two paths. Pick by what the project already uses.') and assumes Claude's competence — it maps deno commands to npm equivalents in one line rather than explaining what the frameworks are, with every token earning its place. |
| actionability | █████ 5/5 | Fully executable, copy-paste-ready guidance: deno create vite my-app, deno install, deno task dev, deno run -Ar jsr:@fresh/init, plus a complete Counter island example and three concrete rules. |
| workflow clarity | ████░ 4/5 | A clear decision-tree ('Pick by what the project already uses') with sequenced init commands for each path, but there are no explicit validation checkpoints; this is acceptable since the workflows involve no destructive or batch operations that would require them. |
| progressive disclosure | █████ 5/5 | Well-organized overview with one-level-deep, clearly signaled references to the real bundle files references/FRESH.md and references/FRESH_MIGRATION.md, keeping the body an effective index into deeper material. |
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | ████░ 4/5 | Lists several concrete topics it covers ('Fresh 2.x routes, handlers, islands, Preact signals, Tailwind, and Fresh 1.x to 2.x migration') alongside specific frameworks, but uses 'Covers…' framing of topics rather than discrete performable actions, so it sits just below the comprehensive-actions anchor. |
| completeness | █████ 5/5 | Explicitly answers both: 'Use when building a web frontend with Deno — running React, Vite…' (when) and 'Covers which path to pick, Fresh 2.x routes, handlers, islands…' (what), with concrete trigger phrases. |
| trigger term quality | █████ 5/5 | Comprehensive natural terms users would actually say — 'building a web frontend with Deno', plus React, Vite, Astro, SvelteKit, Next.js, Nuxt, and Fresh — giving broad keyword coverage with framework-name synonyms. |
| distinctiveness conflict risk | █████ 5/5 | Clearly scoped to Deno-hosted frontends and Fresh specifically, a distinct niche with triggers unlikely to fire for non-Deno or non-frontend skills. |
plugins/deno/agent/skills/deno-sandbox/SKILL.md
A well-structured, highly actionable reference for the Deno Sandbox SDK with strong code coverage and validation guidance for risky untrusted-code execution. The main weakness is conciseness: the disposal message is repeated and a few sections feel padded.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ███░░ 3/5 | Mostly efficient code-heavy content, but the await using disposal point is repeated across the Lifecycle CRITICAL note, Quick Reference, and Common Mistakes, and the "Security Features"/"What's Included" lists read as marketing padding; it could be tightened, matching the anchor-3 'mostly efficient but some unnecessary explanation'. |
| actionability | ████░ 4/5 | Concrete, copy-paste-style examples cover create/spawn/streaming/kill plus three full patterns and a Quick Reference table; minor gaps such as the questionable --allow-none flag and deno deploy --prod command keep it just below fully executable at 5. |
| workflow clarity | ████░ 4/5 | Although organized as a pattern reference rather than a numbered sequence, the risky untrusted-code workflows include explicit validation (exit-code checks, output validation, timeouts, permission restriction) and the Common Mistakes section supplies feedback-loop-style correction, satisfying most checkpoints with only minor sequencing gaps. |
| progressive disclosure | ████░ 4/5 | Clear section structure (Overview, Scope Boundaries, Core Concepts, Common Patterns, API Reference) with one-level-deep pointers to external depth via deno doc jsr:@deno/sandbox and the deno.com URL; no bundle files exist, and the inline pattern examples could arguably live in separate files, so it is not a 5. |
Suggestions:
- Consolidate the
await usingdisposal guidance into a single authoritative statement; the point is currently made in the Lifecycle CRITICAL note, the Quick Reference table, and the Common Mistakes section. - Trim the "What's Included" and "Security Features" bullet lists, which restate general sandboxing concepts Claude already knows, down to only Deno-specific specifics.
- Verify executable accuracy of the flagged commands —
--allow-noneis not a standard Deno permission flag and the deploy command is typicallydeployctl deploy; correct or justify these to lift actionability toward 5.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | ███░░ 3/5 | Names the domain and a few concrete scenarios ("execute untrusted user code", "AI-generated code", "isolated code execution environments") but frames them as use cases rather than listing multiple distinct concrete actions, so it sits at the anchor-3 level rather than the comprehensive action list of 4-5. |
| completeness | ████░ 4/5 | Both halves are present: an explicit "Use when building features that execute untrusted user code..." trigger and a "what" via the capability framing plus "Covers the @deno/sandbox SDK"; the "what" is slightly implicit rather than crisply stated, so it is not a 5. |
| trigger term quality | ████░ 4/5 | Natural terms like "untrusted user code", "AI-generated code", "isolated code execution", and "sandbox" give good keyword coverage; a few common synonyms users might say (e.g. "code playground", "multi-tenant") are missing, keeping it just below comprehensive. |
| distinctiveness conflict risk | ████░ 4/5 | The explicit "@deno/sandbox SDK" anchor carves a clear niche with minimal conflict risk, but the broad "isolated code execution environments" trigger could still overlap with Docker/VM isolation skills, placing it just below a 5. |
plugins/deno/agent/skills/deno/SKILL.md
A high-quality reference skill: executable commands, terse non-obvious guidance, and a clean structure that offloads the full CLI detail to a single well-signaled reference file. The only minor gap is the absence of explicit validation checkpoints in its few multi-step flows.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | █████ 5/5 | Lean and dense: commands in code blocks, flag tables, and terse prose that adds only non-obvious information (e.g. the --min-dep-age supply-chain window, lifecycle scripts not running by default). No padding explaining what Deno or a package manager is. |
| actionability | █████ 5/5 | Fully executable command blocks for dependency management, permissions, tooling, running, scaffolding, and publishing, plus a concrete flag table and copy-paste config JSON — covers the common cases directly. |
| workflow clarity | ████░ 4/5 | Mostly reference material with clear section sequencing and a concrete 'Reviewing Deno code' checklist, but the multi-step processes (e.g. CI install, publishing) lack explicit validation checkpoints, so it sits just below 5. |
| progressive disclosure | █████ 5/5 | Clear overview body with a well-signaled one-level-deep reference to references/CLI.md (verified present), plus pointers to the migrate-to-deno skill and docs.deno.com; content is appropriately split and easy to navigate. |
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists many concrete actions (writing, running, configuring, reviewing, debugging, scaffolding) and enumerates specific coverage areas (deno install/add, permissions, fmt/lint/test/check/bench/compile, publishing), giving comprehensive concrete coverage. |
| completeness | █████ 5/5 | Explicitly answers both 'what' (dependency management, permissions, config placement, workspaces, toolchain, publishing) and 'when' ('Use when writing, running, configuring, reviewing, or debugging code in a Deno project, or when scaffolding a new one'). |
| trigger term quality | ████░ 4/5 | Strong natural trigger verbs ('writing, running, configuring, reviewing, or debugging code', 'scaffolding') plus 'Deno project', but lacks synonyms or file-extension cues (.ts, deno.json) that would push it to 5. |
| distinctiveness conflict risk | █████ 5/5 | Scoped clearly to a 'Deno project' with Deno-specific triggers (deno install, JSR, deno.json), giving it a clear niche with minimal overlap risk against generic coding skills. |
plugins/deno/agent/skills/migrate-to-deno/SKILL.md
A tight, highly actionable migration guide structured as reversible rungs with a command-equivalents table and per-tool reference files. Its only weakness is that validation checkpoints are implicit rather than explicit feedback loops.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | █████ 5/5 | Lean and directive throughout — it never explains what Deno or package managers are, and every line (the rungs, the breakage list, the equivalents table) earns its place. |
| actionability | █████ 5/5 | Fully executable, copy-paste-ready commands (deno install, deno run -A main.js, deno approve-scripts, deno install --allow-scripts=npm:better-sqlite3) plus a dense command-equivalents table covering the common cases. |
| workflow clarity | ████░ 4/5 | The 'Migrate in rungs' section is a clear, reversible sequence with back-out instructions and 'confirming the program works'/'once verified' checkpoints, but validation is implied rather than framed as explicit validate→fix→retry loops. |
| progressive disclosure | █████ 5/5 | Clear overview in SKILL.md with a 'Per-tool details' section pointing to one-level-deep reference files (FROM_NPM.md, FROM_YARN.md, FROM_PNPM.md, FROM_BUN.md, NODE_APIS.md), each described and verified to exist. |
Suggestions:
- Make the per-rung verification explicit: add a concrete 'verify' command (e.g.
deno run -A main.jspasses / tests green) as a named checkpoint before advancing to the next rung. - For Rung 3 (tighten permissions), add a validate→fix→retry loop: run with narrow perms, on denial read the requested scope, grant exactly it, re-run.
- Add a short validation step after lockfile migration (e.g.
deno task buildor test suite) before 'Commit deno.lock once verified' so the verify action is unambiguous.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions — 'drop-in package manager, running existing package.json scripts, CommonJS versus ESM, node_modules layout, lockfile migration, permissions' — giving comprehensive coverage rather than vague language. |
| completeness | █████ 5/5 | Explicitly answers both 'what' ('Covers using Deno as a drop-in package manager...') and 'when' ('Use when moving a Node.js... project to Deno, or when adopting Deno incrementally...') with concrete trigger phrases. |
| trigger term quality | █████ 5/5 | Names the natural terms users say — 'Node.js, npm, Yarn, pnpm, or Bun project to Deno' — covering all relevant package-manager synonyms and the target runtime. |
| distinctiveness conflict risk | █████ 5/5 | Occupies a clear niche — migrating Node-ecosystem projects to Deno — with distinct triggers and minimal overlap risk with unrelated skills. |
plugins/emulate/.agents/skills/apple/SKILL.md
A strong, actionable reference for the Apple emulator with copy-paste curl/code examples and a clear end-to-end flow. Minor gains available by tightening inline JSON blobs and optionally splitting the API reference into a referenced file.
Validation
⚠️ allowed_tools_field — 'allowed-tools' contains unusual tool name(s)
Full review details
Validation Checks
15/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | Mostly efficient reference material with no padding of concepts Claude already knows (no OAuth/PKCE/RS256 primers), but full inline JSON discovery blobs and repeated curl patterns could be trimmed slightly. Not a 5 because the complete OIDC discovery response and several full JSON examples consume tokens that a leaner reference would not. |
| actionability | █████ 5/5 | Fully executable, copy-paste-ready guidance throughout: concrete curl commands, TypeScript snippets for Auth.js and Passport, a YAML seed config, and a numbered full authorization-code flow covering the common integration cases. |
| workflow clarity | ████░ 4/5 | The 'Full Authorization Code Flow' is a clear numbered 4-step sequence, but it lacks explicit validation checkpoints or error-recovery feedback loops; no destructive/batch cap applies since revocation is a single low-stakes mock operation. |
| progressive disclosure | ████░ 4/5 | Well-organized with clear section headers (Start, Pointing Your App, Seed Config, API Endpoints, Common Patterns) and navigable structure, but the full API endpoint reference and seed-config detail live inline with no one-level-deep external references to split them out. |
Suggestions:
- Condense the full OIDC discovery JSON and token-response examples to the fields a caller actually needs, or move the complete API endpoint reference into a separate referenced file.
- Add a brief validation step to the Full Authorization Code Flow (e.g., 'verify the id_token signature against /auth/keys before trusting claims') to raise workflow clarity.
- Move the per-endpoint reference (OIDC discovery, JWKS, token, refresh, revoke) into a references/ file linked from a concise API overview section to improve progressive disclosure.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions — 'test Apple sign-in locally, emulate Apple OIDC discovery, handle Apple token exchange, configure Apple OAuth clients, or work with Apple userinfo' — giving comprehensive coverage of the skill's capabilities. |
| completeness | █████ 5/5 | Clearly answers both what ('Emulated Sign in with Apple / Apple OIDC for local development and testing' plus concrete actions) and when ('Use when the user needs to test Apple sign-in locally...' and 'any task requiring a local Apple OAuth/OIDC provider') with concrete trigger phrases. |
| trigger term quality | █████ 5/5 | Explicit 'Triggers include' list covers natural phrases a user would say — 'Apple OAuth', 'mock Apple login', 'test Apple sign-in', 'Sign in with Apple', 'Apple OIDC', 'local Apple auth' — with synonyms and variants. |
| distinctiveness conflict risk | █████ 5/5 | Apple-specific niche with distinct, branded triggers ('Sign in with Apple', 'Apple OIDC') makes overlap with other skills minimal; it would not fire for non-Apple OAuth tasks. |
plugins/emulate/.agents/skills/aws/SKILL.md
Highly actionable reference documentation with executable curl and SDK examples, but it is a monolithic inline reference that would benefit from per-service split files, and its destructive operations lack validation checkpoints.
Validation
⚠️ allowed_tools_field — 'allowed-tools' contains unusual tool name(s)
Full review details
Validation Checks
15/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | Lean, reference-style content with no over-explanation of concepts Claude already knows, but the ~380 lines repeat '-H "Authorization: Bearer $TOKEN"' in every curl example and could be tightened by factoring auth once. |
| actionability | █████ 5/5 | Fully executable, copy-paste-ready curl commands and AWS SDK v3 snippets covering S3, SQS, IAM, and STS common cases with concrete endpoints and parameters. |
| workflow clarity | ███░░ 3/5 | The 'Common Patterns' sections sequence steps, but destructive operations (DeleteBucket, DeleteObject, PurgeQueue, DeleteUser/DeleteRole) appear with no validation or verification checkpoints, capping workflow clarity at 3. |
| progressive disclosure | ███░░ 3/5 | Section headers per service provide some structure, but the entire 380-line API reference is inlined in SKILL.md with no bundle files or one-level-deep references to split per-service detail. |
Suggestions:
- Add validation/verification steps around destructive operations (e.g., confirm a bucket is empty before DeleteBucket, verify message receipt before DeleteMessage) to lift workflow clarity above the destructive-operation cap of 3.
- Move the per-service API endpoint reference (S3, SQS, IAM, STS curl blocks) into separate reference files linked from SKILL.md to improve progressive disclosure.
- Factor the repeated 'Authorization: Bearer $TOKEN' header out of individual curl examples (e.g., define $TOKEN and a shared header once) to reduce token redundancy.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Names the domain (S3, SQS, IAM, STS) and lists multiple concrete actions — 'test S3 bucket and object operations', 'emulate SQS queues and messages', 'manage IAM users/roles/access keys', 'test STS assume role' — with comprehensive coverage. |
| completeness | █████ 5/5 | Explicitly answers both what ('Emulated AWS cloud services ... for local development and testing') and when ('Use when the user needs to ...') with concrete trigger phrases. |
| trigger term quality | █████ 5/5 | Comprehensive natural trigger phrases including synonyms — 'AWS emulator', 'emulate AWS', 'mock S3', 'local SQS', 'test IAM', 'emulate S3', 'AWS locally', 'STS assume role' — that users would plausibly say. |
| distinctiveness conflict risk | █████ 5/5 | Clear niche (local AWS service emulation) with distinct, service-specific triggers and minimal overlap risk with other skills. |
plugins/emulate/.agents/skills/emulate/SKILL.md
A dense, reference-style skill body that is highly actionable and well-sectioned, with genuine safety validation around secrets handling. The main improvement would be extracting the large all-services seed-config block into a separate reference file to tighten the main body.
Validation
⚠️ skill_md_line_count — SKILL.md is long (544 lines); consider splitting into references/ and linking⚠️ allowed_tools_field — 'allowed-tools' contains unusual tool name(s)
Full review details
Validation Checks
14/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | Mostly lean — tables, commands, and code dominate with little concept over-explanation — but the ~270-line inline full seed-config example for all 13 services could be split into a reference file, a minor trim opportunity. |
| actionability | █████ 5/5 | Fully executable: 'npx emulate' quick start, copy-paste createEmulator TypeScript, Vitest setup, and a complete YAML config covering the common cases — concrete and ready to run. |
| workflow clarity | ████░ 4/5 | Setup sequences are clear and the generated-secrets flow carries explicit validation ('must not exist', 'verifies effective owner-only access', 'fails closed', startup failures remove the artifact); minor checkpoint gaps elsewhere keep it just below 5. |
| progressive disclosure | ████░ 4/5 | Well-organized with clear section headers and clearly signaled cross-skill references (next, nuxt, per-service skills); no bundle reference files exist and the full multi-service config is inlined, which is a minor organization gap rather than a structural problem. |
Suggestions:
- Move the full multi-service seed-config YAML (the ~270-line block under '### Config Structure') into a references/ file and keep only a small representative excerpt inline, linking out for the complete example.
- Add a short numbered 'getting started' workflow (install -> start -> point app env vars -> verify a request) so first-time users have an explicit checkpointed sequence.
- Add an explicit verification step after starting services (e.g., curl a health/token endpoint) so users can confirm the emulator is live before wiring their app.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions — 'start emulated services, configure seed data, write tests against local APIs, set up CI without network access, or work with the emulate CLI or programmatic API' — giving comprehensive coverage of capabilities. |
| completeness | █████ 5/5 | Explicitly answers both what ('Local drop-in API emulator for Vercel, GitHub, Google...') and when ('Use when the user needs to... Triggers include...') with concrete trigger phrases. |
| trigger term quality | █████ 5/5 | Comprehensive natural trigger phrases including synonyms — 'start the emulator', 'emulate services', 'mock API locally', 'create emulator config', 'test against local API', 'npx emulate' — covering terms a user would naturally say. |
| distinctiveness conflict risk | █████ 5/5 | Clear niche — local API emulation for a named set of developer APIs — with distinct triggers and minimal overlap risk with other skills. |
plugins/emulate/.agents/skills/github/SKILL.md
A highly actionable, well-sectioned API reference with extensive executable examples, but it is a monolithic inline document that would benefit from progressive disclosure into reference files, and its guided workflows lack validation checkpoints for destructive operations.
Validation
⚠️ skill_md_line_count — SKILL.md is long (636 lines); consider splitting into references/ and linking⚠️ allowed_tools_field — 'allowed-tools' contains unusual tool name(s)
Full review details
Validation Checks
14/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | Mostly lean, executable curl/TypeScript examples with minimal concept explanation, but the generated-secrets-file prose (lines 58-65) is dense and could be trimmed; a few explanatory passages could be tightened. |
| actionability | █████ 5/5 | Abundant copy-paste-ready curl commands and TypeScript snippets covering the common cases (auth, repos, issues, PRs, OAuth, app tokens) with concrete URLs, headers, and payloads. |
| workflow clarity | ███░░ 3/5 | Sequenced workflows exist (OAuth flow steps 1-5, App installation token flow 1-3), but no explicit validation checkpoints are present and destructive operations like 'Delete repo (cascades issues, PRs, etc.)' lack verification steps, capping this dimension at 3. |
| progressive disclosure | ███░░ 3/5 | Well-organized with clear section headers, but the entire ~580-line API reference is inlined in SKILL.md with no bundle files; content that arguably belongs in separate reference files is inline. |
Suggestions:
- Move the bulk of the per-endpoint API reference into a references/ file (e.g. ENDPOINTS.md) and keep SKILL.md as a concise overview pointing to it, improving progressive disclosure.
- Add explicit validation/verification steps to destructive workflows (e.g. confirm a repo exists and review cascade impact before DELETE), or a checklist for the OAuth and App token flows.
- Tighten the generated-secrets-file prose to the essential behavioral rules, trimming the lengthy ACL/startup-failure explanation where it duplicates concept knowledge.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions — 'interact with GitHub API endpoints locally, test GitHub integrations, emulate repos/issues/PRs, set up GitHub OAuth flows, configure GitHub Apps, test webhooks, or work with actions/checks' — giving comprehensive coverage rather than vague language. |
| completeness | █████ 5/5 | Explicitly answers both what ('Emulated GitHub REST API for local development and testing') and when ('Use when the user needs...') with concrete trigger phrases. |
| trigger term quality | █████ 5/5 | Provides natural trigger phrases users would say — 'GitHub API', 'emulate GitHub', 'mock GitHub', 'test GitHub OAuth', 'GitHub App JWT', 'local GitHub' — including synonyms (emulate/mock/local). |
| distinctiveness conflict risk | █████ 5/5 | Occupies a clear niche (local GitHub API emulation) with distinct, specific triggers that are unlikely to fire for unrelated skills. |
plugins/emulate/.agents/skills/google/SKILL.md
Highly actionable single-file API reference with strong section structure, but it is a monolithic ~600-line document with no bundle files or one-level-deep references, and its destructive/batch Gmail operations lack the validation checkpoints the rubric requires.
Validation
⚠️ skill_md_line_count — SKILL.md is long (609 lines); consider splitting into references/ and linking⚠️ allowed_tools_field — 'allowed-tools' contains unusual tool name(s)
Full review details
Validation Checks
14/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | Mostly efficient — curl/code blocks with brief comments and almost no explanation of concepts Claude already knows — but the 'Full Authorization Code Flow' and 'Send a Gmail Message and Check the Thread' sections re-token-exchange and userinfo curls already shown in the endpoint sections, minor repetition that could be trimmed. |
| actionability | █████ 5/5 | Fully executable, copy-paste-ready curl commands and TypeScript snippets cover the common cases across OAuth/OIDC, Gmail, Calendar, and Drive, with real seed-config examples and URL-mapping tables. |
| workflow clarity | ███░░ 3/5 | The 'Full Authorization Code Flow' is sequenced (1–4) but lacks validation/error-recovery checkpoints, and destructive/batch operations (trash, permanent delete, batchModify, batchDelete) appear without verification steps — the rubric caps workflow clarity at 3 for destructive/batch skills missing validation. |
| progressive disclosure | ███░░ 3/5 | Good in-file section structure (## Gmail API / Calendar / Drive with ### subsections) but the entire ~600-line API reference is inlined in SKILL.md with no references/ or external files; content that clearly belongs in separate reference files is not split out. |
Suggestions:
- Move the per-endpoint Gmail/Calendar/Drive reference into separate files under references/ (e.g. references/gmail-api.md) and keep SKILL.md as an overview with clearly signaled links, improving progressive disclosure.
- Add validation/verification steps (e.g. confirm a GET before permanent DELETE, verify batchModify results) to the destructive and batch Gmail operations so workflow clarity can exceed the cap of 3.
- De-duplicate the token-exchange and userinfo curls in 'Common Patterns' by referencing the earlier 'Token Exchange' / 'User Info' sections rather than restating them.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Names the domain and many concrete actions: 'test Google sign-in locally, emulate OIDC discovery, handle Google token exchange, configure Google OAuth clients, work with Gmail messages/drafts/threads/labels, manage Calendar events, upload or list Drive files' — comprehensive coverage across all five surfaces. |
| completeness | █████ 5/5 | Explicitly answers both: 'what' ('Emulated Google OAuth 2.0, OpenID Connect, Gmail, Calendar, and Drive for local development and testing') and 'when' ('Use when the user needs to...'), plus a dedicated 'Triggers include...' clause with concrete phrases. |
| trigger term quality | █████ 5/5 | Comprehensive natural trigger coverage with synonyms — 'Google OAuth', 'emulate Google', 'mock Google login', 'test Google sign-in', 'OIDC emulator', 'Google OIDC', 'Gmail API', 'Google Calendar', 'Google Drive', 'local Google auth' — terms a user would naturally say. |
| distinctiveness conflict risk | █████ 5/5 | Clear niche — local Google API emulation — with distinct Google-specific triggers; minimal conflict risk with other skills since the surface is narrow and explicitly scoped to Google auth/workspace. |
plugins/emulate/.agents/skills/microsoft/SKILL.md
A strong, highly actionable reference body with executable curl and library-integration examples for every endpoint. Its main weaknesses are redundancy between the API Endpoints and Common Patterns sections and the absence of explicit validation checkpoints in the documented flows.
Validation
⚠️ allowed_tools_field — 'allowed-tools' contains unusual tool name(s)
Full review details
Validation Checks
15/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | The body is mostly lean, executable reference content without explaining concepts Claude already knows, but the 'Common Patterns' section re-demonstrates the authorization code flow and PKCE flow already shown under 'API Endpoints', adding noticeable redundancy. |
| actionability | █████ 5/5 | Fully executable, copy-paste-ready guidance throughout: curl commands for every endpoint, complete code snippets for Auth.js, Passport.js, MSAL.js, and openid-client covering the common integration cases. |
| workflow clarity | ████░ 4/5 | The 'Full Authorization Code Flow' and 'PKCE Flow' provide clear numbered, executable sequences, but explicit validation checkpoints (e.g., verify the token exchange succeeded before calling userinfo) and error-recovery feedback loops are minimal. |
| progressive disclosure | ████░ 4/5 | No bundle files exist and all content is inline in one ~360-line SKILL.md, but it is well-organized into clear sections (Start, Pointing Your App, Seed Config, API Endpoints, Common Patterns) that keep it navigable; the library-integration examples and repeated patterns could arguably be split out. |
Suggestions:
- Consolidate the 'Common Patterns' section: the Full Authorization Code Flow and PKCE Flow duplicate the Token Exchange and PKCE examples already shown under API Endpoints — cross-reference instead of repeating, or keep only the end-to-end orchestration commentary.
- Add an explicit validation step in the Full Authorization Code Flow (e.g., 'Verify the token response contains an id_token before calling userinfo') and a brief error-recovery note for failed token exchanges.
- Consider moving the per-library integration snippets (Auth.js / Passport / MSAL / openid-client) into a references/ file linked from the body to reduce SKILL.md length and improve progressive disclosure.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions — 'test Microsoft sign-in locally, emulate Entra ID OIDC discovery, handle Microsoft token exchange, configure Azure AD OAuth clients, work with Microsoft Graph /me, or test PKCE/client credentials flows' — giving comprehensive coverage of the skill's capabilities. |
| completeness | █████ 5/5 | Explicitly answers both 'what' ('Emulated Microsoft Entra ID OAuth 2.0 / OpenID Connect for local development and testing') and 'when' via a concrete 'Use when the user needs to...' clause with enumerated trigger scenarios. |
| trigger term quality | █████ 5/5 | Provides comprehensive natural trigger terms including synonyms users would actually say: 'Microsoft OAuth', 'Entra ID', 'Azure AD', 'emulate Microsoft', 'mock Microsoft login', 'test Microsoft sign-in', 'Microsoft OIDC', 'local Microsoft auth'. |
| distinctiveness conflict risk | █████ 5/5 | Occupies a clear niche — local Microsoft OAuth/OIDC emulation — with distinct, vendor-specific triggers that minimize overlap with other skills. |
plugins/emulate/.agents/skills/next/SKILL.md
The body is an efficient, highly actionable integration guide with executable code throughout and a clear section structure. It assumes Claude's competence and avoids concept over-explanation; the main improvement would be tightening the prose-heavy persistence/how-it-works sections.
Validation
⚠️ allowed_tools_field — 'allowed-tools' contains unusual tool name(s)
Full review details
Validation Checks
15/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | Mostly lean: assumes competence, skips basic concept explanations, and leads with install + executable code. A few prose passages ('How Persistence Works', 'This is particularly useful for Vercel preview deployments...') could be trimmed further, keeping it just short of a 5. |
| actionability | █████ 5/5 | Copy-paste-ready code for the route handler, Auth.js config, withEmulate wrapper, and persistence adapters, plus typed config reference tables covering the common integration cases. |
| workflow clarity | ████░ 4/5 | Sections follow a logical install-then-configure sequence and 'How It Works' provides a numbered 5-step request flow. The task is configuration rather than destructive/batch work, so the validation cap does not apply, but explicit checkpoints are absent. |
| progressive disclosure | ████░ 4/5 | No bundle files exist, so all content is inline, but it is well organized into clearly headed sections (Install, Route Handler, Auth.js, Font Tracing, Persistence, How It Works, Limitations, Config Reference). At >50 lines it exceeds the simple-skill exception, and the Config Reference could arguably live in a separate file, so it sits at 4 rather than 5. |
Suggestions:
- Tighten the 'How Persistence Works' bullets and the Vercel-preview aside to reduce prose while keeping the behavioral detail.
- Consider extracting the Config Reference tables into a references/ file and linking to it from SKILL.md to improve progressive disclosure for this longer-than-50-line skill.
- Add an explicit verification step (e.g., a curl or browser check against /emulate/github/_emulate/installation-tokens) after the route-handler setup so the workflow has a concrete checkpoint.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists six concrete actions (embed emulators, set up same-origin OAuth, create catch-all route handler, configure Auth.js/NextAuth, add persistence, wrap next.config with withEmulate), giving comprehensive coverage of the adapter's surface. |
| completeness | █████ 5/5 | Explicitly states what the adapter does ('Next.js adapter for embedding emulators...') and when to use it ('Use when the user needs to embed emulators in Next.js...') with concrete trigger phrases. |
| trigger term quality | █████ 5/5 | An explicit 'Triggers include' list combines natural phrases ('Next.js emulator', 'embedded emulator', 'Vercel preview') with technical identifiers (adapter-next, createEmulateHandler, withEmulate), covering synonyms and variations. |
| distinctiveness conflict risk | █████ 5/5 | Occupies a clear niche (Next.js emulator embedding via @emulators/adapter-next) with distinct triggers and minimal overlap with other skills. |
plugins/emulate/.agents/skills/resend/SKILL.md
A highly actionable, executable reference for the Resend emulator with broad endpoint coverage and clean structure. Its weaknesses are repeated send/extract examples across sections and absent validation checkpoints for batch and destructive operations.
Validation
⚠️ allowed_tools_field — 'allowed-tools' contains unusual tool name(s)
Full review details
Validation Checks
15/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | Mostly efficient with no padding about what email/Resend is, but the send-email curl and the magic-link/extract-code sequence are repeated across the Auth, API Endpoints, Extracting Data, and Common Patterns sections, which could be consolidated. |
| actionability | █████ 5/5 | Copy-paste ready curl and TypeScript covering send, batch, retrieve, extract-code, idempotency, domains, keys, audiences, contacts, and the Next.js adapter — fully executable across the common cases. |
| workflow clarity | ███░░ 3/5 | The magic-link and send-and-verify flows are clearly sequenced (1. send, 2. retrieve, 3. read), but the batch endpoint ('up to 100') and destructive DELETE operations carry no validation/verification checkpoints, which caps this dimension at 3 per the rubric. |
| progressive disclosure | ████░ 4/5 | Well-organized with clear section headers and no unnecessary external references (no bundle files exist), though the ~345-line single-file API reference is borderline monolithic and could split the endpoint catalog into a reference file. |
Suggestions:
- Add an explicit validation checkpoint to the batch and DELETE workflows (e.g., list/GET the resource after operating to confirm the expected state) so workflow_clarity can exceed the rubric's batch/destructive cap.
- Consolidate the duplicated send-email curl and extract-code sequence — keep one canonical version in API Endpoints / Common Patterns and cross-reference it from the Auth and Extracting Data sections.
- Consider moving the full per-endpoint curl catalog (Domains, API Keys, Audiences, Contacts) into a references/api.md file and keeping SKILL.md as an overview plus the most-used flows.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Names the domain and lists multiple concrete actions — 'send emails locally', 'test transactional email flows', 'implement magic link or verification code auth', 'inspect sent emails', 'manage domains/contacts/API keys' — giving comprehensive coverage. |
| completeness | █████ 5/5 | Explicitly answers both what ('Emulated Resend email API for local development and testing' plus concrete capabilities) and when ('Use when the user needs to...' followed by a 'Triggers include' clause). |
| trigger term quality | █████ 5/5 | Comprehensive natural trigger terms including synonyms and an env var: 'Resend API', 'emulate Resend', 'send email locally', 'test email', 'magic link', 'verification email', 'email inbox', 'RESEND_BASE_URL'. |
| distinctiveness conflict risk | █████ 5/5 | A clear niche — Resend API emulation — with branded triggers ('Resend API', 'RESEND_BASE_URL') that are unlikely to collide with other skills. |
plugins/emulate/.agents/skills/slack/SKILL.md
A highly actionable, well-structured API emulator reference with comprehensive executable examples, held back by monolithic single-file organization, some redundancy, and missing validation checkpoints around destructive operations.
Validation
⚠️ skill_md_line_count — SKILL.md is long (732 lines); consider splitting into references/ and linking⚠️ allowed_tools_field — 'allowed-tools' contains unusual tool name(s)
Full review details
Validation Checks
14/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | The body is dense reference material with no concept over-explanation, but contains redundancy: the full scope list is repeated verbatim under both oauth_apps and tokens in the seed config, and the Common Patterns section re-illustrates chat.postMessage/reactions.add already shown in API Endpoints. |
| actionability | █████ 5/5 | Copy-paste-ready curl commands with real endpoints, headers, and JSON bodies cover the common cases across chat, conversations, users, files, pins, views, reactions, OAuth, and webhooks, plus programmatic and SDK/Bolt usage. |
| workflow clarity | ███░░ 3/5 | Sequences exist (Start, Pointing Your App, OAuth Flow numbered steps), but destructive/batch operations (chat.delete, conversations.archive, conversations.kick, files.delete) and the OAuth exchange lack validation checkpoints or verify-after-step feedback loops, capping workflow clarity at 3 per the rubric. |
| progressive disclosure | ███░░ 3/5 | Section headers are well organized, but with no bundle files present the entire ~700-line API reference is inlined in SKILL.md and no content is split into one-level-deep referenced files, so content that clearly belongs in separate references stays inline. |
Suggestions:
- Add explicit validation/verification steps after destructive or batch operations (e.g., after chat.delete or conversations.archive, call conversations.history/conversations.info to confirm the new state) and a verify step in the OAuth exchange flow.
- Move the exhaustive endpoint reference and the large seed-config YAML into referenced bundle files (e.g. references/endpoints.md, references/seed-config.yaml) and keep SKILL.md as a lean overview with one-level-deep links.
- De-duplicate the scope list in the seed config (reference a shared anchor or a single token example) and trim the Common Patterns section so it does not re-illustrate calls already shown under API Endpoints.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions — 'interact with Slack API endpoints locally, test Slack integrations, emulate channels/messages/users/views, set up Slack OAuth flows, test incoming webhooks, or work with the Slack Web API' — giving comprehensive coverage of capabilities. |
| completeness | █████ 5/5 | Explicitly answers both 'what' (emulated stateful Slack Web API for local dev/testing) and 'when' ('Use when the user needs…' plus a dedicated 'Triggers include…' clause with concrete trigger phrases). |
| trigger term quality | █████ 5/5 | Comprehensive natural-term coverage with synonyms users would actually say: 'Slack API', 'emulate Slack', 'mock Slack', 'test Slack OAuth', 'Slack bot', 'Slack views', 'incoming webhook', 'local Slack'. |
| distinctiveness conflict risk | █████ 5/5 | Clear niche (local Slack API emulation) with Slack-specific triggers; minimal conflict risk with other skills. |
plugins/emulate/.agents/skills/stripe/SKILL.md
The body is highly actionable and well-sequenced, with copy-paste-ready code and commands throughout. Its main weakness is progressive disclosure: it is a long single-file document with a substantial inline API reference that could be split into a separate file.
Validation
⚠️ allowed_tools_field — 'allowed-tools' contains unusual tool name(s)
Full review details
Validation Checks
15/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | Mostly lean and direct with brief, useful explanations ('Charges are created automatically when a payment intent is confirmed'), but seed config appears twice (YAML block and inline TS in the Next.js adapter), a minor redundancy that could be tightened. |
| actionability | █████ 5/5 | Fully executable, copy-paste ready commands and code: start commands, SDK client config, curl examples for every endpoint, a webhook handler, and complete checkout/payment-intent flows. |
| workflow clarity | ████░ 4/5 | Clear logical sectioning (Start -> Pointing Your App -> Seed Config -> API Endpoints -> Webhooks -> Common Patterns) with concrete steps; minor gap is the absence of an explicit 'verify the emulator is running' checkpoint, though the documented workflows are creation/confirm flows rather than destructive batches. |
| progressive disclosure | ███░░ 3/5 | A single monolithic file (~380 lines) with good section headers but no external reference files; the large inline endpoint catalog (~120 lines of curl examples) is content that could reasonably live in a separate reference file, and no progressive disclosure structure is used. |
Suggestions:
- Move the per-endpoint API reference (Customers/Products/Prices/Checkout/Payment Intents/Charges curl examples) into a references/ENDPOINTS.md file, keeping SKILL.md as an overview that links to it.
- Add a brief validation checkpoint in the Start section, e.g. 'Verify: curl http://localhost:4000/v1/customers -H "Authorization: Bearer sk_test_emulated" returns []', so users can confirm the emulator is running before wiring up their app.
- De-duplicate the seed configuration: show it once (the YAML block) and reference it from the Next.js adapter example rather than re-inlining the products/prices/webhooks seed in TS.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions ('process payments locally, test checkout flows, create customers, manage products and prices, handle payment intents, work with webhooks, or use the Stripe SDK'), giving comprehensive coverage of the skill's capabilities. |
| completeness | █████ 5/5 | Explicitly answers both 'what' ('Emulated Stripe API for local development and testing') and 'when' ('Use when the user needs to...'), with concrete trigger phrases enumerated. |
| trigger term quality | █████ 5/5 | Comprehensive natural trigger terms including synonyms and the env var: 'Stripe API', 'emulate Stripe', 'test payments locally', 'checkout flow', 'payment intent', 'Stripe webhook', 'Stripe SDK', and 'STRIPE_API_KEY'. |
| distinctiveness conflict risk | █████ 5/5 | Clear niche (local Stripe emulation) with distinct, domain-specific triggers and minimal overlap risk with other skills. |
plugins/emulate/.agents/skills/vercel/SKILL.md
Highly actionable and concrete with copy-paste-ready curl examples across the full Vercel API surface, but the ~480-line monolithic endpoint reference is inlined rather than progressively disclosed to bundle files, and destructive/batch operations lack explicit validation checkpoints.
Validation
⚠️ allowed_tools_field — 'allowed-tools' contains unusual tool name(s)
Full review details
Validation Checks
15/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ███░░ 3/5 | The body is mostly efficient curl examples with minimal conceptual padding, but at ~480 lines of inlined endpoint reference it is long and includes material (e.g. the full OAuth integration config block and extensive per-endpoint curl snippets) that could be trimmed or offloaded to a reference file. |
| actionability | █████ 5/5 | Nearly every endpoint ships a copy-paste-ready curl command with headers, method, and a concrete JSON body; the seed config and SDK snippets are equally executable, matching the 'fully executable, copy-paste ready' anchor. |
| workflow clarity | ███░░ 3/5 | Endpoints are well grouped and a 'Common Patterns' section sequences create-project-and-deploy and OAuth flows, but destructive/batch operations (DELETE project that 'cascades', batch env-var upsert, blob delete of multiple URLs) lack explicit validation or verify checkpoints, capping this dimension per the destructive/batch feedback-loop rule. |
| progressive disclosure | ███░░ 3/5 | Sections are clearly organized with headers, but the bulk API reference is inlined entirely in SKILL.md with no bundle files (references/scripts/assets absent) and no one-level-deep pointers to separate reference docs, so content that should be split out remains inline. |
Suggestions:
- Move the per-endpoint curl reference into a references/ file (e.g. REFERENCE.md) and keep SKILL.md as a concise overview pointing to it, lifting progressive_disclosure and conciseness.
- Add explicit validation/verify steps for destructive and batch operations (e.g. GET the project after PATCH, confirm env vars before DELETE cascade, list blob before delete) so workflow_clarity can exceed the destructive/batch cap of 3.
- Trim redundant material such as the full Auth.js provider config block and repeated protection-bypass curl variants to tighten token efficiency.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions: 'emulate projects/deployments/domains, set up Vercel OAuth flows, manage environment variables, create API keys, configure protection bypass, emulate Vercel Blob storage', giving comprehensive coverage of the emulator's surface. |
| completeness | █████ 5/5 | Explicitly answers both what ('Emulated Vercel REST API for local development and testing' plus enumerated capabilities) and when ('Use when the user needs to... Triggers include...'), with concrete trigger phrases matching the anchor example. |
| trigger term quality | ████░ 4/5 | Includes natural trigger phrases a user would say ('Vercel API', 'emulate Vercel', 'mock Vercel', 'test Vercel OAuth', 'Vercel Blob', 'local Vercel'), though it leans on 'Vercel'-prefixed variants rather than spanning broader synonyms a user might naturally phrase. |
| distinctiveness conflict risk | █████ 5/5 | Carves a clear niche (local Vercel API emulation) with distinct, Vercel-specific triggers and no overlap risk with unrelated skills. |
plugins/emulate/agent/skills/aws/SKILL.md
Highly actionable API reference with executable curl and SDK examples across all four services, but it is a monolithic inlined reference with no bundle files, repeated boilerplate headers, and no validation checkpoints around its destructive operations.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | No concept-padding and it assumes Claude's competence, but the API Endpoints section repeats the full Authorization header and base URL on every single curl invocation (~40 times) rather than factoring them out as the Common Patterns section does; minor redundancy keeps it below the lean/every-token-earns-its-place anchor. |
| actionability | █████ 5/5 | Fully executable, copy-paste-ready curl commands covering S3/SQS/IAM/STS operations, plus working AWS SDK v3 snippets, a YAML seed config, and end-to-end Common Patterns — covering the common cases comprehensively. |
| workflow clarity | ███░░ 3/5 | Common Patterns provide sequenced steps (upload→retrieve, send→receive, create-user→create-key) but include no validation checkpoints, and the skill documents destructive operations (Delete bucket, Delete object, Purge queue, Delete user/role); per the rubric's destructive-operations cap, workflow clarity cannot exceed 3. |
| progressive disclosure | ███░░ 3/5 | Good section structure via headers (Start, Auth, API Endpoints per service, Common Patterns), but no bundle files exist and the entire per-service API reference is inlined in SKILL.md when it clearly belongs in separate reference files; not a monolith, but content that should be split is inline. |
Suggestions:
- Move per-service API references into separate files (e.g. references/s3.md, references/sqs.md, references/iam.md, references/sts.md) and keep SKILL.md as an overview with one-level-deep links, raising progressive_disclosure.
- Add validation/verification checkpoints around destructive operations (e.g. verify a bucket is empty before Delete, confirm ReceiveMessage returned no in-flight messages before PurgeQueue) so workflow clarity is not capped at 3.
- Factor the repeated Authorization header and base URL out of the API Endpoints curl examples (set TOKEN/BASE once as Common Patterns does) to tighten token efficiency.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions across all four services ('test S3 bucket and object operations, emulate SQS queues and messages, manage IAM users/roles/access keys, test STS assume role'), matching the comprehensive-coverage anchor rather than the 4 anchor which expects minor gaps. |
| completeness | █████ 5/5 | Explicitly answers both what ('Emulated AWS cloud services (S3, SQS, IAM, STS) for local development and testing') and when ('Use when the user needs to... Triggers include...') with concrete trigger phrases, matching the top anchor exactly. |
| trigger term quality | █████ 5/5 | Provides eight natural trigger phrases with synonyms ('AWS emulator', 'emulate AWS', 'mock S3', 'local SQS', 'test IAM', 'emulate S3', 'AWS locally', 'STS assume role') plus a general catch-all; file extensions are not applicable to AWS services, so this fits the comprehensive-synonyms anchor. |
| distinctiveness conflict risk | █████ 5/5 | Occupies a clear niche (local AWS API emulation) with distinctive triggers unlikely to fire for unrelated skills; minimal overlap risk with other skills. |
plugins/emulate/agent/skills/emulate/SKILL.md
The body is highly actionable with executable examples and a clear configuration model, but it is weighed down by an oversized inline seed-config YAML that should be split into a reference file. Structure and sequencing are otherwise solid.
Validation
⚠️ skill_md_line_count — SKILL.md is long (549 lines); consider splitting into references/ and linking
Full review details
Validation Checks
15/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ███░░ 3/5 | Mostly efficient prose with concrete commands, but a ~270-line full seed-config YAML for all 14 services is inlined directly in SKILL.md, inflating the token budget when a reference file would suffice. |
| actionability | █████ 5/5 | Copy-paste ready throughout: npx emulate commands, a createEmulator TypeScript example, a Vitest/Jest setup block, persistence adapter code, and concrete env-var overrides covering the common cases. |
| workflow clarity | ████░ 4/5 | The start → configure seed → point app via env vars → run tests flow is clearly sequenced, and the generated-secrets path documents failure handling; minor validation gaps but the skill is not primarily a destructive/batch workflow. |
| progressive disclosure | ███░░ 3/5 | Good section structure and clearly signaled one-level pointers to the next/nuxt skills, but no references/ directory exists and the large per-service config block that belongs in a separate reference file is fully inlined. |
Suggestions:
- Move the full per-service seed config (the ~270-line YAML block) into a references/seed-config.yaml file and keep only a minimal two-service example inline, linking to the reference.
- Add a short 'Verify it's running' checkpoint after
npx emulate(e.g. curl a health endpoint or checkemulate list) so the Quick Start has an explicit validation step. - Confirm the referenced skills/next/SKILL.md and skills/nuxt/SKILL.md paths exist in the bundle, or drop the bare path references if those skills are not bundled.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Names the domain (drop-in API emulator for a concrete list of services) and multiple specific actions: 'start emulated services, configure seed data, write tests against local APIs, set up CI without network access, or work with the emulate CLI or programmatic API'. |
| completeness | █████ 5/5 | Explicitly answers both what ('Local drop-in API emulator for ... developer APIs') and when ('Use when the user needs to ... Triggers include ...') with concrete trigger phrases, satisfying the top anchor. |
| trigger term quality | █████ 5/5 | Comprehensive natural trigger phrases users would actually say: "start the emulator", "emulate services", "mock API locally", "create emulator config", "test against local API", "npx emulate", plus the CLI invocation form. |
| distinctiveness conflict risk | █████ 5/5 | Clear niche (local stateful emulation of named developer APIs) with distinct, service-specific triggers; minimal overlap risk with other skills. |
plugins/emulate/agent/skills/github/SKILL.md
A thorough, highly actionable API reference with excellent concrete examples and clear multi-step flows. Its main weakness is progressive disclosure: ~630 lines of endpoint reference live entirely in SKILL.md rather than being split into one-level-deep reference files.
Validation
⚠️ skill_md_line_count — SKILL.md is long (640 lines); consider splitting into references/ and linking
Full review details
Validation Checks
15/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | The body is mostly lean, executable reference material with little padding of concepts Claude already knows, but at ~630 lines the sheer volume in a single SKILL.md is more than the overview role calls for. It is efficient but could be trimmed by offloading bulk reference content. |
| actionability | █████ 5/5 | Abundant copy-paste-ready curl and TypeScript examples cover the common cases across auth, repos, issues, PRs, apps, OAuth, and more, with concrete endpoints and payloads. |
| workflow clarity | ████░ 4/5 | Multi-step flows like the 'GitHub App Installation Token Flow' (numbered 1-3) and 'OAuth Flow' (numbered 1-5) are clearly sequenced; minor validation/checkpoint gaps exist, though the destructive single-call operations are not presented as multi-step workflows so the destructive cap does not apply. |
| progressive disclosure | ███░░ 3/5 | Section headers provide reasonable structure, but the full API reference is inlined monolithically in SKILL.md with no external reference files (none exist in the bundle), so content that clearly belongs in separate files is not split out. |
Suggestions:
- Move the bulk endpoint reference (Users, Repositories, Issues, PRs, Comments, Reviews, Apps, etc.) into one or more reference files under ./references/ and keep SKILL.md as a concise overview with clearly signaled links.
- Add explicit validation/checkpoint steps to workflows involving destructive or state-changing operations (e.g., repo deletion that 'cascades issues, PRs') to strengthen workflow clarity.
- Trim any redundant prose (e.g., repeated notes about private_key handling across the Start, Auth, and GitHub App JWT sections) to tighten token efficiency.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions — 'emulate repos/issues/PRs, set up GitHub OAuth flows, configure GitHub Apps, test webhooks, or work with actions/checks' — giving comprehensive coverage of capabilities. |
| completeness | █████ 5/5 | Explicitly answers both what ('Emulated GitHub REST API for local development and testing') and when (a clear 'Use when...' clause plus a 'Triggers include...' list with concrete phrases). |
| trigger term quality | █████ 5/5 | Comprehensive natural trigger phrases including synonyms — 'GitHub API', 'emulate GitHub', 'mock GitHub', 'test GitHub OAuth', 'GitHub App JWT', 'local GitHub' — that users would naturally say. |
| distinctiveness conflict risk | █████ 5/5 | Occupies a clear niche — local GitHub API emulation — with distinct, specific triggers that minimize overlap with other skills. |
plugins/emulate/agent/skills/google/SKILL.md
A thorough, highly executable reference for the Google emulator with excellent actionability, but it is a monolithic inlined API reference with no progressive disclosure to separate files and lacks validation checkpoints around its destructive and batch operations.
Validation
⚠️ skill_md_line_count — SKILL.md is long (615 lines); consider splitting into references/ and linking
Full review details
Validation Checks
15/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | Prose is lean and avoids explaining basic concepts Claude already knows, but the body inlines a very large API endpoint reference (Gmail/Calendar/Drive) that is token-heavy; minor explanatory lines like the RS256/JWKS note could be trimmed or moved to a reference. |
| actionability | █████ 5/5 | Dense with copy-paste-ready curl commands and TypeScript/YAML examples covering start-up, client wiring for google-auth-library/Auth.js/Passport/openid-client, seed config, and per-endpoint usage across all four API surfaces. |
| workflow clarity | ███░░ 3/5 | The 'Full Authorization Code Flow' gives a clear 4-step sequence, but destructive and batch operations (message/file delete, trash, batchModify, batchDelete) lack validation or verification checkpoints, which caps this dimension at 3 per the rubric. |
| progressive disclosure | ███░░ 3/5 | Sections are well-organized with clear headers, but no bundle files exist and the bulk per-API reference is inlined entirely in SKILL.md rather than split into one-level-deep reference files, fitting the 'content that should be separate is inline' anchor. |
Suggestions:
- Add validation/verification steps before destructive and batch operations — e.g., list-then-confirm before delete/trash, and verify batchModify/batchDelete results — to lift workflow_clarity past the destructive-ops cap.
- Move the per-surface endpoint reference (Gmail, Calendar, Drive) into separate reference files (e.g. references/gmail.md, references/calendar.md, references/drive.md) linked from a concise overview in SKILL.md to improve progressive disclosure and reduce token load.
- Trim or relocate minor explanatory prose such as the RS256/JWKS paragraph into a reference, keeping the body focused on executable guidance.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions across each surface — 'test Google sign-in locally, emulate OIDC discovery, handle Google token exchange, configure Google OAuth clients, work with Gmail messages/drafts/threads/labels, manage Calendar events, upload or list Drive files' — with comprehensive coverage and no vague filler. |
| completeness | █████ 5/5 | Clearly states the 'what' (emulated Google OAuth 2.0/OIDC/Gmail/Calendar/Drive for local dev and testing) and an explicit 'Use when the user needs to...' clause plus a dedicated 'Triggers include...' list, answering both what and when with concrete trigger phrases. |
| trigger term quality | █████ 5/5 | The explicit 'Triggers include "Google OAuth", "emulate Google", "mock Google login", "test Google sign-in", "OIDC emulator", "Google OIDC", "Gmail API", "Google Calendar", "Google Drive", "local Google auth"' gives comprehensive natural-term coverage with synonyms a user would actually say. |
| distinctiveness conflict risk | █████ 5/5 | Scoped to a clear niche — local Google API emulation — with distinct, Google-specific triggers, making collision with unrelated skills minimal. |
plugins/emulate/agent/skills/microsoft/SKILL.md
A thorough, highly actionable reference for the Microsoft emulator with executable examples across all common flows. Its main weakness is progressive disclosure: everything is inlined into one ~370-line SKILL.md with no bundle files or references to split the library integrations and full API reference.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | Largely lean and reference-style with no padding of concepts Claude already knows, but the ~370-line body inlines substantial material (three full library integration examples, complete endpoint reference) that could be trimmed or split. Not a 5 because some inline bulk could earn its place better in separate files. |
| actionability | █████ 5/5 | Provides fully executable, copy-paste-ready curl commands, TypeScript snippets, and a seed YAML config covering auth code flow, PKCE, client credentials, refresh, userinfo, Graph /me, logout, and revocation — the common cases are all covered. |
| workflow clarity | ████░ 4/5 | The 'Common Patterns' section sequences the Full Authorization Code Flow (numbered steps 1-4) and PKCE Flow with concrete commands. Not a 5 because there are no explicit validation/checkpoint steps, though the skill is non-destructive reference material so this is a minor gap. |
| progressive disclosure | ███░░ 3/5 | No bundle files exist and all content lives inline in a single well-sectioned file; content that could reasonably be split (per-library integration guides, full API endpoint reference) is inlined. The section organization is good, but the lack of any one-level-deep references keeps this at 3 rather than higher. |
Suggestions:
- Move the three library integration examples (Auth.js, Passport.js, MSAL.js) into a separate references file and link to it from SKILL.md to improve progressive disclosure.
- Extract the full API Endpoints reference into a dedicated reference file, keeping only the quick-start and most common endpoints inline.
- Add a brief validation/checkpoint note in the Common Patterns flows (e.g., confirming the discovery document resolves before proceeding) to strengthen workflow clarity.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions — 'emulate Entra ID OIDC discovery', 'handle Microsoft token exchange', 'configure Azure AD OAuth clients', 'work with Microsoft Graph /me', 'test PKCE/client credentials flows' — giving comprehensive coverage of capabilities. |
| completeness | █████ 5/5 | Clearly states what it does ('Emulated Microsoft Entra ID ... OAuth 2.0 / OpenID Connect for local development and testing') and explicitly when to use it ('Use when the user needs to...') with concrete trigger phrases. |
| trigger term quality | █████ 5/5 | Provides extensive natural trigger phrases users would say — 'Microsoft OAuth', 'Entra ID', 'Azure AD', 'mock Microsoft login', 'test Microsoft sign-in', 'Microsoft OIDC', 'local Microsoft auth' — covering synonyms and common variations. |
| distinctiveness conflict risk | █████ 5/5 | Occupies a clear niche (local Microsoft OAuth/OIDC emulation) with Microsoft-specific triggers, giving minimal conflict risk with other skills. |
plugins/emulate/agent/skills/resend/SKILL.md
The body is highly actionable and well-structured with executable examples throughout, but its multi-step workflows (notably batch sends and the magic-link flow) lack explicit validation checkpoints and error-recovery feedback loops, capping workflow clarity. Minor conciseness trims would raise it further.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | Lean and mostly efficient with no padding or explanations of basic concepts; minor trims possible such as 'This is the key differentiator of the emulator...' restating the intro, so it sits just below the score-5 'every token earns its place' anchor. |
| actionability | █████ 5/5 | Fully executable, copy-paste-ready curl and TypeScript covering emails, batch, domains, keys, audiences, contacts, webhooks, idempotency, and magic-link extraction — specific examples cover the common cases per the score-5 anchor. |
| workflow clarity | ███░░ 3/5 | The Magic Link / Verification Code Flow is a clear 3-step sequence, but there are no validation checkpoints or error-recovery feedback loops, and the batch endpoint ('up to 100') triggers the rubric cap that forbids scoring above 3 without validation in batch/destructive operations. |
| progressive disclosure | ████░ 4/5 | Single self-contained file with clear, well-organized section headers and no nested references; sits above the score-3 anchor though slightly short of the score-5 'well-signaled one-level-deep references' example given its length and lack of any external file split. |
Suggestions:
- Add validation checkpoints to the Magic Link flow (e.g., verify the retrieved code matches an expected pattern before asserting success; handle the case where no email is returned).
- Include a feedback loop for batch sends (e.g., check the response for partial failures and report/retry failures) to satisfy the batch-operation validation expectation.
- Trim restatements of the intro, such as 'This is the key differentiator of the emulator: every email sent via POST /emails is stored and queryable,' since the opening paragraph already conveys it.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions — 'send emails locally', 'test transactional email flows', 'implement magic link or verification code auth', 'inspect sent emails', 'manage domains/contacts/API keys' — with comprehensive coverage, matching the score-5 anchor exactly. |
| completeness | █████ 5/5 | Explicitly answers both 'what' (emulated Resend email API for local development and testing) and 'when' ('Use when the user needs...') with concrete trigger phrases, matching the score-5 anchor. |
| trigger term quality | █████ 5/5 | Comprehensive natural triggers including synonyms and an env-var identifier — 'Resend API', 'emulate Resend', 'send email locally', 'test email', 'magic link', 'verification email', 'email inbox', 'RESEND_BASE_URL' — the phrases a user would naturally say. |
| distinctiveness conflict risk | █████ 5/5 | Occupies a clear niche (Resend API emulation) with distinct triggers like 'RESEND_BASE_URL' and 'emulate Resend', giving minimal conflict risk with other skills. |
plugins/emulate/agent/skills/slack/SKILL.md
A highly actionable, well-organized API reference with excellent executable examples, but it is a monolithic single-file document: a reference of this size should be split into bundled reference files with the SKILL.md acting as an overview, and the repeated scope lists add avoidable length.
Validation
⚠️ skill_md_line_count — SKILL.md is long (736 lines); consider splitting into references/ and linking
Full review details
Validation Checks
15/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | The body is mostly efficient — minimal concept-explanation padding and dense, informational prose — but the full Slack scope list is repeated three times (Auth section, oauth_apps seed, tokens seed) and the seed-config block is very long, which is removable redundancy. Not a 5 because those verbose repeats could be tightened or factored out. |
| actionability | █████ 5/5 | Fully executable, copy-paste-ready curl commands and TypeScript snippets cover every common case (chat, conversations, users, files, pins, views, reactions, OAuth, webhooks), with concrete IDs and request bodies — exactly the 'specific examples cover the common cases' anchor. |
| workflow clarity | ████░ 4/5 | Endpoints are well-organized by category and the OAuth flow is given as a numbered 5-step sequence in Common Patterns; no destructive/batch validation feedback loops are required for a local emulator, so the missing-checkpoint cap does not apply. Not a 5 because there is no explicit 'verify your setup' checkpoint for first-time users. |
| progressive disclosure | ██░░░ 2/5 | No bundle files exist and the entire ~700-line API reference is inlined in SKILL.md with zero references to separate files — matching the score-2 anchor where 'content that clearly belongs in separate files is inlined'. Section headers provide some structure, but the bulk reference material is not split or signaled as one-level-deep references. |
Suggestions:
- Move the per-endpoint API reference (Chat, Conversations, Users, Files, Pins, Views, Reactions, etc.) into bundled reference files under references/ (e.g. references/endpoints.md) and keep SKILL.md as a concise overview with clearly signaled one-level-deep links.
- De-duplicate the Slack scope list — define it once and reference it from the Auth section, the oauth_apps seed example, and the tokens seed example instead of repeating the full 28-scope block three times.
- Add a short 'Verify it works' checkpoint near the Start section (e.g. run the auth.test curl and confirm ok:true) so first-time users have an explicit success signal before proceeding.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Names the domain and lists multiple concrete capabilities — 'emulate channels/messages/users/views', 'set up Slack OAuth flows', 'test incoming webhooks', 'work with the Slack Web API' — giving comprehensive coverage rather than generic phrasing. |
| completeness | █████ 5/5 | Explicitly answers both 'what' (emulated Slack API for local development and testing with enumerated capabilities) and 'when' (an explicit 'Use when the user needs to...' clause plus a 'Triggers include' list). |
| trigger term quality | █████ 5/5 | Comprehensive natural-term coverage with synonyms — 'Slack API', 'emulate Slack', 'mock Slack', 'test Slack OAuth', 'Slack bot', 'Slack views', 'incoming webhook', 'local Slack' — matching the kind of phrasing a user would actually say. |
| distinctiveness conflict risk | █████ 5/5 | A clear niche — local Slack API emulation — with distinct, domain-specific triggers, making it unlikely to fire for unrelated skills. |
plugins/firebase/.agents/skills/firebase-ai-logic-basics/SKILL.md
The skill is well-structured with good progressive disclosure to real reference files and genuinely executable setup/App-Check guidance, but core-capability sections are largely abstract hints lacking inline code and workflows lack explicit verification checkpoints. Minor redundancy in the model-name warnings and reference listings adds token cost.
Validation
⚠️ metadata_version — 'metadata.version' is missing⚠️ frontmatter_unknown_keys — Unknown frontmatter key(s) found; consider removing or moving to metadata
Full review details
Validation Checks
14/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ███░░ 3/5 | The body is mostly efficient with terse one-line capability descriptions, but the 'CRITICAL: Use current model names' warning is repeated nearly verbatim three times and some background phrasing ('Firebase AI Logic is a product of Firebase that allows developers to add gen AI...') is mildly padded, matching the 'mostly efficient but could be tightened' anchor. |
| actionability | ███░░ 3/5 | Setup and App Check debug-token sections provide concrete executable commands and code, but most core-capability sections ('Text-Only Generation', 'Chat Session', 'Structured Output', 'Search Grounding') give only abstract one-line hints with no inline code, fitting 'some concrete guidance but incomplete; missing key details'. |
| workflow clarity | ███░░ 3/5 | Setup and App Check debug-token flows are clearly numbered, but verification checkpoints are implicit or absent (e.g., no 'verify the Gemini Developer API is enabled' or 'confirm an app exists' step), matching 'steps listed but validation gaps; checkpoints missing or implicit'. |
| progressive disclosure | ████░ 4/5 | The body is an overview that signals one-level-deep references to real bundle files (usage_patterns_web.md, usage_patterns_android.md, ios_setup.md, flutter_setup.md), all of which exist; not 5 because the reference list is duplicated across 'Initialization Code References' and 'References', and several capability headers (Text-Only Generation, Search Grounding) are empty stubs. |
Suggestions:
- Add a minimal executable snippet to each core-capability section (e.g., a generateContent call for Text-Only, startChat for Chat, generateContentStream for Streaming) instead of only describing them, since those reference files are platform-specific and the body gives no shared example.
- Add explicit verification checkpoints to the setup workflow (e.g., after
init ailogic, confirm the Gemini Developer API is enabled in the Firebase console; afterapps:list, branch on 'no app found'). - De-duplicate the 'Use current model names' warning to a single callout and consolidate the duplicated reference listings in 'Initialization Code References' and 'References' into one section to save tokens.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | ████░ 4/5 | Names the domain (Firebase AI Logic / Gemini API) and lists several concrete coverage areas — 'setup, multimodal inference, structured output, and security' — matching the 'lists several specific actions; minor gaps' anchor; not 5 because the actions are coverage labels rather than fully enumerated concrete operations. |
| completeness | ███░░ 3/5 | Provides a clear 'what' (integrating Firebase AI Logic covering setup, multimodal inference, structured output, security) but no explicit 'when to use' clause; per the rubric, a missing 'Use when...' clause caps completeness at 3. |
| trigger term quality | ███░░ 3/5 | Contains relevant keywords ('Firebase AI Logic', 'Gemini API', 'web applications') but lacks a 'Use when...' trigger clause and natural synonyms/file extensions, fitting the 'some relevant keywords but missing common variations' anchor; not 4 because trigger guidance is absent. |
| distinctiveness conflict risk | ████░ 4/5 | Targets a clear niche ('Firebase AI Logic (Gemini API)') that is mostly distinct from other skills with only minor overlap risk against a generic Gemini-integration skill; not 5 because the description scopes to 'web applications' while the body covers mobile platforms too, a minor specificity gap. |
Suggestions:
- Add a 'Use when...' clause naming natural trigger phrases users would say (e.g., 'Use when integrating the Gemini API into a Firebase app, or when the user mentions Firebase AI Logic, multimodal inference, or structured Gemini output').
- Reconcile the platform scope — the description says 'web applications' but the body covers Android, iOS, and Flutter as well; broaden to 'web and mobile applications' or state the web focus explicitly.
- Include common synonyms/extensions in the trigger terms (e.g., 'Gemini', 'Firebase AI Logic', 'Vertex AI for Firebase') to improve keyword coverage.
plugins/firebase/.agents/skills/firebase-firestore/SKILL.md
A well-structured, executable skill body that efficiently routes the reader through edition detection to the right reference set. The only gap is the absence of an explicit verification step after database creation.
Validation
⚠️ metadata_version — 'metadata.version' is missing⚠️ relative_links — Relative link issues: 14 deeper-than-1-level⚠️ referenced_paths_exist — Referenced path issues: 14 deeper-than-1-level
Full review details
Validation Checks
13/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | █████ 5/5 | Lean body with no padding or basic-concept explanations; almost entirely commands, branch labels, and short imperatives, with one justified critical instruction ('MUST always identify the Firestore instance edition'). |
| actionability | █████ 5/5 | Fully executable copy-paste CLI commands with flags throughout ('npx -y firebase-tools@latest firestore:databases:list', '--edition="enterprise" --location=...'), covering the common provisioning/inspection cases. |
| workflow clarity | ████░ 4/5 | Clear branching sequence (Instance Found vs No Instance) with an edition-detection checkpoint and user confirmation for location, but no explicit post-creation verification step after 'firestore:databases:create'. |
| progressive disclosure | █████ 5/5 | Overview body points to one-level-deep references split by edition (references/standard/, references/enterprise/), all referenced files verified to exist, with clearly labeled navigation and delegation to the firestore-rules-creation skill. |
Suggestions:
- Add an explicit post-creation verification checkpoint, e.g. re-run 'firestore:databases:get ' to confirm the new database's edition and location before proceeding to the guides.
- After creating a database in branch B, state that the edition should be re-read/confirmed rather than assuming Enterprise, in case the create command's output needs checking.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions ('Sets up, manages, queries, and configures') plus specifics ('data modeling, security rules, indexes, and SDK integrations (Web, Python, iOS, Android, Flutter)'), giving comprehensive coverage. |
| completeness | █████ 5/5 | Explicitly answers both what ('Sets up, manages, queries, and configures Cloud Firestore databases...') and when ('Use when...'), with concrete trigger phrases and a 'Don't use for' boundary. |
| trigger term quality | █████ 5/5 | Natural trigger phrases users would say ('creating/listing Firestore databases, defining data models/indexes, writing SDK queries, or integrating Firestore SDKs') with good synonym coverage across platforms. |
| distinctiveness conflict risk | █████ 5/5 | Clear Firestore niche with an explicit exclusion list ('Don't use for Firebase Hosting, Data Connect, Auth, Storage/GCS, Crashlytics, Functions, or BigQuery'), minimizing conflict with sibling Firebase skills. |
plugins/firebase/.agents/skills/firebase-security-rules-auditor/SKILL.md
The body is a well-structured, actionable audit methodology with a concrete checklist, scoring rubric, and output format. It is slightly over-padded in framing and lacks an explicit error-recovery loop, but otherwise strong.
Validation
⚠️ metadata_version — 'metadata.version' is missing
Full review details
Validation Checks
15/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | The body is mostly efficient and assumes Claude's competence, but includes minor over-explanation that could be trimmed — the overview paragraph restates the description and the 'hole in the wall' / 'do not assume a rule is secure' lines add flavor rather than actionable content. |
| actionability | █████ 5/5 | As an instruction-only skill it provides a concrete six-item checklist with specific checks ('is string', 'is int', 'hasOnly()/diff() ownership'), a 1–5 severity rubric, and a defined JSON output format; absence of code is not penalized because the guidance is specific and actionable. |
| workflow clarity | ████░ 4/5 | A clear sequence exists — run the mandatory checklist, assign severity, score 1–5, emit JSON — with the checklist items acting as checkpoints; it is not a destructive/batch operation so the validation cap does not apply, though no explicit validate→fix→retry feedback loop is present. |
| progressive disclosure | ████░ 4/5 | No bundle files exist, and the single SKILL.md is well-sectioned (Overview, checklist, admin bootstrapping, scoring, output format) with all content appropriately inline; the body exceeds 50 lines so the simple-skill 5 exception does not strictly apply, leaving minor organization headroom. |
Suggestions:
- Trim the overview paragraph and the 'hole in the wall' motivational framing to reduce token overhead, since the description already conveys the skill's purpose.
- Add an explicit validate→fix→retry style feedback loop (e.g., re-run the checklist after proposed rule fixes to confirm the score improves) to strengthen workflow clarity for the audit cycle.
- Consider moving the full 1–5 scoring rubric and JSON output schema into a short reference file if the skill grows, to keep SKILL.md a lean overview.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete audit actions — 'privilege escalation, role bypasses, create vs update inconsistencies, resource exhaustion, type safety, size limits, and hasOnly ownership checks' — giving comprehensive coverage rather than vague language. |
| completeness | █████ 5/5 | Explicitly answers both 'what' (audits Firebase security rules for a concrete list of issues) and 'when' ('Use when auditing/reviewing rules, running red-team rule assessments, or scoring against auditor checklists'), with concrete trigger phrases and boundary exclusions. |
| trigger term quality | ████░ 4/5 | Natural trigger phrases are present ('auditing/reviewing rules', 'red-team rule assessments', 'scoring against auditor checklists'), but a few common synonyms a user might say (e.g., 'pentest my rules', 'check my firestore rules') are missing, so it is not fully comprehensive. |
| distinctiveness conflict risk | █████ 5/5 | A clear niche (Firebase security rules auditing) with distinct triggers and an explicit 'Don't use for Firebase CLI (login, deploy), Auth, Crashlytics, Remote Config, or database queries' boundary that minimizes conflict risk. |
plugins/firebase/.agents/skills/firestore-rules-creation/SKILL.md
The body is highly actionable with a well-structured, validated workflow for a destructive/batch security context, but it is verbose with repeated emphasis and presents a large monolith that would benefit from splitting reference material into bundled files.
Validation
⚠️ skill_md_line_count — SKILL.md is long (585 lines); consider splitting into references/ and linking⚠️ metadata_version — 'metadata.version' is missing
Full review details
Validation Checks
14/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ███░░ 3/5 | The body is ~585 lines with noticeable repetition (the humility disclaimer appears in the intro and again in Critical Constraints #8; RBAC 'NEVER' rules are restated; MANDATORY/CRITICAL emphasis recurs), though the bulk is genuine domain knowledge rather than concepts Claude already knows. Not a 2 because it avoids explaining basics, not a 4 because the repeated emphasis and duplicated guidance could be trimmed. |
| actionability | █████ 5/5 | Provides fully executable guidance: a complete helper-function library, the validator function pattern with create/update wiring, and a concrete getAfter()-based counter-update example covering the common cases. |
| workflow clarity | █████ 5/5 | Four clearly sequenced phases (Codebase Analysis -> Generation -> Devil's Advocate Attack -> Syntactic Validation) with an explicit feedback loop ('Repeat Phase-3 until no attacks succeed') and a validation checkpoint ('firebase deploy --only firestore:rules --dry-run'). |
| progressive disclosure | ███░░ 3/5 | Has section structure (Phase headers, sub-headings) but is a ~585-line monolith with no bundle files and zero external references; large reference-like material (the ~140-line helper-function block and the 20-item attack checklist) is inlined rather than split into separate files. Not a 2 because headers provide real navigation; not a 4 because content that belongs in separate reference files is not split out. |
Suggestions:
- Dedupe the repeated content: the humility disclaimer in the intro is restated in Critical Constraints feat(web): add URL parameter support for auto-opening plugin install modal #8, and the RBAC 'NEVER/ALWAYS' rules overlap with the bad/good RBAC example block — consolidate to one location.
- Extract the helper-function library and the Phase-3 attack checklist into separate reference files under references/ (e.g. references/helper-functions.rules, references/attack-vectors.md) and link to them one level deep, reducing the SKILL.md body.
- Trim redundant emphasis words (CRITICAL/MANDATORY/NEVER repeated on near-identical points) without losing the directives; reserve the strongest emphasis for genuinely distinct rules.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions ('Designs, authors, refactors, and hardens') plus specific sub-tasks ('writing schema/domain validators, preventing update bypasses, enforcing type safety and resource limits, or implementing role-based access control'), giving comprehensive coverage. |
| completeness | █████ 5/5 | Explicitly answers both 'what' (designs/authors/refactors/hardens production-grade Firestore Security Rules) and 'when' (a 'Use when...' clause with concrete trigger phrases), matching the top anchor. |
| trigger term quality | █████ 5/5 | Covers natural phrases users would say ('creating security rules', 'writing schema/domain validators', 'preventing update bypasses', 'role-based access control') plus the file reference 'firestore.rules', including synonyms and the file extension. |
| distinctiveness conflict risk | █████ 5/5 | Clear niche (Firestore rules creation) with an explicit negative boundary ('Don't use for security rules auditing (use firebase-security-rules-auditor), database provisioning, or client SDK queries'), minimizing conflict risk. |
plugins/firebase/agent/skills/extension-to-functions-codebase/SKILL.md
The content is actionable and reasonably concise with a clear five-step migration sequence. It loses points for missing validation checkpoints in the workflow and for failing to link the provided reference bundle files.
Validation
⚠️ metadata_version — 'metadata.version' is missing
Full review details
Validation Checks
15/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | The body is efficient and assumes Claude's competence — rules and code snippets are tight with minimal padding, though a few inline TS/JSON blocks could be marginally trimmed. |
| actionability | ████░ 4/5 | Provides concrete, mostly executable guidance (real defineString/onInit code, onDocumentWritten imports, package.json fields), with minor gaps such as the unshown import context for requiresRole/requiresAPI. |
| workflow clarity | ███░░ 3/5 | Five numbered steps are clearly sequenced, but there are no validation/verification checkpoints; the destructive-leaning publish guard ("NEVER execute npm publish") and trigger upgrades lack validate-then-proceed loops, capping workflow clarity at 3. |
| progressive disclosure | ███░░ 3/5 | Bundle files exist in references/ (destructuring-shim.md, signature-mapping.md, configuration-migration.md) but the body never signals or links them, so detailed material that belongs in those references is inlined in SKILL.md. |
Suggestions:
- Add explicit validation checkpoints between steps, e.g. after upgrading triggers run a build/typecheck and only proceed when it passes.
- Link the existing reference files inline (e.g. "See destructuring-shim.md for shim details") and move the deeper code/field examples there, keeping SKILL.md an overview.
- Add a brief verify section before the publish reminder to confirm package structure and exports map are valid.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Names multiple concrete actions — "converting an installed Firebase Extension ... into a standalone Cloud Functions for Firebase codebase or publishable npm package", "V1 to V2 trigger upgrades", "lifecycle hooks", and "declarative security" — giving comprehensive coverage of the skill's capabilities. |
| completeness | ███░░ 3/5 | The "what" is clear and concrete, but there is no "Use when ..." clause or equivalent explicit trigger guidance, which caps completeness at 3 per the rubric guideline. |
| trigger term quality | ████░ 4/5 | Strong natural terms ("Firebase Extension", "Cloud Functions for Firebase", "npm package", "V1 to V2 trigger upgrades") that users would say, but missing some common synonyms like "2nd Gen", "functions", or file/extension references. |
| distinctiveness conflict risk | █████ 5/5 | Occupies a clear niche (Firebase Extension → Cloud Functions / npm package migration) with distinct triggers and minimal overlap risk with other skills. |
Suggestions:
- Append an explicit trigger clause, e.g. "Use when migrating or repackaging an installed Firebase Extension into Cloud Functions or an npm package."
- Add common synonyms users might say, such as "2nd Gen functions" or "functions upgrade", to broaden natural trigger coverage.
plugins/firebase/agent/skills/firebase-ai-logic-basics/SKILL.md
The body is well-structured with good progressive disclosure to real reference files and concrete setup commands, but core capability sections are thin/vague with no inline executable code, and workflows lack explicit validation checkpoints.
Validation
⚠️ metadata_version — 'metadata.version' is missing⚠️ frontmatter_unknown_keys — Unknown frontmatter key(s) found; consider removing or moving to metadata
Full review details
Validation Checks
14/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ███░░ 3/5 | Mostly efficient with sectioned structure, but it repeats the identical 'Use current model names' warning verbatim twice and includes light product-backstory padding ('previously known as Vertex AI for Firebase, represents the evolution...'); it could be tightened without losing meaning. |
| actionability | ███░░ 3/5 | Setup provides concrete executable commands (npm install, firebase-tools init ailogic), but the core capability sections (text-only, multimodal, chat, streaming, structured output) give only one-line hints like 'use generateContentStream' with no inline executable code, leaving the actual examples delegated to reference files. |
| workflow clarity | ███░░ 3/5 | A rough setup sequence and well-numbered App Check debug-token steps exist, but the main generate-from-setup flow lacks explicit validation checkpoints (e.g., no verify step after init ailogic), so checkpoints are missing or only implicit. |
| progressive disclosure | ████░ 4/5 | Content is split into real one-level-deep reference files (usage_patterns_web.md, usage_patterns_android.md, ios_setup.md, flutter_setup.md) with clearly signaled links in an 'Initialization Code References' section; minor gaps include a duplicated bottom 'References' list and capability sections that are stubs. |
Suggestions:
- Add a minimal inline code snippet for at least text generation and structured output so the core flow is actionable without opening a reference file.
- Deduplicate the repeated 'Use current model names' warning and trim product-history padding to improve token efficiency.
- Insert an explicit validation/verify step after
npx firebase-tools init ailogic(e.g., confirm the Gemini Developer API is enabled) to strengthen the setup workflow.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | ████░ 4/5 | Names the domain (Firebase AI Logic / Gemini API into web applications) and lists several concrete capability areas — 'setup, multimodal inference, structured output, and security' — but omits chat, streaming, image generation, and grounding, leaving minor coverage gaps rather than comprehensive coverage. |
| completeness | ███░░ 3/5 | The 'what' is clearly stated ('integrating Firebase AI Logic... Covers setup, multimodal inference, structured output, and security') but there is no 'Use when...' clause or equivalent explicit trigger guidance, which caps completeness at 3 per the rubric guidelines. |
| trigger term quality | ████░ 4/5 | Natural developer-facing terms like 'Firebase AI Logic', 'Gemini API', 'multimodal inference', and 'structured output' are present, but it lacks common synonyms or variations (e.g., 'Gemini', 'AI chat', 'Vertex AI') that users might say. |
| distinctiveness conflict risk | ████░ 4/5 | It occupies a clear niche (Firebase AI Logic / Gemini API integration) with distinct triggers and minimal conflict risk, though it could overlap slightly with a generic Gemini/Vertex AI skill; not a 5 because the 'web applications' scope understates the full multi-platform coverage. |
Suggestions:
- Add an explicit 'Use when...' clause naming natural triggers, e.g. 'Use when integrating Gemini/Firebase AI Logic into web, Android, iOS, or Flutter apps for setup, multimodal inference, structured output, or chat.'
- Include broader natural synonyms (Gemini, Vertex AI, AI chat) so the description matches how users actually phrase the request.
- Align the stated scope ('web applications') with the body's multi-platform coverage to avoid underselling the skill.
plugins/firebase/agent/skills/firebase-app-hosting-basics/SKILL.md
A well-structured overview that delegates detail to three clearly signaled reference files and gives concrete config and commands. Its main weakness is the deploy workflow, which lists steps but omits any verification or feedback checkpoint.
Validation
⚠️ metadata_version — 'metadata.version' is missing
Full review details
Validation Checks
15/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | Mostly lean and free of basic-concept over-explanation (no definition of SSR, Next.js, etc.), but editorial lines like 'This is the recommended flow for most users' and 'not required to use App Hosting' could be trimmed, so it is efficient rather than maximally lean. |
| actionability | ████░ 4/5 | Provides a copy-paste-ready firebase.json apphosting block and concrete npx -y firebase-tools@latest apphosting:secrets / deploy commands, but the actual apphosting.yaml contents and exact CI/CD commands are deferred to reference files, leaving minor gaps. |
| workflow clarity | ███░░ 3/5 | The deploy-from-source flow is a clear numbered 4-step sequence, but it lacks any validation or verification checkpoint (e.g., confirming the backend is healthy post-deploy), matching the 'steps listed but checkpoints missing' anchor. |
| progressive disclosure | █████ 5/5 | Clear overview body with well-signaled, one-level-deep references to configuration.md, cli_commands.md, and emulation.md (all real bundle files), each linked with context for when to consult it, making navigation easy. |
Suggestions:
- Add an explicit post-deploy verification step to the deploy-from-source workflow (e.g., check backend status with
firebase-tools apphosting:backends:getand confirm the URL serves) to introduce a validation checkpoint. - Inline a minimal apphosting.yaml example (run command, env vars) alongside the firebase.json block so the primary deploy path is fully executable without opening the reference.
- Trim opinionated filler such as 'This is the recommended flow for most users' and 'not required to use App Hosting' to tighten token efficiency.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions — 'deploying Next.js/Angular apps, configuring apphosting.yaml or firebase.json apphosting blocks, managing secrets, setting up GitHub CI/CD, or configuring Blaze billing requirements' — with comprehensive coverage of the skill's surface area. |
| completeness | █████ 5/5 | Explicitly answers both 'what' ('Deploys and manages full-stack web applications ... using Firebase App Hosting') and 'when' with a concrete 'Use when ...' trigger clause, satisfying the top anchor. |
| trigger term quality | ████░ 4/5 | Strong natural keyword coverage (Next.js, Angular, apphosting.yaml, firebase.json, secrets, GitHub CI/CD, Blaze billing) that users would actually say, but a few common variations/synonyms are not enumerated, keeping it just below comprehensive. |
| distinctiveness conflict risk | █████ 5/5 | Clear niche (Firebase App Hosting for SSR full-stack apps) with distinct triggers, and an explicit 'Don't use for classic static web hosting, Auth, Firestore, Crashlytics, or Xcode' boundary that minimizes conflict with adjacent Firebase skills. |
plugins/firebase/agent/skills/firebase-auth-basics/SKILL.md
The body is a well-structured overview with executable provisioning guidance and clear one-level-deep references. Weakest on conciseness due to conceptual explanation Claude already knows, with a minor progressive-disclosure gap from an orphaned reference file.
Validation
⚠️ metadata_version — 'metadata.version' is missing
Full review details
Validation Checks
15/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ███░░ 3/5 | The body is mostly efficient and Firebase-specific, but the Core Concepts section explains things Claude largely already knows ('A user is an entity that can sign in to your app', what ID/refresh tokens are, and a marketing-style opener 'provides backend services, easy-to-use SDKs'), fitting 'mostly efficient but includes some unnecessary explanation'; it is not a 4 because several padded explanatory passages could be trimmed. |
| actionability | ████░ 4/5 | Provides an executable firebase.json config block, a concrete deploy command ('npx -y firebase-tools@latest deploy --only auth'), and numbered Console steps; client SDK code lives in references rather than inline, so it is 'mostly executable guidance with minor gaps' rather than the fully copy-paste-ready 5 anchor. |
| workflow clarity | ████░ 4/5 | A clear three-step sequence (Provisioning -> Client Setup -> Security Rules) with CRITICAL warnings acting as checkpoints for the unauthorized-domain error and the required deploy; it is not a 5 because there is no explicit verify/validate step confirming the deploy succeeded, and not a 3 because the sequence and checkpoints are largely present. |
| progressive disclosure | ████░ 4/5 | SKILL.md is a concise overview pointing to one-level-deep references via clear markdown links (client_sdk_web.md, flutter_setup.md, client_sdk_android.md, security_rules.md), with content appropriately split; it is not a 5 because the bundle's ios_setup.md exists but is never referenced from the body, a minor organization gap matching 'minor organization gaps'. |
Suggestions:
- Trim the Core Concepts section: drop the marketing opener and the definition of what a user/token is, keeping only Firebase-specific property lists and the recommended-default guidance.
- Add a brief verify step after deploy (e.g., confirm providers appear in Console or check
firebase auth:describe) to close the workflow validation gap. - Either reference ios_setup.md from the Client Setup section or remove the orphaned file so all bundle files are discoverable.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | ███░░ 3/5 | Names the domain ('Firebase Authentication') and a few concrete areas ('user sign-in, user management, or secure data access using auth rules'), but the verbs ('setting up and using') are generic rather than enumerating specific actions, matching the anchor that lists domain plus 1-2 concrete actions without comprehensive coverage. |
| completeness | █████ 5/5 | Explicitly answers both what ('Guide for setting up and using Firebase Authentication') and when ('Use this skill when the user's app requires user sign-in, user management, or secure data access using auth rules') with concrete trigger phrases, matching the top anchor; it is not a 4 because the 'when' clause is explicit and specific rather than weakly implied. |
| trigger term quality | ████░ 4/5 | Includes natural trigger phrases a user would say ('user sign-in', 'user management', 'secure data access', 'auth rules') with good coverage, though common synonyms like 'login' or 'authenticate' are missing, fitting the anchor for good keyword coverage with a few natural terms absent. |
| distinctiveness conflict risk | ████░ 4/5 | Firebase Authentication is a clear niche with distinct triggers and minimal conflict risk, but 'secure data access using auth rules' slightly overlaps with sibling Firestore/Storage security-rules skills, fitting 'mostly distinct; minor overlap risk with closely related skills' rather than the fully distinct 5 anchor. |
Suggestions:
- Replace generic verbs 'setting up and using' with concrete actions like 'enabling auth providers, deploying auth config, and integrating sign-in SDKs'.
- Add common synonyms users say such as 'login' or 'authenticate' to broaden trigger coverage.
- Tighten the 'auth rules' trigger to make clear this skill covers auth rules only in the context of Firebase Authentication, reducing overlap with Firestore/Storage skills.
plugins/firebase/agent/skills/firebase-basics/SKILL.md
A well-organized, highly actionable CLI skill body with executable commands and a clear prerequisite workflow. It loses points mainly on conciseness (some redundant npx justification) and on two progressive-disclosure gaps: one broken reference link and one orphaned bundle file.
Validation
⚠️ metadata_version — 'metadata.version' is missing⚠️ relative_links — Relative link issues: 1 missing, 13 deeper-than-1-level⚠️ referenced_paths_exist — Referenced path issues: 2 missing, 26 deeper-than-1-level
Full review details
Validation Checks
13/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ███░░ 3/5 | Mostly efficient and directive, but contains over-explanation Claude doesn't need ('To ensure you always use the latest version of the Firebase CLI, always prepend commands with...') and repeats the npx-prefix guidance across the prerequisites and principles sections; could be tightened. |
| actionability | █████ 5/5 | Fully executable, copy-paste-ready commands throughout — npx -y firebase-tools@latest login --no-localhost, projects:create <project-id> --display-name, apps:sdkconfig ANDROID <APP_ID> --project <PROJECT_ID> — covering the common CLI cases with concrete flags. |
| workflow clarity | ████░ 4/5 | Clear three-step prerequisite sequence (Local Environment Setup → Authentication → Active Project) with an explicit agent pause-and-ask checkpoint and login validation ('command should output the current user'), but project creation lacks a success-verification step. No destructive/batch operations, so no cap applies. |
| progressive disclosure | ████░ 4/5 | Well-structured sections with one-level-deep, clearly signaled references, but references/refresh/claude.md is cited (Principles item 5) yet absent from the bundle, and references/flutter_setup.md exists in the bundle but is never referenced — minor organization gaps against an otherwise clean structure. |
Suggestions:
- Remove the broken
references/refresh/claude.mdlink (Principles item 5) or add the missing file so the Cursor/Claude Code refresh pointer resolves. - Either reference
references/flutter_setup.mdfrom the SDK Setup section (alongside Web/Android/iOS) or remove the orphaned file from the bundle. - Tighten the 'Use npx for CLI commands' principle — drop the explanatory justification ('To ensure you always use the latest version...') since the imperative alone is clear, and avoid restating the npx-prefix rule across multiple sections.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions — 'CLI installation, version checks (firebase-tools@latest --version), CLI login (including --no-localhost), project creation, project selection (firebase use), and app config file downloads (google-services.json, GoogleService-Info.plist)' — with comprehensive coverage and no vague filler. |
| completeness | █████ 5/5 | Explicitly answers both what (CLI setup/login/project creation+selection/config downloads) and when ('Use ONLY for CLI login, project creation/switching, or downloading app config files'), with concrete trigger phrases and an explicit negative-boundary clause. |
| trigger term quality | ████░ 4/5 | Good keyword coverage including natural domain terms and concrete file names (google-services.json, GoogleService-Info.plist, firebase use), but leans on CLI jargon (firebase-tools@latest, --no-localhost) and omits a few common user phrasings like 'set up firebase' or 'switch firebase project'. |
| distinctiveness conflict risk | █████ 5/5 | Clear niche with an explicit exclusion list ('Don't use for Firebase Hosting deploy, Firestore, Auth, App Hosting, Data Connect, Crashlytics, or Remote Config') that minimizes overlap with adjacent Firebase skills. |
plugins/firebase/agent/skills/firebase-crashlytics/SKILL.md
The skill body is a well-structured, lean overview that delegates platform detail to real one-level reference files — strong progressive disclosure and conciseness. Its weak spot is actionability: the body itself contains no executable code or commands, relying entirely on linked references for the concrete steps.
Validation
⚠️ metadata_version — 'metadata.version' is missing
Full review details
Validation Checks
15/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | The body is lean — a short overview, prerequisites, platform links, and a feature bullet list — with only minor padding ('complete guide', 'a number of features to make crash reports more actionable') keeping it off the 5 anchor. |
| actionability | ███░░ 3/5 | It points to concrete reference files (android_setup.md, ios_setup.md) and lists specific SDK features, but the body itself contains no executable code or commands, so guidance is incomplete rather than mostly-executable. |
| workflow clarity | ████░ 4/5 | A clear sequence is present (Prerequisites → SDK Setup → SDK Usage) with no destructive/batch operations that would require validation checkpoints, so the 3-cap for missing validation does not apply; it falls short of 5 only because no explicit checkpoints are shown. |
| progressive disclosure | █████ 5/5 | The body is a concise overview with well-signaled, one-level-deep references to real bundle files (references/android_setup.md and references/ios_setup.md, both present) plus clearly labeled external docs, so content is appropriately split and easy to navigate. |
Suggestions:
- Add a minimal copy-paste-ready code snippet (e.g. the Crashlytics init call or a setCustomKey example) inline in the SDK Usage section so the body is actionable without forcing a file hop.
- Tighten 'The SDK provides a number of features to make crash reports more actionable' to a direct instruction to remove the remaining padding.
- Optionally surface one prerequisite checkpoint (e.g. 'Confirm a Firebase app exists before SDK setup') to make the workflow sequence explicit.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | ███░░ 3/5 | Names the domain (Firebase Crashlytics) and two concrete actions — 'provisioning and SDK usage' — but 'SDK usage' is generic and 'Comprehensive guide' is an over-claim, so it does not reach the several-specific-actions bar of 4. |
| completeness | ████░ 4/5 | Explicitly answers both what ('provisioning and SDK usage') and when ('Use this skill when the user needs help setting up Crashlytics, adding crash reporting...'); the 'what' is slightly generic so it falls short of the fully-concrete 5 anchor. |
| trigger term quality | ████░ 4/5 | Natural trigger phrases a user would say — 'setting up Crashlytics', 'adding crash reporting', 'Crashlytics SDK' — give good coverage; not a 5 because no synonyms or extension-style variants are present. |
| distinctiveness conflict risk | █████ 5/5 | Firebase Crashlytics is a specific named product with distinct triggers ('Crashlytics', 'crash reporting'), giving a clear niche and minimal overlap with other skills. |
Suggestions:
- Replace 'Comprehensive guide for Firebase Crashlytics, including provisioning and SDK usage' with a concrete action list (e.g. 'Provision Crashlytics, install the SDK, and record custom keys, logs, and non-fatal exceptions') to lift specificity and completeness.
- Drop the over-claim 'Comprehensive guide' — name the specific capabilities instead.
- Add a synonym-style trigger such as 'crash reporting' or 'mobile crash analytics' to push trigger-term coverage toward comprehensive.
plugins/firebase/agent/skills/firebase-data-connect/SKILL.md
A well-organized overview with executable commands, clear workflow sequencing, and validation checkpoints. Its main weakness is that every detailed reference file it points to is missing from the bundle, breaking the progressive-disclosure promise.
Validation
⚠️ metadata_version — 'metadata.version' is missing⚠️ relative_links — Relative link issues: 25 missing
Full review details
Validation Checks
14/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | The body is largely lean — concrete commands, a compact project tree, and pointers to references rather than inlined tutorials — with only minor padding (the product-rename NOTE and the wide operation-strategies table) that could be trimmed. |
| actionability | ████░ 4/5 | Provides copy-paste-ready commands (firebase-tools@latest dataconnect:compile, sdk:generate, emulators:start, deploy, init) and a concrete connector.yaml SDK block; detailed syntax is deferred to references, leaving only minor gaps inline. |
| workflow clarity | ████░ 4/5 | Sequenced workflows (define model -> operations -> SDK -> deploy) with an explicit validation checkpoint (dataconnect:compile/sdk:generate to validate), satisfying the database-operation validation requirement, though an explicit 'if errors, fix and re-validate' feedback loop is not stated inline. |
| progressive disclosure | ███░░ 3/5 | The body is well-signaled with one-level-deep 'Read [reference/...]' pointers and a Feature Capability Map for navigation, but none of the referenced bundle files (reference/*.md, examples.md, templates.md) exist in the skill directory, so the disclosure structure is incomplete and navigation would fail at runtime. |
Suggestions:
- Ship the referenced bundle files (reference/schema.md, operations.md, security.md, realtime.md, native_sql.md, sdk_*.md, config.md, examples.md, templates.md) so the signaled navigation actually resolves.
- Add an explicit 'if validation fails, review the error, fix the schema/operations, and re-run dataconnect:compile' feedback loop to the local-build and deploy workflows to lift workflow clarity.
- Tighten the operation-strategies table and fold the product-rename note into a single line to reduce token overhead.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions — 'Builds and deploys... backends with PostgreSQL securely', 'designing schemas with tables and relations', 'writing authorized queries and mutations', 'configuring real-time data updates', 'generating type-safe SDKs' — giving comprehensive coverage of the skill's capabilities. |
| completeness | █████ 5/5 | Explicitly answers both 'what' ('Builds and deploys... backends... securely') and 'when' with two concrete 'Use when...' clauses naming schemas, queries/mutations, real-time updates, SDKs, relational-database need, and product-name mentions. |
| trigger term quality | ████░ 4/5 | Good keyword coverage with product-name synonyms ('SQL Connect', 'Data Connect', 'Firebase SQL Connect', 'Firebase Data Connect', 'relational database with Firebase'), but a few natural terms a user might say (e.g. GraphQL, Cloud SQL) are absent, so it sits just below the comprehensive anchor. |
| distinctiveness conflict risk | █████ 5/5 | Targets a clearly distinct Firebase product with dedicated trigger phrases ('SQL Connect', 'Data Connect'), so it is unlikely to fire for unrelated skills. |
plugins/firebase/agent/skills/firebase-firestore/SKILL.md
A well-structured routing skill body: it enforces edition detection up front, gives executable firebase-tools commands, and cleanly defers detailed guidance to real one-level-deep reference files. Minor gaps are a wordy CRITICAL callout and no explicit post-provisioning verification step.
Validation
⚠️ metadata_version — 'metadata.version' is missing⚠️ relative_links — Relative link issues: 14 deeper-than-1-level⚠️ referenced_paths_exist — Referenced path issues: 14 deeper-than-1-level
Full review details
Validation Checks
13/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | Mostly lean with executable commands and minimal preamble, but the 'Mandatory Reference Reading' CRITICAL callout is somewhat wordy ('to understand specific architectural requirements and pipeline initialization patterns') and could be trimmed, placing it just below the lean anchor. |
| actionability | ████░ 4/5 | Provides concrete, copy-paste-ready commands (firestore:databases:list/get/create, firestore:locations) with clear placeholders, but stops short of showing how to parse edition from the get output, leaving a minor gap. |
| workflow clarity | ████░ 4/5 | Clear two-branch sequence (Instance Found vs No Instance) with explicit gates (edition detection, user choice of database/location), but lacks a post-create verification step, so it is just below the explicit-feedback-loop anchor. |
| progressive disclosure | █████ 5/5 | The body is a concise overview that routes by edition to one-level-deep reference files via clear markdown links; all referenced paths (standard/ and enterprise/ bundles) exist as real files, matching the well-signaled navigation anchor. |
Suggestions:
- Tighten the Enterprise 'Mandatory Reference Reading' callout to drop explanatory padding like 'to understand specific architectural requirements and pipeline initialization patterns'.
- Add a verification checkpoint after firestore:databases:create (e.g., re-run databases:get to confirm the edition/location) to close the workflow_clarity feedback loop.
- Show how to read the edition field from the databases:get output so the routing branch is fully executable without inference.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions ('Sets up, manages, queries, and configures') plus comprehensive coverage of sub-capabilities ('data modeling, security rules, indexes, and SDK integrations (Web, Python, iOS, Android, Flutter)'), matching the comprehensive-coverage anchor. |
| completeness | █████ 5/5 | Explicitly answers both what ('Sets up, manages, queries, and configures Cloud Firestore databases...') and when ('Use when creating/listing Firestore databases, defining data models/indexes, writing SDK queries...') with concrete trigger phrases, matching the top anchor. |
| trigger term quality | ████░ 4/5 | Good natural-term coverage ('creating/listing Firestore databases, defining data models/indexes, writing SDK queries, integrating Firestore SDKs') but misses common synonyms users might say like 'NoSQL', 'collections', or 'documents', so it sits just below the comprehensive anchor. |
| distinctiveness conflict risk | █████ 5/5 | Clear Firestore niche with explicit negative boundary guidance ('Don't use for Firebase Hosting, Data Connect, Auth, Storage/GCS, Crashlytics, Functions, or BigQuery'), minimizing conflict with adjacent Firebase skills. |
plugins/firebase/agent/skills/firebase-hosting-basics/SKILL.md
The body follows an excellent progressive-disclosure structure with verified reference files, but its overview is padded with marketing-style feature bullets Claude doesn't need, and it offers only one inline executable command with no deployment workflow checkpoints.
Validation
⚠️ metadata_version — 'metadata.version' is missing
Full review details
Validation Checks
15/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ███░░ 3/5 | The Instructions section is lean, but the Overview paragraph and 'Key Features' bullets restate concepts Claude already knows (CDN caching, built-in SSL, GitHub integration) and could be trimmed. |
| actionability | ███░░ 3/5 | The emulation step gives a copy-paste command, but the two primary tasks (configure firebase.json, deploy) are pointer-only in the body ('see references/...'), so the body alone is not fully executable. |
| workflow clarity | ███░░ 3/5 | The numbered Configuration/Deploying/Emulation sections are topic groupings rather than a sequenced workflow, and there are no validation checkpoints (e.g., deploy to a preview channel, verify, then promote to live). |
| progressive disclosure | █████ 5/5 | Clean overview body with well-signaled, one-level-deep markdown links to the real files references/configuration.md and references/deploying.md; detail is appropriately externalized and navigation is easy. |
Suggestions:
- Trim the Overview paragraph and 'Key Features' bullets to feature names only (or remove them) — Claude already knows what a CDN and built-in SSL are.
- Add a brief deploy workflow with a validation checkpoint, e.g. deploy to a preview channel first, verify the URL, then promote to the live channel.
- Inline a minimal concrete snippet for the two primary tasks (e.g. a one-line firebase.json hosting skeleton and the
firebase deploy --only hostingcommand) so the body is actionable without opening the references.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions — deploys, configures, sets up custom domains, configures firebase.json (redirects, rewrites, headers, multi-site), and manages preview channels — giving comprehensive coverage rather than vague language. |
| completeness | █████ 5/5 | Explicitly answers both what ('Deploys and configures classic Firebase Hosting...') and when ('Use when deploying static sites/SPAs, setting up custom domains, configuring firebase.json...'), plus a negative boundary ('Don't use for Firebase App Hosting (Next.js/SSR)...'). |
| trigger term quality | █████ 5/5 | Covers natural terms users would say ('static websites', 'single-page apps (SPAs)', 'custom domains', 'firebase.json', 'redirects, rewrites, headers', 'multi-site', 'preview channels') including synonyms like SPAs/single-page apps and static sites/static websites. |
| distinctiveness conflict risk | █████ 5/5 | Targets a clear Firebase Hosting niche and explicitly excludes App Hosting, Auth, Firestore, Data Connect, and Crashlytics, minimizing conflict risk with adjacent skills. |
plugins/firebase/agent/skills/firebase-remote-config-basics/SKILL.md
The body is well-structured with executable CLI commands, real reference links, and a mandatory user-review checkpoint before deployment. Its main weakness is a verbatim-duplicated section and some filler text that hurt token efficiency.
Validation
⚠️ metadata_version — 'metadata.version' is missing
Full review details
Validation Checks
15/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ███░░ 3/5 | Mostly efficient, but the '### Template Management via CLI' heading and its two-line intro are duplicated verbatim, and filler lines like 'The SDK provides a number of features...' pad the body. |
| actionability | ████░ 4/5 | Provides copy-paste-ready CLI commands (remoteconfig:get, deploy --only remoteconfig, remoteconfig:versions:list) and a config-mapping JSON snippet, but the 'Autonomous Editing & Discovery' step stays high-level rather than giving concrete edits. |
| workflow clarity | ████░ 4/5 | Clear get→edit→review→deploy→verify sequence with an explicit 'MANDATORY: User Review and Verification' checkpoint, though the duplicated header and a loosely-defined config-mapping step introduce minor gaps. |
| progressive disclosure | ████░ 4/5 | SDK setup is split into one-level-deep, clearly linked reference files (references/android_setup.md, references/ios_setup.md) that exist on disk, with the body serving as an overview; minor organization issues remain. |
Suggestions:
- Remove the duplicated '### Template Management via CLI' heading and its repeated two-line intro (the section appears twice verbatim).
- Delete filler sentences such as 'The SDK provides a number of features to make your application dynamic and responsive to user segments.' that add no actionable guidance.
- Make the 'Autonomous Editing & Discovery' step concrete with a short example of editing the conditions/parameters JSON instead of leaving it as high-level direction.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions—managing templates, feature flags, loading strategies, SDKs, downloading/deploying JSON, version history, in-app defaults, fetchAndActivate(), real-time listeners—yielding comprehensive coverage. |
| completeness | █████ 5/5 | Explicitly answers both 'what' (Manages Firebase Remote Config templates, feature flags...) and 'when' (Use when downloading/deploying...) with concrete trigger phrases. |
| trigger term quality | █████ 5/5 | Includes natural user-facing terms (Remote Config, feature flags, remoteconfig JSON templates, version history) plus the actual SDK method fetchAndActivate(), giving broad keyword coverage. |
| distinctiveness conflict risk | █████ 5/5 | Occupies a clear Remote Config niche and lists explicit 'Don't use for' exclusions for sibling Firebase products, minimizing wrong-skill triggering. |
plugins/firebase/agent/skills/firebase-security-rules-auditor/SKILL.md
The content is a well-structured, actionable red-team audit rubric with a concrete checklist, scoring scale, and output format. Its main gap is the absence of an explicit validation/review checkpoint in the workflow before findings are reported.
Validation
⚠️ metadata_version — 'metadata.version' is missing
Full review details
Validation Checks
15/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | The body is lean and purposeful — it does not explain what Firebase or security rules are — though a few checklist items (e.g., item 3's collaboration-app aside) could be trimmed slightly. |
| actionability | ████░ 4/5 | Concrete, specific audit checks ('Compare create and update rules', 'check request.resource.data for role/isAdmin/ownerId', 'look for string length or array size limits') plus a fully specified JSON output schema give mostly executable guidance for an instruction-only skill. |
| workflow clarity | ███░░ 3/5 | A clear sequence exists (adopt persona → run the six-item mandatory checklist → apply the 1–5 scoring rubric → emit JSON), but there is no explicit validation/verification checkpoint to re-check findings or confirm severity before output, leaving checkpoints implicit. |
| progressive disclosure | ████░ 4/5 | No bundle files exist and none are needed; content is organized into well-labeled sections (Overview, Scoring Criteria, Audit Checklist, Admin Bootstrapping, Scoring, Output format) with no deep nesting, though the dense audit-checklist block could optionally live in a reference file. |
Suggestions:
- Add an explicit validation step to the workflow, e.g. 'Before emitting JSON, re-verify each finding against the original rules and confirm its severity against the 1–5 scale,' to introduce a feedback checkpoint.
- Tighten checklist item 3 (Business Logic vs. Rules) by replacing the collaboration-app aside with a one-line concrete check, reducing incidental verbosity.
- Consider extracting the detailed Mandatory Audit Checklist into a references/ file (e.g. CHECKLIST.md) and keeping SKILL.md as an overview, to improve progressive disclosure if the skill grows.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete audit actions — 'vulnerabilities, privilege escalation, role bypasses, create vs update inconsistencies, resource exhaustion, type safety, size limits, and hasOnly ownership checks' — giving comprehensive coverage of what the skill does. |
| completeness | █████ 5/5 | Explicitly states both what it does (audits Firebase security rules for a named list of issues) and when to use it ('Use when auditing/reviewing rules, running red-team rule assessments, or scoring against auditor checklists'), plus a concrete negative boundary. |
| trigger term quality | ████░ 4/5 | Includes natural phrases a user would say ('auditing/reviewing rules', 'running red-team rule assessments', 'scoring against auditor checklists') plus domain terms (Firestore, Cloud Storage), but a few natural synonyms are missing so it is just below comprehensive. |
| distinctiveness conflict risk | █████ 5/5 | A clear niche (Firebase Firestore/Storage security-rules auditing) with an explicit 'Don't use for Firebase CLI (login, deploy), Auth, Crashlytics, Remote Config, or database queries' boundary, minimizing conflict with adjacent skills. |
plugins/firebase/agent/skills/firestore-rules-creation/SKILL.md
The body is highly actionable and built around an excellent validated workflow, but it is excessively verbose and monolithic — large reference-grade material (helper functions, attack checklist) is inlined rather than split into bundle files.
Validation
⚠️ skill_md_line_count — SKILL.md is long (588 lines); consider splitting into references/ and linking⚠️ metadata_version — 'metadata.version' is missing
Full review details
Validation Checks
14/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ██░░░ 2/5 | The ~570-line body is noticeably verbose: a ~140-line inlined helper-function dump, pervasive repeated 'CRITICAL'/'MUST'/'NEVER' emphasis, and a 20-item attack checklist that could be condensed. Several padded sections could be trimmed without losing guidance. |
| actionability | ████░ 4/5 | Provides concrete, mostly executable code — helper functions, bad/good RBAC examples, isValidCounterUpdate with getAfter(), and validStatusTransition() — covering the common cases with only minor gaps. |
| workflow clarity | █████ 5/5 | A clear Phase-1→Phase-4 sequence with explicit validation checkpoints and feedback loops ('Repeat Phase-3 until no attacks succeed', syntactic validation in Phase-4), exactly what destructive/security work requires. |
| progressive disclosure | ██░░░ 2/5 | No bundle files exist and the body is a monolithic wall; content that clearly belongs in separate reference files (the helper-function dump, the attack checklist) is fully inlined with no signaled references. |
Suggestions:
- Move the ~140-line helper-function catalog and the 20-item devil's-advocate attack checklist into reference files under ./references/ and link to them from SKILL.md to cut the body drastically.
- Trim repeated emphasis ('CRITICAL'/'MUST'/'NEVER' used many times over) — state each directive once and trust the workflow to enforce it.
- Consolidate overlapping guidance: the 'Validate data' principles, 'Critical Directives', and 'Advanced Validation' sections restate similar requirements and could be unified.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions ('Designs, authors, refactors, and hardens') plus specific capabilities like 'writing schema/domain validators', 'preventing update bypasses', 'enforcing type safety and resource limits', and 'role-based access control' — comprehensive coverage of the skill's actions. |
| completeness | █████ 5/5 | Explicitly answers both 'what' (designs/authors/refactors/hardens Cloud Firestore Security Rules) and 'when' (explicit 'Use when…' with concrete trigger phrases), and adds negative triggers ('Don't use for…') for disambiguation. |
| trigger term quality | ████░ 4/5 | Includes natural phrases users would say ('creating security rules', 'role-based access control', 'firestore.rules') with good coverage, but a few common natural synonyms like 'firebase security rules' or 'secure my firestore database' are missing. |
| distinctiveness conflict risk | █████ 5/5 | Clear niche (Cloud Firestore Security Rules) with explicit disambiguation from the sibling auditor skill ('Don't use for security rules auditing (use firebase-security-rules-auditor)'), minimizing wrong-skill trigger risk. |
plugins/firebase/agent/skills/xcode-project-setup/SKILL.md
The body is highly actionable with concrete executable examples and a real bundled script, but is held back by some verbosity explaining known concepts and a missing post-run validation checkpoint for the destructive .pbxproj modification.
Validation
⚠️ metadata_version — 'metadata.version' is missing
Full review details
Validation Checks
15/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ███░░ 3/5 | Mostly efficient with clear sections and executable commands, but includes unnecessary backstory Claude already knows (the Firebase -ObjC linker-stripping explanation, "Always Use Latest SDK Version" rationale), placing it at 3 rather than 4. |
| actionability | █████ 5/5 | Provides a concrete swift run signature plus two copy-paste-ready examples (Alamofire and Firebase) with real URLs and versions, fully covering the common cases per the 5 anchor. |
| workflow clarity | ███░░ 3/5 | Sequence and toolchain/empty-directory checkpoints are present, but a destructive .pbxproj-modifying workflow lacks a post-run validation/build feedback loop to confirm successful linking; the missing-validation cap holds this at 3. |
| progressive disclosure | ████░ 4/5 | Heavy logic is appropriately offloaded to the bundled scripts/xcode_spm_setup Swift package (verified present), with a clear single-level reference and well-organized sections; not a 5 because some inlined Firebase/version detail could live in a dedicated reference. |
Suggestions:
- Add a post-run verification step (e.g.,
xcodebuild -listor a build) to confirm the package linked successfully, giving the destructive .pbxproj workflow a proper feedback loop. - Trim the Firebase -ObjC linker-stripping backstory and the "Always Use Latest SDK Version" rationale to a one-line directive; Claude already understands linker behavior and version hygiene.
- Move the Firebase
-ObjC/OTHER_LDFLAGSdetails into a short dedicated reference file (e.g.,references/firebase.md) and link to it from the body to tighten progressive disclosure.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | ████░ 4/5 | Lists several concrete actions ("modifies Xcode projects (.pbxproj)", "add Swift Packages", "link files") but the action set is a touch short of comprehensive coverage, fitting the 4 anchor better than 5. |
| completeness | █████ 5/5 | Explicitly states what it does (modifies Xcode projects to add SPM packages and link files) and when to use it ("Use this skill whenever an iOS project needs dependencies installed"), matching the 5 anchor. |
| trigger term quality | ████░ 4/5 | Strong natural coverage with "iOS project", "dependencies installed", "Swift Packages", ".pbxproj", "Firebase", "Alamofire"; a few synonyms (SPM, Cocoa) are missing, so it sits at 4 rather than 5. |
| distinctiveness conflict risk | █████ 5/5 | Occupies a clear niche (Xcode .pbxproj + SPM dependency installation) with specific triggers and minimal overlap risk with other skills. |
plugins/mastra/.agents/skills/mastra/SKILL.md
A well-architected overview skill that excels at progressive disclosure — a clean routing table to verified, one-level-deep references — with concrete commands and clear sequenced workflows. The main weakness is repetition of the anti-memory/verify-first message and the absence of an explicit validate→retry feedback loop in the workflows.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | The body is mostly efficient — a compact reference table, short sections, and concrete commands — but the "do not trust internal knowledge / verify against current docs" message is restated across the Critical section, Priority order, When-you-see-errors, and Development workflow sections; consolidating those would trim noticeable repetition. |
| actionability | ████░ 4/5 | Concrete, runnable cues are present (ls node_modules/@mastra/, npm run dev, http://localhost:4111, scripts/provider-registry.mjs, mastra api ...) with a question→file routing table, but the body is primarily a router that delegates executable detail to the reference files rather than embedding copy-paste examples. |
| workflow clarity | ████░ 4/5 | Sequenced workflows are clear (numbered "Priority order for writing code" and "Development workflow") with checkpoints like checking installed packages first and running the provider registry before model use, but no explicit validate→fix→retry feedback loop is present, which keeps it just below a 5. |
| progressive disclosure | █████ 5/5 | A clear overview maps each user question to a one-level-deep reference via a well-signaled table; all 10 referenced files and the provider-registry.mjs script exist in the bundle, content is appropriately split, and navigation is easy. |
Suggestions:
- Consolidate the repeated "don't trust internal memory / verify against current docs" message into a single Critical section and reference it once elsewhere instead of restating it across Priority order, When-you-see-errors, and Development workflow.
- Add one explicit validate→fix→retry feedback loop (e.g., after running
mastra apior after writing code: verify against embedded docs, on type-mismatch re-check current API, then retry) to lift workflow_clarity toward 5. - Embed one or two short copy-paste snippets inline (e.g., a minimal
new Agent({...})/new Workflow({...})skeleton from the embedded docs) so the body is actionable on its own before delegating to references.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions — "building agents, workflows, tools, memory, workspaces, and storage", plus "documentation lookup, API verification, TypeScript setup, common errors, migrations" and CLI "inspect or call resources" — giving comprehensive coverage of the skill's capabilities. |
| completeness | █████ 5/5 | Explicitly answers both "what" ("Comprehensive Mastra framework guide for building...") and "when" ("Use for documentation lookup, API verification, TypeScript setup, common errors, migrations, and mastra api CLI tasks") with concrete trigger phrases. |
| trigger term quality | ████░ 4/5 | Good natural keywords users would say ("documentation lookup", "common errors", "migrations", "API verification", "mastra api CLI"), but coverage leans slightly product-jargon-heavy ("Trace Intelligence") and omits some common synonyms; not quite the comprehensive synonym/extension set of a 5. |
| distinctiveness conflict risk | █████ 5/5 | A clear niche — the named "Mastra framework" with product-specific "mastra api CLI" triggers — makes it highly distinguishable with minimal risk of triggering for an unrelated skill. |
plugins/mastra/agent/skills/mastra/SKILL.md
The content is well-structured and mostly actionable, with excellent progressive disclosure via a question-to-reference routing table and concrete verification commands. The main weakness is mild over-explanation in a few framing sections and deferral of executable code examples to reference files rather than showing representative inline snippets.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | Largely lean with imperative, short sections and a routing table, but a few lines pad concepts Claude already knows ('Everything you know about Mastra is likely outdated or wrong', 'Studio is the interactive UI for building, testing, and managing...') that could be trimmed. |
| actionability | ████░ 4/5 | Provides concrete commands ('ls node_modules/@mastra/', 'npm run dev', 'http://localhost:4111', run 'scripts/provider-registry.mjs') and a per-question routing table, but most actual agent/workflow construction guidance is deferred to reference files rather than given as inline executable code. |
| workflow clarity | ████░ 4/5 | The 'Priority order for writing code' and 'Development workflow' are clearly numbered with explicit installed/not-installed branches and verification nudges ('Always run this before using a model', 'confirm that the installed CLI exposes the command'), though detailed error-recovery feedback loops live in the references rather than inline. |
| progressive disclosure | █████ 5/5 | The body is a concise overview with a well-signaled routing table mapping user questions to one-level-deep reference files (all verified present) plus a scripts entry, making navigation easy and keeping bulk detail out of SKILL.md. |
Suggestions:
- Tighten the framing sections: 'Critical: Do not trust internal knowledge' and the Mastra Studio definition restate concepts Claude already knows and could be condensed to one line each.
- Add one small inline executable example (e.g. a minimal Agent or Workflow constructor) so the body demonstrates the API shape before pointing to references, rather than routing all code to reference files.
- Make the verification feedback loop explicit in the Development workflow (e.g. 'if embedded docs contradict your draft, rewrite from the docs') so error recovery is visible without reading a reference.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions — 'building agents, workflows, tools, memory, workspaces, and storage', 'documentation lookup, API verification, TypeScript setup, common errors, migrations', and 'mastra api CLI tasks: inspect or call resources' — giving comprehensive coverage rather than a single generic action. |
| completeness | █████ 5/5 | Explicitly answers both 'what' ('Comprehensive Mastra framework guide for building...') and 'when' via a clear 'Use for...' clause enumerating concrete trigger scenarios. |
| trigger term quality | ████░ 4/5 | Good natural keywords ('documentation lookup', 'API verification', 'TypeScript setup', 'common errors', 'migrations', 'mastra api CLI') but most are phrased as task categories rather than the exact casual phrases a user would say, and a few synonyms are missing. |
| distinctiveness conflict risk | █████ 5/5 | Tightly bound to Mastra-specific triggers ('mastra api CLI', 'Mastra platform', 'Trace Intelligence'), giving it a clear niche with minimal overlap risk against other skills. |
plugins/orpc/.agents/skills/orpc-migrate/SKILL.md
A lean, executable migration playbook with concrete code, ordered steps, explicit validation checkpoints, and clean delegation of detail to authoritative docs pages. It assumes Claude's competence throughout and surfaces the non-obvious v2 breaking changes that pretrained knowledge gets wrong.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | █████ 5/5 | Dense and information-rich with no padding or explanation of concepts Claude already knows; every line carries non-obvious v2 migration specifics (package renames, breaking changes, silent behavior shifts) that earn their tokens. |
| actionability | █████ 5/5 | Provides copy-paste-ready code (toORPCRouter, os.$context, RPCHandler, createORPCClient, RPCLink) and concrete commands (npm install @orpc/server@beta, npm view @orpc/server dist-tags) covering the common migration cases. |
| workflow clarity | █████ 5/5 | Both migrations are laid out as ordered, numbered steps with explicit validation checkpoints ('typecheck and unit tests after steps 1, 2, and 4; step 3 needs integration or e2e tests'), failure-isolation logic, and a final grep sweep. |
| progressive disclosure | █████ 5/5 | Well-sectioned overview that deliberately omits full mapping tables and delegates them to clearly signaled, one-level-deep docs URLs; no nested references and the body stays navigable. |
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Names both migration paths and their concrete mechanics (incremental wrapping via @orpc/trpc, full rewrite with concept mapping, package renames, breaking changes, safe order of operations), giving comprehensive coverage of specific actions. |
| completeness | █████ 5/5 | Explicitly states what the skill does (two migration paths with their sub-techniques) and gives a concrete 'Use when...' clause enumerating trigger scenarios, plus a negative boundary. |
| trigger term quality | █████ 5/5 | Lists natural user phrases across synonyms — migrate, convert/wrap, upgrade, fix breaking changes, swap @trpc/* for @orpc/* — matching how a user would actually request this skill. |
| distinctiveness conflict risk | █████ 5/5 | Occupies a clear niche (oRPC migration) and explicitly disambiguates from the sibling orpc skill via 'Not for greenfield oRPC work... use the orpc skill', minimizing wrong-skill triggering. |
plugins/orpc/agent/skills/orpc-contract/SKILL.md
The body is a lean, highly actionable contract-first oRPC guide with executable examples for every phase and clear section-level sequencing. It could improve workflow clarity with explicit validation/checkpoint steps and could offload the heavier OpenAPI-generation and client-factory material into reference files.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | █████ 5/5 | Lean and dense throughout — it assumes Claude's competence, never explains what oRPC or schemas are, and every line (e.g. 'A contract has no .handler', 'Repeated .input/.output calls stack schemas instead of replacing them') delivers a non-obvious, high-value fact. |
| actionability | █████ 5/5 | Fully executable, copy-paste-ready code blocks for every phase — defining with oc, implementing with implement, RPC and OpenAPI clients, minifying/shipping the contract, the npm SDK factory, and the Hey API openapi-ts config — covering the common cases concretely. |
| workflow clarity | ████░ 4/5 | The body is sequenced as a clear multi-step process (define → implement → consume → ship → generate) with one section per phase and inline guidance, but it lacks explicit validation checkpoints or feedback loops; this is not a destructive/batch skill so the 3-cap does not apply, yet a checkpoint is still missing for a 5. |
| progressive disclosure | ████░ 4/5 | No bundle files exist (references/, scripts/, assets/ are absent), but the body is well-organized into one-section-per-phase with clearly signaled one-level-deep pointers to external docs pages and to the orpc / orpc-openapi skills for adjacent detail; organization is strong though it could split the OpenAPI-generation and client-factory sections into reference files. |
Suggestions:
- Add an explicit validation/checkpoint step in the implement or consume workflow (e.g. type-check that the implementer mirrors the contract, or verify the client type resolves) to raise workflow_clarity.
- Consider moving the 'Generate the contract from an existing OpenAPI spec' Hey API config and the per-procedure client-factory material into a references/ file, keeping the body as an overview, to strengthen progressive_disclosure now that no bundle files exist.
- Add a short 'Verify' note after the ship/publish step (e.g. check that dist types resolve and the published client is typed) to give the publish workflow a feedback loop.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions — 'defining the API shape with oc', 'implementing it with implement', 'consuming the contract from typesafe clients', 'generating a contract from an existing OpenAPI spec', 'publishing a typed API client to npm' — giving comprehensive, specific coverage of the skill's capabilities. |
| completeness | █████ 5/5 | Clearly answers both 'what' ('Design oRPC v2 APIs contract-first...') and 'when' via an explicit 'Use when...' clause listing concrete trigger phrases; the explicit trigger guidance prevents the cap at 3. |
| trigger term quality | █████ 5/5 | Natural, comprehensive trigger phrases a user would actually say — 'depends on @orpc/contract', 'defining a contract with oc', 'implementing a contract with implement', 'sharing an API contract between server and client packages', 'generating a contract from an existing OpenAPI spec', 'publishing a typed API client to npm' — including the package name and key API names as synonyms. |
| distinctiveness conflict risk | █████ 5/5 | Carves a clear niche (contract-first oRPC v2) and explicitly disambiguates from sibling skills — 'For core builder, serving, and client work without a contract, use the orpc skill; for REST/OpenAPI exposure... use the orpc-openapi skill' — minimizing conflict risk. |
plugins/orpc/agent/skills/orpc-migrate/SKILL.md
A tight, actionable migration playbook with sequenced steps, executable code, and explicit validation checkpoints for a risky batch operation. Its only real weakness is inline time-sensitive version guidance that a dedicated 'current status' or 'deprecated' section would isolate better.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | The body is dense and assumes Claude's competence (no 'what is oRPC' preamble), but carries time-sensitive version info inline — 'v2 currently ships under the beta npm dist-tag', the @beta install suffix — outside any 'deprecated/old patterns' section, which the rubric penalizes for conciseness. |
| actionability | █████ 5/5 | Copy-paste-ready code blocks for every step (toORPCRouter, os.$context, RPCHandler, RPCLink/createORPCClient, tanstack-query utils) plus specific commands (npm install @orpc/server@beta, npm view @orpc/server dist-tags, grep for old package names) cover the common cases fully. |
| workflow clarity | █████ 5/5 | Both migrations are explicitly ordered with per-step validation — 'verifying after each', 'typecheck and unit tests after steps 1, 2, and 4; step 3 needs integration or e2e tests', and a closing grep sweep — giving clear checkpoints and feedback loops for a batch/destructive codebase operation. |
| progressive disclosure | ████░ 4/5 | Well-organized into clear sections (tRPC→oRPC incremental vs. full rewrite, v1→v2, docs retrieval) with deliberately externalized mapping tables pointed to one-level-deep docs URLs, but the skill is a single monolithic file with no bundle files to split detail into, leaving minor organization headroom. |
Suggestions:
- Move the beta-dist-tag and 'plain installs get v1' status note into a short, clearly labeled 'Current status / version' or 'Deprecated' section so the time-sensitive fact is isolated from the evergreen migration steps.
- Consider extracting the v1→v2 package-rename table and the deprecated-alias cheat-sheet reference into a bundled reference file (e.g. references/v1-v2-aliases.md) so the body stays a lean overview and the volatile mapping detail is one level deep and reloadable.
- Add a one-line explicit 'verify' checkpoint after the v1→v2 package-rename step (step 1) noting that remaining typecheck errors are the hard breaks to tackle next, mirroring the validation pattern used in the tRPC path.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions — 'Migrate existing codebases', 'incremental wrapping via the @orpc/trpc integration', 'full rewrite with the concept mapping', 'package renames', 'fix oRPC v2 breaking changes', 'swap @trpc/* packages for @orpc/* equivalents' — giving comprehensive coverage of the skill's capabilities. |
| completeness | █████ 5/5 | Explicitly answers both what (migrate codebases across tRPC→oRPC and v1→v2 paths) and when (a concrete 'Use when...' trigger list), plus a clear negative boundary ('Not for greenfield oRPC work...'). |
| trigger term quality | █████ 5/5 | The 'Use when asked to migrate from tRPC to oRPC, convert or wrap a tRPC router, upgrade oRPC v1 to v2, fix oRPC v2 breaking changes, or swap @trpc/* packages for @orpc/* equivalents' clause gives comprehensive natural trigger phrases including version numbers and package-name patterns users would actually say. |
| distinctiveness conflict risk | █████ 5/5 | Occupies a clear niche (oRPC migration) and explicitly disambiguates from the sibling orpc skill via the 'Not for greenfield oRPC work... use the orpc skill' boundary, minimizing wrong-skill triggering. |
plugins/orpc/agent/skills/orpc-openapi/SKILL.md
A well-organized, executable reference for the OpenAPI side of oRPC v2, with copy-paste code and an explicit verification step. It is mostly lean, though some explanatory prose could be tightened.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | Dense and efficient, assuming Claude knows OpenAPI basics and explaining only oRPC v2-specifics, but the body carries a fair amount of explanatory prose that could be trimmed slightly in places. |
| actionability | █████ 5/5 | Multiple complete, copy-paste-ready TypeScript blocks with real imports and concrete values cover routing, serving, calling, and spec generation across the common cases. |
| workflow clarity | ████░ 4/5 | Each task is clearly sequenced with an explicit verification checkpoint ('Verify the wiring before declaring success: request /spec.json... and confirm the method, path, and status'), but there is no fix-and-retry feedback loop to reach a 5. |
| progressive disclosure | █████ 5/5 | No bundle files are needed; the body is organized into well-signaled ## sections and cleanly defers out-of-scope topics to sibling skills and the external docs index, all one level deep. |
Suggestions:
- Tighten the Input/output mapping and Serving prose where it restates behavior already shown in the code, to lift conciseness toward a 5.
- Add a short fix-and-retry feedback loop after the verification step (e.g., if /spec.json or the routed endpoint mismatches, re-check openapi() metadata and try again) to strengthen workflow clarity.
- Consider moving the bracket-notation decoding rules and the paramsStyles/queryStyles enumeration into a reference file, keeping SKILL.md as an overview, to further sharpen progressive disclosure.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions — exposing a router as an OpenAPI HTTP API, defining REST routes via openapi()/.route, serving with OpenAPIHandler, Smart Coercion, OpenAPILink, OpenAPIGenerator, and Scalar/Swagger docs — for comprehensive coverage. |
| completeness | █████ 5/5 | Explicitly answers both 'what' (first sentence) and 'when' (a detailed 'Use when...' clause with concrete triggers), and adds when-not-to-use disambiguation toward sibling skills. |
| trigger term quality | █████ 5/5 | Comprehensive coverage of the exact names developers would say (@orpc/openapi, OpenAPIHandler, RPCHandler, OpenAPILink, OpenAPIGenerator, Smart Coercion, Scalar/Swagger) plus synonyms across OpenAPI 3.2/3.1/3.0. |
| distinctiveness conflict risk | █████ 5/5 | Clear niche with explicit redirection to the orpc-contract and orpc skills for adjacent work, minimizing the chance of triggering for the wrong skill. |
plugins/orpc/agent/skills/orpc/SKILL.md
The body is a high-quality, code-first reference that assumes competence and gives executable guidance across every core oRPC v2 task, with version-gating and typecheck checkpoints. The main weakness is token weight: a full inlined doc-map and lengthy link lists could be split into a reference file, nudging conciseness and progressive disclosure down slightly.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | The body is dense and assumes Claude's competence — it never explains what TypeScript, an API, or a schema is, and every section leads with executable code — but the inlined full doc-map enumeration (lines 240-248) and the long 'Beyond the basics' link list add length beyond strict necessity, keeping it just below anchor 5. Not a 3 because there is no padded over-explanation of known concepts. |
| actionability | █████ 5/5 | Provides fully executable, copy-paste-ready TypeScript for procedures, routers, middleware, errors, RPCHandler on both fetch and node adapters, server- and client-side calls, and the safe client, plus concrete npm commands ('npm ls @orpc/server', 'npm install @orpc/server@beta', 'npm view @orpc/server dist-tags'), covering the common cases per anchor 5. |
| workflow clarity | ████░ 4/5 | Sections sequence logically (define → assemble → middleware/context → errors → serve → call → beyond basics) with explicit checkpoints — 'Check what is installed before writing code' version gating and 'run the project's typecheck before declaring success' as the correctness signal — but it reads as a structured reference rather than a stepwise workflow with feedback loops, so it sits at anchor 4 rather than 5; no destructive/batch cap applies. |
| progressive disclosure | ████░ 4/5 | No bundle files exist (references/scripts/assets directories absent), so structure is judged on the single file plus its external pointers: clear section headers and well-signaled one-level-deep outward references (llms.txt, per-page .md URLs, sibling skills). It is not a 5 because the 230-line single file inlines a full docs-site map and plugin/integration lists that a bundle file could hold, a minor organization gap per anchor 4. |
Suggestions:
- Move the full docs-path enumeration (lines 240-248) and possibly the 'Beyond the basics' link catalog into a references/ file (e.g. DOCS.md), keeping only the llms.txt retrieval mechanics inline; this would lift both conciseness and progressive_disclosure toward 5.
- Add a one-line orientation at the top stating the recommended read order for a brand-new oRPC task (e.g. 'define → assemble → serve → call'), turning the implicit section order into an explicit workflow and pushing workflow_clarity toward 5.
- If a destructive/batch operation pattern is common (e.g. bulk procedure registration or router refactors), add an explicit validate→fix→retry loop note so workflow_clarity is not capped for those cases.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Names multiple concrete actions — 'defining procedures with the os builder (.input/.output/.handler)', 'assembling routers, middleware and context', 'serving via RPCHandler', 'calling from server-side clients (call, createRouterClient) or client-side clients (createORPCClient with RPCLink)', 'streaming over SSE' — giving comprehensive coverage of the framework's capabilities, matching the anchor 5 example. |
| completeness | █████ 5/5 | Explicitly answers both: what ('Build, serve, and call end-to-end typesafe APIs with oRPC v2' plus an enumerated action list) and when ('Use for any task in a project that depends on @orpc/* packages, even a one-procedure change' plus concrete trigger phrases), matching anchor 5 exactly; not a 4 because the 'when' is fully explicit with concrete triggers rather than improvable. |
| trigger term quality | █████ 5/5 | Covers natural terms a user of the framework would actually say — 'oRPC v2', '@orpc/* packages', 'RPCHandler', 'RPCLink', 'TanStack Query', 'SSE', 'ORPCError' — including the package-name synonym and concrete builder/API identifiers, matching comprehensive anchor 5 coverage. |
| distinctiveness conflict risk | █████ 5/5 | The '@orpc/*' / 'oRPC v2' niche is narrow and it explicitly disambiguates from siblings ('For REST/OpenAPI exposure, prefer the orpc-openapi skill; for contract-first design, the orpc-contract skill; for tRPC or oRPC v1 migrations, the orpc-migrate skill'), giving minimal conflict risk per anchor 5. |
plugins/portless/.agents/skills/portless/SKILL.md
A highly actionable, well-structured manual with strong copy-paste examples and a thorough CLI reference, but it carries redundancy (repeated framework-injection rules, motivational padding) and keeps all reference material in one large file rather than progressively disclosing it. System-level workflows also lack explicit validation checkpoints.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ███░░ 3/5 | The content is mostly efficient reference material, but the 'Why portless' motivational bullets restate concepts Claude already knows and the framework PORT-injection rules are explained twice (How It Works and Troubleshooting) with heavy overlap, so it could be tightened. |
| actionability | █████ 5/5 | Abundant copy-paste-ready bash, JSON, and TypeScript examples plus a comprehensive CLI reference table give fully executable guidance covering the common cases. |
| workflow clarity | ███░░ 3/5 | Quick Start is clearly sequenced and 'portless doctor' offers a diagnostic, but system-level operations (OS service install, /etc/hosts modification, trust-store changes) lack explicit validate→proceed feedback loops, capping the score. |
| progressive disclosure | ███░░ 3/5 | Section headers are well-organized, but this is a 485-line monolithic file with the full CLI reference, env-var table, and deep feature docs (Tailscale, ngrok, LAN, OS service) inlined rather than split into one-level-deep reference files. |
Suggestions:
- Remove the duplicated framework-PORT-injection explanation — keep it in one place (e.g. Troubleshooting) and cross-reference from How It Works, and trim the 'Why portless' bullets to the few portless-specific problems.
- Move the exhaustive CLI reference, environment-variable table, and deep feature docs (Tailscale/ngrok/LAN/OS service) into separate reference files, leaving SKILL.md as an overview + Quick Start with clearly signaled one-level-deep links.
- Add explicit validate→proceed steps for system-level operations (e.g. after 'service install' run 'service status'; after 'hosts sync' verify resolution with 'doctor') to give those workflows feedback loops.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions — integrating, configuring dev server names, setting up the local proxy, working with .localhost domains, and troubleshooting — giving comprehensive coverage rather than minor gaps. |
| completeness | █████ 5/5 | Explicitly states both what it does ('Set up and use portless for named local dev server URLs') and when to use it via a 'Use when…' clause with concrete trigger phrases. |
| trigger term quality | █████ 5/5 | Covers natural terms users would say ('dev server names', 'local proxy', '.localhost domains', 'port/proxy issues') plus concrete URL examples and the extension-like '.localhost', giving comprehensive keyword coverage. |
| distinctiveness conflict risk | █████ 5/5 | The distinctive 'portless' name plus a niche (.localhost dev-server proxy) with specific triggers yields minimal overlap risk with other skills. |
plugins/portless/agent/skills/portless/SKILL.md
Highly actionable and well-structured reference for portless with concrete examples throughout, but it is a large monolithic file with some duplicated prose that could be tightened or split into reference bundles.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ███░░ 3/5 | Mostly actionable reference content without explaining basic concepts, but the framework port-injection rules are stated twice in near-identical dense paragraphs (lines 181 and 395) and several prose blocks could be tightened; not a score-4 'minor instances' level of padding. |
| actionability | █████ 5/5 | Abundant copy-paste-ready bash, JSON, and JS/TS code blocks plus a full CLI reference and config tables cover the common cases, matching the fully-executable score-5 anchor. |
| workflow clarity | ████░ 4/5 | Install/Quick Start and How-It-Works give clear sequenced steps and 'portless doctor' acts as a diagnostic checkpoint; not a score-5 because the main workflows lack explicit validate→fix→retry feedback loops, though the destructive-cap guideline does not apply since clean/prune are single commands, not multi-step batch workflows. |
| progressive disclosure | ███░░ 3/5 | Well-organized with clear section headers, but the file is a ~480-line monolith with large CLI-reference and env-var tables inlined and no external reference files; the under-50-line simple-skill exception does not apply, so it sits at 'some structure, content that could be separate is inline'. |
Suggestions:
- De-duplicate the framework port-injection rules: keep the full list once (e.g. under Troubleshooting) and reference it from 'How It Works' rather than restating the long paragraph.
- Move the large CLI Reference and Environment variables tables into separate reference files (e.g. references/cli.md, references/env.md) and link to them from SKILL.md to improve progressive disclosure.
- Tighten dense prose blocks like the multi-segment TLD and framework injection paragraphs into shorter bullet lists to reduce token cost.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions — 'Set up and use', 'integrating portless into a project', 'configuring dev server names', 'setting up the local proxy', 'working with .localhost domains', 'troubleshooting port/proxy issues' — giving comprehensive coverage rather than the 1-2 actions of a score-3 anchor or the minor-gaps of a score-4. |
| completeness | █████ 5/5 | Explicitly answers both what ('Set up and use portless for named local dev server URLs') and when ('Use when integrating... configuring... setting up... troubleshooting...') with concrete trigger phrases, matching the score-5 anchor. |
| trigger term quality | ████░ 4/5 | Natural terms like 'localhost', '.localhost domains', 'dev server', 'port', 'proxy issues' give good coverage; falls short of score-5 because it lacks a few common synonyms/variations a user might say (e.g. 'local tunnel', 'local URL'). |
| distinctiveness conflict risk | █████ 5/5 | Names a specific tool (portless) with a clear niche (.localhost named dev URLs) and distinct triggers, giving minimal conflict risk with other skills. |
plugins/turborepo/.agents/skills/turborepo/SKILL.md
A strong, action-oriented reference skill: executable examples, decision-tree navigation, and a clean one-level-deep reference structure with all cited files present. The only slack is light redundancy across the shorthand-rule sections.
Validation
⚠️ skill_md_line_count — SKILL.md is long (952 lines); consider splitting into references/ and linking⚠️ relative_links — Relative link issues: 24 deeper-than-1-level⚠️ referenced_paths_exist — Referenced path issues: 35 deeper-than-1-level
Full review details
Validation Checks
13/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | Mostly efficient and information-dense with no padding of concepts Claude already knows, but the "turbo run vs shorthand" rule is restated across the Secondary Rule section, the "Using turbo Shorthand in Code" anti-pattern, and inline examples, and a few anti-patterns overlap, so minor trimming is possible. |
| actionability | █████ 5/5 | Fully executable guidance throughout — copy-paste-ready turbo.json/package.json blocks, concrete CLI commands, and paired WRONG/CORRECT examples covering the common configuration cases. |
| workflow clarity | ████░ 4/5 | Decision trees sequence common scenarios clearly and a few conditional procedures exist (e.g., the prebuild fix branched on whether dependencies are declared, the "before flagging outputs" checklist), but there are no explicit validate→fix→retry feedback loops for the more involved migrations. |
| progressive disclosure | █████ 5/5 | Clear overview in SKILL.md with well-signaled one-level-deep references: inline pointers in every decision tree plus a categorized Reference Index table, and all 23 cited reference files exist and match the cited paths. |
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple specific concrete actions and scenarios — "configures tasks/workflows/pipelines, creates packages, sets up monorepo, shares code between apps, runs changed/affected packages, debugs cache" — giving comprehensive coverage of what the skill addresses. |
| completeness | █████ 5/5 | Explicitly answers both what ("Turborepo monorepo build system guidance") and when (both a "Triggers on:" list and a "Use when user:" clause with concrete trigger phrases). |
| trigger term quality | █████ 5/5 | Comprehensive natural trigger terms including the file name (turbo.json), CLI flags (--filter, --affected), synonyms (caching, remote cache), and domain phrases a Turborepo user would naturally say. |
| distinctiveness conflict risk | █████ 5/5 | Occupies a clear Turborepo-specific niche with distinctive triggers (turbo.json, dependsOn, --affected, --filter) and minimal overlap risk with unrelated skills. |
plugins/turborepo/agent/skills/turborepo/SKILL.md
The content is highly actionable with excellent progressive disclosure and concrete WRONG/CORRECT examples, but it is lengthy with some repetition and lacks explicit validation feedback loops for its batch/build operations.
Validation
⚠️ skill_md_line_count — SKILL.md is long (960 lines); consider splitting into references/ and linking⚠️ relative_links — Relative link issues: 24 deeper-than-1-level⚠️ referenced_paths_exist — Referenced path issues: 35 deeper-than-1-level
Full review details
Validation Checks
13/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ███░░ 3/5 | The body is mostly efficient and avoids explaining concepts Claude already knows, but at ~959 lines it repeats the 'turbo run vs turbo' rule across three sections (Secondary Rule, Critical Anti-Patterns, and decision trees) and could be tightened. It sits between 'mostly efficient with some unnecessary explanation' and 'efficient with minor trimmable instances'. |
| actionability | █████ 5/5 | Guidance is fully executable: copy-paste-ready JSON/YAML/bash blocks with explicit WRONG/CORRECT pairs, plus decision trees that route to specific commands and reference files covering the common cases. |
| workflow clarity | ███░░ 3/5 | Decision trees give clear routing and some procedures are sequenced (e.g., the missing-outputs check), but the skill covers batch operations (building/filtering many packages, cache invalidation) without explicit validate→fix→retry feedback loops, which caps this score per the batch-operation guidance. |
| progressive disclosure | █████ 5/5 | The body is a well-organized overview with decision trees and a Reference Index table; detailed material is split one level deep under references/ with all referenced paths verified to exist and clearly signaled, making navigation easy. |
Suggestions:
- Consolidate the 'turbo run vs turbo' guidance into one section and cross-reference it elsewhere to reduce repetition across the Secondary Rule, Critical Anti-Patterns, and decision trees.
- Add explicit validate→fix→retry checkpoints for batch/build operations (e.g., after
turbo run build --affected, runturbo run testor a boundary check before proceeding) to raise workflow clarity. - Trim or move some of the longer anti-pattern explanations (e.g., the root .env rationale and the prebuild walk-through) into reference files to tighten the core SKILL.md body.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | The description names the domain ('Turborepo monorepo build system guidance') and lists multiple concrete actions — 'configures tasks/workflows/pipelines, creates packages, sets up monorepo, shares code between apps, runs changed/affected packages, debugs cache' — giving comprehensive coverage of capabilities. |
| completeness | █████ 5/5 | It explicitly answers 'what' (Turborepo monorepo build system guidance with enumerated capabilities) and 'when' ('Use when user: configures tasks/workflows/pipelines ... or has apps/packages directories') with concrete trigger phrases. |
| trigger term quality | █████ 5/5 | It combines natural user phrasing ('Use when user: configures tasks...') with concrete technical tokens and file names (turbo.json, dependsOn, --filter, --affected, remote cache, 'turbo' CLI), giving comprehensive coverage of terms users would actually say. |
| distinctiveness conflict risk | █████ 5/5 | The niche is clearly Turborepo-specific with distinct triggers (turbo.json, --filter, --affected, dependsOn, remote cache), giving minimal conflict risk with other skills. |
plugins/vueuse/.agents/skills/vueuse-functions/SKILL.md
The content is a well-structured, single-purpose decision guide with excellent progressive disclosure (clean one-level reference links, all verified) and a coherent workflow. Its main weakness is actionability: the body provides decision rules but no executable code, deferring all implementation detail to reference files.
Validation
⚠️ relative_links — Relative link issues: 2 suspicious
Full review details
Validation Checks
15/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | The body is a structured reference catalog that assumes Claude's intelligence (no explaining what Vue/composables are) and delegates full usage to reference files, but the 423-line repetitive table is a notable token cost that isn't perfectly lean. |
| actionability | ███░░ 3/5 | The Invocation rule (AUTO/EXTERNAL/EXPLICIT_ONLY) and 'check first whether a VueUse function can implement the requirement' give concrete decision guidance, but the body contains no executable code or commands — implementation is delegated entirely to reference files. |
| workflow clarity | ████░ 4/5 | 'When to Apply' gives a coherent decision sequence (check VueUse fit, map to function, follow Invocation rule, consult reference), with only a minor validation gap (no explicit 'verify the composable behaves as expected' step). |
| progressive disclosure | █████ 5/5 | SKILL.md is an overview (When to Apply + categorized catalog) pointing one level deep to ./references/*.md for each function; all 268 referenced files exist on disk with no nested deeper reference chains, and links are clearly signaled and organized by category. |
Suggestions:
- Add a brief 'Quick start' example showing one or two canonical composable usages inline (e.g. useStorage/useToggle) so the body is executable without a reference hop.
- Add an explicit verification checkpoint in 'When to Apply', e.g. 'After applying a composable, confirm reactive behavior matches the requirement before moving on.'
- Trim repeated boilerplate in the catalog (e.g. recurring MDN links) or move the full table to a reference index file to reduce the SKILL.md token footprint.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | ███░░ 3/5 | Names the domain (Vue.js/Nuxt, VueUse composables) and a couple of concrete actions ('apply composables', 'build features'), but 'where appropriate' and 'build... features' are generic with no enumerated capability list. |
| completeness | ███░░ 3/5 | The 'what' is clear at a high level, but there is no explicit 'Use when...' trigger clause — 'when' is only weakly implied by 'where appropriate', capping completeness at 3 per the rubric. |
| trigger term quality | ████░ 4/5 | Includes natural terms a user would say ('VueUse composables', 'Vue.js', 'Nuxt'), but misses common synonyms and file extensions (.vue, reactivity, refs). |
| distinctiveness conflict risk | ████░ 4/5 | Targets a specific library niche (VueUse composables) that is mostly distinct from generic skills, with only minor overlap risk against broader Vue development skills. |
Suggestions:
- Add an explicit 'Use when...' clause with concrete trigger phrases, e.g. 'Use when building Vue.js or Nuxt features and a VueUse composable may fit (reactive state, browser APIs, storage, animation, etc.).'
- Enumerate 2-3 concrete capability areas (e.g. 'manage reactive state, bind browser APIs, handle storage and events') to lift specificity from 3 to 4-5.
- Include natural synonyms users say ('composables', 'reactivity', 'refs', '.vue files') to broaden trigger-term coverage.
plugins/vueuse/agent/skills/vueuse-functions/SKILL.md
The skill body is a well-structured, lean catalog that practices strong progressive disclosure by linking each composable to a one-level-deep reference file, but it provides no executable code in the body itself and only an implicit, checkpoint-free workflow.
Validation
⚠️ relative_links — Relative link issues: 2 suspicious
Full review details
Validation Checks
15/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | The per-function table rows are terse one-liners with no basic-concept padding, and the overview assumes Claude's competence; the only slack is minor redundancy in the "When to Apply" bullets (lines 18-20 restate the same idea three times), so it sits at efficient-with-minor-trimmable-instances rather than the fully-lean 5. |
| actionability | ███░░ 3/5 | The body is a routing index: it maps needs to functions and gives concrete AUTO/EXTERNAL/EXPLICIT_ONLY invocation rules, but contains no executable code and defers all usage details to ./references, so key execution details are missing from the body itself. |
| workflow clarity | ███░░ 3/5 | An implied sequence exists (check VueUse applicability -> map to function -> apply invocation rule -> consult reference), but it is expressed as principle bullets rather than a numbered sequence and has no validation checkpoints, matching the steps-present-but-checkpoints-missing anchor. |
| progressive disclosure | █████ 5/5 | The body is a well-organized overview/index with every function linked one level deep to a real references/.md file (verified to exist), keeping detail out of SKILL.md and making navigation easy; this matches the clear-overview-with-one-level-deep-references anchor. |
Suggestions:
- Add a short "Quick start" example showing one or two common composables used inline (e.g. useStorage, useDark) so the body carries executable guidance, not just routing.
- Replace the redundant "When to Apply" bullets with a compact numbered decision flow (check applicability -> pick function -> apply invocation rule -> consult reference -> verify behavior).
- Tighten the three near-duplicate bullets on lines 18-20 into a single instruction to remove the minor redundancy.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | ███░░ 3/5 | Names the domain ("VueUse composables", "Vue.js / Nuxt") and one concrete action ("Apply VueUse composables") plus an outcome ("build concise, maintainable features"), but does not enumerate several distinct capabilities, so it stops at the 1-2 concrete actions anchor rather than the comprehensive 5. |
| completeness | ███░░ 3/5 | Has a clear "what" (apply VueUse composables to build features) but no explicit "Use when..." trigger clause; "where appropriate" only weakly implies the when, so per the missing-trigger-guidance rule completeness is capped at 3. |
| trigger term quality | ███░░ 3/5 | Includes relevant natural terms ("VueUse composables", "Vue.js", "Nuxt") a user would say, but misses common variations/synonyms such as "Vue 3", "composable", or "reactive utilities", fitting the some-keywords-but-missing-variations anchor. |
| distinctiveness conflict risk | █████ 5/5 | The VueUse/Vue.js/Nuxt niche is specific and unlikely to fire for unrelated skills, matching the clear-niche-with-minimal-conflict-risk anchor; it is not the 4 anchor because there is no meaningful overlap with closely related skills. |
Suggestions:
- Add an explicit trigger clause, e.g. "Use when building or refactoring Vue.js / Nuxt features that could leverage an existing composable".
- List a couple of concrete capability examples (e.g. state, sensors, network, watchers) to lift specificity beyond one generic action.
- Include common synonyms/variations users say ("Vue 3", "composable", "reactive utility") to broaden trigger term coverage.
To improve your score, point your agent at the Tessl optimization guide. Need help? Jump on our Discord.
Feedback
Report issues with this review at tesslio/skill-review, or send private feedback from your terminal with tessl feedback.
Merged
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Automated refresh of vendored skills.sh skills to their latest upstream versions.
Updated lock directories:
plugins/emulateplugins/firebaseplugins/mastraplugins/nuxt-seoplugins/nuxt-uiplugins/orpcplugins/portlessplugins/react-nativeplugins/reactplugins/slidevplugins/turborepoplugins/vercel-sandboxplugins/vueuseGenerated by
.github/workflows/update-skills.yml→scripts/update-skills.ts.Summary by cubic
Refreshes vendored skills to their latest upstream versions, adding the
denoplugin and new Firebase, Deno, and emulator skills.Notable changes
denoplugin added with skills covering the Deno runtime, deploy, sandboxes, frontends, and migrations from npm, Yarn, pnpm, and Bun.emulate:*from allowed-tools, add Clerk and Twilio coverage, and document new behaviors like idempotent Resend sends and RS256-signed Google ID tokens.Written for commit a574d0d. Summary will update on new commits.