IndyDevDan — I finally CRACKED Claude Agent Skills

Why this is in the vault

This is Dan’s October 27 video — the most-watched practicing engineer’s first serious attempt to taxonomize Claude Code’s seven primary feature surfaces (skills, sub-agents, slash commands, MCP servers, hooks, output styles, plugins) and explain when to use which. It’s vault-worthy because:

1. It’s the cleanest decision tree the vault has on “skill vs. slash command vs. sub-agent vs. MCP.” RDCO operates with 60+ skills today and the founder/Ray have been making these calls intuitively. Dan’s framework — autonomous trigger? parallelizable? external-integration? recurring management vs. one-off task? — gives us a defensible rubric for every future case.
2. Independent restatement of the “prompt is the primitive” claim with new urgency. Dan was already saying “the prompt is the fundamental unit of knowledge work” two years ago; here he warns engineers against the new fashion of “converting all my slash commands to skills.” That warning lands directly on RDCO’s bias for skills (the founder’s standing memory says “always use ~/.claude/skills/ format, never ~/.claude/commands/”). Dan’s argument is more nuanced: lead with prompts (slash commands), promote to sub-agent if you need parallelism, promote to skill only if you need to manage a recurring problem space.
3. Convergence with Garry Tan’s “Thin Harness, Fat Skills.” Tan (April 11) said the harness should be thin and the skills should be fat. Dan (October 27, six months earlier) said skills are “a higher compositional level you use to group features together to solve a specific problem in a repeat way” — and gave skills 8/10 with a major caveat about reliability when chained. Both arrive at the same architectural verdict from different angles. Three independent voices (Dan, Tan, Pachaar) on the same architecture earns shelf space.

Core argument

Skills are the right primitive only when you need to manage a recurring problem space, not when you need to do a recurring task. Dan’s framework:

The four feature comparison matrix:

• Skills: agent-triggered, context-efficient (progressive disclosure), context-persistent, modular (dedicated directory). Best for autonomous behavior the agent should reach for without being asked.
• Sub-agents: agent-triggered, context-efficient (isolated), not context-persistent (lose state on return). Best for parallelizable work where you’re OK losing intermediate context.
• Slash commands: explicitly user-triggered, context-efficient, context-persistent. The base primitive. Best for one-off tasks, manual triggers, units of compute.
• MCP servers: programmatically-triggered, context-expensive on bootup, persistent. Best for external integrations and bundling third-party services.

The composition hierarchy:

1. Skill (top) — can compose many MCP servers, sub-agents, and slash commands.
2. Slash command — primitive and compositional; can call skills, sub-agents, MCPs.
3. Sub-agent — can call slash commands and MCPs, but not other sub-agents.
4. MCP server (bottom) — leaf; doesn’t call up the stack.

Decision rules:

• One-off task: slash command.
• Want to parallelize the same task: sub-agent.
• External integration: MCP server.
• Recurring problem space requiring management of multiple states/tools/prompts: skill.
• Lifecycle event (auto-trigger on git commit, file change, etc.): hook.
• Reusable extension to share with others: plugin.
• Output formatting/persona: output style.

The Core 4 underlies all of it: context, model, prompt, tool. Every feature is a different composition of the Core 4. If you can’t trace a feature to the Core 4, it’s noise.

Pros and cons of skills (Dan’s 8/10 verdict):

• Pros: agent-invoked, progressive disclosure (context-efficient), dedicated file-system pattern (modular), composes other features, agent-first.
• Cons: doesn’t go all the way (no nested sub-agents directory, no nested slash-commands directory inside a skill — the most important primitive can’t be embedded inside the skill bundle), reliability of chained skills is unproven, the actual innovation is “thin opinionated file structure” — most of what skills do could be done with prompt engineering + custom slash commands + slash-command tool.

The single sharpest line: “If you can do the job with a sub-agent or a custom slash command, and it’s a one-off job, do not use a skill. This is not what skills are for.”

Mapping against Ray Data Co

