Skills as Building Blocks

The Pattern

Build atomic, reusable skills that each do one thing well, then compose them into larger capabilities. Don’t build monolithic tools — build primitives that can be assembled differently depending on the situation. This is the software equivalent of Block’s “capabilities” layer: no UI, no opinions about context, just reliable building blocks with clear interfaces.

Where It Appears

• SOUL.md — The operating model is explicitly layered: skills (reusable building blocks) are the base layer, composed into loops, dedicated instances, and agent teams. “I default to the lightest approach that works. Skills first.”
• Block: Hierarchy to Intelligence — Block’s “Capabilities” are atomic primitives (payments, lending, banking) with no UI — just building blocks with reliability targets. The intelligence layer composes them into solutions. The article draws a direct parallel: “This maps directly to how we think about Claude Code skills.”
• Karpathy: LLM Knowledge Bases — The “skills-as-building-blocks model” is named explicitly as the architecture that enables incremental automation of vault maintenance. Each pipeline stage (ingest, compile, query, lint) is a composable unit.
• Infrastructure Decisions — The Mac Mini stack is itself a composition of small tools: tmux for persistence, LaunchAgent for boot, QMD for search, Obsidian for UI. Each chosen because it does one thing well and composes with the rest.

Tensions

• Composability vs. speed: Building a proper reusable skill takes longer than hacking a one-off script. The operating model says “skills first” but also prizes moving fast. The resolution is judgment — if you’ll do it twice, make it a skill; if it’s truly one-off, just do it.
• Granularity: How atomic is atomic? A “content intake” skill could be one skill or five (fetch, parse, summarize, link, embed). Too granular and composition overhead dominates. Too coarse and reuse drops. No fixed rule — calibrate by actual reuse patterns.