⏳ This skill is pending AI review.
Scores will appear once the review pipeline completes.
document
Record a decision, document existing code, or file a supplied research material. Modes: document decision (ADR, RFC, or rule), document code (spec, doc, guide, or scenario for existing behavior), document research (only when a finished report or one external material is already in hand). Use for 'we decided', 'record this decision', 'document why we chose X', 'make it our standard', 'draft an RFC', 'should we switch to Y' proposals, 'resolve the RFC', 'we accepted the proposal', 'document the auth module', 'capture how the payment system works', reference material, how-to instructions, or a user flow with examples over an existing spec. Name the type inside the subject to skip the type question. Planning a feature or an intended user journey → /archcore:plan. Checking docs against code or docs health → /archcore:review.
Choose how to use this skill
You do not need every option. Choose the path your AI client supports. The stable page stays the same; versioned files are immutable.
1. Native installer
This listing has no registered native installer command. Use the complete package or source fallback below, depending on what your client supports.
Do not guess an installer command or replace an existing version without reviewing the diff.
2. Complete package recommended
Download the ZIP when available. It includes SKILL.md plus the references, security notes and version metadata.
No complete ProSkills package is published for this listing yet.3. Prompt-only
Copy the prompt above when the agent can read the stable page or when you want to adopt the workflow without installing a skill.
Need only the instruction file?
Download SKILL.md only if your client requires a single file. The complete ZIP is safer for a full installation because it preserves the references and release context.
No path installs or executes anything by itself. Your agent still needs access to the project files. Before updating, compare the installed version and review the diff.
// RATINGS
// README
Archcore - Spec-driven development and git-native context engineering for AI coding agents
The agent stops guessing and starts following the system.
A coding agent can write the code. It does not know your project: what the feature must do, where the code belongs, which decisions and rules already apply. So it guesses, and you explain the same things again in the next session.
Archcore keeps specs, architecture, decisions, rules, and plans in Git, and makes the right project context available to AI coding agents as they work. It helps your coding agent make changes that fit your repo's architecture, rules, and past decisions.
/archcore:planbefore you build. The agent implements from a spec, examples, and tasks, sized to the change./archcore:documentas you go. One sentence from you becomes a finished, linked document./archcore:reviewbefore merge. Archcore compares the branch with the documents and names the side that is wrong.
Install
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
Then, in your project:
archcore init
The installer adds the CLI and plugins for Claude Code, Codex CLI, and GitHub Copilot CLI when it finds them. archcore init connects the agents you choose to this project. It also supports Gemini CLI, OpenCode, Roo Code, and Cline. Cursor needs one extra setup step.
Already have a CLAUDE.md, AGENTS.md, or rule files? Say /archcore:init import in your agent to turn them into project documents.
The documents stay in your repo, in .archcore/. Details: privacy.
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. Your answers become documents in .archcore/: a spec with requirements, and a plan with tasks mapped to files. A user-facing change also gets examples in Given/When/Then form. Larger work can add a PRD, research, or a formal requirements chain.
Archcore weighs the change, computes the route, and reports its size from S to XL. You never 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. A data migration adds a migration runbook.
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 decision why we chose [X]
/archcore:document code [module]
/archcore:document records what is true now: a decision, a team standard, how a module works, or a how-to. You do not choose a format. Archcore selects the document type, reads the code and the existing documents, and checks that the document does not exist yet. It asks you only what it cannot find. It links the new document to the related ones. A decision can also produce the rule and the guide that follow from it.
With no subject, /archcore:document reads the changes on your branch and asks one question about what to record.
The document outlives the session. It is in Git with the code, it 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 when the code breaks a document that still stands, spec-wrong when the document is out of date. You fix the right side. 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.
Use the three commands together on one change, or use one alone. Archcore does not need a plan for every change.
The slash commands run in Claude Code, Cursor, Codex CLI, and GitHub Copilot. In every connected agent, a plain sentence works too: “Plan [your feature]”, “Record why we chose [X]”, “Review my branch”.
Project knowledge becomes files
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 spec is one part of context, not the whole context: decisions, rules, plans, and guides live beside it. 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.
Go deeper
How Archcore works · Quick start · Commands · Contributing (source is on dev) · Apache 2.0 license
// HOW IT'S BUILT
KEY FILES