**Abstract.** Agent skills must be loaded into a context window before they can run, so their *packaging* sets a floor on the cost of every task. This note compares two packagings of the same body of [[10x Agents workflow]] skills measured by file count and token size: - the original monolithic skill files from the [[10xDevs 3.0]] training, - and the same skills refactored into [[Coniferous forest]] cone-linked atomic notes Headline findings: ![[#^verdict]] ## 1. Background An agent does not pay for code it stores — it pays for context it loads. The same body of knowledge is packaged two ways: - **Monolith** ([[10xDevs 3.0]]) — each skill is one self-contained `SKILL.md` that inlines the methodology and ontology it relies on. - **Cone** ([[Coniferous forest]] / [[10x Agents workflow]]) — the same material decomposed into atomic notes linked into a DAG; a task loads only its [[Source cone]] (its transitive dependencies), not a whole file. The two are functionally equivalent; they differ only in how the knowledge is packaged for loading. This note quantifies that difference. ## 2. Hypothesis The [[Knowledge cone]] form costs far less context for the same work, for three compounding reasons: - **H1 — deduplication.** Atomisation strips the shared methodology that monoliths inline into every file. - **H2 — bounded load.** Loading only a skill's [[Source cone]] beats loading a whole `SKILL.md`. - **H3 — depth-free and lazy loading.** The cone shrinks further when the shared foundation is amortised rather than counted per skill, and when phases are loaded on demand rather than all at once. ## 3. Method - **Token proxy** — `chars / 4`, the estimate `Scripts/cone.js` uses. A proxy, not a real tokenizer (see [[#5. Threats to validity]]), but applied identically to both sides, so the *ratios* hold even where absolute counts drift. - **Monolith side** — file count and byte size of `Repositories/coniferous-forest-10x` via `find`/`wc`: the 47 skill files, and the full 61 including `context/`, `.claude/prompts/`, and `CLAUDE.md`. - **Cone side** — `Scripts/cone.js "<skill>"` for each skill's source cone (note count + estimated tokens over the full transitive closure). The [[#4.3 Depth-free cone]] analysis splits that listing by hop distance (the tool indents each note by its distance from the root) and sums sizes per layer; the [[#4.4 Lazy loading]] analysis takes individual phase-note sizes directly. Hop-layered counts come from a parsing pass and may differ ±1 note from the tool's totals; canonical per-task totals in [[#4.2 Per-task load]] are `cone.js`'s own. ## 4. Results ### 4.1 Whole-system load | | files | tokens (est.) | |---|---|---| | **10x skills** (`Repositories/coniferous-forest-10x`) | 47 skill files (45 `.md` + 2 `.yaml`); 61 with `context/` + `prompts/` + `CLAUDE.md` | ~198k (skills) / ~219k (whole repo) | | **Refactored** (cone of [[10x Agents workflow]]) | 419 notes | ~87.4k | The refactor trades a few big files for many tiny ones — ~9× more files — yet total token mass drops ~60% (219k → 87k). The cause is deduplication: the 23 monolithic `SKILL.md` files each re-inline the same shared methodology and ontology (`SKILL.md` total alone ≈ 573 KB ≈ 143k tokens). Atomising that shared substance lets every skill *reference* it once instead of copy-pasting it. **(supports H1)** ### 4.2 Per-task load You never load all 419 notes; for one skill you load only its [[Source cone]]. The monolith has no equivalent move — to run one skill you load its whole `SKILL.md` (and it still leans on the shared `context/`). | skill | monolith `SKILL.md` | refactored cone | |---|---|---| | `10x-roadmap` | 68.6 KB ≈ ~17.1k | 25 notes / ~10.7k | | `10x-plan` | 46.3 KB ≈ ~11.6k | 24 notes / ~9.9k | | `10x-implement` | (shared in larger files) | 19 notes / ~8.6k | | `10x-frame` | — | 18 notes / ~9.0k | | `10x-research` | — | 14 notes / ~7.8k | | `10x-shape` | 49.5 KB ≈ ~12.4k | 104 notes / ~16.2k | `10x-shape` is the apparent counter-case: its cone (16.2k) is *larger* than its monolith (12.4k), because shaping reaches deep into foundational ontology and the cone pulls every dependency. [[#4.3 Depth-free cone]] shows why this overstates the real cost. **(supports H2, with one exception)** ### 4.3 Depth-free cone The per-task numbers above are the *full transitive closure* — every link followed down to generic primitives ([[Set]], [[Graph]], [[DIKW]]). But that depth is shared foundation, not skill-specific work, and attributing it per skill double-counts: the foundation is loaded once and amortised across the whole forest. Split each cone by hop distance and the skill's own substance is the shallow layer, while the deep tail is ontology it merely *reaches*: | skill | full cone | skill-specific (hop ≤ 1) | deep tail (hop ≥ 2) | |---|---|---|---| | `10x-shape` | 105 notes / ~16.2k | **26 notes / ~9k** | 79 notes / ~7k | | `10x-roadmap` | 26 notes / ~11k | **21 notes / ~8k** | 5 notes / ~3k | | `10x-plan` | 25 notes / ~10k | **13 notes / ~3k** | 12 notes / ~7k | | `10x-implement` | 20 notes / ~9k | **13 notes / ~3k** | 7 notes / ~6k | For `10x-shape`, the 79-note tail (hops 2–12) adds only ~7k, in 0.1–1k dribbles of generic ontology — load it *once* and every other skill reuses it. Strip that double-count and the shape skill's own cost is ~9k, **below** its 12.4k monolith, dissolving the [[#4.2 Per-task load]] counter-case. The monolith has no such factoring: each `SKILL.md` re-inlines its share of the foundation — the source of the ~219k vs ~87k whole-system gap. **(supports H3)** ### 4.4 Lazy loading A 10x skill is a workflow — a higher-order skill whose phases are themselves skills ([[Skill and subagent final definition]]). So you never load the whole cone to *start* it; you load only the phase you are executing, when you reach it — the on-demand traversal [[Coniferous forest]] is built for. The phases of `10x-roadmap` are 19 tiny step-notes: - most are **0.1–0.4k** each (`Decompose and sequence` ~0.4k, `Read the PRD and inputs` ~0.2k, `Emit the roadmap` ~0.3k …); - the single largest is `PRD Schema` at ~3.0k. So the peak working set at any instant is roughly the biggest single phase (~3k), not the 11k full cone and certainly not the 17k `SKILL.md`, and each phase's marginal load is just the notes it adds that aren't already resident. A monolith cannot do this: the `SKILL.md` is one file, so reaching *any* phase means the whole document is resident the entire run. **(supports H3)** ## 5. Threats to validity - **Token proxy.** `chars / 4` is not a real tokenizer; absolute counts may be off 10–20%. Applied identically to both sides, so comparative ratios stay robust. - **Amortisation assumes breadth.** "Foundation loads once" ([[#4.3 Depth-free cone]]) only pays off across *several* skills in one session. A lone skill run cold loads its full cone including the deep tail — the thinnest-margin case, where a deeply-foundational skill like `10x-shape` can exceed its monolith. - **Monolith per-task figure understated.** Each `SKILL.md` still leans on the shared `context/`; [[#4.2 Per-task load]] counts the skill file alone, so the true monolith load is *higher* — biasing against the hypothesis, i.e. the real gap is wider. - **Cone identity.** The 419-note figure is the cone of this comparison artifact — essentially, but not provably identically, the deployable workflow's note set. - **Graph maturity.** Cone sizes reflect the vault's current linking; further atomisation would move the shallow/deep split. ## 6. Conclusion — verdict on the hypothesis The hypothesis holds on all three clauses, and the threats above bias against it rather than for it: - [x] **H1 (deduplication) — confirmed.** Whole-system mass falls ~60% (219k → 87k), traceable to the ~143k of methodology the 23 `SKILL.md` files duplicate. - [x] **H2 (bounded load) — confirmed.** A task loads its source cone (~8–11k) instead of a whole `SKILL.md` (12–17k); the lone exception, `10x-shape`, is an artifact of counting shared foundation per skill. - [x] **H3 (depth-free + lazy) — confirmed.** Counting only the shallow cone drops `10x-shape` to ~9k — below its monolith — and lazy per-phase loading drops the peak working set to ~3k. ^verdict Net: the [[Knowledge cone]] packaging costs less context than monolithic skills for the same work, and its advantage *widens* with two factors the monolith cannot exploit — the breadth of a session (more skills sharing one loaded foundation) and the granularity of loading (one phase resident at a time). The single thin-margin case, a lone deeply-foundational skill run cold, is exactly what depth-free and lazy loading are designed to recover, and do.