fix: update vendored skills to latest versions - #268
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 | 142 |
| Duplication | 16 |
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 | ███░░ 3/5 | The body is mostly efficient with concrete examples throughout, but the §10 '--version fast path' section spends several paragraphs explaining ESM static-import behavior Claude already knows, which could be tightened. |
| actionability | ████░ 4/5 | It provides concrete TOON output examples, an executable copy-paste JS fast-path snippet, explicit exit codes, and concrete error formats; most guidance is actionable with only minor gaps in the standards-oriented (non-code) sections. |
| workflow clarity | ████░ 4/5 | Content is organized into a clear numbered 10-section progression and §7 gives a clean 3-step session-integration pattern; this is a standards reference rather than a destructive/batch workflow, so no validation cap applies, though no explicit validate-fix-retry loop is present. |
| progressive disclosure | ████░ 4/5 | The document has good section structure with clearly signaled headers and a single one-level-deep external reference (the TOON spec link); no nested references exist, but the ~270-line monolith could split some detail (e.g. the §10 fast path) into a bundled reference file. |
Suggestions:
- Tighten §10 by collapsing the ESM-import-trap prose into a brief causal statement plus the code block and the two 'keep it honest' rules, trusting Claude's knowledge of static imports.
- Consider moving the §10 fast-path implementation detail into a bundled reference file and keeping SKILL.md focused on the standard ('--version must be a fast path'), improving progressive disclosure.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | ███░░ 3/5 | Names the domain ('CLI tools that agents use via shell execution') and lists several verbs ('building, modifying, or reviewing'), but those actions are generic high-level verbs rather than concrete operations, matching the anchor that names a domain with 1-2 actions but is not comprehensive. |
| completeness | █████ 5/5 | It explicitly answers both 'what' (ergonomic standards for agent-facing CLIs) and 'when' ('Use when building, modifying, or reviewing any agent-facing CLI') with concrete trigger phrases, matching the top anchor. |
| trigger term quality | ████░ 4/5 | 'CLI tools', 'agent-facing CLI', and 'shell execution' are natural phrases a user would say when needing this skill; a few common synonyms like 'command-line' or 'terminal tool' are missing, placing it just above the midpoint. |
| distinctiveness conflict risk | ████░ 4/5 | The 'agent-facing CLI ergonomics' niche is clearly distinct with specific triggers, but 'building CLI tools' is broad enough to risk minor overlap with general CLI-design or agent-skill-authoring skills. |
Suggestions:
- Sharpen the 'what' with a more concrete capability phrase (e.g., 'defines output format, schema, error, and help standards') instead of the generic 'building, modifying, or reviewing' verbs.
- Add common synonyms such as 'command-line tools' or 'terminal tools' alongside 'CLI' to broaden natural trigger coverage.
plugins/axi/agent/skills/axi/SKILL.md
Validation
- ❌ name_field — 'name' field is missing from frontmatter
Full review details
Validation Checks
15/16 checks passed.
plugins/emulate/.agents/skills/emulate/SKILL.md
Highly actionable with executable commands and complete config examples, but the body is padded by a large inlined config block and lacks explicit validation checkpoints for destructive/stateful operations, capping workflow clarity. No bundle files exist, so the inlined reference content limits progressive disclosure.
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 with well-targeted tables and code, but the large inlined full config example (lines 153-294) and repeated base-URL precedence explanations across sections add padding that could be trimmed or moved to a reference. |
| actionability | █████ 5/5 | Provides fully executable, copy-paste-ready CLI commands, TypeScript programmatic examples, and concrete config YAML covering the common cases, with specific option tables and env-var mappings. |
| workflow clarity | ███░░ 3/5 | Common workflows are sequenced via labeled sections (Quick Start, CLI, Programmatic API), but there are no explicit validation/checkpoint steps for destructive or stateful operations like reset(), generated-secrets handling, or state persistence despite the rubric cap requiring validation for batch/destructive work. |
| progressive disclosure | ███░░ 3/5 | It is well sectioned and points to per-service skills and adapter packages, but no bundle files exist; the bulky per-service config reference is inlined entirely rather than split into separate reference files, leaving structure mid-range. |
Suggestions:
- Move the large per-service seed-config YAML reference (lines 153-294) into a references/ file and keep only a minimal inline example, reducing token cost and improving progressive disclosure.
- Add explicit validation/verification steps for stateful or destructive operations — e.g. verify the generated-secrets file is owner-only after
--generated-secrets-file, and confirmreset()ran before re-seeding tests. - Trim the repeated base-URL precedence narrative (lines 77-79, 109, 331) to a single canonical precedence list to avoid redundant explanation.
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' — across a clearly enumerated set of developer APIs, giving comprehensive coverage. |
| completeness | █████ 5/5 | Explicitly answers both 'what' (drop-in API emulator for named services with seed data, tests, CI) and 'when' via a clear 'Use when...' clause with concrete trigger phrases. |
| trigger term quality | █████ 5/5 | Provides comprehensive natural trigger phrases users would say ('start the emulator', 'emulate services', 'mock API locally', 'create emulator config', 'test against local API', 'npx emulate') plus synonyms and the CLI invocation. |
| distinctiveness conflict risk | ████░ 4/5 | The local-emulation niche with named third-party APIs is fairly distinct, but the breadth of services and phrases like 'mock API locally' create minor overlap risk with generic mocking skills. |
plugins/emulate/.agents/skills/github/SKILL.md
The content is a well-structured, highly actionable API reference with minimal padding. Its main weakness is that the large endpoint catalog lives entirely in SKILL.md rather than being split into reference files, which would lighten the always-loaded context.
Validation
⚠️ skill_md_line_count — SKILL.md is long (620 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 with executable examples and avoids explaining concepts Claude already knows, but at ~620 lines the overall volume is large and some endpoint-grouping reference could be deferred to bundle files. |
| actionability | █████ 5/5 | Provides copy-paste-ready curl commands and TypeScript snippets covering the common cases across auth, repos, issues, PRs, apps, OAuth, and more. |
| workflow clarity | ████░ 4/5 | Multi-step flows like the OAuth flow (numbered 1–5) and the App installation token flow (numbered 1–3) are clearly sequenced, though explicit validation checkpoints are absent. |
| progressive disclosure | ████░ 4/5 | No bundle files exist, but the single-file body is well-organized with clear section headers; the large API reference is all inline yet navigable. |
Suggestions:
- Move the per-endpoint API reference (Users, Repositories, Issues, Pull Requests, Comments, Reviews, etc.) into a references/ file such as ENDPOINTS.md, keeping only Quick Start, Auth, and Common Patterns in SKILL.md.
- Add explicit validation/verification steps to workflows involving destructive or cascade operations (e.g., the DELETE repo endpoint that 'cascades issues, PRs, etc.'), so Claude confirms state before and after.
- Add a one-line pointer near the top of the API Endpoints section to the reference file so navigation stays one level deep.
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', 'work with actions/checks' — giving comprehensive coverage of the emulator's capability surface. |
| completeness | █████ 5/5 | Clearly states what it does ('Emulated GitHub REST API for local development and testing') and when to use it ('Use when the user needs to interact with GitHub API endpoints locally...'), plus a concrete trigger-phrase list. |
| trigger term quality | █████ 5/5 | Explicit trigger list covers natural user phrases and synonyms — 'GitHub API', 'emulate GitHub', 'mock GitHub', 'test GitHub OAuth', 'GitHub App JWT', 'local GitHub' — matching how a user would actually ask. |
| distinctiveness conflict risk | █████ 5/5 | Niche is narrowly defined as local GitHub API emulation with distinct triggers, making conflict with other skills minimal. |
plugins/emulate/.agents/skills/stripe/SKILL.md
The body is highly actionable and well-structured with executable code throughout, but it inlines a sizable API reference and omits validation checkpoints for destructive operations, capping workflow clarity.
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 | Assumes Claude's competence with no concept-explaining fluff and tight section headers, but the inline Next.js proxy block and full per-endpoint curl reference add some length that could be trimmed or externalized. |
| actionability | █████ 5/5 | Provides fully executable, copy-paste-ready guidance: start commands, SDK construction with real params, curl examples, and TypeScript webhook handler code covering the common cases. |
| workflow clarity | ███░░ 3/5 | Sections are sequenced by topic, but destructive operations (DELETE customer, cancel payment intent, expire checkout session) lack explicit validation checkpoints; the destructive-ops rule caps this at 3. |
| progressive disclosure | ████░ 4/5 | Well-organized into clear sections with no nested references, but the full API reference is inlined rather than split into a separate file, leaving minor organization gaps. |
Suggestions:
- Add explicit verification steps (e.g., retrieving the resource after DELETE, checking status before cancel/expire) before destructive curl calls to lift workflow_clarity above the destructive-op cap.
- Move the per-endpoint API reference into a separate REFERENCE.md and link to it one level deep to improve progressive_disclosure and conciseness.
- Externalize the Next.js adapter proxy block into an examples file to reduce inline length while keeping the core start/SDK guidance in SKILL.md.
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') with comprehensive coverage, matching the score-5 anchor. |
| completeness | █████ 5/5 | Explicitly answers what ('Emulated Stripe 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 trigger phrases ('Stripe API', 'test payments locally', 'checkout flow', 'payment intent', 'Stripe webhook', 'Stripe SDK') plus the STRIPE_API_KEY env var, matching the score-5 anchor. |
| distinctiveness conflict risk | █████ 5/5 | Clear niche (local Stripe emulation) with distinct Stripe-specific triggers and minimal overlap risk with other skills. |
plugins/emulate/agent/skills/emulate/SKILL.md
Validation
- ❌ name_field — 'name' field is missing from frontmatter
Full review details
Validation Checks
15/16 checks passed.
plugins/emulate/agent/skills/github/SKILL.md
Validation
⚠️ skill_md_line_count — SKILL.md is long (617 lines); consider splitting into references/ and linking- ❌ name_field — 'name' field is missing from frontmatter
Full review details
Validation Checks
14/16 checks passed.
plugins/emulate/agent/skills/stripe/SKILL.md
Validation
- ❌ name_field — 'name' field is missing from frontmatter
Full review details
Validation Checks
15/16 checks passed.
plugins/lavish/.agents/skills/lavish/SKILL.md
The body is a deliberately thin pointer to a CLI source of truth, which keeps it token-efficient, well-structured, and easy to navigate. The main gap is the absence of any inline artifact example, leaving the common 'build the artifact' step fully external.
Validation
⚠️ metadata_version — 'metadata.version' is missing
Full review details
Validation Checks
15/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | █████ 5/5 | The body is lean: it states what the tool does in one sentence and delegates all current workflow/design/playbook detail to CLI commands rather than restating it, with every token earning its place. |
| actionability | ████░ 4/5 | It gives copy-paste-ready executable commands (npx -y lavish-axi --help, npx -y lavish-axi design, npx -y lavish-axi playbook <id>) and a concrete fallback rule, but it provides no inline artifact-building example, so the common case isn't fully covered. |
| workflow clarity | ████░ 4/5 | It sequences the workflow clearly (fetch current CLI guidance -> build the artifact, with explicit handling of empty vs non-empty arguments and a follow-up-command rewriting rule), and no destructive/batch validation cap applies since it defers such steps to the CLI. |
| progressive disclosure | █████ 5/5 | It is a concise overview that signals one-level-deep references via CLI subcommands rather than files, with no bundle files present to over-inline; navigation is explicit and discovery-oriented. |
Suggestions:
- Add one short inline example of the build/annotation round-trip (e.g., a one-line
npx -y lavish-axi artifact.htmlinvocation and where the user's feedback returns) so the core action is visible without running the CLI. - Clarify the empty-argument branch with a concrete cue: state that when $ARGUMENTS is empty the agent should still emit
npx -y lavish-axi playbookfirst to pick an id, rather than only 'infer what to visualize'. - Note the expected input format for the CLI (an HTML file path) near the invoke example so the user knows what to pass without reading --help.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | It lists multiple concrete actions (turn responses into HTML artifacts the user can annotate and send feedback on, via a named CLI) and catalogs the artifact types (plan, comparison, diagram, table, code diff, report), giving comprehensive coverage. |
| completeness | █████ 5/5 | It explicitly answers both what it does ('Turn complex or visual agent responses into rich, reviewable HTML artifacts... using the lavish-axi CLI') and when to use it ('Use when about to give a plan, comparison, diagram, table, code diff, report...'). |
| trigger term quality | ████░ 4/5 | Natural trigger terms like 'plan, comparison, diagram, table, code diff, report' are present and align with what users ask for, but it lacks explicit file-extension or synonym-level coverage and leans on the abstract phrase 'easier to grasp visually'. |
| distinctiveness conflict risk | ████░ 4/5 | The 'annotate HTML artifacts / review feedback loop' niche is fairly distinct, but the broad 'anything easier to grasp visually than as prose' trigger creates some overlap with general diagramming or code-review skills. |
plugins/lavish/agent/skills/lavish/SKILL.md
Validation
- ❌ name_field — 'name' field is missing from frontmatter
⚠️ metadata_version — 'metadata.version' is missing
Full review details
Validation Checks
14/16 checks passed.
plugins/nuxt-ui/.agents/skills/nuxt-ui/SKILL.md
A well-architected skill body: actionable install/MCP guidance, a task-to-reference routing table, and a clean one-level-deep reference tree that all resolves to real files. Slight conciseness headroom in the MCP section and the absence of explicit validation loops are the only nits.
Validation
⚠️ relative_links — Relative link issues: 13 deeper-than-1-level⚠️ referenced_paths_exist — Referenced path issues: 13 deeper-than-1-level
Full review details
Validation Checks
14/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | The body is lean and assumes Claude's competence — terse core rules, copy-paste install blocks, and a compact routing table — but the MCP-server setup section (two tool-config snippets plus a six-item tools list) and phrasing like 'If not already configured, add it' add a little that could be trimmed, so 4 rather than 5. |
| actionability | █████ 5/5 | Fully executable guidance throughout: complete install commands and config for both Nuxt and Vue/Vite, copy-paste claude mcp add and .cursor/mcp.json snippets, concrete MCP tool names, and unambiguous core rules like 'Always wrap the app in UApp'. |
| workflow clarity | ████░ 4/5 | 'How to use this skill' gives a clear load-before-code sequence and the routing table maps each task to specific references, with core rules acting as checkpoints; it lacks explicit validate/verify feedback loops, but UI composition is non-destructive so no cap applies — minor gaps keep it at 4. |
| progressive disclosure | █████ 5/5 | Clear overview with well-signaled one-level-deep references grouped into guidelines/layouts/recipes plus a quick-reference index, and a routing table for navigation; every referenced path (all 14 files) exists in the bundle, so structure and navigation are exemplary. |
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | ████░ 4/5 | Lists several concrete actions — 'Build UIs', 'customizing themes to match a brand', 'building forms', 'composing layouts like dashboards, docs sites, and chat interfaces' — with a concrete scope ('125+ accessible Vue components with Tailwind CSS theming'), but a couple of verbs ('Build UIs', 'creating interfaces') stay generic and coverage is not exhaustive, so it sits at 4 rather than 5. |
| completeness | █████ 5/5 | Explicitly answers both 'what' ('Build UIs with @nuxt/ui v4 — 125+ accessible Vue components with Tailwind CSS theming') and 'when' ('Use when creating interfaces, customizing themes to match a brand, building forms, or composing layouts...') with concrete trigger phrases. |
| trigger term quality | ████░ 4/5 | Natural phrases a user would say are well covered ('creating interfaces', 'customizing themes to match a brand', 'building forms', 'composing layouts like dashboards, docs sites, and chat interfaces'), but it lacks synonyms and file-extension / package-name variations that would push it to 5. |
| distinctiveness conflict risk | ████░ 4/5 | The library version '@nuxt/ui v4' and the 125-component scope carve a clear niche, but generic trigger verbs like 'creating interfaces' and 'building forms' carry minor overlap risk with other UI-library skills, keeping it just below 5. |
plugins/nuxt-ui/agent/skills/nuxt-ui/SKILL.md
Validation
- ❌ name_field — 'name' field is missing from frontmatter
⚠️ relative_links — Relative link issues: 13 deeper-than-1-level⚠️ referenced_paths_exist — Referenced path issues: 13 deeper-than-1-level
Full review details
Validation Checks
13/16 checks passed.
plugins/portless/.agents/skills/portless/SKILL.md
The body is highly actionable with concrete, executable commands and clear section organization, supported by strong troubleshooting and diagnostic guidance. Its main weakness is conciseness — several dense prose passages repeat or over-explain framework-specific behavior that could be condensed or moved to a reference file.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ███░░ 3/5 | Mostly efficient with concrete commands, but several long prose passages re-explain mechanics Claude could infer (e.g. the multi-paragraph framework flag-injection rules in 'How It Works' and repeated TLD/hostname matching details), so it sits at the 'mostly efficient but could be tightened' anchor. |
| actionability | █████ 5/5 | Provides fully executable, copy-paste-ready commands throughout — install, run, monorepo config, turborepo scripts, env-var table, CLI reference — with specific examples covering common cases, matching the 5 anchor. |
| workflow clarity | ████░ 4/5 | Quick Start and Integration Patterns give a clear sequenced path with explicit validation/diagnostics via portless doctor and troubleshooting checkpoints; a few multi-step flows (proxy loop, Tailscale) lack an explicit validate-then-proceed loop, so it is just below the 5 anchor. |
| progressive disclosure | ████░ 4/5 | Well-organized with clear section headers and a single inlined reference structure (no bundle files, all content in SKILL.md); the CLI reference and env-var tables are appropriately placed, but with no external reference files the split could be marginally cleaner, placing it above the 3 anchor. |
Suggestions:
- Condense the framework flag-injection rules in 'How It Works' and 'Framework not respecting PORT' into a compact table or move the detailed exception list to a references file, since the same conditions are described twice.
- Tighten the multi-segment TLD/DNS-label rules paragraph in 'How It Works' to the essential constraints; the full per-label length rules read as reference material.
- Extract the long CLI Reference and Environment variables tables into a reference file and link to it from the body to improve progressive disclosure and reduce the body's token footprint.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Names the tool and multiple concrete actions — 'Set up and use portless', 'configuring dev server names', 'setting up the local proxy', 'working with .localhost domains', 'troubleshooting port/proxy issues' — comprehensive coverage matching the 5 anchor. |
| 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 ('Use when integrating portless...configuring dev server names...troubleshooting port/proxy issues'), matching the 5 anchor with concrete trigger phrases. |
| trigger term quality | █████ 5/5 | Includes natural terms users say — 'named local dev server URLs', 'portless', 'dev server names', 'local proxy', '.localhost domains', 'port/proxy issues' — comprehensive coverage including synonyms and file extension. |
| distinctiveness conflict risk | █████ 5/5 | Has a clear niche — replacing port numbers with named .localhost URLs via a local proxy — with distinct triggers unlikely to fire for other skills, matching the 5 anchor. |
plugins/portless/agent/skills/portless/SKILL.md
Validation
- ❌ name_field — 'name' field is missing from frontmatter
Full review details
Validation Checks
15/16 checks passed.
plugins/react/.agents/skills/vercel-react-view-transitions/SKILL.md
A high-quality, dense reference for the React View Transition API with executable examples, well-organized progressive disclosure to four reference files, and clear conceptual sequencing. Minor room to tighten length and surface an explicit in-body validation checkpoint in the workflow.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | Lean and information-dense with no padding of concepts Claude already knows, but at ~320 lines a few illustrative duplicate examples and explanatory clauses could be marginally trimmed, keeping it just below the fully-lean anchor. |
| actionability | █████ 5/5 | Provides copy-paste-ready JSX covering the common cases — enter/exit, list reorder, shared-element morph, Suspense reveal, and type-keyed directional navigation — with complete, executable snippets. |
| workflow clarity | ████░ 4/5 | Signals a clear implementation order ('Start with the audit — do not skip it', then copy CSS recipes) and delegates the detailed step sequence to implementation.md, but in-body validation checkpoints are only implied rather than explicit. |
| progressive disclosure | █████ 5/5 | Well-structured overview with one-level-deep, clearly signaled references to implementation.md, patterns.md, css-recipes.md, and nextjs.md (all present in references/), plus a consolidated Reference Files section for easy navigation. |
Suggestions:
- Tighten the body by collapsing illustrative duplicate examples (e.g., the two type-keyed enter/exit blocks) into one, reducing token load without losing coverage.
- Add one explicit validation checkpoint in the Implementation Workflow section (e.g., 'Verify the animation plays in Chromium 125+ and degrades silently on unsupported browsers') rather than delegating all checks to implementation.md.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions — 'add page transitions, animate route changes, create shared element animations, animate enter/exit of components, animate list reorder, implement directional (forward/back) navigation animations, or integrate view transitions in Next.js' — giving comprehensive coverage of the API's capabilities. |
| completeness | █████ 5/5 | Explicitly answers both what ('Guide for implementing smooth, native-feeling animations using React's View Transition API') and when ('Use this skill whenever the user wants to...' plus 'Also use when the user mentions...') with concrete trigger phrases. |
| trigger term quality | █████ 5/5 | Comprehensive natural-term coverage including synonyms and technical identifiers: 'page transitions', 'route changes', 'shared element animations', 'list reorder', 'view transitions', 'startViewTransition', 'ViewTransition', 'transition types', and 'animating between UI states in React'. |
| distinctiveness conflict risk | █████ 5/5 | Occupies a clear niche (React View Transition API, no third-party animation libraries) with distinct, specific triggers and minimal overlap risk with other skills. |
plugins/react/agent/skills/vercel-react-view-transitions/SKILL.md
Validation
- ❌ name_field — 'name' field is missing from frontmatter
Full review details
Validation Checks
15/16 checks passed.
plugins/tiptap/.agents/skills/tiptap/SKILL.md
A well-structured overview that points into the cloned docs/source with concrete code for the headline collaboration case. Most feature sections are pointer-only, and a touch of intro padding and missing explicit verification keep it just below the top band.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | Mostly lean and pointer-driven, assuming Claude's competence; the intro's "Do not guess or invent patterns, make sure the code you write matches the library source code and the documentation" is mildly redundant padding. |
| actionability | ████░ 4/5 | Gives executable commands ("npm view @tiptap/core version") and complete collaboration code (Y.Doc, Editor with Collaboration.configure, TiptapCollabProvider), though several feature sections only point to doc paths without code. |
| workflow clarity | ████░ 4/5 | Clear numbered sequences for setup and doc referencing plus a grounding self-check; no destructive/batch operations so the validation cap does not apply, but explicit verification checkpoints are otherwise light. |
| progressive disclosure | ████░ 4/5 | Well-organized into clear sections with one-level-deep references to specific tiptap-docs paths; no bundle files are present, and the structure is clean with minor organization gaps. |
Suggestions:
- Tighten the intro: collapse "Make sure any decision you make is in accordance to the 'Best Practices' section..." and "Do not guess or invent patterns..." into a single grounding instruction.
- Add a brief executable snippet or key API call for at least one more high-frequency feature (e.g. Comments or Import/Export) instead of only a doc-path pointer.
- Add an explicit verify step after implementing a feature (e.g. build/typecheck or run the editor against the docs example) to strengthen the workflow's feedback loop.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions—"integrate and work with the Tiptap rich text editor", "building or modifying a rich text editor", "installing Tiptap extensions", and "implementing features like collaboration, comments, AI, or document conversion"—giving comprehensive coverage. |
| completeness | █████ 5/5 | Clearly states what it does and gives an explicit "Use when..." clause with concrete triggers (building/modifying, installing extensions, implementing listed features), matching the top anchor. |
| trigger term quality | ████░ 4/5 | Includes natural user phrases ("rich text editor with Tiptap", "installing Tiptap extensions", "collaboration, comments, AI", "document conversion") but is missing a few common synonyms; good but not exhaustive coverage. |
| distinctiveness conflict risk | █████ 5/5 | The Tiptap rich text editor niche is specific and the triggers are distinctive, so overlap with other skills is minimal. |
plugins/tiptap/agent/skills/tiptap/SKILL.md
Validation
- ❌ name_field — 'name' field is missing from frontmatter
Full review details
Validation Checks
15/16 checks passed.
plugins/turborepo/.agents/skills/turborepo/SKILL.md
A dense, highly actionable configuration guide with strong progressive disclosure to a real reference bundle. Its main weakness is conciseness: a few rules are restated multiple times and the body is long, and remediation workflows could use explicit validation checkpoints.
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 | ███░░ 3/5 | Mostly efficient and example-driven without explaining concepts Claude already knows, but the turbo run vs shorthand rule recurs three times (lines 79-97, 220-248, 432-439) and package-task-vs-root-task guidance repeats, adding noticeable length that could be tightened. |
| actionability | █████ 5/5 | Copious copy-paste-ready JSON/YAML/bash examples with explicit DO/DON'T pairs and framework-specific output globs cover the common configuration cases fully. |
| workflow clarity | ████░ 4/5 | Decision trees at the top give clear routing sequences and the prebuild/outputs fix sections list numbered steps, but multi-step remediation procedures lack explicit validate-then-proceed checkpoints. |
| progressive disclosure | █████ 5/5 | Clear overview with decision trees routing to a verified, one-level-deep references/ tree, plus a full Reference Index table for easy navigation; all referenced anchor paths (e.g. tasks.md#outputs, packages.md#compilation-strategies, boundaries/RULE.md#rule-types) resolve to real files. |
Suggestions:
- Consolidate the
turbo runvs shorthand rule into one authoritative section and cross-reference it instead of restating it in 'Secondary Rule', 'Critical Anti-Patterns', and the--parallelentry. - Add explicit validate-then-proceed checkpoints to multi-step remediation procedures (e.g., after migrating prebuild scripts, run
turbo run build --dryto confirm dependency ordering before declaring done). - Move the long 'Critical Anti-Patterns' catalog into a reference file (e.g. references/configuration/anti-patterns.md) and keep SKILL.md to the top patterns plus the decision trees and Reference Index.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | ████░ 4/5 | Lists several concrete actions ('configures tasks/workflows/pipelines, creates packages, sets up monorepo, shares code between apps, runs changed/affected packages, debugs cache'), though framed primarily as trigger conditions rather than a comprehensive action inventory. |
| completeness | █████ 5/5 | Explicitly answers both what ('Turborepo monorepo build system guidance') and when ('Use when user: configures tasks..., creates packages...') with concrete trigger phrases. |
| trigger term quality | █████ 5/5 | Comprehensive coverage of natural terms users would say, including config file names (turbo.json), CLI flags (--filter, --affected), and key concepts (dependsOn, remote cache, caching, internal packages). |
| distinctiveness conflict risk | █████ 5/5 | Clear Turborepo-specific niche with distinct triggers (turbo.json, --filter, --affected, dependsOn) unlikely to fire for unrelated skills. |
plugins/turborepo/agent/skills/turborepo/SKILL.md
Validation
⚠️ skill_md_line_count — SKILL.md is long (942 lines); consider splitting into references/ and linking- ❌ name_field — 'name' field is missing from frontmatter
⚠️ 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
12/16 checks passed.
plugins/vercel-sandbox/.agents/skills/sandbox/SKILL.md
A dense, highly actionable API reference with executable code throughout and well-sequenced usage patterns. It is held back by being a monolithic single-file reference with no progressive disclosure into bundle files and some sections that could be trimmed.
Validation
⚠️ skill_md_line_count — SKILL.md is long (1152 lines); consider splitting into references/ and linking
Full review details
Validation Checks
15/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ███░░ 3/5 | Each section is efficient and avoids explaining concepts Claude already knows, but the body inlines the entire API surface (CLI quick reference, L7 matchers, multi-user, snapshots) — a large reference that could be tightened or split, fitting 'Mostly efficient but includes some unnecessary explanation or could be tightened'. |
| actionability | █████ 5/5 | Quotes extensive copy-paste TypeScript and bash blocks (e.g. await Sandbox.create({ name: "my-dev-env", ... }), sandbox run -- node -e "console.log('hello')") covering creation, commands, files, network policy, and CLI — fully executable guidance across common cases. |
| workflow clarity | ████░ 4/5 | The 'Common Patterns' sections (Dev Server, Build and Test, Base+Forks) give clear sequences with validation checkpoints like if (install.exitCode !== 0) throw new Error, but the skill is primarily a multi-feature reference rather than a single fragile workflow, so it sits at 'Clear sequence with most checkpoints present; minor validation gaps'. |
| progressive disclosure | ███░░ 3/5 | No bundle files exist in references/, scripts/, or assets/ and the whole API is inlined in SKILL.md; section headers provide structure, but content that could live in separate files (CLI reference, network policy details) is inline, matching 'Some structure but could be better organized; references present but not clearly signaled'. |
Suggestions:
- Move the CLI Quick Reference and detailed Network Policy / L7 matcher sections into reference files (e.g. CLI.md, NETWORK.md) linked from a concise overview to improve progressive disclosure.
- Tighten or relocate the full limitations table and per-method listings to trim token cost while keeping the quick-start path inline.
- Add an explicit validate-fix-retry feedback loop around destructive operations (delete, stop with rollback) to strengthen workflow_clarity.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | ███░░ 3/5 | Quotes "Creates isolated Linux MicroVMs using Vercel Sandbox SDK" — names the domain and one concrete action, but the remainder is trigger language rather than a list of several specific capabilities, matching the anchor 'Names domain and 1-2 concrete actions'. |
| completeness | █████ 5/5 | Explicitly answers both what ("Creates isolated Linux MicroVMs using Vercel Sandbox SDK") and when ("Use when building code execution environments... or when the user mentions 'sandbox'...") with concrete trigger phrases, matching the top anchor. |
| trigger term quality | █████ 5/5 | Quotes "sandbox", "microvm", "isolated execution", "@vercel/sandbox", plus "running untrusted code" and "spinning up dev servers" — comprehensive natural terms including synonyms and the package identifier, matching the top anchor. |
| distinctiveness conflict risk | █████ 5/5 | Scoped to a specific SDK ("Vercel Sandbox SDK", "@vercel/sandbox") with niche triggers, giving it a clear slot with minimal overlap with other skills. |
Suggestions:
- Add 2-3 concrete capabilities (e.g., 'run commands, manage files, snapshot filesystems') alongside 'Creates isolated Linux MicroVMs' to lift specificity.
plugins/vercel-sandbox/agent/skills/sandbox/SKILL.md
Validation
⚠️ skill_md_line_count — SKILL.md is long (1148 lines); consider splitting into references/ and linking- ❌ name_field — 'name' field is missing from frontmatter
Full review details
Validation Checks
14/16 checks passed.
plugins/workflow-sdk/.agents/skills/migrating-to-workflow-sdk/SKILL.md
The body is a well-structured, action-oriented migration playbook with strong validation gates and clean progressive disclosure. Minor conciseness loss comes from repeating resume-routing rules across multiple sections.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | Directive, non-padded style that assumes Claude's competence, but the resume routing rules are restated across Default rules, the Fast-path router, the Verification checklist, and the counterexamples, adding repetition. |
| actionability | ████░ 4/5 | Provides concrete identifiers and rules (createHook()+resumeHook(), createWebhook({ respondWith: 'manual' }), getStepMetadata().stepId) with ordered boundary syntax; full copy-paste code is delegated to references rather than inlined. |
| workflow clarity | █████ 5/5 | Sequences Intake, Default rules, Fast-path router, required output shape, and an explicit Verification checklist with fail conditions that form a clear validate-and-recover feedback loop. |
| progressive disclosure | █████ 5/5 | Clear overview with well-signaled one-level-deep references (all references/*.md files exist), each pointer annotated with the exact target section for easy navigation. |
Suggestions:
- Consolidate the resume-surface rules so they appear once (e.g., in resume-routing.md) and are referenced rather than restated in Default rules, the Fast-path router, and the counterexamples.
- Inline one minimal runnable workflow+step snippet in the Default rules so the core 'use workflow' vs 'use step' boundary is executable without loading a reference file.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists concrete migration actions and enumerates specific source constructs (Activities, Workers, Signals, step.run(), ASL Task/Choice/Wait/Parallel states, task tokens, child workflows), giving comprehensive coverage rather than vague abstraction. |
| completeness | █████ 5/5 | Explicitly answers 'what' ('Migrates ... workflows to the Workflow SDK') and 'when' ('Use when porting ...') with concrete trigger phrases. |
| trigger term quality | █████ 5/5 | Natural terms users say when porting are present including API-specific names and synonyms (Signals, step.waitForEvent(), wait.forToken, triggerAndWait, task tokens, ASL state names). |
| distinctiveness conflict risk | █████ 5/5 | Scoped to migration from four named orchestration systems with distinct construct triggers, giving a clear niche with minimal overlap risk. |
plugins/workflow-sdk/.agents/skills/workflow-init/SKILL.md
A concise, well-structured decision flow with concrete framework detection and clear handoff guidance. The main weakness is that core install/configure execution detail is delegated to external URLs rather than provided inline, leaving a minor actionability and workflow-clarity gap.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | █████ 5/5 | Lean body using terse lists and a URL table with no padding or explanation of concepts Claude already knows; every section earns its place. |
| actionability | ████░ 4/5 | Provides concrete detection rules (e.g., "next dep or next.config.*"), explicit URLs, and verify commands, but defers the actual install/configure steps to external guides ("follow the guide step-by-step") rather than inlining them. |
| workflow clarity | ████░ 4/5 | Clearly sequenced 0-4 decision flow with a sanity check and a verify step that includes confirm-logs and curl checkpoints, but verification details are somewhat implicit and the bulk of execution steps live in the fetched external guide. |
| progressive disclosure | ████░ 4/5 | Well-organized sections with one-level-deep external URL references in a clear table and no nested references, though the primary instructional detail is delegated to fetched URLs rather than bundled files. |
Suggestions:
- Inline at least the minimal install/configure commands for the common frameworks so the skill is executable without fetching the external guide.
- Make the verify step more explicit by specifying the expected log lines or a concrete assertion rather than "Confirm logs show the workflow and steps executing."
- Add a brief error-recovery note for when the dev server fails to start or the curl returns an unexpected status, to strengthen the validation feedback loop.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | States two concrete actions ("Install and configure Vercel Workflow SDK before it exists in node_modules") and enumerates a comprehensive list of supported frameworks, matching the multiple-specific-actions anchor. |
| completeness | █████ 5/5 | Explicitly answers both what (install and configure the SDK before it exists in node_modules) and when ("Use when the user asks to..." with concrete trigger phrases), matching the top anchor. |
| trigger term quality | █████ 5/5 | Provides several natural trigger phrases users would say ("install workflow", "set up workflow", "add durable workflows", "configure workflow sdk", "init workflow") with synonyms, matching the comprehensive natural-terms anchor. |
| distinctiveness conflict risk | █████ 5/5 | Narrow niche (pre-install Vercel Workflow SDK setup for a specific framework list) with distinct triggers, giving minimal conflict risk with other skills. |
plugins/workflow-sdk/.agents/skills/workflow/SKILL.md
A high-quality, actionable body: nearly everything is executable TypeScript or CLI commands, with clear sequencing and real validation checkpoints (serde rules, workflow validate). Its chief weakness is conciseness, as the ~780-line body inlines substantial reference material and repeated import blocks that the bundled docs it cites could carry. Progressive disclosure is solid but would benefit from pushing more reference-style content into the cited docs.
Validation
⚠️ skill_md_line_count — SKILL.md is long (792 lines); consider splitting into references/ and linking⚠️ relative_links — Relative link issues: 3 suspicious
Full review details
Validation Checks
14/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ███░░ 3/5 | At ~780 lines the body is mostly efficient per-section but accumulates noticeable verbosity: long World SDK method-signature listings, multiple full streaming examples, and repeated import blocks could be trimmed or deferred to the bundled docs it points to, so it sits at 'mostly efficient with some unnecessary explanation' rather than lean. |
| actionability | █████ 5/5 | Pervasive copy-paste-ready TypeScript and bash/npx commands cover the common cases (steps, hooks, errors, serde, streaming, testing, debugging), and concrete call signatures like page.extract_tables()-style API specifics (e.g. world.runs.list({ resolveData })) make it fully executable. |
| workflow clarity | ████░ 4/5 | Multi-step procedures are well sequenced with explicit validation guidance ("Validate immediately", the serde "Critical rules", workflow validate/--check-serde checkpoints), but for batch/destructive-style operations the validate->fix->retry feedback loop is present in the serde section yet less consistently surfaced elsewhere, leaving a minor checkpoint gap versus 5. |
| progressive disclosure | ████░ 4/5 | Good structure with clearly signaled one-level-deep references to bundled docs (node_modules/workflow/docs/, @workflow/ai/docs/) and an organized directory map up top; the body keeps inline only key examples, though some large reference-style listings (full World SDK signatures, streaming examples) could live in the referenced docs for a cleaner 5. |
Suggestions:
- Trim the World SDK method-signature listings and the multiple full namespaced-streaming examples down to one representative example each, deferring exhaustive coverage to the referenced
node_modules/workflow/docs/API files to reduce ~200 lines. - Consolidate the repeated TypeScript import blocks (Quick reference, Streaming, Observability) into a single imports section referenced once, so the same imports are not re-stated in every example.
- Surface the validate->fix->retry feedback loop (modeled well in the serde section) in the testing/debugging workflows too, so checkpoint loops are consistent for batch and long-running operations.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | ████░ 4/5 | Lists several concrete actions ("survive restarts", "pause for external events", "retry on failure", "coordinate multi-step operations over time") plus the SDK name, but these are partly capability framing rather than a flat enumeration of distinct operations, leaving minor gaps in coverage versus the comprehensive 5 anchor. |
| completeness | █████ 5/5 | Explicitly answers both 'what' ("Creates durable, resumable workflows using Vercel's Workflow SDK") and 'when' ("Use when building workflows that need to survive restarts...", "Triggers on mentions of...") with concrete trigger phrases, matching the 5 anchor. |
| trigger term quality | ████░ 4/5 | Good natural keyword coverage ("workflow", "durable functions", "resumable", "workflow sdk", "queue", "event", "push", "subscribe", "step-based orchestration") that users would plausibly say, but it omits obvious synonyms and file/package extensions that would push it to 5. |
| distinctiveness conflict risk | ████░ 4/5 | The Vercel Workflow SDK niche is fairly distinct, but several trigger terms ("queue", "event", "push", "subscribe") are broad and could overlap with messaging or pub-sub skills, so it is mostly distinct rather than a clear niche with minimal conflict. |
plugins/workflow-sdk/agent/skills/migrating-to-workflow-sdk/SKILL.md
Validation
- ❌ name_field — 'name' field is missing from frontmatter
Full review details
Validation Checks
15/16 checks passed.
plugins/workflow-sdk/agent/skills/workflow-init/SKILL.md
Validation
- ❌ name_field — 'name' field is missing from frontmatter
Full review details
Validation Checks
15/16 checks passed.
plugins/workflow-sdk/agent/skills/workflow/SKILL.md
Validation
⚠️ skill_md_line_count — SKILL.md is long (788 lines); consider splitting into references/ and linking- ❌ name_field — 'name' field is missing from frontmatter
⚠️ relative_links — Relative link issues: 3 suspicious
Full review details
Validation Checks
13/16 checks passed.
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.
pleaseai-release-bot
Bot
force-pushed
the
chore/update-skills
branch
from
August 24, 2026 06:21
87b2e33 to
7f8cb9f
Compare
|
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/axiplugins/emulateplugins/lavishplugins/nosticsplugins/nuxt-uiplugins/portlessplugins/reactplugins/slack-agentplugins/slidevplugins/tiptapplugins/tsdownplugins/turborepoplugins/vercel-sandboxplugins/web-designplugins/wordpressplugins/workflow-sdkGenerated by
.github/workflows/update-skills.yml→scripts/update-skills.ts.