How is this different from CLAUDE.md or AGENTS.md?

Instruction files are flat memory: one tool, one file. Archcore is structured. It stores typed documents (ADR, rule, plan, guide, spec) with relations and versioned history, read and written during real work, and reused across every agent.

I already have a CLAUDE.md or .cursor/rules. Do I start over?

No. archcore init imports your existing instruction files (CLAUDE.md, AGENTS.md, .cursorrules, .cursor/rules/*) as structured documents, so the context you already wrote carries over.

Which AI agents are supported?

The plugin runs inside Claude Code, Cursor 2.5+, Codex CLI 0.117+, and GitHub Copilot CLI. The CLI works with any MCP-aware agent: those four plus Gemini CLI, OpenCode, Roo Code, and Cline. It is also scriptable in CI.

Does this eat my agent's context window?

No. At session start the agent gets a compact index of your documents. Full documents are pulled on demand over MCP, through search, relations, and single reads, instead of being loaded wholesale.

Does my code leave my machine?

No. The plugin and CLI run fully local: no accounts, no telemetry, no external services. .archcore/ is plain markdown versioned in your Git repo.

Do I need both the plugin and the CLI?

You install one thing. The plugin runs on the CLI, so the CLI comes first: archcore init wires your agents and installs the plugin on the hosts you pick (Claude Code, Cursor, Codex CLI, GitHub Copilot CLI). On any other MCP-aware agent the CLI is all there is to install.

Spec-Driven Development & Context Engineering for AI Coding Agents

Archcore is a git-native context layer for AI coding agents. It keeps specs, architecture, decisions, rules, and plans in Git, and makes the right project context available to AI coding agents as they work, so Claude Code, Cursor, GitHub Copilot, Gemini CLI, and other agents follow your real architecture instead of guessing.

Your code is in Git. Your project understanding should be too.

Decisions disappear into chat history. Instruction files like CLAUDE.md and AGENTS.md grow into walls of text. Every agent sees a different version of the project. Specs become stale handoff artifacts, and architecture and conventions get re-explained every session. Single instruction files are flat, tool-specific, and weakly structured: they pile up without type, link, or history, so the agent has no way to find which rule applies to which directory, which decision blocks a refactor, or which spec governs a contract. The replacement here is nineteen typed document categories, named relations between them (implements, extends, depends_on, related), and versioned history: the same artifacts senior engineers already write, but that agents can read, write, and reason about during real work.

Specs that stay connected to implementation

Use structured specs and plans to define what should be built, then keep them alongside the decisions, rules, and architecture the agent needs during implementation. The spec-driven track runs idea → PRD → spec → plan, and a requirements cascade is available for market discovery (MRD → BRD → URD) and for regulated work (BRS → StRS → SyRS → SRS). A spec is one part of context, not the whole context: it ships next to the architecture, prior decisions, constraints, and team rules the agent also needs.

Engineer the context your coding agents work from

Context is more than a prompt or a bigger context window. Archcore makes project knowledge explicit (decisions and constraints are written down, not inferred from code), structured (typed documents with relations, not one growing file), selective (the agent loads what applies to the file in front of it), versioned (context changes ship in the same pull request as the code), and portable across coding agents.

Designing what an agent is told before it acts, and what checks it afterwards, is called harness engineering: guides that steer the agent ahead of an edit, and sensors that verify the result. A harness for a coding agent is a specific form of context engineering, not a successor to it. Your agent already ships the loop, the tools, the permissions, and the sandbox. Archcore holds the half no vendor can ship for you, because it has never seen your repository: what your project decided, what it requires, and what it forbids. See harness engineering, explained.

Project context belongs in Git

Everything lives in .archcore/ inside your repository, versioned alongside the code it documents: reviewable in pull requests, portable across tools, team-owned, and with no opaque agent memory holding anything you cannot read or edit. No servers, no databases, no accounts, no telemetry. The CLI is a single cross-platform binary; the MCP server runs locally as a child process; install scripts pull release binaries from GitHub Releases. See the documentation or read the privacy policy for details.

One project context. Every coding agent.

archcore init wires whichever agents you already run, and each one reads and writes the same .archcore/ directory in your repo. Eight agents today: Claude Code, Cursor, Codex CLI, GitHub Copilot, Gemini CLI, OpenCode, Roo Code, and Cline. Architecture-aware /archcore slash commands, skills, and guardrails run inside Claude Code, Cursor, Codex CLI, and GitHub Copilot CLI; every other agent reaches the same context over MCP and session hooks, and the whole thing is scriptable in CI.

How it works: the loop

Four steps on one feature, from an empty repo to a merged branch. Say the sentence or type the shortcut: they do the same thing. /archcore:init ("Set up Archcore in this repo") reads the project and proposes a stack rule, a run guide, an architecture overview, and a spec for each module that changes most. /archcore:plan ("Plan rate limiting for the public API") returns a spec and a plan sized from what the change actually touches. /archcore:document ("Record the decision to use a token bucket in Redis") writes an ADR holding the reasoning as well as the verdict. /archcore:review ("Review my branch before merge") reads the diff against both, in both directions. Between the four there is no command at all: hooks bring the applicable spec and ADR to the agent while it edits, and each session opens with a recap of what is decided and what is in progress. No new service to run: your context lives in the repo, moves with it through Git, and reaches every agent you open. See how to use Archcore for the whole loop.