Skip to content

name: Skill systems naming convention (atomic vs orchestrator) description: When creating new Claude Code skills, classify each one as either atomic (one job, reusable) or orchestrator (wires N atomic skills into a chain). Avoid mega-skills. Source: Simon Scrapes "Stop Downloading Claude Code Skills" 2026-05-01. type: feedback originSessionId: 676743bd-c6d2-4af1-9376-2ea429911b4f

Skill systems pattern

Every new skill on forge gets classified up-front:

Type Description SKILL.md size Example
Atomic skill One job, reusable across systems. No control flow that calls other skills. Small (one screen) /screenshot, /recall, /notify, /watchyoutube, /save-to-drive, /preview-site
Orchestrator skill Chains N atomic skills, manages I/O between them. No business logic of its own. Small (declarative wiring + handoff rules) /orient, /strategy, /email-triage
Skill system The composed end-to-end automation = orchestrator + the atomic skills it calls n/a (it's a composition, not a file) future /jwvr-shortform, /<brand>-content-cycle

Decision tree when building a new skill

  1. Is this one focused job? Atomic skill.
  2. Is this 3+ phases with reusable pieces (transcription, image grab, posting, etc.)? Skill system: build the orchestrator + the missing atomic skills, reuse the ones that already exist.
  3. Tempted to write a 500+ line SKILL.md doing four different things? Stop. That's a mega-skill. Decompose it into atomic skills + an orchestrator before continuing.

What an orchestrator skill must specify

Per Anthropic's "sequential workflow orchestration" pattern (and the Simon Scrapes video at FD53kEpLh9c [5:48–6:26]):

  1. Skill architecture: which atomic skills run, in what order
  2. Inputs per step: what each atomic skill needs to do its job
  3. Output handoffs: how step N's output becomes clean input for step N+1
  4. Human-in-loop checkpoints: where to pause for Justin to approve/adjust (per his email-actions-confirm and social-media-draft-only rules)
  5. Visual output format: markdown handoff, HTML dashboard, Notion sub-page, Telegram message, etc.

Why this matters

  • Reuse compounds. A transcript-extraction atomic skill feeds short-form video systems, newsletter systems, and blog systems. Build once, plug in many places. Justin's /watchyoutube is already a perfect atomic skill for this.
  • Update once, propagate everywhere. Fix a bug in the atomic skill, every orchestrator that uses it benefits.
  • Progressive disclosure. Anthropic designed skills to load only the context needed. Mega-skills blow that up; small atomic skills preserve it.
  • Forge already does this informally. This rule formalizes the existing pattern (/orient + tools, /strategy + brand load, /email-triage + bucket-sort phases) so future skills don't drift into mega-skill territory.

When NOT to apply

  • Single-shot scripts that are too small to be a skill at all (just a forge_*.py in scripts/ and an entry in MEMORY.md is enough).
  • One-off worker prompts via /spawn (those are tasks, not reusable skills).
  • Existing skills that already work and aren't mega. Don't retrofit for vocabulary's sake; this is forward-looking.