Skip to content

Archcore commands and examples

Use Archcore in your agent to record project knowledge, plan a change, or review work against existing decisions. Describe the outcome in conversation or use one of the four slash commands below.

Slash commands require the Archcore plugin in a supported host. Other MCP agents can read and write the same documents through natural-language requests. For terminal operations, use the CLI command reference.

You want toCommandResult
Create initial context from this repository/archcore:initA preview of project documents and host wiring
Scope a change before implementation/archcore:planA document package based on the request and existing context
Record a decision or describe existing code/archcore:documentA typed document based on the supplied facts
Check changes against project context/archcore:reviewFindings about code and recorded documents
/archcore:init

Use this in a repository with existing code. The agent examines its structure and proposes an initial set of documents. Review the preview before confirming document creation and host wiring. An empty project has no implemented architecture to describe.

This is separate from terminal archcore init, which creates .archcore/ and configures your agent. See installation.

The first word selects the kind of run. Settings follow it.

ArgumentEffect
refresh (first word)Adds missing context in a previously seeded repository and refreshes host wiring
domain <slug> (first word)Focuses a run on one domain
--depth=light|standard|deepSets the synthesis budget; the default is standard
--scale=small|medium|largeOverrides detected repository scale
/archcore:init --depth=light
/archcore:init domain payments
/archcore:init refresh

Plugin v0.9.0 replaced --refresh, --domain=, and --mode with refresh, domain <slug>, and --scale. A former flag such as --refresh now starts a plain init.

Depth limits the proposed coverage; it is not a target number of documents. Review the count in the preview, especially for a large repository.

/archcore:plan add CSV export to the reporting API

The agent reads project context and code, identifies missing information, and announces the proposed document package. A small fix can need no new documents. One capability can need a spec and a plan; a larger initiative can need requirements and several specs.

Questions concern information the agent could not establish from the available sources. Review the resulting plan before choosing whether to implement it. An interrupted package can resume from its draft documents.

To run a specific planning workflow, put its mode first:

ModeUse it for
sddA full requirements, specification, and plan package
sourcesMarket, business, and user requirements sources
isoThe formal BRS, StRS, SyRS, and SRS requirements chain
researchAn investigation, closed by scope coverage or a recommendation
/archcore:plan research compare storage options for our pending database decision

A pending decision or named candidates select rnd; a territory investigation selects research. rnd and evidence are not modes. To file one external material, use /archcore:document research. Research and evidence vocabulary requires Archcore CLI 0.8.3 or later. On an older CLI, research falls back to rnd and reports the required version.

Any other first word, including a route name or a document type name, is part of the topic. The agent computes the route itself and does not ask you to choose one. The plugin source owns the routing rules.

When a planned capability has a user-facing surface, such as a UI or a conversational skill, or the repository has features/*.feature files or a BDD test runner, the package adds a journey beside the prd and a scenario after the capability’s spec. See document types. Scenario and journey support requires Archcore CLI 0.8.4 or later; on an older CLI, the agent skips both and reports the required version.

You can put a mode first to skip classification. Without a mode, the agent classifies the request from its wording and the branch changes.

ModeUse it forTypes it can produce
decisionA decision your project made, or an open proposaladr, rfc, rule
codeExisting code, reference material, a procedure, or a user flow over an existing specspec, doc, guide, scenario
researchA finished report or one external material that you already haveresearch, rnd, evidence

Use a decision your project actually made:

/archcore:document decision record our decision to use PostgreSQL and the reasons we discussed

A settled decision is an adr; an open proposal is an rfc. Review the result before marking it accepted. The agent can offer related rules, guides, or implementation documents when the decision calls for them.

To describe existing code, name the module and the information you need:

/archcore:document code describe src/payments and its public boundaries

Use document types to distinguish a behavioral contract (spec) from a reference description (doc). Record current behavior from source; do not turn an undocumented assumption into an accepted contract. When the repository has features/*.feature files, the agent reads them as evidence for specs and scenarios.

To skip the type question, name the type in the request:

/archcore:document code scenario for checkout

To file a ready report or one external material:

/archcore:document research https://example.com/report

The URL above is a placeholder: replace it with the material you want to record. A report that ends in a recommendation becomes an rnd; a report that covers a scope becomes a research; one material becomes an evidence.

Plugin v0.9.0 removed document evidence and document journey. Use document research for a material, and /archcore:plan for an intended user path.

/archcore:review
/archcore:review drift
/archcore:review deep
/archcore:review closeout

On a branch with changes, review checks the work against recorded context. On the default branch, or without a branch diff, the default command reports project health. A mode as the first word selects a different run:

ModeEffect
driftChecks for stale documents
deepRuns a full documentation audit, with coverage and relation findings
closeoutCloses a finished feature: reconciles the recorded plan with the implementation
experienceRecords a repeated change as a cpat or a task-type

Plugin v0.9.0 replaced --drift and --deep with plain words. A former flag such as --drift is now read as topic text.

Name a path or topic to narrow the review. When the scope includes scenarios, closeout reports whether each example was run, confirmed, or unconfirmed, and lists spec clauses that have no example. Document acceptance and permanent removal remain explicit decisions.

Start with one decision, rule, or procedure that the agent will need soon. Ask:

Extract the API error convention from AGENTS.md into an Archcore rule. Preserve its meaning and show me the draft before changing the source instructions.

Review the new document and check retrieval in a fresh session. Then remove duplicated project knowledge from the source instruction file, keeping agent-specific settings and the Archcore managed block.

/archcore:init can also import existing CLAUDE.md, AGENTS.md, and .cursorrules content as part of its preview. Review the import before approving it. Project context explains file organization and relations.

Some commands delegate multi-document work to archcore-assistant or read-only auditing to archcore-auditor. You normally request the outcome through the commands above; the skill chooses its helper. The host controls tool permissions.