[bcherny]

Fixes public issue #83803

The plugin-dev skill's validate-agent.sh failed on plugin-dev's own agent files. Three root causes, all set -euo pipefail interactions:

1. Abort at the first warning. ((warning_count++)) / ((error_count++)) evaluate the arithmetic expression, and ((expr)) returns a nonzero exit status when the expression's value is 0 — so the first increment from 0 killed the script under set -e, mid-run, with exit 1. All increments now use count=$((count + 1)), which is an assignment and always returns 0.

2. Abort on any absent frontmatter field. Extractions like TOOLS=$(echo "$FRONTMATTER" | grep '^tools:' | ...) propagate grep's exit 1 (no match) into the assignment, aborting the script instead of reporting the missing field. Each extraction now ends in || true.

3. False "missing <example> blocks" warning. DESCRIPTION was extracted with grep '^description:', which only captures the first physical line — but plugin-dev's own agents use multi-line descriptions whose <example> blocks sit on later lines, so valid agents were flagged. The extraction now captures the full multi-line value (from description: up to the next top-level agent key).

Verification (all three plugin-dev agents previously died at the first warning with exit 1):

• agents/agent-creator.md, agents/plugin-validator.md, agents/skill-reviewer.md → all checks pass, exit 0
• A valid agent file that only triggers warnings → runs to the summary, exit 0
• An intentionally invalid file (bad name, missing color) → all 3 errors reported, exit 1

New validate-agent.test.sh next to the script covers all three cases as a regression test.

Fixed validate-agent.sh aborting at the first warning and rejecting valid agent files

🤖 Generated with Claude Code

[fsc-eriker]

Wouldn't a simpler fix be to switch to preincrement ((++warning_count))

[sylvesterkaczmarek]

description continuation only stops at name|model|color|tools, but valid agent frontmatter also includes keys such as permissionMode, disallowedTools, mcpServers, and maxTurns. Since YAML key order is free, a folded description followed by one of those keys absorbs it into DESCRIPTION and can false-flag later validation. Stop on any new top-level frontmatter key (or parse YAML) and add a regression with description: > followed by permissionMode:.

[sylvesterkaczmarek]

Thanks, that evidence changes the right fix. I agree that simply extending the stop-key list is not sufficient. The absorption bug I reported is real, but if the plugin’s own fixtures are not valid frontmatter to Claude Code, then a validator test that treats them as valid is also testing the wrong language. I would align this validator with the product’s actual frontmatter/YAML parsing rules, or at minimum use fixtures that the product itself accepts, and then validate the extracted description. That resolves the key-order ambiguity without inventing a second parser grammar in awk.

[konsta95]

.