"Publish the spec, and the network builds itself."
Inspired by the shared schematics of Daniel Suarez's Daemon — where the Darknet spread through build specifications that independent teams executed without permission, coordination, or contact with the author.

An agentic schematic is a self-contained build specification package — every requirement, parameter, dependency, implementation phase, and acceptance test for one capability, in plain Markdown and portable shell. The author publishes once; any builder — any LLM, any human team, any organization — constructs the capability independently, in any runtime, without ever consulting them.

The spec is the only coordination mechanism.

Traditional spec handoffs fail in one of two directions:

• A conversation. "Let me walk you through the setup" — the knowledge lives in people and calls. It doesn't transfer, doesn't scale, doesn't survive.
• A document that isn't self-contained. "See the original repo", "ask the author about the TLS setup", "this assumes the staging server" — every hidden dependency is a coordination round-trip with the author.

A schematic refuses both. It is a contract, not a conversation:

• Self-contained — every requirement, assumption, parameter, and verification lives inside the package. If a fact matters, it's in the package — or it doesn't exist.
• Vendor-agnostic — plain Markdown and portable shell. No references to any specific agent's tools, skill formats, or harness features. The reader may be any LLM in any runtime — or a human team on another continent.
• Idempotent — every implementation phase re-runs without damage; verification produces the same verdict every time.
• Parameterized — no absolute paths, no machine-specific facts. Every environment-specific value is a named parameter with a discovery method.

The schematic removes the author from the loop entirely. That is the point.

Every schematic follows the same layout, SCHEMATIC.md at the root of a package directory:

<schematic-name>/
├── SCHEMATIC.md          # the spec: requirements → acceptance (always)
├── modules/              # one contract doc per separable component
├── scripts/              # reference implementations (setup, verification)
├── skeleton/             # starter files to copy verbatim, then fill
└── templates/            # output structures the capability produces

The SCHEMATIC.md format's own companion is not part of a package: it is canonical at schemas/spec-1/SCHEMATIC.md.schema, keyed by the spec: field every spec declares in its frontmatter — one copy for the whole catalog, and scripts/validate-catalog.sh fails any spec that names a revision the catalog has no companion for.

Inside SCHEMATIC.md, sections appear in a fixed order:

---
name: my-schematic
version: 0.1.0
status: draft
spec: 1
description: One-line summary copied to the marketplace
created: 2026-09-17
updated: 2026-09-17
---

# Schematic: <Capability>

## Applicable Context     → must discover locally / may assume / must not change
## Requirements           → R-1, R-2, … every one testable
## Dependencies           → D-1, D-2, … every one with failure behavior
## Parameters             → P-1, P-2, … every one with a discovery method
## Modules                → one explicit contract per module
## Implementation         → ordered, idempotent phases, each verified
## Acceptance             → A-1, A-2, … one per requirement
## Removal                → stated, safe uninstall procedure

Two kinds of .schema file exist, and the split matters:

• The container format — SCHEMATIC.md itself — has a single canonical companion, schemas/spec-1/SCHEMATIC.md.schema, keyed by the spec: field in a spec's frontmatter (spec: 1 selects that revision). It is not copied into packages: one document, one place to fix it.
• Artifact schemas describe content that is genuinely per-package: an agent.rego ships with an agent.rego.schema alongside it, so an implementer with zero prior knowledge of Rego can still work with the file. The convention: every <name>.<ext> gets a <name>.<ext>.schema next to it.

The ten binding principles — each an acceptance criterion, not a style preference:

1. Vendor-agnostic — no agent-specific tools or formats
2. Portable — no absolute paths or machine-specific literals
3. Self-contained — the package is the complete world
4. Predictable, intuitive, ergonomic — identical layout, same section order
5. Idempotent and deterministic — re-runnable without damage
6. Parameterized and modular — every tunable in one table, every concern a module; behavior differences are configuration, never code edits
7. Dependencies called out — with discovery and failure behavior
8. Composable in kind — a dependency may be another schematic, pinned to a commit and a content hash
9. Applicable context stated — discover vs assume vs don't-change
10. Pluggable — clean seams and a stated removal procedure

Full details: skills/schematics/skills/create-schematic/references/schematic-principles.md.

.agent-schematics/marketplace.json is this repository's catalog: it lists every schematic package, and nothing else. It is not a plugin marketplace — a schematic is a build specification anyone implements, not something a harness installs — and its format is its own, declared by the file's $schema and documented in schemas/catalog-1/marketplace.json.schema. The website at schemaformat.ai renders it live with one-click copy-as-Markdown for each entry.

This repository also ships one plugin — the authoring toolkit — registered separately in the Claude Code marketplace file .claude-plugin/marketplace.json.

/plugin marketplace add cameri/schematics
/plugin install schematics@cameri-schematics

A schematic doesn't need to be installed — it's a spec, not a program. Hand SCHEMATIC.md (plus referenced files) to any agent session, or copy it from the website with one click. The agent implements the phases and verifies against the acceptance tests. No interview, no plugin required.

The schematics plugin's build-schematic skill pulls a schematic package from any public GitHub repository into the current project:

build <name>@<user>/<repo>

It resolves the package (via the repo's .agent-schematics/marketplace.json catalog or conventional paths), downloads the spec plus its modules, scripts, and skeleton, validates the spec against the schematic format, and does nothing but place files — nothing executes at build time, and fetched specs are treated as untrusted data. The package lands in .schematics/<name>/; review it, then ask the session to implement it.

A skill teaches an agent a procedure in the agent's own format. It is tied to the harness that loads it, and its instructions assume the agent's tools and context.

A plugin is a distribution wrapper: it packages skills, commands, and agents for one harness's marketplace and installer.

A schematic is none of these. It is a vendor-agnostic build specification: plain Markdown and portable shell, with every requirement, dependency, parameter, phase, and acceptance test stated inside the package. A schematic doesn't extend an agent — it instructs how to build a capability, and any builder (any LLM, any team, any org) can execute it with zero coordination with the author. Skills and plugins are how one agent gets an ability; schematics are how everyone gets the ability rebuilt, anywhere.

The relationship is complementary: this repo ships the authoring skills as a plugin because that is a convenient way to distribute them, but the schematics those skills produce deliberately depend on nothing but a shell and a text editor.

The schematics plugin authors new schematics (interview-driven), reverse-engineers them from existing implementations, and maintains them as living specs. Install it, then ask any agent to "create a schematic" or "schematize this repo":

/plugin marketplace add cameri/schematics
/plugin install schematics@cameri-schematics

Or read the skill directly: skills/schematics/skills/create-schematic/SKILL.md.

To publish a schematic here: open an issue describing the capability, then create <name>/SCHEMATIC.md, add an entry to .agent-schematics/marketplace.json, and open a PR referencing the issue. See CONTRIBUTING.md for the full process.

Schematics are contributions. A schematic is a capability others can build independently — if you've built something an agent or a team should be able to reproduce from a spec, distill it and open a PR. The schematics plugin's reverse-engineering workflow does the distilling.

The hard questions (why rebuild instead of fork, prompt-injection risk, "IaC already does this") are answered in the site FAQ.

Rule: no PRs without an issue. Every PR must reference an open issue opened beforehand to start the discussion. PRs from outside contributors without a prior issue are rejected automatically, and the rejection cites this rule. Details in CONTRIBUTING.md.

MIT © 2026 cameri

_{made for builders who never met the author}