Persistent Project Context for Claude Code

Reference · Updated August 10, 2026

Archcore gives Claude Code structured project context from Git, including specs, architecture decisions, rules, plans, and project knowledge, so the agent can follow how your repository is actually built.

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

Then add the plugin from 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.

Prefer no plugin? The CLI alone gives Claude Code MCP tools and hooks. Both paths read the same directory.

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

For work that needs a specification before implementation, /archcore:plan runs a gated track: idea → PRD → spec → plan. Each gate skips itself when a document already covers it, so a well-specified request runs without questions.

/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.

A useful way to hold it: CLAUDE.md tells Claude Code what you want. Archcore tells it how your system works. The first is a preference, the second is a fact about the repository, and the second is the one that has to survive a new session, a new teammate, and a different agent.

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

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