How to use Archcore
Install Archcore and give your coding agent project context. Plan changes, save decisions, and check that code follows them.
Install Archcore
The install script adds the Archcore CLI and the plugin for Claude Code, Codex CLI, GitHub Copilot CLI, and OpenCode when their commands are on PATH. Then run archcore init in your project folder.
During setup, choose the agents you use. Archcore connects them to the project through MCP and hooks. Cursor needs plugin setup in its Plugins panel.
Already have a CLAUDE.md, AGENTS.md, or rule files? Run /archcore:init import in your agent to turn them into project documents.
Use Archcore’s four skills in order
A skill is a set of instructions your agent follows for one job. Here, four skills help you add rate limiting to a public API: a cap on how often clients can call it.
Ask your agent using the example prompt, or run the slash command shown below. The commands work in Claude Code, Cursor, Codex CLI, and Copilot. Other agents access Archcore through MCP.
1. Describe the project
/archcore:init
Set up Archcore in this repo.
Your agent reads the repository and proposes documents describing its architecture, rules, and key modules. You review the proposal before Archcore saves it in .archcore/.
2. Plan the feature
/archcore:plan
Plan rate limiting for the public API.
Your agent reads the repository and the existing documents first, then asks you only what it cannot find there. It writes a spec for how rate limiting must behave and a plan with tasks mapped to files. A user-facing change also gets examples of the cases that matter.
Archcore sizes the change from S to XL and picks the documents. You do not choose a template or a size.
| 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 |
| One new capability | A spec and a plan |
| Several capabilities | A PRD, one spec per capability, and a plan |
Risk raises the size. A security requirement adds a formal requirements chain, and a data migration adds a migration runbook.
3. Save the decision
/archcore:document
Record the decision to use a token bucket in Redis.
Document the rate limiting module.
Your agent saves the choice and its reasoning in an architecture decision record (ADR) and links it to the spec. Future tasks can look up why you chose Redis for rate limiting. Ask it to document a module instead, and it reads the code and writes a spec or a reference document.
4. Review the code
/archcore:review
Review my branch before merge.
Your agent checks the code changes against the spec from step 2 and the decision from step 3. Each finding gets one verdict: code-wrong when the code breaks a requirement, spec-wrong when the document is out of date, and ok when they match. A change with no document still gets checked against the project’s decisions and rules.
You do not need all four on every change. Each command also works alone: record a decision while you code, or review a branch that had no plan.
While you code, supported hooks bring relevant specs and decisions to your agent. At the start of a session, they provide a recap of decisions and work in progress. Other agents can read the same documents through MCP.
The next feature starts with the context you have already saved. Your specs and decisions stay in Git alongside the code.