• Direct contradiction with the standing “skills over commands” memory. The founder’s persistent memory says “always use ~/.claude/skills/ format, never ~/.claude/commands/.” Dan’s framework says that’s right only when the work is recurring problem-space management; for one-off tasks, slash commands are the correct primitive. The reconciliation isn’t to flip the bias — it’s to add a triage step. New skill request: ask “is this managing a recurring problem or doing a recurring task?” If the latter, ship as a slash command living inside the relevant skill (composition).
• Audit the existing 60+ skills against Dan’s heuristic. First-pass guess: most skills pass (they manage recurring problem spaces — process-newsletter manages “everything that comes from the newsletter ingestion problem,” check-board manages “the Notion task-board lifecycle”). Some skills look like they should be slash commands inside a parent skill: e.g., imessage:configure, imessage:access, discord:configure, discord:access — these are one-off operations that could live as /configure-imessage, /access-imessage inside a single channels skill. Worth a one-pass audit.
• The “skills should embed slash commands” gap Dan flags is acutely felt in RDCO. Today, RDCO skills reference slash commands by string (e.g., /check-board invokes check-board skill, but if a skill wants to invoke /process-newsletter it has to use the slash-command tool by name). There’s no ~/.claude/skills/foo/commands/ directory. Dan’s complaint is the same one the founder hits when extending skills. This is a feature request to Anthropic, not something RDCO can fix internally — but worth flagging so we don’t blame our own architecture for an upstream limitation.
• Validates RDCO’s existing composition pattern in process-newsletter and process-youtube. Both skills spawn sub-agents per article/video and compose with MCP (Gmail, qmd) and prompts. Dan’s hierarchy explicitly endorses this: skill at the top, MCPs and sub-agents underneath, prompts as the primitive. RDCO is already using the architecture Dan recommends; the framework gives us vocabulary to defend it.
• Reliability concern lands on RDCO’s autonomous loop. Dan: “Can I actually chain together five skills and expect them to be called back-to-back-to-back-to-back? Or should I again just use a prompt?” RDCO’s autonomous Mac Mini agent already chains 4–6 skills per cycle (morning-prep → process-newsletter → process-youtube → check-board → graph-reingest). If Dan’s intuition is right that chained skills are less reliable than chained slash commands, RDCO might be hitting silent failures we’re not catching. Worth instrumenting: log every skill invocation per cron cycle, count failures, look for chain-position bias (does skill #5 in the chain fail more than skill #1?).
• process-youtube itself is the canonical “skill not a slash command” case. It manages a problem space (YouTube ingestion has many states: URL discovery, transcript download, metadata extraction, vault filing, cross-link, Notion update). It composes deterministic tools (yt-dlp), a sub-agent loop (per-video processing), and an output (vault file + Notion update). This is exactly Dan’s “use a skill when you need to manage a recurring problem space” definition. RDCO has been right to make this a skill.
• The “build the thing that builds the thing” meta-skill pattern is already in RDCO. Dan’s “meta skill that builds other skills” maps to skill-creator:skill-creator and to improve (the self-improvement loop). RDCO is already operating at this level.

Open follow-ups

• One-pass audit of ~/.claude/skills/ against Dan’s heuristic. For each skill, classify as: (a) correct skill (manages recurring problem space), (b) should be a slash command (one-off task), (c) should be a parent skill with embedded slash commands. Estimated 2–3 hours. Output: a delta plan for which skills to demote or restructure.
• Instrument the autonomous loop for skill-chain reliability. Add logging to capture per-cycle: which skills ran, which succeeded, which failed silently. Run for 1 week, look for chain-position bias. If Dan’s intuition is right, RDCO’s chained-cron architecture has a hidden tax we should design around.
• Create a “Common issues” section template for skills based on observed failure modes. Cross-reference with the IDD setup-hook pattern (companion ingestion this cycle) — encode recurring failures inline in the skill prompt so the agent self-resolves.
• Add a triage decision in the skill-creator skill. When the founder or Ray asks for a new skill, the skill-creator should ask “is this managing a recurring problem space or doing a recurring task?” and route accordingly. Concretizes Dan’s heuristic into the workflow.
• Sanity Check angle: “When NOT to build a skill.” Most engineers in the Anthropic ecosystem are over-rotating on skills. The contrarian take: skills are 8/10 when they fit the use case, 3/10 when they don’t, and the “fit” criterion is harder than people realize. Could be a strong piece — the framing of “what’s the actual innovation here?” is undercovered.
• Ship the “build the thing that builds the thing” meta-pattern as a Sanity Check angle. The vault has been circling this since March (Tan, Pachaar, Dan, Greyling, the harness-era thread). Dan’s “meta skill” is the cleanest concrete example. A piece on this could position RDCO as one of the few operators actually doing the meta-pattern in production (improve, skill-creator, the autonomous loop itself).

Related

• ~/rdco-vault/06-reference/transcripts/2026-04-19-indydevdan-cracked-claude-agent-skills-transcript.md — raw transcript
• ~/rdco-vault/06-reference/2026-04-19-indydevdan-top-2-percent-plan-2026.md — Dan’s 2026-bets video; “custom agents above all” maps directly to “build skills for problem spaces you own”
• ~/rdco-vault/06-reference/2026-04-11-garry-tan-thin-harness-fat-skills.md — Tan’s “thin harness, fat skills”; same architectural verdict from a different angle
• ~/rdco-vault/06-reference/2026-04-10-akshay-pachaar-agent-harness-anatomy.md — Pachaar on the anatomy of an agent harness; provides the structural vocabulary for Dan’s composition hierarchy
• ~/rdco-vault/06-reference/2026-04-13-every-folder-is-the-agent.md — Every’s “every folder is the agent”; the file-system-as-agent argument that Dan’s “skills have a dedicated directory structure” instantiates
• ~/rdco-vault/06-reference/2026-04-15-every-claude-managed-agents-mini-vibe-check.md — Every’s vibe-check on managed agents; complementary view on when to reach for skills