@vibe-agent-toolkit/vat-development-agents 0.1.32-rc.2 → 0.1.32-rc.3

package/dist/.claude/plugins/marketplaces/vat-skills/CHANGELOG.md

@@ -27,6 +27,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Fixed
 - `vat audit --compat` now honors config-layer `targets` declared in `vibe-agent-toolkit.config.yaml`, matching `vat skills validate` verdicts inside a VAT project. Previously only `plugin.json` / `marketplace.json` targets flowed into plugin-level compat analysis. Multi-skill plugins use the union of every in-plugin skill's targets.
+- `skill-quality-checklist.md`: description-opener rule no longer contradicts Anthropic's official skill-description guidance. `Use when <concrete trigger>` is now explicitly allowed (it's the recommended pattern); only vague filler like `Use when you want to...` / `Use when you need to...` is banned. Prior wording banned all `Use when...` openers, which contradicted VAT's own authoring guidance.
 
 ### Removed
 - **BREAKING:** `COMPAT_REQUIRES_BROWSER_AUTH`, `COMPAT_REQUIRES_LOCAL_SHELL`, `COMPAT_REQUIRES_EXTERNAL_CLI` codes (replaced by `CAPABILITY_*` + `COMPAT_TARGET_*`).

package/dist/.claude/plugins/marketplaces/vat-skills/plugins/vibe-agent-toolkit/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "vibe-agent-toolkit",
   "description": "Development agents and skills for building with vibe-agent-toolkit",
-  "version": "0.1.32-rc.2",
+  "version": "0.1.32-rc.3",
   "author": {
     "name": "vibe-agent-toolkit contributors"
   }

package/dist/.claude/plugins/marketplaces/vat-skills/plugins/vibe-agent-toolkit/skills/authoring/resources/skill-quality-checklist.md

@@ -6,7 +6,7 @@ Work through this checklist before publishing a skill. Items are grouped into ge
 
 - [ ] **Name**: short, specific, lowercase-with-hyphens. Matches what the skill does, not how.
 - [ ] **Description — trigger keywords first**: lead with the concepts that should trigger this skill. Claude truncates descriptions aggressively — the most important words must come first. "Sprint analysis, velocity tracking, work item queries" not "This skill is used for when you need to analyze sprints."
