Archcore

Git-native project context for AI coding agents.
The agent stops guessing and starts following the system.

Website · Docs · Quick start

Install · Three commands · What you get · How it compares · Go deeper

curl -fsSL https://archcore.ai/install.sh | bash

A coding agent can write the code. It does not know your project: what the feature must do, where the code belongs, and which decisions and rules already apply. So it guesses, and you explain the same things again in the next session.

Archcore keeps specs, decisions, rules, and plans in Git, next to the code. Your agent reads them before it changes the code, so the change fits your architecture and past decisions.

Ask your agent in plain words:

• "Plan rate limiting for the public API."
• "Record why we chose Redis for the token bucket."
• "Document how the billing module works."
• "Review my branch before merge."

The agent picks the document type, asks only what it cannot find in the repo, and writes plain Markdown into .archcore/.

---

Install

1. Install the CLI and the agent plugins.

On macOS, Linux, or WSL:

curl -fsSL https://archcore.ai/install.sh | bash

On Windows (PowerShell 5.1+):

irm https://archcore.ai/install.ps1 | iex

The installer adds the CLI. It also adds the plugins for Claude Code, Codex CLI, and GitHub Copilot CLI when it finds them.

2. Connect your project.

archcore init

archcore init connects the agents you choose to this project.

3. Start in your agent.

/archcore:init

/archcore:init reads the repo and proposes a first set of documents: the stack, how to run the project, and an architecture overview. You confirm once.

Already have CLAUDE.md, AGENTS.md, or rule files?

Say /archcore:init import in your agent. Archcore turns those files into typed project documents.

Supported agents

Agent	Setup
Claude Code, Codex CLI, GitHub Copilot CLI	The installer adds the plugin
OpenCode	archcore init adds the plugin to the project
Gemini CLI, Roo Code, Cline	archcore init connects them
Cursor	One extra setup step

Privacy

The documents stay in your repo, in .archcore/. Details: privacy.

---

Three commands

When	Command	What you get
Before you build	/archcore:plan [your feature]	A spec, examples, and tasks, sized to the change
As you go	/archcore:document [subject]	One sentence from you becomes a finished, linked document
Before merge	/archcore:review	The branch checked against the documents, with the side that is wrong

Use the three commands together on one change, or use one alone. The slash commands run in Claude Code, Cursor, Codex CLI, and GitHub Copilot. In every connected agent, a plain sentence works too.

Plan: the agent builds from documents, not from a chat message

/archcore:plan [your feature]

/archcore:plan reads the repo and the existing documents first. Then it asks you only what it cannot find there. You never choose a template or a mode: plan creates only the documents that the change needs.

The change	What plan prepares
A small fix	No documents
A settled choice	A decision record
A change to existing behavior	A check of the covering spec: update the spec, or fix the code
A sequenced migration	A plan
One new capability	A spec and a plan
Several capabilities	A PRD, one spec per capability, and a plan

Risks, examples, and larger work

A user-facing change also gets examples in Given/When/Then form. A risk adds the check it needs: a security fix gets a security check. A formal requirements chain starts only when an obligation asks for traceability. A data migration that people run by hand adds a migration runbook. Larger work can add a PRD or research.

The agent then implements from the spec, the examples, and the tasks. The open questions are settled before the code, not after it.

Document: you say it once, Archcore writes the document

/archcore:document why we chose [X]
/archcore:document how [module] works

/archcore:document records what is true now: a decision, a team standard, how a module works, or a how-to. Archcore selects the document type, reads the code, and checks that the document does not exist yet. It links the new document to the related ones.

No subject, statuses, and follow-up documents

With no subject, /archcore:document reads the changes on your branch and asks one question about what to record.

A decision can also produce the rule and the guide that follow from it. Each document has a status (draft, then accepted), and review checks it against the code.

Review: the code and the documents agree before merge

/archcore:review

When documents cover the change, /archcore:review compares the branch with them in both directions. Each finding names the code and the document that disagree, and carries one verdict:

• code-wrong: the code breaks a document that still stands. Fix the code.
• spec-wrong: the document is out of date. Fix the document.

Plans, and changes no document covers

When a plan covers the branch, review checks its tasks and closes the plan when the work is done.

When no document covers the change, review still checks the branch against the decisions and rules the project has. If the branch repeats a pattern that no document records, review offers to record it. To record work that shipped without a plan, run /archcore:document.

---

What you get

Each command leaves plain Markdown in .archcore/, versioned with the code it describes. The document type is in the filename.

.archcore/
├── architecture/
│   └── architecture-overview.doc.md    ← /archcore:init
├── conventions/
│   └── project-stack.rule.md           ← /archcore:init
└── api/
    ├── rate-limiting.spec.md           ← /archcore:plan
    ├── rate-limiting.plan.md           ← /archcore:plan
    ├── token-bucket-in-redis.adr.md    ← /archcore:document
    └── error-shapes.rule.md            ← /archcore:document

A change to a document is a diff in a pull request, like a change to code. This repository's own .archcore/ is a working example.

---

How it compares

	Chat history	One CLAUDE.md or AGENTS.md	Archcore
Where context lives	In one session	In one file in the repo	In typed documents in .archcore/
Next session	Starts from zero	Reads the whole file	Reads the documents for the files it changes
Who writes it	Nobody	You, by hand	The agent, from one sentence from you
Kinds of context	Mixed in the chat	Mixed in one file	Specs, decisions, rules, plans, and guides, each in its own type
Checked against code	No	No	/archcore:review before merge

The trade-offs are real. The documents are files that your team reviews and keeps current, like code. A small fix gets no documents, so Archcore adds little to a project that has only small fixes. A single CLAUDE.md is still enough for a small repo with few rules.

---

Go deeper

• How Archcore works
• Quick start
• Commands
• Contributing (the source is on dev)
• Apache 2.0 license