Anthropic's "Complete Guide to Building Skills" vs. our Agent Brigade

Founder shared Anthropic's The Complete Guide to Building Skills for Claude (33pp, last modified 2026-01-26) and asked how it compares to our brigade framing, especially the skill-building brigade. This is that comparison.

TL;DR — they're at different altitudes, and they slot together

Anthropic's guide is how to author one good skill. Our brigade is how to manufacture vetted skills at scale. The guide is a spec-for-the-artifact plus a lightweight, mostly-manual authoring process. The brigade is an automated, quality-gated production line that bakes the guide's rules into its spec + critic stations and then adds the three things the guide explicitly does not have: automated lift measurement, a kill (86) decision, and scale (orchestration + fleet + rail + nesting).

The sharpest tell: the guide is candid that its evaluation story is immature — it admits measurement is "vibes-based assessment," and states twice that skill-creator "does not execute automated test suites or produce quantitative evaluation results." That is precisely the gap our execution-eval station was built to fill. We built the thing they said they haven't.

Reframe: Anthropic uses the kitchen analogy too — but only at the runtime layer ("MCP is the professional kitchen, skills are the recipes"). We took the kitchen-brigade to the production layer. The two uses of "kitchen" are complementary. Our brigade is the missing production half of their picture.

What each one is

Where we AGREE (validation — we independently landed on their model)

• Progressive disclosure. Their three-level model (frontmatter always-loaded → SKILL.md body when relevant → linked files on demand) is exactly the pattern our context bundle uses — we explicitly structured the bundle "like a SKILL.md" (pointer manifest + when-to-read + sources pulled on demand). We generalized their pattern to bundles as well as skills.
• skill-creator is a tool, not the process. They position it as the authoring assistant; we use it inside the author + execution-eval stations, not as the whole pipeline. Same call.
• Lift over baseline. Their "performance comparison" test (with-skill vs without-skill: tokens, tool calls, failed calls, back-and-forth) is our execution-eval A/B ablation. We turned their recommended manual test into a first-class automated station. Strong corroboration of our biggest bet.
• Description = the trigger mechanism. Their "what it does + when to use it + key capabilities" rule maps directly onto our critic's triggering axis (the variance-analysis critic scored triggering and independently added the EVM carve-out the spec missed).
• Single-task iteration loop. Their "iterate on one challenging task until Claude succeeds, then extract the winning approach" is the same instinct as our test-author generating the oracle set and the author converging against it.

Where the BRIGADE goes beyond the guide

1. Automated measurement (the headline). They admit eval is vibes-based and skill-creator doesn't produce quantitative results. Our execution-eval station: N-sample A/B with lift ± stddev, per-fixture lift attribution, and regression baselines persisted to the rail. Our own refinement — two kinds of lift (judgment vs convention), distinguished by the tier curve — is sharper than even their performance-comparison sketch.
2. The kill (86) decision. The guide assumes the skill is worth building. We make that evidence-gated: lift ≈ 0 → 86 the ticket. This is the anti-slop mechanism the guide has no concept of.
3. Blind test authoring. Their testing is author-driven (you write your own cases). Our test station is blind to the implementation — the author can't grade its own homework.
4. The expo + convergence loop. Their "iterative refinement" is a pattern you hand-write into a skill. Our orchestrator is an external control loop with explicit routing (advance / refire-to-author / reroute-to-spec / escalate), a max_rounds budget, and phase state. The guide has nothing at this layer.
5. Fleet + rail. Manufacturing across a whole departmental grid (Andrew's ~60-skill grid). The guide is single-skill; Ch4 is distribution, not a production queue.
6. Russian-doll nesting. The skill-dev brigade builds other brigades (the factory). No analog in the guide.
7. Type taxonomy drives eval. Their "three use-case categories" drive technique choice; our 5-type taxonomy drives the fixture shape and eval harness (computational → synthetic known-answers, etc.). Tighter coupling.

Where the GUIDE is sharper — things to ADOPT

(The honest half. These are real, and cheap to fold in.)

• Lift Reference A wholesale into the critic station as deterministic lint. The guide ships a ready-made checklist of hard mechanical rules we should enforce as cheap, non-vibes critic checks: SKILL.md exactly (case-sensitive), kebab-case name (no spaces/underscores/capitals), no README.md inside the skill folder, no "claude"/"anthropic" in the name (reserved), no XML angle brackets in frontmatter (injection vector), description ≤ 1024 chars, SKILL.md < 5,000 words, allowed-tools to restrict tool access. We may be missing several. These are deterministic — perfect for a lint axis.
• The 20–50-simultaneous-skills degradation threshold + "skill packs." This directly hits Andrew's ~60-skill departmental grid. If a department enables 60 skills at once, responses degrade — the guide warns about exactly the regime our fleet manufactures into. Fold "selective enablement / packs" into the fleet/distribution design now, not later.
• Composability + portability as first-class, testable properties. Our critics judge structure/fidelity/triggering, but not explicitly "works alongside other skills" or "portable across Claude.ai / Code / API." The guide elevates both to core principles. Candidate critic axis.
• "Bundle a script for determinism." For critical validations, ship code, not language ("Code is deterministic; language interpretation isn't"). Relevant to our computational skills — variance-analysis could ship a calculator script rather than trusting model arithmetic.
• Distribution chapter = the CAF/Cowork blueprint. Ch4 (org-level workspace-wide deploy shipped 2025-12-18; the open Agent Skills standard; the /v1/skills API for pipelines) is directly the productization layer for getting CAF skills to ~12 eng + 60 sales via the two-rail Cowork/Code model. The guide confirms and extends what we'd sketched.
• Right-size honesty. The guide's "15–30 min to a first skill" lightweight path is a reminder the heavyweight brigade is overkill for a simple one-off. The brigade earns its weight at scale (the grid) or where lift must be proven (client deliverables). Don't brigade a one-liner.

Synthesis — they compose, they don't compete

The guide is the spec for a good skill + the lightweight manual path. The brigade is the automated production system that:

1. bakes the guide's rules into its spec + critic stations (adopt Reference A as lint),
2. adds the three things the guide lacks (automated lift, the kill decision, scale), and
3. uses the guide's distribution chapter as the productization blueprint.

The guide validates our biggest bet (lift-over-baseline) and admits it hasn't automated it — so the brigade reads as the guide's natural extension into manufacturing, not a competing philosophy.

Concrete next actions (when the brigade work un-parks behind cert):

• Add a deterministic lint axis to the critic station from Reference A (naming, no-README, frontmatter limits, no-XML, allowed-tools).
• Fold the 20–50 / skill-packs constraint into the fleet + the CAF distribution design.
• Consider composability + portability critic axes.
• Treat the guide's Ch4 as the reference for CAF skill distribution (Cowork org-admin rail + Code plugin rail).

Related

• [[2026-06-28-agent-brigade-rough-edges-editor-pass]] — the brigade pattern editor's pass ("make the expo real")
• ~/Projects/ray-plugins/plugins/skill-dev-pipeline/DESIGN.md — the v2 design canvas (seat/pipeline/fleet; execution-eval station)
• ~/Projects/ray-plugins/plugins/skill-dev-pipeline/skills/skill-dev-orchestrator/SKILL.md — the expo convergence loop
• [[index]] — tooling