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. Specs become stale handoff artifacts. Every agent sees a different version of the project. Instruction files like CLAUDE.md and AGENTS.md 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.

Same prompt. Different agent.

Ask both to add rate limiting to the auth endpoints. Without Archcore the agent picks a library it happens to know, ignores the Redis store you already run, reinvents conventions the team settled months ago, and you re-explain the same rules again: logical code that is not how this repo works. With Archcore it loads the ADR that chose a Redis token bucket, pulls the rule for error shapes in src/auth/, reuses the middleware pattern already there, and writes the new decision back as a versioned document. The only difference is whether it could see your decisions, rules, and patterns first.

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, and ends in a verdict on each finding: spec-wrong when the document is stale, code-wrong when the branch broke a decision, and ok when the two agree. 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.

Engineer the context your coding agents work from

The four commands are the part you type. The rest happens on its own: when the agent opens src/api/rate-limit.ts, Archcore gives it the documents that constrain that file before the edit: the spec for public API rate limiting, the ADR that chose a Redis token bucket, and the rule for error shapes in src/api/. The agent gets them without being asked. That is what makes it engineered context rather than a longer prompt: 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. See context engineering for AI coding agents.

Designing what an agent is told before it acts, and what checks it afterwards, is called harness engineering. See harness engineering, explained.

Specs that stay connected to implementation

Methodology tools define a development process. Archcore keeps the resulting project knowledge alive, connected, versioned, and available to agents throughout implementation. Define what to build, then keep the definition where the work happens: the spec that scoped the feature is the one review reads your branch against, and the one the next plan starts from. 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 that context, not the whole of it: it ships next to the architecture, prior decisions, constraints, and team rules the agent also needs. See spec-driven development for AI coding agents.

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 why project context belongs in Git, the documentation, or 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.