Persistent Project Context for Claude Code

Reference · Updated September 9, 2026

Archcore gives Claude Code structured project context from Git: specs, architecture decisions, rules, plans, and project knowledge. Documents are read locally. The privacy policy explains installation and update analytics.

Updated September 9, 2026: Clarified the comparison, linked supporting references, and reviewed current Archcore behavior.

Claude Code is Archcore’s production plugin host. It gets the full surface: slash commands, skills, gated tracks, guardrails, MCP tools, and session hooks.

What Archcore adds to Claude Code

Claude Code already reads your files, runs commands, and edits code. What it cannot do is know why your system is shaped the way it is, because that was never written into the code.

Archcore closes that specific gap:

• Before an edit, the pre-write hook injects the rules and specs that apply to the file being changed.
• At session start, a recap of what is decided and what is in progress, instead of a cold start.
• During the work, MCP tools to search, read, create, and link documents.
• Before the merge, a review that checks the branch against the decisions it claims to follow.

Installation

Archcore’s plugin needs the CLI on your PATH, because the CLI is what serves the MCP server the plugin talks to.

# 1. Install the CLI
curl -fsSL https://archcore.ai/install.sh | bash    # macOS / Linux
# Windows: irm https://archcore.ai/install.ps1 | iex

# 2. Set up the repository
cd your-project && archcore init

When you select Claude Code in archcore init, Archcore installs the plugin for that host. If you need to install the plugin separately, run these commands inside Claude Code:

/plugin marketplace add archcore-ai/plugin
/plugin install archcore@archcore-plugins

archcore init scaffolds .archcore/, registers the MCP server, installs the session hooks, and imports the CLAUDE.md you already wrote.

The CLI provides setup, MCP tools, and hooks. The plugin adds the planning, documentation, and review skills that use those tools and the same project documents.

Project context

Context lives as typed Markdown in a .archcore/ directory inside your repository:

.archcore/
  architecture/
    read-write-split.adr.md      # a decision, with its rationale
    session-api.spec.md          # a contract for a boundary
  api/
    typed-errors.rule.md         # scoped to src/api/
  auth/
    migration-q3.plan.md         # work in flight

Each document has a type, a status, and named relations (implements, extends, depends_on, related), so Claude Code can walk from the file it is editing to the rule that governs it and the decision that explains why the rule exists. See project context for what belongs in each.

Spec-driven development

/archcore:plan reads the request and existing project documents, then chooses the document package. A small fix can need no new documents. One capability usually needs a spec and a plan; a larger initiative can need an umbrella PRD and a spec per capability. The planning reference describes the routes.

For an explicit SDD path, use:

/archcore:plan sdd auth redesign

The spec does not stop being useful when the code lands. It stays in the repository, gets loaded when the boundary is edited, and is what /archcore:review measures the diff against. Spec-driven development covers the practice in full.

Automatic context and hooks

This is the part that needs no command.

The pre-write hook is the one that changes day-to-day behaviour. The rule about src/api/ arrives when Claude Code touches src/api/, not at the top of a long prompt where it competes with everything else.

MCP

The CLI runs a local stdio MCP server as a child process of Claude Code. It exposes document tools: list, search, get, create, update, remove, and relation management.

archcore mcp install --agent claude-code

archcore init does this for you. The MCP page covers why a protocol beats a file, and what a context server should expose.

The four commands

Everyday work needs none of them. They exist for the explicit cases.

Compared with CLAUDE.md and Claude Code memory

Claude Code has its own instruction and memory features. They solve adjacent problems.

Claude Code documents both nested CLAUDE.md files and editable Auto Memory notes. Cursor also reads CLAUDE.md. Archcore adds an explicit engineering-document workflow: types, status, relationships, and review against the branch.

You do not have to choose immediately. archcore init imports your existing CLAUDE.md as typed documents: conventions become rules, the reasoning behind them becomes decision records, and path-scoped instruction files keep their scope while gaining status and history.

Worked example

This is an illustrative scenario. The outcome depends on the agent reading the relevant documents and on review catching violations; it is not a measured comparison.

You ask Claude Code to add rate limiting to the auth endpoints.

Without project context. It picks a library it knows, ignores the Redis store you already run, invents an error shape, and puts the middleware somewhere reasonable but wrong for this repository.

With Archcore. The pre-write hook delivers the ADR recording that rate limiting goes through a Redis token bucket, the rule for error shapes under src/auth/, and the spec for the session API. The agent reuses the existing middleware pattern, returns the error shape your client already maps, and writes the new decision back as a document your team reviews in the pull request.

Same prompt. The difference is what the agent could see first.

Next

• Context engineering: the discipline this page applies
• Project context: what belongs in the documents
• Plugin: the full command surface and host matrix