How the Template Emerged
The origin is boring in the best way. I was writing skills, markdown files with YAML frontmatter that tell an AI coding agent what to do. Each skill needed to work in Claude, Cursor, Windsurf, OpenCode, and Codex. Each of those tools has a different frontmatter format, different file layout expectations, and different conventions for how skills get discovered. Maintaining seven copies of the same skill by hand was a non-starter.
So I built a compiler. It reads a single source markdown file, resolves {{include:...}} markers that pull in shared fragments, applies IDE-specific frontmatter transforms, and writes to seven output directories. One source, seven outputs. Edit a fragment once, recompile, and every skill that includes it gets the update.
That compiler, plus the fragment system, plus the convention for how skills and CLIs relate to each other, became the skill-system-template. The template itself needed a project to live in, which became Agentic Skill Mill.
Agentic Skill Mill: The Forge
Agentic Skill Mill is the parent project. It does two things:
- It teaches agents how to build skill projects. The skill itself (
skill/skills/agentic-skill-mill/agentic-skill-mill.md) is a runbook that walks an agent through adding commands, creating fragments, composing skills, renaming projects, and turning research into actionable tooling. A skill about skills. Recursive, but it works. - It provides the
skillmillCLI. Structured commands for agents and humans:inspect-manifest,inspect-skill,inventory,forge,audit-exports. Every command supports--jsonso agents can consume the output programmatically.
The architecture:
Skills (what to do) CLI Companion (tools to do it with)
skill/skills/*.md src/cli/commands/*.ts
skill/fragments/*.md src/core/*.ts
| |
v v
compiled/ (7 IDE formats) dist/ (npm link -> global CLI)
| |
+---------> Agent <----------+Skills are step-by-step runbooks. Fragments are shared knowledge blocks. The CLI provides structured commands that skills invoke by name. The compiler resolves fragments and generates IDE-specific outputs. This pattern, skills + fragments + compiler + CLI, is the template that every child project inherits.
The manifest (skill/build/manifest.json) declares which skills exist, which fragments each skill depends on, and which compilation targets to generate. The compiler validates the manifest against the source files and fails loudly if something is missing. I like loud failures. Quiet ones cost you hours.
AgentThreader: Manifest-Driven Orchestration
AgentThreader solves the problem that shows up the moment you try to use AI coding tools for anything beyond single-shot tasks: how do you run many agentic tasks in sequence, with durable state, verification, and recovery, without babysitting every step?
The v2 specification (skill/SPEC.md in the repo) lays out the hard parts clearly. They are not prompt formatting. They are:
- Durable state and resume after interruptions
- Deterministic parsing of machine-readable results from model output
- Verification owned by the runner, not the model
- Bounded recovery after fixable failures
- Portability across CLIs without rewriting orchestrator logic
AgentThreader addresses all five. The architecture separates concerns cleanly:
- The manifest declares work as a
manifest.v2JSON file with tasks, dependencies, timeouts, and verification profiles. - The orchestrator owns scheduling, verification, checkpointing, and healing. Single source of truth.
- Adapters invoke specific CLIs (Claude, Cursor,
agent,opencode) through a uniform interface. - Workers and healers emit fenced JSON contracts (
task_result.v2,heal_decision.v2) that are schema-validated before any state changes. - The state machine (
state.v2) supports atomic writes and resume from any interruption point.
The healing model is bounded: start conservative (one task at a time), expand when stable, stop when automation is no longer justified. The healer diagnoses failures, patches prompts, and retries, but it cannot edit source code and it cannot spiral. That constraint is load-bearing.
The companion CLI (agent-threader) gives you validate-manifest, init-state, parse-result, parse-heal, status, logs, doctor, and explain. All with --json.
The target use case is batch code edits, audit runs, stage-based workflows, overnight runs. Anything where a failure halfway through shouldn’t lose everything. It is not a general-purpose multi-agent framework. It is a durable, inspectable runner for prompt-driven CLI workflows, and that narrowness is the point.
AgentHistoric: Philosopher-Named Persona Routing
AgentHistoric takes a different path than the other two projects. It shares the compilation tooling, the seven-target output, the fragment system, but it layers on its own Mixture-of-Experts (MoE) routing system, its own regression suite, and a body of research I spent months on.
The core idea is that philosopher names function as compact semantic indexing keys for steering LLM reasoning behavior. Not roleplay. High-compression control. Commercial LLMs already have latent representational structure for figures like Peirce, Descartes, Popper, Rogers, Blackmore, Dennett, Liskov, Dijkstra, Knuth, Shannon, and Simon. AgentHistoric exploits that structure deliberately, grounding each persona in a specific philosophical lineage and mapping it to a distinct role in the software lifecycle.
The routing layer is where most of the complexity lives. Negative routing guards prevent common mis-routes. Diversified sub-domain heuristics (18+ entries) reduce over-selection of popular experts. Progressive two-pass routing handles ambiguous prompts. A judge-mediated deliberation council synthesizes multi-concern tasks. An adversarial verification pipeline lets Popper attempt to falsify implementation work before it ships. That last one is my favorite; it catches the “I wrote it and it looks good to me” failure mode that plagues every solo developer and every model that cheerfully validates its own output.
The routing layer, the regression suite (109 unit tests, behavioral assertions, model-parity tracking), and the expert personas are all defined in canonical JSON under prompt-system/ and rendered into every target by the build system.
I published a technical report on the underlying approach:
Sonntag, Barrett. (2025). Philosophical Persona Prompting as Semantic Indexing for Latent Representation Steering in Large Language Models. Zenodo. DOI: 10.5281/zenodo.19559517
The Shared Bones
All three projects share a core architectural pattern:
| Component | What it is | Shared? |
|---|---|---|
| Skill sources | Markdown with YAML frontmatter and {{include:...}} markers | Same format across all three |
| Fragments | Shared knowledge blocks in skill/fragments/ | Same inclusion mechanism |
| Compiler | skill/build/compile.mjs, resolves includes, applies IDE-specific frontmatter | Same compiler, same manifest format |
| Manifest | skill/build/manifest.json, declares skills, fragments, targets | Same schema |
| Compilation targets | 7 IDE formats: Claude, Cursor (rules + skills), Windsurf (rules + skills), OpenCode, Codex | Same 7 targets |
| Companion CLI | TypeScript CLI with Commander.js, --json support, structured output | Same pattern, different commands |
| Install scripts | install-local.sh, install-local.ps1, hosted bootstrap scripts | Same pattern, project-specific |
What varies is the domain logic. AgenticSkillMill’s domain is skill project management. AgentThreader’s domain is orchestration contracts and state machines. AgentHistoric’s domain is persona routing and regression testing.
The template is not a framework. There is no shared dependency or base class. Each project has its own package.json, its own TypeScript source tree, its own test suite. The template is a pattern: a way of structuring skill projects so that the compilation, fragmentation, and CLI parts work the same way everywhere. When I improve the compiler or discover a better convention in one project, Agentic Skill Mill can propagate that improvement to the child projects through its own skill. The agent reads the updated source, understands the change, and applies it in context. No shared dependency, no version lock, no accidental coupling. Just a skill that knows how to teach other projects what it learned.
Links
| Project | GitHub | Site | npm |
|---|---|---|---|
| Agentic Skill Mill | barretts/AgenticSkillMill | agenticskillmill.com | agentic-skill-mill |
| AgentThreader | barretts/AgentThreader | agentthreader.com | agent-threader |
| AgentHistoric | barretts/AgentHistoric | agenthistoric.com | — |
All three are MIT licensed.