The repos exploding on GitHub are skill libraries, not crew frameworks. Skill vs agent decision table, SKILL.md anatomy, a daily ritual and a cost cap.
The repos climbing GitHub this month tell you where agent engineering went: skills, not crews. Anthropic's public anthropics/skills repository, the community awesome-agent-skills collection with more than a thousand entries, NVIDIA's skills pack for robotics and CUDA workflows, and community libraries carrying 380-plus production skills all share one shape. Each skill is a folder with a SKILL.md that a coding agent loads when the task matches. No orchestrator personas. No twelve-box crew diagram. The market voted, and it voted for reusable competence over rented attention.
Short answer: a skill is a written procedure with a trigger, inputs, forbidden actions and a verification step. One strong agent plus a shelf of skills beats a crew of specialists on cost, on consistency and on debuggability, for the reasons the Nature Machine Intelligence coordination study quantified in July. This piece gives you the decision table, the skill anatomy we ship, a daily ritual loop and the cost cap that keeps it honest.
Skill versus agent: the decision table
| You want | Write a skill when | Spin up an agent when |
|---|---|---|
| Consistent output format | Always. Formats are rules, not personalities. | Never. |
| Domain procedure (deploy, publish, audit) | The steps are known and repeatable. | The steps require a different tool set or model than the main agent has. |
| Quality check | The check can be run as a script or checklist inside the same run. | The checker must not see the maker's reasoning (audit wall). |
| Parallel throughput | Units are few and sequential is fine. | Many independent, read-heavy units that do not need to agree. |
| Memory of project facts | Always. A lock file, read at start. | Never. Memory agents are the most expensive way to store a paragraph. |
The right column is short on purpose. It matches the three tests in the multi-agent tax: different capability, audit wall, real parallelism. Everything else is a skill.
Anatomy of a skill file
A skill that survives contact with a real project has five parts. Frontmatter with a name and a one-line description the agent matches against. A trigger section that says when to load it and, just as important, when not to. Inputs it expects. Forbidden actions. A verification block that produces evidence, not a feeling.
---
name: publish-blog-post
description: Add a post module, register it in the barrel, validate SEO fields, and verify the route renders. Use when asked to publish or add a blog post.
---
# Publish blog post
## Trigger
Use when the task creates or edits a post under src/data/blog-posts/.
Do NOT use for WordPress-resident posts (see wp-post-edit skill).
## Inputs
- slug, title, meta_description, content (HTML), category, tags
- published_at in YYYY-MM-DD
## Procedure
1. Create src/data/blog-posts/<date>-<slug>.ts exporting a BlogPost[]
2. Import it in src/data/blog-posts.ts, add slug to POST_ORDER (top), spread into posts
3. Run the validator: node scripts/validate-post.mjs <slug>
## Forbidden
- Never edit next.config.ts redirects; use src/data/blog-redirects.ts
- Never set author to a personal name; author is the brand
- Never publish under 1,500 words in STANDARD mode
## Verification (must all pass)
- validator exits 0: meta 120–150 chars, no apostrophes, title 50–65 chars
- npx tsc --noEmit reports 0 errors
- curl -s localhost:3002/blogs/<slug> | grep -c 'application/ld+json' >= 2Notice what is not in it: no persona, no "you are an expert editor." The agent already has a model. What it lacks is the procedure, the guardrails and the definition of done. A skill supplies exactly those three things, and nothing else.
Comments · 0
Beta: comments are stored locally on your device and not visible to other readers.
No comments yet. Be the first to share your thoughts.