-- [ ] **Description — no filler openers, third-person voice**: never start with "This skill...", "A skill that...", "Used to...", "Use when you want to..." — these waste the first tokens on zero-information words. Avoid first/second person ("I can help...", "You can use...") — Anthropic guidance is third person throughout.
+- [ ] **Description — no filler openers, third-person voice**: never start with "This skill...", "A skill that...", "Used to..." — these waste the first tokens on zero-information words. Avoid first/second person ("I can help...", "You can use...") — Anthropic guidance is third person throughout. `Use when <concrete trigger>` is the recommended pattern (matches Anthropic's official skill-description guidance); what's banned is vague filler like `Use when you want to...` or `Use when you need to...` — those don't name a trigger, they just add words.
 - [ ] **Description ≤250 characters**: Claude Code truncates descriptions at 250 characters in the `/skills` listing (since v2.1.86). Aim for ≤200 chars for safety; ≤130 chars if shipping a large skill collection (60+ skills) so the total budget fits.
 - [ ] **Purpose statement in first 3 lines**: an agent skimming the top of SKILL.md should understand what it does and when to use it without reading further.
 - [ ] **SKILL.md body ≤500 lines**: Anthropic recommends keeping SKILL.md under 500 lines. Split detailed content into reference files when approaching the limit.

package/dist/generated/resources/skills/skill-quality-checklist.js

@@ -4,13 +4,13 @@
 
 export const meta = {};
 
-export const text = "# Skill Quality Checklist\n\nWork through this checklist before publishing a skill. Items are grouped into general (all skills) and CLI-backed (skills that bundle and invoke scripts).\n\n## General — All Skills\n\n- [ ] **Name**: short, specific, lowercase-with-hyphens. Matches what the skill does, not how.\n- [ ] **Description — trigger keywords first**: lead with the concepts that should trigger this skill. Claude truncates descriptions aggressively — the most important words must come first. \"Sprint analysis, velocity tracking, work item queries\" not \"This skill is used for when you need to analyze sprints.\"\n- [ ] **Description — no filler openers, third-person voice**: never start with \"This skill...\", \"A skill that...\", \"Used to...\", \"Use when you want to...\" — these waste the first tokens on zero-information words. Avoid first/second person (\"I can help...\", \"You can use...\") — Anthropic guidance is third person throughout.\n- [ ] **Description ≤250 characters**: Claude Code truncates descriptions at 250 characters in the \`/skills\` listing (since v2.1.86). Aim for ≤200 chars for safety; ≤130 chars if shipping a large skill collection (60+ skills) so the total budget fits.\n- [ ] **Purpose statement in first 3 lines**: an agent skimming the top of SKILL.md should understand what it does and when to use it without reading further.\n- [ ] **SKILL.md body ≤500 lines**: Anthropic recommends keeping SKILL.md under 500 lines. Split detailed content into reference files when approaching the limit.\n- [ ] **Single responsibility**: the skill does one thing well. If it has multiple unrelated sections, consider splitting into separate skills.\n- [ ] **Consistent terminology**: pick one term per concept and use it throughout. Switching between synonyms (\"artifact\" vs \"bundle\" vs \"package\") confuses agents.\n- [ ] **No time-sensitive content**: avoid \"as of November 2025\" or \"use the new API after July 2026\". Route deprecated guidance into a clearly labeled \"old patterns\" section so agents skip it.\n- [ ] **Every bundled file is referenced**: if a file is in the package, some markdown file should link to it or explain what it is. Dead files confuse agents and waste context.\n- [ ] **References one level deep**: link reference files directly from SKILL.md, not via intermediate hubs. Claude does partial reads on nested references and may miss content several hops down.\n- [ ] **TOC on reference files >100 lines**: long reference files should include a table of contents at the top. Claude often previews with partial reads — a TOC ensures the full scope of available content is visible.\n- [ ] **All links resolve**: every \`[text](path)\` link points to a file that exists. Run \`vat verify\` to check.\n- [ ] **Build clean**: \`vat skills build\` succeeds and \`vat verify\` passes with zero errors.\n- [ ] **Test the trigger**: ask yourself \"if an agent sees only this name and description, will it know when to load this skill?\" If you need to read the SKILL.md to understand the description, the description is wrong.\n\n## CLI-Backed Skills — Additional Checks\n\nThese apply to skills that bundle executable scripts and instruct agents to run commands.\n\n- [ ] **Environment guard**: the skill checks that the CLI binary exists before running commands (e.g., verify \`scripts/cli.mjs\` is present). Agents should get a clear error, not a cryptic Node.js stack trace.\n- [ ] **Pre-flight auth check**: if the CLI requires credentials or tokens, the skill verifies them before operations. Fail fast with clear guidance on how to authenticate.\n- [ ] **CLI invocation section**: provide exact command patterns with placeholder arguments. Agents copy these verbatim — ambiguous prose gets misinterpreted.\n- [ ] **Error handling guidance**: document what to do when the CLI fails. Which errors are retryable? When should the agent stop and ask the user?\n- [ ] **No bare command names in prose or tables**: agents may try to execute anything that looks like a command. Wrap command references in context or use code blocks with clear framing.\n- [ ] **Cross-platform commands**: avoid \`timeout\` (not on macOS), platform-specific \`sed\` flags, \`grep -P\`, and other non-portable utilities. If platform-specific, document alternatives.\n- [ ] **\`files\` config declares CLI binaries**: use \`files\` entries in \`vibe-agent-toolkit.config.yaml\` so VAT copies scripts into the skill package at build time. Don\'t rely on external copy scripts.\n- [ ] **Document bundled assets and templates**: if scripts reference files programmatically (not via markdown links), explain what\'s bundled and why in the SKILL.md. The consuming agent should understand the full package contents.\n\n## Using This Checklist\n\nThis is a living document. When a new failure pattern is discovered in skill authoring, add a checklist item here. The goal is shift-left: catch issues before they ship rather than debugging them in production.\n\nItems marked as checks (not automated validation) are judgment calls that tooling can\'t fully enforce. An agent or human reviews them manually. Items that _can_ be automated are already enforced by \`vat verify\` — this checklist covers the gaps.\n\nReviewed against external best practices (Anthropic skills documentation, anthropics/skills repository, superpowers conventions, Claude Code release notes through 2026-04-15) before initial publication.\n";
+export const text = "# Skill Quality Checklist\n\nWork through this checklist before publishing a skill. Items are grouped into general (all skills) and CLI-backed (skills that bundle and invoke scripts).\n\n## General — All Skills\n\n- [ ] **Name**: short, specific, lowercase-with-hyphens. Matches what the skill does, not how.\n- [ ] **Description — trigger keywords first**: lead with the concepts that should trigger this skill. Claude truncates descriptions aggressively — the most important words must come first. \"Sprint analysis, velocity tracking, work item queries\" not \"This skill is used for when you need to analyze sprints.\"\n- [ ] **Description — no filler openers, third-person voice**: never start with \"This skill...\", \"A skill that...\", \"Used to...\" — these waste the first tokens on zero-information words. Avoid first/second person (\"I can help...\", \"You can use...\") — Anthropic guidance is third person throughout. \`Use when <concrete trigger>\` is the recommended pattern (matches Anthropic\'s official skill-description guidance); what\'s banned is vague filler like \`Use when you want to...\` or \`Use when you need to...\` — those don\'t name a trigger, they just add words.\n- [ ] **Description ≤250 characters**: Claude Code truncates descriptions at 250 characters in the \`/skills\` listing (since v2.1.86). Aim for ≤200 chars for safety; ≤130 chars if shipping a large skill collection (60+ skills) so the total budget fits.\n- [ ] **Purpose statement in first 3 lines**: an agent skimming the top of SKILL.md should understand what it does and when to use it without reading further.\n- [ ] **SKILL.md body ≤500 lines**: Anthropic recommends keeping SKILL.md under 500 lines. Split detailed content into reference files when approaching the limit.\n- [ ] **Single responsibility**: the skill does one thing well. If it has multiple unrelated sections, consider splitting into separate skills.\n- [ ] **Consistent terminology**: pick one term per concept and use it throughout. Switching between synonyms (\"artifact\" vs \"bundle\" vs \"package\") confuses agents.\n- [ ] **No time-sensitive content**: avoid \"as of November 2025\" or \"use the new API after July 2026\". Route deprecated guidance into a clearly labeled \"old patterns\" section so agents skip it.\n- [ ] **Every bundled file is referenced**: if a file is in the package, some markdown file should link to it or explain what it is. Dead files confuse agents and waste context.\n- [ ] **References one level deep**: link reference files directly from SKILL.md, not via intermediate hubs. Claude does partial reads on nested references and may miss content several hops down.\n- [ ] **TOC on reference files >100 lines**: long reference files should include a table of contents at the top. Claude often previews with partial reads — a TOC ensures the full scope of available content is visible.\n- [ ] **All links resolve**: every \`[text](path)\` link points to a file that exists. Run \`vat verify\` to check.\n- [ ] **Build clean**: \`vat skills build\` succeeds and \`vat verify\` passes with zero errors.\n- [ ] **Test the trigger**: ask yourself \"if an agent sees only this name and description, will it know when to load this skill?\" If you need to read the SKILL.md to understand the description, the description is wrong.\n\n## CLI-Backed Skills — Additional Checks\n\nThese apply to skills that bundle executable scripts and instruct agents to run commands.\n\n- [ ] **Environment guard**: the skill checks that the CLI binary exists before running commands (e.g., verify \`scripts/cli.mjs\` is present). Agents should get a clear error, not a cryptic Node.js stack trace.\n- [ ] **Pre-flight auth check**: if the CLI requires credentials or tokens, the skill verifies them before operations. Fail fast with clear guidance on how to authenticate.\n- [ ] **CLI invocation section**: provide exact command patterns with placeholder arguments. Agents copy these verbatim — ambiguous prose gets misinterpreted.\n- [ ] **Error handling guidance**: document what to do when the CLI fails. Which errors are retryable? When should the agent stop and ask the user?\n- [ ] **No bare command names in prose or tables**: agents may try to execute anything that looks like a command. Wrap command references in context or use code blocks with clear framing.\n- [ ] **Cross-platform commands**: avoid \`timeout\` (not on macOS), platform-specific \`sed\` flags, \`grep -P\`, and other non-portable utilities. If platform-specific, document alternatives.\n- [ ] **\`files\` config declares CLI binaries**: use \`files\` entries in \`vibe-agent-toolkit.config.yaml\` so VAT copies scripts into the skill package at build time. Don\'t rely on external copy scripts.\n- [ ] **Document bundled assets and templates**: if scripts reference files programmatically (not via markdown links), explain what\'s bundled and why in the SKILL.md. The consuming agent should understand the full package contents.\n\n## Using This Checklist\n\nThis is a living document. When a new failure pattern is discovered in skill authoring, add a checklist item here. The goal is shift-left: catch issues before they ship rather than debugging them in production.\n\nItems marked as checks (not automated validation) are judgment calls that tooling can\'t fully enforce. An agent or human reviews them manually. Items that _can_ be automated are already enforced by \`vat verify\` — this checklist covers the gaps.\n\nReviewed against external best practices (Anthropic skills documentation, anthropics/skills repository, superpowers conventions, Claude Code release notes through 2026-04-15) before initial publication.\n";
 
 export const fragments = {
   general-AllSkills: {
     header: "## General — All Skills",
-    body: "- [ ] **Name**: short, specific, lowercase-with-hyphens. Matches what the skill does, not how.\n- [ ] **Description — trigger keywords first**: lead with the concepts that should trigger this skill. Claude truncates descriptions aggressively — the most important words must come first. \"Sprint analysis, velocity tracking, work item queries\" not \"This skill is used for when you need to analyze sprints.\"\n- [ ] **Description — no filler openers, third-person voice**: never start with \"This skill...\", \"A skill that...\", \"Used to...\", \"Use when you want to...\" — these waste the first tokens on zero-information words. Avoid first/second person (\"I can help...\", \"You can use...\") — Anthropic guidance is third person throughout.\n- [ ] **Description ≤250 characters**: Claude Code truncates descriptions at 250 characters in the \`/skills\` listing (since v2.1.86). Aim for ≤200 chars for safety; ≤130 chars if shipping a large skill collection (60+ skills) so the total budget fits.\n- [ ] **Purpose statement in first 3 lines**: an agent skimming the top of SKILL.md should understand what it does and when to use it without reading further.\n- [ ] **SKILL.md body ≤500 lines**: Anthropic recommends keeping SKILL.md under 500 lines. Split detailed content into reference files when approaching the limit.\n- [ ] **Single responsibility**: the skill does one thing well. If it has multiple unrelated sections, consider splitting into separate skills.\n- [ ] **Consistent terminology**: pick one term per concept and use it throughout. Switching between synonyms (\"artifact\" vs \"bundle\" vs \"package\") confuses agents.\n- [ ] **No time-sensitive content**: avoid \"as of November 2025\" or \"use the new API after July 2026\". Route deprecated guidance into a clearly labeled \"old patterns\" section so agents skip it.\n- [ ] **Every bundled file is referenced**: if a file is in the package, some markdown file should link to it or explain what it is. Dead files confuse agents and waste context.\n- [ ] **References one level deep**: link reference files directly from SKILL.md, not via intermediate hubs. Claude does partial reads on nested references and may miss content several hops down.\n- [ ] **TOC on reference files >100 lines**: long reference files should include a table of contents at the top. Claude often previews with partial reads — a TOC ensures the full scope of available content is visible.\n- [ ] **All links resolve**: every \`[text](path)\` link points to a file that exists. Run \`vat verify\` to check.\n- [ ] **Build clean**: \`vat skills build\` succeeds and \`vat verify\` passes with zero errors.\n- [ ] **Test the trigger**: ask yourself \"if an agent sees only this name and description, will it know when to load this skill?\" If you need to read the SKILL.md to understand the description, the description is wrong.",
-    text: "## General — All Skills\n\n- [ ] **Name**: short, specific, lowercase-with-hyphens. Matches what the skill does, not how.\n- [ ] **Description — trigger keywords first**: lead with the concepts that should trigger this skill. Claude truncates descriptions aggressively — the most important words must come first. \"Sprint analysis, velocity tracking, work item queries\" not \"This skill is used for when you need to analyze sprints.\"\n- [ ] **Description — no filler openers, third-person voice**: never start with \"This skill...\", \"A skill that...\", \"Used to...\", \"Use when you want to...\" — these waste the first tokens on zero-information words. Avoid first/second person (\"I can help...\", \"You can use...\") — Anthropic guidance is third person throughout.\n- [ ] **Description ≤250 characters**: Claude Code truncates descriptions at 250 characters in the \`/skills\` listing (since v2.1.86). Aim for ≤200 chars for safety; ≤130 chars if shipping a large skill collection (60+ skills) so the total budget fits.\n- [ ] **Purpose statement in first 3 lines**: an agent skimming the top of SKILL.md should understand what it does and when to use it without reading further.\n- [ ] **SKILL.md body ≤500 lines**: Anthropic recommends keeping SKILL.md under 500 lines. Split detailed content into reference files when approaching the limit.\n- [ ] **Single responsibility**: the skill does one thing well. If it has multiple unrelated sections, consider splitting into separate skills.\n- [ ] **Consistent terminology**: pick one term per concept and use it throughout. Switching between synonyms (\"artifact\" vs \"bundle\" vs \"package\") confuses agents.\n- [ ] **No time-sensitive content**: avoid \"as of November 2025\" or \"use the new API after July 2026\". Route deprecated guidance into a clearly labeled \"old patterns\" section so agents skip it.\n- [ ] **Every bundled file is referenced**: if a file is in the package, some markdown file should link to it or explain what it is. Dead files confuse agents and waste context.\n- [ ] **References one level deep**: link reference files directly from SKILL.md, not via intermediate hubs. Claude does partial reads on nested references and may miss content several hops down.\n- [ ] **TOC on reference files >100 lines**: long reference files should include a table of contents at the top. Claude often previews with partial reads — a TOC ensures the full scope of available content is visible.\n- [ ] **All links resolve**: every \`[text](path)\` link points to a file that exists. Run \`vat verify\` to check.\n- [ ] **Build clean**: \`vat skills build\` succeeds and \`vat verify\` passes with zero errors.\n- [ ] **Test the trigger**: ask yourself \"if an agent sees only this name and description, will it know when to load this skill?\" If you need to read the SKILL.md to understand the description, the description is wrong."
+    body: "- [ ] **Name**: short, specific, lowercase-with-hyphens. Matches what the skill does, not how.\n- [ ] **Description — trigger keywords first**: lead with the concepts that should trigger this skill. Claude truncates descriptions aggressively — the most important words must come first. \"Sprint analysis, velocity tracking, work item queries\" not \"This skill is used for when you need to analyze sprints.\"\n- [ ] **Description — no filler openers, third-person voice**: never start with \"This skill...\", \"A skill that...\", \"Used to...\" — these waste the first tokens on zero-information words. Avoid first/second person (\"I can help...\", \"You can use...\") — Anthropic guidance is third person throughout. \`Use when <concrete trigger>\` is the recommended pattern (matches Anthropic\'s official skill-description guidance); what\'s banned is vague filler like \`Use when you want to...\` or \`Use when you need to...\` — those don\'t name a trigger, they just add words.\n- [ ] **Description ≤250 characters**: Claude Code truncates descriptions at 250 characters in the \`/skills\` listing (since v2.1.86). Aim for ≤200 chars for safety; ≤130 chars if shipping a large skill collection (60+ skills) so the total budget fits.\n- [ ] **Purpose statement in first 3 lines**: an agent skimming the top of SKILL.md should understand what it does and when to use it without reading further.\n- [ ] **SKILL.md body ≤500 lines**: Anthropic recommends keeping SKILL.md under 500 lines. Split detailed content into reference files when approaching the limit.\n- [ ] **Single responsibility**: the skill does one thing well. If it has multiple unrelated sections, consider splitting into separate skills.\n- [ ] **Consistent terminology**: pick one term per concept and use it throughout. Switching between synonyms (\"artifact\" vs \"bundle\" vs \"package\") confuses agents.\n- [ ] **No time-sensitive content**: avoid \"as of November 2025\" or \"use the new API after July 2026\". Route deprecated guidance into a clearly labeled \"old patterns\" section so agents skip it.\n- [ ] **Every bundled file is referenced**: if a file is in the package, some markdown file should link to it or explain what it is. Dead files confuse agents and waste context.\n- [ ] **References one level deep**: link reference files directly from SKILL.md, not via intermediate hubs. Claude does partial reads on nested references and may miss content several hops down.\n- [ ] **TOC on reference files >100 lines**: long reference files should include a table of contents at the top. Claude often previews with partial reads — a TOC ensures the full scope of available content is visible.\n- [ ] **All links resolve**: every \`[text](path)\` link points to a file that exists. Run \`vat verify\` to check.\n- [ ] **Build clean**: \`vat skills build\` succeeds and \`vat verify\` passes with zero errors.\n- [ ] **Test the trigger**: ask yourself \"if an agent sees only this name and description, will it know when to load this skill?\" If you need to read the SKILL.md to understand the description, the description is wrong.",
+    text: "## General — All Skills\n\n- [ ] **Name**: short, specific, lowercase-with-hyphens. Matches what the skill does, not how.\n- [ ] **Description — trigger keywords first**: lead with the concepts that should trigger this skill. Claude truncates descriptions aggressively — the most important words must come first. \"Sprint analysis, velocity tracking, work item queries\" not \"This skill is used for when you need to analyze sprints.\"\n- [ ] **Description — no filler openers, third-person voice**: never start with \"This skill...\", \"A skill that...\", \"Used to...\" — these waste the first tokens on zero-information words. Avoid first/second person (\"I can help...\", \"You can use...\") — Anthropic guidance is third person throughout. \`Use when <concrete trigger>\` is the recommended pattern (matches Anthropic\'s official skill-description guidance); what\'s banned is vague filler like \`Use when you want to...\` or \`Use when you need to...\` — those don\'t name a trigger, they just add words.\n- [ ] **Description ≤250 characters**: Claude Code truncates descriptions at 250 characters in the \`/skills\` listing (since v2.1.86). Aim for ≤200 chars for safety; ≤130 chars if shipping a large skill collection (60+ skills) so the total budget fits.\n- [ ] **Purpose statement in first 3 lines**: an agent skimming the top of SKILL.md should understand what it does and when to use it without reading further.\n- [ ] **SKILL.md body ≤500 lines**: Anthropic recommends keeping SKILL.md under 500 lines. Split detailed content into reference files when approaching the limit.\n- [ ] **Single responsibility**: the skill does one thing well. If it has multiple unrelated sections, consider splitting into separate skills.\n- [ ] **Consistent terminology**: pick one term per concept and use it throughout. Switching between synonyms (\"artifact\" vs \"bundle\" vs \"package\") confuses agents.\n- [ ] **No time-sensitive content**: avoid \"as of November 2025\" or \"use the new API after July 2026\". Route deprecated guidance into a clearly labeled \"old patterns\" section so agents skip it.\n- [ ] **Every bundled file is referenced**: if a file is in the package, some markdown file should link to it or explain what it is. Dead files confuse agents and waste context.\n- [ ] **References one level deep**: link reference files directly from SKILL.md, not via intermediate hubs. Claude does partial reads on nested references and may miss content several hops down.\n- [ ] **TOC on reference files >100 lines**: long reference files should include a table of contents at the top. Claude often previews with partial reads — a TOC ensures the full scope of available content is visible.\n- [ ] **All links resolve**: every \`[text](path)\` link points to a file that exists. Run \`vat verify\` to check.\n- [ ] **Build clean**: \`vat skills build\` succeeds and \`vat verify\` passes with zero errors.\n- [ ] **Test the trigger**: ask yourself \"if an agent sees only this name and description, will it know when to load this skill?\" If you need to read the SKILL.md to understand the description, the description is wrong."
   },
   cliBackedSkills-AdditionalChecks: {
     header: "## CLI-Backed Skills — Additional Checks",

package/dist/skills/authoring/resources/skill-quality-checklist.md

@@ -6,7 +6,7 @@ Work through this checklist before publishing a skill. Items are grouped into ge
 
 - [ ] **Name**: short, specific, lowercase-with-hyphens. Matches what the skill does, not how.
 - [ ] **Description — trigger keywords first**: lead with the concepts that should trigger this skill. Claude truncates descriptions aggressively — the most important words must come first. "Sprint analysis, velocity tracking, work item queries" not "This skill is used for when you need to analyze sprints."
-- [ ] **Description — no filler openers, third-person voice**: never start with "This skill...", "A skill that...", "Used to...", "Use when you want to..." — these waste the first tokens on zero-information words. Avoid first/second person ("I can help...", "You can use...") — Anthropic guidance is third person throughout.
+- [ ] **Description — no filler openers, third-person voice**: never start with "This skill...", "A skill that...", "Used to..." — these waste the first tokens on zero-information words. Avoid first/second person ("I can help...", "You can use...") — Anthropic guidance is third person throughout. `Use when <concrete trigger>` is the recommended pattern (matches Anthropic's official skill-description guidance); what's banned is vague filler like `Use when you want to...` or `Use when you need to...` — those don't name a trigger, they just add words.
 - [ ] **Description ≤250 characters**: Claude Code truncates descriptions at 250 characters in the `/skills` listing (since v2.1.86). Aim for ≤200 chars for safety; ≤130 chars if shipping a large skill collection (60+ skills) so the total budget fits.
 - [ ] **Purpose statement in first 3 lines**: an agent skimming the top of SKILL.md should understand what it does and when to use it without reading further.
 - [ ] **SKILL.md body ≤500 lines**: Anthropic recommends keeping SKILL.md under 500 lines. Split detailed content into reference files when approaching the limit.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vibe-agent-toolkit/vat-development-agents",
-  "version": "0.1.32-rc.2",
+  "version": "0.1.32-rc.3",
   "description": "VAT development agents - dogfooding the vibe-agent-toolkit",
   "type": "module",
   "keywords": [
@@ -65,13 +65,13 @@
     "postinstall": "vat claude plugin install --npm-postinstall || exit 0"
   },
   "dependencies": {
-    "@vibe-agent-toolkit/agent-schema": "0.1.32-rc.2",
-    "@vibe-agent-toolkit/cli": "0.1.32-rc.2",
+    "@vibe-agent-toolkit/agent-schema": "0.1.32-rc.3",
+    "@vibe-agent-toolkit/cli": "0.1.32-rc.3",
     "yaml": "^2.8.2"
   },
   "devDependencies": {
     "@types/node": "^25.0.3",
-    "@vibe-agent-toolkit/resource-compiler": "0.1.32-rc.2",
+    "@vibe-agent-toolkit/resource-compiler": "0.1.32-rc.3",
     "ts-patch": "^3.2.1",
     "typescript": "^5.7.3"
   },