fix: update vendored skills to latest versions - #269
fix: update vendored skills to latest versions#269pleaseai-release-bot[bot] wants to merge 1 commit into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
PR author is in the excluded authors list. |
Up to standards ✅🟢 Issues
|
|
🔍 Tessl Skill Review
|
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | Dense operational prose with mostly commands and rules, but the readiness conditions are restated across multiple steps and a few sentences could be trimmed, leaving minor over-explanation. |
| actionability | █████ 5/5 | Fully executable, copy-paste-ready commands throughout (e.g. 'd3k portless status --json', 'd3k -t --app-url ""', 'd3k agent-browser click @e2') covering the common runtime, testing, and evidence-gathering cases. |
| workflow clarity | █████ 5/5 | A clearly numbered 1-5 sequence with explicit validation gates ('Do not start d3k until ...') and feedback loops ('If startup fails, inspect ...', 'If the managed browser is unavailable, ... restart d3k cleanly'); validation is present so the destructive/batch cap does not apply. |
| progressive disclosure | ████░ 4/5 | Well-organized into clearly labeled sections and self-contained with no nested references, but at ~140 lines with no bundle files or one-level-deep references it does not meet the lean/simple-skill bar for a 5. |
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | ████░ 4/5 | Names several concrete actions ('reuse or background-start d3k non-interactively', 'wait for readiness', 'use its project-stable managed Chrome profile', 'inspect unified browser/server evidence') but 'inspect unified evidence' stays slightly abstract, so it falls just short of comprehensive. |
| completeness | █████ 5/5 | Explicitly answers both 'what' (own the runtime, reuse/background-start, wait for readiness, use the Chrome profile, inspect evidence) and 'when' with a concrete 'Use when the user asks to use d3k, run/dev/test/debug a web project with d3k, or reproduce a browser issue' clause. |
| trigger term quality | ████░ 4/5 | Includes natural phrases a user would say ('use d3k', 'run/dev/test/debug a web project with d3k', 'reproduce a browser issue'); good coverage but missing common synonyms or extensions, so not a 5. |
| distinctiveness conflict risk | █████ 5/5 | Tied to a specific named tool ('d3k') with distinct triggers, giving it a clear niche and minimal overlap with other skills. |
plugins/dev3000/agent/skills/d3k/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
A well-organized, highly actionable reference skill body with executable code and clear sections. Its main weaknesses are a bulky inlined config block and mild repetition of base-URL precedence guidance, which keep conciseness and progressive disclosure just below perfect.
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 and assumes competence (no explanation of OAuth or what an API is), but the ~140-line inlined config block and repeated base-URL precedence explanation across three sections are minor instances that could be trimmed. |
| actionability | █████ 5/5 | Fully executable, copy-paste-ready guidance throughout: real npx emulate commands, complete TypeScript createEmulator/Vitest/persistence examples, and option tables with defaults covering the common cases. |
| workflow clarity | ████░ 4/5 | Clear sequences for setup, test harness, and config auto-detection with most checkpoints present (e.g. generated-secrets validation and fail-closed behavior, test reset/afterEach), but lacks explicit validate-fix-retry checklists for the few risky operations. |
| progressive disclosure | ████░ 4/5 | Good section structure with well-signaled one-level-deep references to the next/nuxt skills; the only gap is the large inlined Config Structure YAML that could live in a separate reference file. |
Suggestions:
- Move the large multi-service Config Structure YAML block into a separate reference file (e.g. references/config-examples.yaml) and link to it from SKILL.md to improve progressive disclosure and conciseness.
- Consolidate the base-URL precedence explanation (currently repeated in the CLI options, Programmatic API options, and HTTPS sections) into a single authoritative location.
- Add an explicit validate-fix-retry checklist for the generated-secrets-file flow and any other destructive steps to raise workflow clarity.
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') and names specific services, giving comprehensive coverage of capabilities. |
| completeness | █████ 5/5 | Explicitly answers both what ('Local drop-in API emulator for Vercel, GitHub, Google, Slack, Apple, Microsoft, AWS, Linear, and other developer APIs') and when (the 'Use when...' clause plus concrete 'Triggers include...' phrases). |
| trigger term quality | █████ 5/5 | Includes comprehensive natural trigger phrases users would say ('start the emulator', 'emulate services', 'mock API locally', 'create emulator config', 'test against local API', 'npx emulate'), covering synonyms and the actual CLI command. |
| distinctiveness conflict risk | █████ 5/5 | Occupies a clear niche (local API emulation for named developer APIs) with distinct, service-specific triggers, minimizing conflict risk with other skills. |
plugins/emulate/.agents/skills/github/SKILL.md
The body is highly actionable with executable examples, but it is a monolithic ~600-line API reference inlined into SKILL.md with no progressive disclosure into separate files, and destructive operations lack validation checkpoints. Splitting the endpoint reference into a bundled file and adding verification steps would raise the weaker dimensions.
Validation
⚠️ skill_md_line_count — SKILL.md is long (622 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 | Prose is lean and free of padding about concepts Claude already knows, but the ~600-line endpoint reference is bulk that could be trimmed or moved out of SKILL.md, leaving minor over-length rather than verbosity. |
| actionability | █████ 5/5 | Fully executable, copy-paste-ready curl commands and TypeScript snippets cover the common cases across auth, repos, issues, PRs, apps, OAuth, and webhook flows. |
| workflow clarity | ███░░ 3/5 | Sequenced flows exist in 'Common Patterns' (OAuth flow numbered 1-5, App token flow numbered), but the bulk is unstructured endpoint listings and destructive operations (DELETE repo with cascades) lack explicit validation/verification checkpoints. |
| progressive disclosure | ███░░ 3/5 | No bundle files exist and the entire endpoint reference is inlined in SKILL.md; content that clearly belongs in a separate reference file is kept inline, matching the inlined-reference anchor. |
Suggestions:
- Move the bulk endpoint reference into a separate bundled reference file (e.g. references/endpoints.md) and keep SKILL.md as a concise overview pointing to it, improving progressive disclosure and conciseness.
- Add explicit validation/verification checkpoints to destructive and batch operations (e.g. confirm a repo exists and check cascade impact before DELETE, verify webhook delivery after creation).
- Tighten 'Misc' and per-section endpoint dumps into a compact summary table or reference link to reduce inlined bulk.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions — emulate repos/issues/PRs, set up OAuth flows, configure GitHub Apps, test webhooks, and work with actions/checks — giving comprehensive coverage of capabilities. |
| completeness | █████ 5/5 | Explicitly answers both 'what' (stateful emulated GitHub REST API for local dev/testing) and 'when' via a 'Use when...' clause plus a 'Triggers include...' list with concrete trigger phrases. |
| trigger term quality | █████ 5/5 | Provides 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 and minimal overlap risk with other skills. |
plugins/emulate/.agents/skills/next/SKILL.md
The body is a well-structured, highly actionable integration guide with executable code throughout and a clear runtime-flow explanation. It is held back from full marks only by minor redundant prose and the absence of an explicit setup sequence or external reference split.
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 | Largely lean with executable examples, but a few asides restate context Claude already has — e.g. 'This is particularly useful for Vercel preview deployments where OAuth callback URLs change with every deployment' duplicates the description, and 'keeping serverless bundles small' is a minor non-essential aside. |
| actionability | █████ 5/5 | Every section ships copy-paste-ready code: the install command, a full createEmulateHandler route, Auth.js provider wiring, withEmulate next.config usage, and both custom and filePersistence adapters, backed by complete config-reference tables. |
| workflow clarity | ████░ 4/5 | The 'How It Works' section gives a clear 5-step request-flow sequence and setup is logically ordered by topic; no destructive/batch operations exist so the validation cap does not apply, though an explicit setup ordering (install → route → auth → font tracing → persistence) is only implicit. |
| progressive disclosure | ████░ 4/5 | A single self-contained file with clean section headers and no nested references; at ~150 lines it exceeds the under-50-line simple-skill case that would warrant a 5, and the Config Reference tables could conceivably live in a separate reference file, so it sits just below the top anchor. |
Suggestions:
- Trim context Claude already knows: drop the Vercel-preview OAuth rationale from the intro (it is in the description) and the 'keeping serverless bundles small' aside in Install.
- Add a short ordered setup checklist near the top (install → add catch-all route → wire Auth.js provider → wrap next.config → add persistence) so the topical sections read as an explicit sequence.
- Consider moving the Config Reference tables and PersistenceAdapter interface into a references/REFERENCE.md and linking to it one level deep, keeping SKILL.md as a tighter overview.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions — 'embedding emulators', 'set up same-origin OAuth for Vercel preview deployments', 'create an emulate catch-all route handler', 'configure Auth.js/NextAuth', 'add persistence', 'wrap next.config with withEmulate' — giving comprehensive coverage of the adapter's capabilities. |
| completeness | █████ 5/5 | Explicitly answers both 'what' (Next.js adapter for embedding emulators via @emulators/adapter-next) and 'when' with a clear 'Use when the user needs to…' clause plus concrete trigger phrases, matching the top anchor. |
| trigger term quality | █████ 5/5 | Surfaces natural trigger phrases a user would actually say — 'Next.js emulator', 'adapter-next', 'embedded emulator', 'same-origin OAuth', 'Vercel preview', 'createEmulateHandler', 'withEmulate' — including package names and API identifiers. |
| distinctiveness conflict risk | █████ 5/5 | A narrow, well-defined niche (embedding emulators inside a Next.js app) anchored to a specific package, making false-positive triggering for unrelated skills unlikely. |
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 (619 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/next/SKILL.md
Validation
- ❌ name_field — 'name' field is missing from frontmatter
Full review details
Validation Checks
15/16 checks passed.
plugins/portless/.agents/skills/portless/SKILL.md
A thorough, highly actionable CLI reference with excellent code/command coverage and clear navigation. Its main weakness is redundancy—the framework-injection paragraph is duplicated—and mild marketing padding in the motivation section.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | The body is mostly lean for a CLI reference (commands, config tables, env vars all earn their place), but the framework-PORT-injection behavior is explained nearly verbatim in both "How It Works" and "Troubleshooting", and the 9-bullet "Why portless" list is mildly promotional padding. |
| actionability | █████ 5/5 | Fully executable throughout: a complete CLI reference table, copy-paste bash commands, JSON config examples, and code snippets covering the common cases (install, run, monorepo, multi-app, sharing, troubleshooting). |
| workflow clarity | ████░ 4/5 | Quick Start and the numbered "How It Works" give a clear install→run→access sequence, and portless doctor serves as a diagnostic checkpoint, but destructive ops (clean, prune, service uninstall) lack an explicit validate-before feedback loop. |
| progressive disclosure | ████░ 4/5 | Well-organized with clear section headers, tables, and a logical overview-to-detail flow with no nested references; at ~480 lines as a single file it is larger than ideal, and some bulky reference material (framework injection details, env-var table) could be delegated, but placement is generally appropriate for a CLI tool. |
Suggestions:
- Remove the duplicate framework-PORT-injection paragraph: keep the full explanation in one place (e.g. Troubleshooting > Framework not respecting PORT) and link to it from 'How It Works' with a one-line summary.
- Trim the 9-item 'Why portless' list to the 3-4 most agent-relevant motivations (port conflicts, monorepo multiplier, agents testing wrong port) to cut promotional padding.
- Add an explicit validation checkpoint before destructive commands: e.g. suggest running
portless doctororportless listbeforeportless clean/prune/service uninstallso users confirm what will be removed.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions—"Set up and use portless", "integrating portless into a project", "configuring dev server names", "setting up the local proxy", "working with .localhost domains", "troubleshooting port/proxy issues"—with a concrete before/after URL example, giving comprehensive coverage. |
| completeness | █████ 5/5 | Explicitly answers both: what ("Set up and use portless for named local dev server URLs" with an illustrative example) and when (a clear "Use when..." clause with five concrete trigger scenarios). |
| trigger term quality | █████ 5/5 | Covers the natural terms a user would say—"named local dev server URLs", "dev server names", "local proxy", ".localhost domains", "port/proxy issues"—including synonyms (port, proxy, dev server) and the file/domain extension ".localhost". |
| distinctiveness conflict risk | █████ 5/5 | Names a specific tool ("portless") and a narrow niche (named .localhost dev URLs), with triggers tied to that tool's domain, so overlap with other skills is minimal. |
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 tightly written, gotcha-rich reference skill with executable code, clear prioritized workflow guidance, and excellent progressive-disclosure structure pointing to real, verified reference files. Minor room for tightening in the intro and a couple of recurring 'default="none"' explanations, and the 'AGENTS.md' compiled-document pointer references a file not present in the bundle.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | The body is dense with non-obvious gotchas (placement rules, nested-VT limitations, share precedence, silent-failure modes) and assumes Claude's competence without explaining basics, but a few phrases ('smooth, native-feeling') and repeated 'default="none"' guidance could be trimmed. |
| actionability | █████ 5/5 | Provides copy-paste-ready JSX covering enter/exit, list reorder, shared-element morphs, type-keyed maps, and a reusable DirectionalTransition wrapper, with specific props and concrete values throughout. |
| workflow clarity | ████░ 4/5 | Gives a clear priority-ordered implementation table ('Implement all applicable patterns from this list, in this order') and points to a 7-step workflow with a verify step in references/implementation.md; the main body itself defers most checkpoints to that reference rather than restating them. |
| progressive disclosure | █████ 5/5 | Clear overview with five well-signaled, one-level-deep reference files, an explicit 'Reference Files' index, and valid in-body deep links (e.g. patterns.md#layout-displacement-morph, css-recipes.md#reduced-motion); content is appropriately split between overview and references. |
Suggestions:
- Trim the intro marketing phrase 'smooth, native-feeling animations' and consolidate the recurring 'default="none"' guidance into one canonical statement to reduce repeated tokens.
- Either add the referenced 'AGENTS.md' compiled document to the bundle or remove the 'Full Compiled Document' pointer so there are no dangling references.
- Surface a brief explicit validation/verify checkpoint in the main body's Implementation Workflow section (not only in references/implementation.md) so the core skill stands alone.
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...animations using React's View Transition API') and 'when' with concrete trigger clauses ('Use this skill whenever the user wants to...', 'Also use when the user mentions...'). |
| trigger term quality | █████ 5/5 | Comprehensive natural-term coverage including synonyms and API names: 'page transitions', 'route changes', 'shared element animations', 'list reorder', 'view transitions', 'startViewTransition', 'ViewTransition', and 'transition types'. |
| distinctiveness conflict risk | █████ 5/5 | Clear niche (React View Transition API) with distinct triggers and an explicit boundary ('without third-party animation libraries'), minimizing overlap with general animation or CSS 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
The content is a well-structured, actionable integration guide that defers detail to the cloned Tiptap docs via clearly signaled one-level-deep references. It is concise and assumes competence, with only minor tightening and verification-checkpoint gaps.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | The body is lean and assumes Claude's competence without explaining basic concepts, but the intro paragraph repeats the 'reference docs and source code' instruction in several phrasings that could be tightened. |
| actionability | ████░ 4/5 | Provides concrete executable commands (npm view @tiptap/core version, git clone URLs, immediatelyRender: false) and copy-paste-ready code for collaboration, while most feature sections give specific extension names and exact doc paths rather than code — minor gaps in coverage. |
| workflow clarity | ████░ 4/5 | A clear sequence is present (clone repos → pull latest main → research docs/source → implement per feature) with Best Practices acting as guardrails, though explicit verification checkpoints after implementation are only implicit. |
| progressive disclosure | █████ 5/5 | The body is a well-organized overview with clearly signaled, one-level-deep references to specific external doc paths (tiptap-docs/src/content/...), keeping detail out of SKILL.md and making navigation easy. |
Suggestions:
- Tighten the intro paragraph: the 'reference the Tiptap code and documentation', 'grounded in the Tiptap documentation and source code', and 'matches the library source code and the documentation' phrases all say the same thing — consolidate to one.
- Add an explicit verification step to the task workflow (e.g. 'After implementing, confirm the change compiles/renders and matches the documented API') so the sequence has a concrete checkpoint.
- For feature sections that currently only name the extension and a doc path, consider one short executable snippet each (as done for collaboration) to raise actionability.
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 of the domain. |
| completeness | █████ 5/5 | Explicitly answers both 'what' ('Helps coding agents integrate and work with the Tiptap rich text editor') and 'when' with a clear 'Use when...' clause enumerating concrete trigger scenarios. |
| trigger term quality | ████░ 4/5 | Strong natural keywords ('rich text editor', 'Tiptap', 'Tiptap extensions', 'collaboration', 'comments', 'AI', 'document conversion') that users would say, though a few common synonyms (e.g. 'text editor', 'WYSIWYG') are absent and there is no file-extension equivalent. |
| distinctiveness conflict risk | █████ 5/5 | Targets a clear, specific niche (the Tiptap rich text editor) with distinctive triggers, making conflict with unrelated skills unlikely. |
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 highly actionable, well-organized skill with excellent executable examples and a clean reference-index navigation system. Its main weakness is conciseness: the body is long (~930 lines) and repeats the turbo run rule across multiple sections, with some anti-pattern detail that could live in reference files.
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 | The ~930-line body is mostly efficient and assumes Claude's competence (no 'what is a monorepo' padding), but the turbo run vs turbo shorthand rule is restated in three separate sections ('Package Tasks', 'Secondary Rule', and 'Critical Anti-Patterns') and several long anti-pattern walkthroughs could be tightened or moved to references. Fits 'mostly efficient but could be tightened'; not a 2 because there is no concept-over-explanation padding, and not a 4 because the repetition and length are noticeable rather than minor. |
| actionability | █████ 5/5 | Abundant copy-paste-ready JSON/YAML/bash blocks covering build pipelines, env vars, filtering, CI, package configurations, and decision trees routing to specifics. Fully executable guidance covering the common cases. |
| workflow clarity | ████░ 4/5 | Clear numbered sequences (e.g., the 'Package Tasks' 1-2-3 steps) and excellent decision-tree routing give an unambiguous path for each task. Not a 5 because explicit validate->fix->retry checkpoints are largely absent; not capped at 3 because this is configuration-authoring guidance rather than a destructive runtime batch operation. |
| progressive disclosure | ████░ 4/5 | Good structure with a comprehensive Reference Index table and decision trees pointing one level deep to 24 verified reference files, all well-organized into topical subdirectories. Not a 5 because substantial anti-pattern catalog content with full JSON blocks is inlined in SKILL.md rather than split into references. |
Suggestions:
- Consolidate the
turbo runvsturboshorthand rule, which is explained in 'Package Tasks', 'Secondary Rule', and again under 'Critical Anti-Patterns' — state it once and cross-reference from the other sections. - Move the longer anti-pattern deep-dives (e.g., globalDependencies, transit nodes, package-specific overrides) into reference files such as references/configuration/gotchas.md, keeping only a short WRONG/CORRECT summary in SKILL.md.
- Trim the body toward a lean overview by promoting detailed JSON walkthroughs to the references so the main file stays a routing hub rather than a ~930-line catalog.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | ████░ 4/5 | Names the domain ('Turborepo monorepo build system guidance') and the 'Use when user:' clause enumerates several concrete scenarios (configures tasks/workflows/pipelines, creates packages, sets up monorepo, shares code between apps, runs changed/affected packages, debugs cache). Not a 5 because the lead 'what' is the generic word 'guidance' rather than a list of concrete build actions, and not a 3 because well more than 1-2 specific actions are named. |
| completeness | █████ 5/5 | Explicitly answers both 'what' (Turborepo monorepo build system guidance) and 'when' ('Use when user: configures tasks/workflows/pipelines, creates packages, sets up monorepo, ... or has apps/packages directories') with concrete trigger phrases. The explicit 'Use when' clause is present, so completeness is not capped at 3. |
| trigger term quality | █████ 5/5 | Comprehensive natural-term coverage including synonyms and file/flag forms: 'turbo.json', 'turbo' CLI, '--filter', '--affected', 'dependsOn', 'caching', 'remote cache', 'CI optimization', 'monorepo structure/best practices'. Matches the anchor for comprehensive coverage including extensions and CLI flags. |
| distinctiveness conflict risk | █████ 5/5 | Clear niche (Turborepo specifically) with distinct triggers like 'turbo.json', 'turbo' CLI, '--filter', '--affected', 'dependsOn' that are unlikely to fire for unrelated skills. Minimal conflict risk. |
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 high-quality, highly actionable SDK reference with lean prose and exhaustive executable examples. Its main weaknesses are a monolithic structure with no progressive disclosure into reference files, and workflows that lack explicit validation feedback loops for destructive operations.
Validation
⚠️ skill_md_line_count — SKILL.md is long (1156 lines); consider splitting into references/ and linking
Full review details
Validation Checks
15/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | Lean, code-dense prose with little basic-concept padding (e.g. "Your knowledge of @vercel/sandbox may be outdated") and terse, useful comments. Not 5 because the ~1150-line monolith loads many tokens on every invocation when only a fraction is typically needed, and a few sentences could be trimmed. |
| actionability | █████ 5/5 | Extensive copy-paste-ready TypeScript and bash examples cover creation, command execution, file operations, network policy, snapshots, the CLI, and idiomatic patterns across the common cases. |
| workflow clarity | ███░░ 3/5 | Patterns like the Build and Test Pattern sequence steps with exit-code checks, but there are no explicit validate→fix→retry feedback loops, and destructive operations (sandbox.delete, sandbox run --rm) lack verification steps. Not 4 because checkpoints are missing or implicit for the destructive paths. |
| progressive disclosure | ███░░ 3/5 | Clear section headers (## Creating Sandboxes, ## Running Commands, etc.) structure the content, but ~1150 lines of API and CLI reference that belong in separate files are inlined with no reference bundle (references/scripts/assets absent). Not 4 because the lack of any file split is more than a minor gap. |
Suggestions:
- Split the API and CLI reference into separate reference files (e.g. references/sdk-reference.md, references/cli-reference.md) and keep SKILL.md as a concise overview with links, so only the needed detail loads into context.
- Add explicit verification checkpoints for destructive operations — e.g. confirm the sandbox name and inspect snapshot status before
sandbox.delete()orsandbox run --rm. - Include a validate→fix→retry feedback loop for batch workflows (e.g. the Build and Test Pattern) showing how to re-run on failure instead of only throwing.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | ███░░ 3/5 | "Creates isolated Linux MicroVMs using Vercel Sandbox SDK" names the domain and a concrete action, but the capability list is not comprehensive — managing, forking, snapshots, and network policy are absent. Not 4 because the 'what' is essentially a single action plus use-cases rather than several distinct capabilities. |
| completeness | █████ 5/5 | It clearly states what ("Creates isolated Linux MicroVMs using Vercel Sandbox SDK") and when ("Use when building code execution environments, running untrusted code... or when the user mentions...") with concrete trigger phrases. |
| trigger term quality | ████░ 4/5 | Explicit triggers "sandbox", "microvm", "isolated execution", or "@vercel/sandbox" give good natural-term coverage a user would actually say. Not 5 because common variants such as "VM"/"virtual machine" or "isolation" are missing. |
| distinctiveness conflict risk | █████ 5/5 | Tightly scoped to "Vercel Sandbox SDK" with niche triggers like "microvm" and "@vercel/sandbox", giving a clear niche with minimal conflict risk. |
plugins/vercel-sandbox/agent/skills/sandbox/SKILL.md
Validation
⚠️ skill_md_line_count — SKILL.md is long (1152 lines); consider splitting into references/ and linking- ❌ name_field — 'name' field is missing from frontmatter
Full review details
Validation Checks
14/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.



Automated refresh of vendored skills.sh skills to their latest upstream versions.
Updated lock directories:
plugins/dev3000plugins/emulateplugins/portlessplugins/react-nativeplugins/reactplugins/tiptapplugins/turborepoplugins/vercel-sandboxGenerated by
.github/workflows/update-skills.yml→scripts/update-skills.ts.Summary by cubic
Syncs the vendored skills in all plugin lock directories to their latest upstream versions via the automated update workflow.
Notable upstream changes
d3know runs a Portless readiness check and requiresd3k portless setupbefore starting any app process.deleteOrphanSnapshotsis passed.turboreposkill bumps its schema version to2.10.13-canary.1.metadata.jsonfiles, and the view-transitions skill removes theexperimental.viewTransitionflag guidance.Written for commit 373ebe4. Summary will update on new commits.