fix: update vendored skills to latest versions - #269
Open
pleaseai-release-bot[bot] wants to merge 1 commit into
Open
fix: update vendored skills to latest versions#269pleaseai-release-bot[bot] wants to merge 1 commit into
pleaseai-release-bot[bot] wants to merge 1 commit into
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
|
🔍 Tessl Skill Review
|
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | The stub is mostly lean, but the 'Why agent-browser' bullet list and the paragraph rationalizing why content is served from the CLI ('The CLI serves skill content that always matches the installed version, so instructions never go stale…') are minor over-explanation that could be trimmed. |
| actionability | ████░ 4/5 | Provides copy-paste executable commands (npm i -g agent-browser && agent-browser install, agent-browser skills get core, the specialized skills get list, skills list), but the actual browser-automation usage patterns are deferred one indirection away to skills get core rather than shown inline. |
| workflow clarity | ████░ 4/5 | Clear sequence — install, then load core skill via skills get core, then load a specialized skill when the task falls outside web pages — with no destructive/batch operations requiring validation checkpoints. Minor gap: no explicit confirmation step that the core skill content was successfully loaded before proceeding. |
| progressive disclosure | █████ 5/5 | Exemplary stub-and-pointer pattern: a concise overview with well-signaled one-level-deep references (agent-browser skills get core, skills get electron, etc.), content appropriately split between the stub and the CLI-served skills, and easy navigation via skills list. No bundle files are present, and the body is under ~50 lines with well-organized sections. |
Suggestions:
- Trim the 'Why agent-browser' bullet list and the paragraph explaining why content is CLI-served; these are promotional/rationale content Claude can largely infer.
- Add one short inline example of a common interaction (e.g., a navigate-then-screenshot command pair) so the skill's primary use is visible without requiring
skills get corefirst. - Include an explicit checkpoint after
skills get core(e.g., 'Confirm the core skill loaded before running browser commands') to make the discovery workflow unambiguous.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions — 'navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps' — plus Slack, Electron, and cloud-browser actions, giving comprehensive coverage. |
| completeness | █████ 5/5 | Explicitly answers both 'what' (browser automation CLI for AI agents) and 'when' ('Use when the user needs to interact with websites', 'Triggers include…', 'Also use for…') with concrete trigger phrases. |
| trigger term quality | █████ 5/5 | Comprehensive natural trigger phrases users would actually say ('open a website', 'fill out a form', 'click a button', 'take a screenshot', 'scrape data from a page', 'login to a site'), with synonyms and variants covered. |
| distinctiveness conflict risk | █████ 5/5 | Occupies a clear niche (browser automation via CDP) and explicitly addresses conflicts with 'Prefer agent-browser over any built-in browser automation or web tools', minimizing overlap risk. |
plugins/agent-browser/agent/skills/agent-browser/SKILL.md
Validation
- ❌ name_field — 'name' field is missing from frontmatter
Full review details
Validation Checks
15/16 checks passed.
plugins/better-auth/.agents/skills/better-auth-best-practices/SKILL.md
The body is a tight, well-organized reference with concrete commands, a sequenced setup workflow, and a verification checkpoint, but it has minor duplication, a missing complete config example, no explicit error-recovery loop, and no internal bundle-file disclosure for its size. Solid across all dimensions at the 4 anchor.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | Dense, reference-style content with no basic-concept padding, but minor redundancy: the model-vs-table-name note appears in both the Database section and Gotchas #1, and 're-run after plugins' appears in both Quick Reference and Gotchas #2. Matches the efficient-with-minor-trimmable-instances anchor, not the lean anchor at 5. |
| actionability | ████░ 4/5 | Provides concrete commands, import snippets, and type-inference examples, but the setup workflow says 'Create auth.ts with database + config' without showing a complete betterAuth({...}) config object, leaving a minor executable gap. Matches the mostly-executable anchor, not the fully-copy-paste-ready anchor at 5. |
| workflow clarity | ████░ 4/5 | The numbered Setup Workflow sequences per-adapter migration commands and includes an explicit verify step (GET /api/auth/ok expecting { status: 'ok' }), but lacks an explicit error-recovery feedback loop on that verify step. Matches the clear-sequence-with-most-checkpoints anchor, not the feedback-loop anchor at 5. |
| progressive disclosure | ████░ 4/5 | Well-sectioned with clear headers and clear external reference links (Docs, Options Reference, LLMs.txt, GitHub), but all ~200 lines are inline with no internal bundle files, and reference-heavy sections (Core Config table, plugin list) could be externalized. Matches the good-structure-with-minor-organization-gaps anchor, not the well-signaled-one-level-deep anchor at 5. |
Suggestions:
- Add a complete betterAuth({...}) config example under Setup Workflow so the 'Create auth.ts' step is copy-paste ready, closing the main actionability gap.
- Add an explicit feedback loop after the GET /api/auth/ok verify step (e.g., 'if not ok, check BETTER_AUTH_SECRET/BETTER_AUTH_URL and basePath, then retry') to push workflow_clarity toward 5.
- Dedupe the model-vs-table-name and re-run-after-plugins notes so each appears once, and consider moving the Core Config Options table and plugin list into reference bundle files to improve conciseness and progressive_disclosure.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists five concrete actions (configure server/client, set up database adapters, manage sessions, add plugins, handle environment variables), matching the comprehensive-coverage anchor rather than the minor-gaps anchor at 4. |
| completeness | █████ 5/5 | Explicitly answers both 'what' (configure…handle environment variables) and 'when' (a 'Use when…' clause with concrete trigger phrases), matching the anchor that requires both clearly and explicitly. |
| trigger term quality | █████ 5/5 | Covers natural terms plus synonyms and file references — 'Better Auth', 'betterauth', 'auth.ts', 'TypeScript authentication', 'email/password', 'OAuth', 'plugin configuration' — matching the comprehensive-coverage anchor. |
| distinctiveness conflict risk | █████ 5/5 | Targets a named library niche with distinct triggers ('Better Auth', 'auth.ts') and minimal overlap risk with other skills, matching the clear-niche anchor. |
plugins/better-auth/.agents/skills/email-and-password-best-practices/SKILL.md
A solid, mostly executable reference: concrete code throughout, a sequenced Quick Start with a verification step, and clean sectioning. It falls short of 5 mainly due to a vague Client Side Validation stub, missing error-recovery feedback loops, and no progressive disclosure into reference files.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | Mostly lean and code-driven with brief, useful notes rather than basic-concept padding; the standalone 'Client Side Validation' sentence with no example and a few restating Notes are minor trim opportunities. |
| actionability | ████░ 4/5 | Provides concrete, copy-paste-ready better-auth config and API call examples across all major topics; the bare 'Client Side Validation' section and a couple of '// your logic here' placeholders are minor gaps. |
| workflow clarity | ████░ 4/5 | The Quick Start gives a clear 5-step sequence ending in an explicit verification checkpoint ('attempt sign-up and confirm verification email triggers'), but lacks a validate-fix-retry feedback loop for the security-sensitive reset flow. |
| progressive disclosure | ████░ 4/5 | Well-organized into clearly headed sections with no nested references and no bundle files to navigate; the comprehensive reset/hashing material is all inline in a single ~200-line file, a minor organization gap. |
Suggestions:
- Replace the bare 'Client Side Validation' sentence with a concrete client-side validation code example (e.g. authClient checks before signUp) to lift actionability.
- Add an explicit validate -> fix -> retry feedback loop to the password reset / migration workflows, since these are security-sensitive operations that currently cap workflow clarity.
- Consider moving the detailed Password Reset and Password Hashing reference material into a separate reference file linked from a concise overview, to improve progressive disclosure.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists four concrete, distinct actions — 'Configure email verification, implement password reset flows, set password policies, and customise hashing algorithms' — giving comprehensive coverage of the email/password domain. |
| completeness | █████ 5/5 | Explicitly answers both 'what' (the four configuration actions) and 'when' via a clear 'Use when users need to set up...' clause with concrete trigger phrases. |
| trigger term quality | ████░ 4/5 | Good natural-term coverage with 'login, sign-in, sign-up, credential authentication, password security', but omits common variations users say such as 'forgot password', 'email login', or '2FA/account registration', leaving a few synonyms missing. |
| distinctiveness conflict risk | █████ 5/5 | Scoped tightly to 'Better Auth email/password authentication' with triggers tied to that library, giving a clear niche and minimal conflict risk with other skills. |
plugins/better-auth/.agents/skills/organization-best-practices/SKILL.md
A code-dense, accurate reference for the Better Auth organization plugin with strong actionability, weakened by repeated config boilerplate, a redundant final example, missing validation loops around destructive operations, and a monolithic single-file structure.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ███░░ 3/5 | Prose is lean and assumes competence (no 'what is RBAC' filler), but the full betterAuth({ plugins: [organization({...})] }) wrapper is repeated across Setup, Invitations, Teams, DAC, and a redundant 'Complete Configuration Example' that re-covers already-shown options — a clear tightening opportunity. |
| actionability | ████░ 4/5 | Most sections give copy-paste-ready TypeScript covering the common cases (create org, invite, set active, add member, create role/team, hooks, schema), but several methods (removeMember, updateMemberRole, getFullOrganization, addTeamMember, updateRole, deleteRole) are only named without code, leaving minor gaps. |
| workflow clarity | ███░░ 3/5 | Setup is a clear 4-step sequence with a verify checkpoint ('check that organization, member, invitation tables exist'), but destructive operations (organization deletion, ownership transfer, member removal) lack validate→fix→retry feedback loops, capping the score per the destructive-operation rule. |
| progressive disclosure | ███░░ 3/5 | No bundle files exist and the body references none; everything lives in one ~474-line file with good headers, but substantial sections (Teams, Dynamic Access Control, Lifecycle Hooks, Schema Customization) are inlined that, for a skill this size, would benefit from one-level-deep reference files. |
Suggestions:
- Collapse the repeated
betterAuth({ plugins: [organization({...})] })wrapper into one canonical config and have later sections show only the relevant option snippet; remove or trim the 'Complete Configuration Example' since it re-covers existing material. - Add explicit validation feedback loops for destructive operations — e.g., before deletion, check ownership transfer succeeded and confirm no members remain; before role removal, verify the role is unassigned.
- Extract the larger reference sections (Teams, Dynamic Access Control, Lifecycle Hooks, Schema Customization) into one-level-deep reference files (e.g. TEAMS.md, HOOKS.md) and link them from SKILL.md to improve progressive disclosure.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions — 'Configure multi-tenant organizations, manage members and invitations, define custom roles and permissions, set up teams, and implement RBAC' — giving comprehensive coverage of the plugin's capability surface. |
| completeness | █████ 5/5 | Explicitly answers both 'what' (the enumerated configuration/management actions) and 'when' ('Use when users need org setup, team management, member roles, access control, or the Better Auth organization plugin') with concrete trigger phrases. |
| trigger term quality | ████░ 4/5 | The 'Use when' clause surfaces natural phrases ('org setup, team management, member roles, access control'), but a few common synonyms (e.g. 'invites', 'groups', 'permissions') are missing relative to the anchor 5 example. |
| distinctiveness conflict risk | █████ 5/5 | Tightly scoped to 'Better Auth's organization plugin' with that exact phrase as a trigger, creating a clear niche with minimal overlap risk against other skills. |
plugins/better-auth/.agents/skills/two-factor-authentication-best-practices/SKILL.md
A dense, executable reference: nearly every section is copy-paste-ready code with inline default-value comments, and the file is well-organized with no nested references. The only gap is the absence of explicit validation/feedback-loop steps for the enable and verify flows, which keeps workflow clarity just below full marks.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | █████ 5/5 | Lean throughout — short setup steps, minimal prose, executable code blocks with inline comments for defaults; it assumes Claude's competence and avoids explaining what 2FA or libraries are, with every section earning its place. |
| actionability | █████ 5/5 | Code is copy-paste ready across all flows — enabling 2FA, verifying TOTP, configuring OTP delivery and storage, regenerating/using backup codes, sign-in redirect handling, disabling — with concrete client calls and a complete consolidated config example. |
| workflow clarity | ████░ 4/5 | The sign-in flow is a clear numbered sequence and Setup includes a 'Verify' step (check twoFactorSecret column), but there are no explicit validation checkpoints for the enable/verify flows themselves; mostly clear with minor validation gaps. |
| progressive disclosure | █████ 5/5 | Single-file SKILL.md (~330 lines) well-organized into logical sections (Setup, TOTP, OTP, Backup Codes, Sign-In, Security, Disabling) with no nested references and no bundle files needed; the simple-skill exception applies — well-organized sections score 5. |
Suggestions:
- Add an explicit verification checkpoint after enabling 2FA (e.g., confirm twoFactorEnabled is true after the first successful TOTP verify) to strengthen the enable workflow's validation loop.
- For the sign-in flow, document the error/failure branch (what to do when verification fails or the user lacks 2FA) so the multi-step process has a feedback loop rather than only the happy path.
- Consolidate the repeated 'twoFactor({...})' option blocks (TOTP/OTP/backup/security) since the Complete Configuration Example already unifies them, reducing redundancy.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions — 'Configure TOTP authenticator apps, send OTP codes via email/SMS, manage backup codes, handle trusted devices, and implement 2FA sign-in flows' — covering the full 2FA domain comprehensively, matching the 'multiple specific concrete actions; comprehensive coverage' anchor. |
| completeness | █████ 5/5 | Explicitly answers both 'what' (the enumerated capabilities) and 'when' ('Use when users need MFA, multi-factor authentication, authenticator setup, or login security with Better Auth') with concrete trigger phrases. |
| trigger term quality | ████░ 4/5 | Includes strong natural terms ('MFA, multi-factor authentication, authenticator setup, login security, 2FA'), but lacks common synonym variations like 'two-factor' spelled out or specific file/extension-style triggers; good coverage with a few natural terms missing. |
| distinctiveness conflict risk | █████ 5/5 | Scoped to 'Better Auth's twoFactor plugin' with a clear niche (2FA in a specific framework), giving it distinct triggers and minimal conflict risk with other skills. |
plugins/better-auth/agent/skills/better-auth-best-practices/SKILL.md
Validation
- ❌ name_field — 'name' field is missing from frontmatter
Full review details
Validation Checks
15/16 checks passed.
plugins/better-auth/agent/skills/email-and-password-best-practices/SKILL.md
Validation
- ❌ name_field — 'name' field is missing from frontmatter
Full review details
Validation Checks
15/16 checks passed.
plugins/better-auth/agent/skills/organization-best-practices/SKILL.md
Validation
- ❌ name_field — 'name' field is missing from frontmatter
Full review details
Validation Checks
15/16 checks passed.
plugins/better-auth/agent/skills/two-factor-authentication-best-practices/SKILL.md
Validation
- ❌ name_field — 'name' field is missing from frontmatter
Full review details
Validation Checks
15/16 checks passed.
plugins/dev3000/.agents/skills/d3k/SKILL.md
An actionable, well-sequenced runtime skill with strong validation and error-recovery loops. Slight conciseness redundancy and the absence of any reference structure keep two dimensions at 4 rather than 5.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| 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 strong, executable reference for the emulate tool: concrete commands and code throughout and clear navigation to sibling skills. Weak spots are repeated base-URL priority wording, the lack of an explicit validated workflow, and a large inlined config block that has no companion reference 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 reference material (commands, tables, config) with little concept padding, but the baseUrl override priority order is restated in three places (CLI options, programmatic options, portless section), which could be consolidated. Not a 5 due to that repetition; not a 3 because the bulk is tight and executable. |
| actionability | █████ 5/5 | Copy-paste-ready throughout: 'npx emulate' quick start, full CLI flag table, executable TypeScript createEmulator examples, a Vitest/Jest setup block, and a complete seed-config YAML covering the common cases. |
| workflow clarity | ███░░ 3/5 | Section ordering implies an adoption flow (start → configure → integrate → persist) but there is no explicit sequenced multi-step workflow with validation checkpoints for Claude to follow; the skill is reference-oriented rather than workflow-oriented, fitting the score-3 anchor. |
| progressive disclosure | ████░ 4/5 | Well-organized sections with clearly signaled one-level-deep references to the next and nuxt skills; the main gap is a large inlined seed-config block and absence of any bundle reference file that could hold per-service detail. Good structure with minor organization gaps rather than the clean overview-plus-references of a 5. |
Suggestions:
- State the baseUrl override priority order once (e.g. in the Programmatic API options table) and reference it from the CLI and portless sections instead of restating it three times.
- Add a short numbered 'Getting started' workflow with an explicit verification checkpoint (e.g. 'curl http://localhost:4001' or hit /_emulate/installation-tokens) so Claude can confirm services are up before integrating.
- Move the per-service seed-config detail into a references/CONFIG.md (or per-service files) and keep only a minimal representative example inline, improving progressive disclosure now that no bundle files exist.
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' — covering the skill comprehensively, matching the score-5 anchor. |
| completeness | █████ 5/5 | Clearly answers both 'what' ('Local drop-in API emulator for Vercel, GitHub...') and 'when' ('Use when the user needs to... Triggers include...') with concrete trigger phrases, matching the score-5 anchor exactly. |
| trigger term quality | █████ 5/5 | Explicitly enumerates natural trigger phrases users would say — 'start the emulator', 'emulate services', 'mock API locally', 'create emulator config', 'test against local API', 'npx emulate' — giving comprehensive coverage including the CLI invocation. |
| distinctiveness conflict risk | █████ 5/5 | A clear niche — local emulation of specific developer APIs — with distinct triggers ('emulate', 'npx emulate', 'mock API locally') that minimize overlap with unrelated skills. |
plugins/emulate/.agents/skills/github/SKILL.md
The body is a dense, highly actionable API reference with excellent executable examples and clear multi-step flows, but it is a large monolithic document that would benefit from splitting the per-endpoint reference into bundled reference files rather than inlining everything in SKILL.md.
Validation
⚠️ skill_md_line_count — SKILL.md is long (627 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 mostly efficient reference material with executable curl/typescript snippets and little conceptual padding, but the extended sections on generated-secrets ACL handling (lines 56-65) and the installation-token inspection route (lines 614-618) read as more detail than Claude needs in the top-level overview. |
| actionability | █████ 5/5 | Nearly every endpoint family is shown with copy-paste-ready curl commands carrying concrete URLs, headers, and JSON bodies, plus programmatic TypeScript/seed examples covering start, auth, and OAuth flows. |
| workflow clarity | ████░ 4/5 | Multi-step flows like the GitHub App installation-token flow (lines 599-616) and OAuth flow (lines 620-626) are clearly sequenced with numbered steps, and delete semantics note cascade behavior, but there is no explicit validate-after-write checkpoint for destructive operations (e.g., confirming a PR merge applied branch protection as intended). |
| progressive disclosure | ███░░ 3/5 | The content is well sectioned but is a single monolithic SKILL.md with all endpoint documentation inlined and no references/ or scripts/ bundle files to offload the long API reference; per the rubric's judging guidance, progressive_disclosure should be scored against the actual (empty) bundle structure, so this lands as 'structure present but bulk that could be separate is inline'. |
Suggestions:
- Move the per-endpoint API reference (Users, Repositories, Issues, PRs, Comments, etc.) into a bundled reference file (e.g. references/endpoints.md) and keep SKILL.md as a concise overview pointing to it, improving progressive disclosure.
- Add an explicit validation checkpoint after destructive operations (e.g., after a DELETE or PR merge, fetch the affected resource to confirm the expected state) to strengthen workflow clarity for risky actions.
- Trim the generated-secrets ACL and installation-token inspection detail in the top-level overview, linking to a dedicated reference for those edge-case behaviors.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | ████░ 4/5 | Lists multiple concrete actions — 'interact with GitHub API endpoints locally', 'emulate repos/issues/PRs', 'set up GitHub OAuth flows', 'configure GitHub Apps', 'test webhooks', 'work with actions/checks' — but stops just short of fully comprehensive, leaving minor coverage gaps around Gists, Git Data refs/trees, and search. |
| completeness | █████ 5/5 | Clearly answers both 'what' ('Emulated GitHub REST API for local development and testing') and 'when' via an explicit 'Use when...' clause plus enumerated 'Triggers include...' phrases with concrete trigger terms. |
| trigger term quality | █████ 5/5 | Comprehensive natural-term coverage with synonyms and likely user phrasings — 'GitHub API', 'emulate GitHub', 'mock GitHub', 'test GitHub OAuth', 'GitHub App JWT', 'local GitHub' — closely matching the rubric's anchor for full coverage including common variations. |
| distinctiveness conflict risk | █████ 5/5 | Occupies a clear niche — local GitHub API emulation/mocking — with distinct triggers unlikely to fire for unrelated skills, and the 'without hitting the real GitHub API' framing sharpens its boundary against any real-GitHub tooling skill. |
plugins/emulate/.agents/skills/linear/SKILL.md
A well-structured, actionable reference for the Linear emulator: executable start/auth commands, a concrete seed config, and a tidy GraphQL/OAuth surface. It assumes Claude's competence and avoids concept padding, with only minor conciseness and workflow-checkpoint gaps.
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 and operational with no concept explanations, though the GraphQL surface and mutation listings are lengthy; a few lines could be tightened. |
| actionability | █████ 5/5 | Provides copy-paste ready commands (npx emulate --service linear), a full executable curl example with headers, and a concrete seed-config YAML covering common cases. |
| workflow clarity | ████░ 4/5 | The start action is unambiguous and reference sections are well ordered, but it is a reference skill without an explicit multi-step workflow or validation checkpoints. |
| progressive disclosure | ████░ 4/5 | Single well-organized SKILL.md with clear section headers and no nested references; slightly above 50 lines so not a perfect 5 under the simple-skill exception. |
Suggestions:
- Consider moving the full GraphQL query/mutation lists into a separate reference file, keeping SKILL.md as a lean overview with the most common operations inline.
- Add a short validation step (e.g. how to confirm the emulator is running and reachable) after the Start command to strengthen workflow clarity.
- Tighten the OAuth actor paragraph and Current Limits list into punchier bullets to trim a few tokens.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists concrete emulated entities and actions (issues, comments, teams, workflow states, OAuth apps, webhooks, agent sessions) with comprehensive coverage of the Linear surface. |
| completeness | █████ 5/5 | Explicitly answers both what ('Emulated Linear GraphQL API for local development and testing') and when ('Use when the user needs to test Linear integrations locally...') with concrete trigger phrases. |
| trigger term quality | █████ 5/5 | Provides extensive natural trigger phrases including synonyms ('emulate Linear', 'mock Linear', 'local Linear') and specific scenarios ('test Linear OAuth', 'Linear webhook', 'Linear agent'). |
| distinctiveness conflict risk | █████ 5/5 | Occupies a clear Linear-specific niche with Linear-branded triggers, making conflict with other skills minimal. |
plugins/emulate/.agents/skills/next/SKILL.md
A strong, action-oriented skill body with executable code throughout and clear structural organization. The main weakness is mild redundancy in the persistence examples; progressive disclosure is fine for a single-file skill but could factor out the reference tables if the document grows.
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 | Efficient and assumes Claude's knowledge of Next.js/Auth.js without padding, but the createEmulateHandler call is repeated in the Persistence section and the config tables slightly restate inline examples; minor trimming possible. |
| actionability | █████ 5/5 | Fully executable, copy-paste-ready TypeScript for the route handler, Auth.js provider config, withEmulate wrapping, and persistence adapters, supplemented by concrete config-reference tables. |
| workflow clarity | ████░ 4/5 | Sections are clearly sequenced (Install → Route Handler → Auth → Font tracing → Persistence → How It Works) and the request lifecycle is enumerated; no destructive/batch operations need validation checkpoints, though explicit verification of the mounted route is only implied. |
| progressive disclosure | ████░ 4/5 | No bundle files exist; all content lives in a single well-organized file with clear section headers and inline reference tables, which is appropriate for a self-contained skill of this size, though the Config Reference could conceivably be split out. |
Suggestions:
- In the Persistence section, show only the persistence-adapter delta (the kvAdapter object and the persistence field) instead of repeating the full createEmulateHandler call to reduce redundancy.
- Add a brief verification step after the Route Handler section (e.g., curl the /emulate/github/_emulate/installation-tokens endpoint or start the dev server) so users can confirm the catch-all route is mounted.
- If the Config Reference tables grow, consider moving them to a references/ file and linking from the body to keep the main SKILL.md as a lean overview.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | █████ 5/5 | Lists multiple concrete actions — embedding emulators, same-origin OAuth setup, catch-all route handler creation, Auth.js/NextAuth configuration, persistence, and withEmulate config wrapping — giving comprehensive coverage of capabilities. |
| completeness | █████ 5/5 | Explicitly answers 'what' (Next.js adapter for embedding emulators via @emulators/adapter-next) and 'when' (Use when the user needs to embed emulators...) with concrete trigger phrases. |
| trigger term quality | █████ 5/5 | Comprehensive natural triggers including quoted phrases ('Next.js emulator', 'embedded emulator', 'same-origin OAuth', 'Vercel preview') alongside API names a user would naturally reference. |
| distinctiveness conflict risk | █████ 5/5 | A clear niche — emulators embedded inside a Next.js app via a specific package — with distinct triggers and minimal risk of firing for unrelated 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 (624 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/linear/SKILL.md
Validation
- ❌ name_field — 'name' field is missing from frontmatter
Full review details
Validation Checks
15/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
A well-structured reference skill that assumes Claude's competence, leads with executable commands and complete code examples, and points feature details to one-level-deep doc URLs. The main gap is that several feature sections (Comments, Tracked changes, Import/Export) are link-only with no inline starter guidance.
Full review details
Validation Checks
16/16 checks passed.
Review Details
| Dimension | Score | Detail |
|---|---|---|
| conciseness | ████░ 4/5 | Mostly lean and assumes competence (e.g. 'Avoid cloning. You usually don't need to.'), with the cautionary intro earning its place; a few sentences such as 'This is not the Tiptap editor you know...' could be tightened, keeping it just below the every-token-earns-its-place 5 anchor. |
| actionability | ████░ 4/5 | Provides concrete executable guidance — 'npm view @tiptap/core version', a copy-paste git clone command, and complete Collaboration/TiptapCollabProvider code blocks — with minor gaps where feature sections only link out without inline examples. |
| workflow clarity | ████░ 4/5 | Clear sequences for finding source/docs and best-practice rules with explicit decision guidance ('Clone only for source... you cannot get either way'), and no destructive/batch operation that would trigger the validation cap; minor checkpoint gaps keep it at 4 rather than 5. |
| progressive disclosure | ████░ 4/5 | Well-organized into clear sections with one-level-deep, clearly signaled external doc references; no bundle files exist so all content lives appropriately in SKILL.md, but it exceeds the simple-skill threshold that would allow a 5 on structure alone. |
Suggestions:
- Add a one-line starter snippet or the key extension name to each link-only feature section (Comments, Tracked changes, Import/Export, Pages) so Claude can begin without fetching the doc first.
- Tighten the opening paragraphs (e.g. 'This is not the Tiptap editor you know...') into a single concise caution line to improve token efficiency.
- For the collaboration setup, add an explicit verification step (e.g. confirm the provider connection status before declaring the feature wired up) to add a checkpoint to the only multi-step code workflow.
Description Review
| Dimension | Score | Detail |
|---|---|---|
| specificity | ████░ 4/5 | Lists several concrete actions — 'building or modifying a rich text editor with Tiptap, installing Tiptap extensions, or implementing features like collaboration, comments, AI, or document conversion' — but the 'implementing features like...' phrasing stays slightly abstract, so it sits just below the comprehensive 5 anchor. |
| completeness | █████ 5/5 | Explicitly answers what ('Helps coding agents integrate and work with the Tiptap rich text editor') and when ('Use when building or modifying... installing Tiptap extensions, or implementing features like...'), matching the anchor that requires both with concrete trigger phrases. |
| trigger term quality | ████░ 4/5 | Includes natural terms users would say ('rich text editor', 'Tiptap', 'Tiptap extensions', 'collaboration', 'comments') with good coverage, but misses common synonyms like 'WYSIWYG' that would push it to 5. |
| distinctiveness conflict risk | █████ 5/5 | Targets a clear niche (the Tiptap editor specifically) with distinct triggers ('with Tiptap', 'Tiptap extensions'), giving minimal overlap risk with other skills. |
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.
pleaseai-release-bot
Bot
force-pushed
the
chore/update-skills
branch
from
September 7, 2026 06:30
373ebe4 to
cce6e51
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/agent-browserplugins/better-authplugins/dev3000plugins/emulateplugins/eveplugins/portlessplugins/react-nativeplugins/reactplugins/shadcn-uiplugins/tiptapplugins/turborepoplugins/vercel-sandboxGenerated by
.github/workflows/update-skills.yml→scripts/update-skills.ts.