Documentation

How to adopt Anchor.

Install the runtime. Adopt the methodology. This is the canonical How surface for Anchor — product introduces adoption; Documentation owns the walkthrough.

Getting Started

Install the runtime. Adopt the methodology.

Anchor separates tooling from practice. You install a runtime once; you adopt a coordination methodology into your own project artifacts.

Software steps come first: install the runtime, then initialize your workspace. After anchor init, your project's .anchor workspace is the primary working context. Engineering decisions and project state belong there — not in the public documentation.

Next, adopt the methodology: orient your AI host (Cursor, Claude Code, or another compatible host) and establish project context — typically Project Entry and Handoff. Depending on whether you are adopting Anchor in an existing project or starting a new one, follow the guidance that matches your situation below.

Then begin engineering from those durable artifacts. Verify the CLI with anchor help (there is no --help flag).

1. 01npm install -g @jon4ohio/anchor-runtime
2. 02cd your-project && anchor init

• Existing project — map what already owns each responsibility; create Entry and Handoff only where gaps remain; keep existing ADRs and docs in place.
• New project — establish Entry and Handoff early; add a Spec when scope is clear; skip ADRs until a decision constrains future work.
• Ask your AI host to orient before work: Entry first; Handoff if continuing; relevant Spec or ADR for the task.

Concepts

Responsibilities before files.

Knowledge has responsibilities. Contracts formalize those responsibilities. Artifacts implement contracts — they are not the interface.

Seven contracts each own one kind of truth: Entry (orientation), Spec (scope), ADR (decisions), Skill (transferable expertise), Playbook (execution order), Review (quality gates), and Handoff (continuity).

The Capability API exposes engineering responsibilities as stable identities (for example orientation@1, continuity@1, review@1). Clients depend on what to fulfill, not on a directory layout.

• One owner per truth — do not duplicate durable facts across files.
• Reference, don’t restate — link to the contract that owns a truth.
• Promote only after repetition — don’t invent contracts from a single conversation.

Architecture

Stable rationale, not a file tree.

Public architecture is presented by concept — responsibility-first design, product vs framework layers, and capability-as-API — not by ADR number as navigation.

Responsibility-first teaching means adopters discover existing ownership before introducing new structure. Overlay adoption keeps your ADRs and AI context files where they are.

A thin local runtime delivers methodology as versioned knowledge snapshots. The host AI provides inference; project state remains in the adopter’s repository.

Underlying records (ADRs, position papers) support these concepts. They are implementation artifacts for the architecture surface, not the primary way users browse How.

Reference

Runtime commands and behavior.

Once you have begun engineering, these commands describe runtime capabilities. The runtime prepares a workspace and can fulfill declared engineering responsibilities. It does not host inference, own project state, or decide when work should happen.

Capability fulfillment language remains provisional until the Capability API acceptance gate clears in real adoption.

• anchor help — list commands (no --help flag).
• anchor init — create .anchor workspace config and default artifact locations.
• anchor fulfill <identity> — fulfill a capability identity (e.g. orientation) after you have adopted the methodology.
• Local MCP tool aliases map to fulfill("<identity>") where the host supports them.

Maturity

Evidence Window open.

Independent adoption evidence is still pending. Maintainer dogfooding and a controlled portfolio experiment support capability claims under labeled conditions — not broad market validation.

The Capability API remains Proposed upstream until acceptance gates clear in real adoption. This Documentation surface is the public How; the implementation repository is optional for adoption.