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?

No. The plugin runs on the CLI under the hood, so installing the plugin gets you both. Want just the core context layer? Install the CLI on its own.

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.

Both entry points read and write the same .archcore/ directory; pick by the agent you run. The plugin adds architecture-aware /archcore slash commands, skills, and guardrails inside Claude Code, Cursor, Codex CLI, and GitHub Copilot CLI. The CLI provides the context layer itself over MCP and session hooks for every other MCP-aware agent and for CI, covering eight agents today: Claude Code, Cursor, Gemini CLI, GitHub Copilot, OpenCode, Codex CLI, Roo Code, and Cline.

Capture, connect, apply, evolve

Capture specs, decisions, rules, plans, and project knowledge. Connect related artifacts into one project context. Apply the relevant context while agents work: session hooks inject the right documents at the start of every conversation, and MCP exposes tools (list, get, create, update) so the agent can browse and edit documents during a session. Everyday context needs no command at all. Four slash commands (/archcore:init, /archcore:plan, /archcore:document, /archcore:review) cover setup, planning, capture, and review. Evolve context with the codebase, through Git.