/document

name: document
argument-hint: "[subject]"
description: "Record a decision, document existing code, or file a supplied research material, in free text; no first word is a mode. 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, a repeated agent procedure, a user flow with examples over an existing spec, or a finished report or one external material already in hand. Name any document type inside the subject — journey, prd, idea, or cpat included — to get exactly that type. Planning a feature, an investigation not yet done, or an intended user journey the request asks to plan ('plan the onboarding journey') → /archcore:plan. Checking docs against code or docs health → /archcore:review."

/archcore:document

Record the present state: a technical decision, existing code, or a supplied research material. Context resolution (`skills/_shared/gate-contract.md`, section Context resolution) classifies the request and finds the present owner; a gate inside the selected track selects the document type. Write affinity: knowledge types; a filed `research` and the decision cascade's `plan` belong to vision. The standard cascade can add a `cpat` (experience). A type the user names explicitly keeps its own category (Named type below).

Command tense: `/archcore:plan` declares a future canon delta, `/archcore:document` records the present state — including work that shipped without a plan — and `/archcore:review` reconciles a past declared delta. Claim vocabulary: `skills/_shared/delta-routing.md`.

Load `skills/_shared/gate-contract.md` and `skills/_shared/elicitation-contract.md` before executing any gate.

Tracks

| Classification | Track and entry | Types the entry gate selects | |---|---|---| | decision | `skills/_shared/tracks/decision.md`, `decision.classify` | `adr`, `rfc`; `rule` through the standard cascade; an existing `rfc` draft on the topic → `decision.resolve`, which records an `adr` on an accepted verdict | | code-doc | `skills/_shared/tracks/describe.md`, `describe.read` | `spec`, `guide`, `task-type`, `scenario`, `doc` | | research material | `skills/_shared/tracks/research.md`, `research.frame` | `research`, `rnd` by the closing test; one external material → `evidence` |

No first word is a mode. When the subject text names a type (`skills/_shared/gate-contract.md`, Entry terms) that the selected track produces, the selecting gate treats that type as settled and asks no type question: `record an rfc for gRPC` reaches the RFC branch; a leading type slug takes the Named type path. No track produces a `journey`; a `journey` comes from `/archcore:plan` or from the named-type path below.

Named type

WHEN the first word of the subject is a kernel document type slug, or the subject writes a slug in backticks, the named type wins over routing (`explicit-type-request-wins.adr`). A slug elsewhere in plain topic text names no type here; inside a track the gate contract's naming rule still applies. When two slugs qualify, the first one wins.

1. IF a document track produces the named type as its own product, THEN enter that track with the type settled: `adr`, `rfc` → decision; `spec`, `doc`, `guide`, `scenario` → describe; `research`, `rnd`, `evidence` → research. 2. IF no document track produces it as its own product — `rule`, `journey`, `prd`, `idea`, `plan`, `cpat`, `task-type`, `mrd`, `brd`, `urd`, `brs`, `strs`, `syrs`, `srs` — THEN compose it directly per the steps below. A `rule` comes from the decision track only as a cascade member behind an `adr`; a named `rule` needs neither. 3. Apply the compatibility file for the type before the first MCP call that names it. 4. Search `.archcore/` for a local document of that type on the topic; when one exists, offer to update it instead. 5. Load `skills/_shared/<type>-contract.md` when that file exists, and `skills/_shared/precision-rules.md`. 6. WHEN no contract file exists, compose the sections of the `create_document` template for that type. 7. Create the document with `status: draft` through `create_document`. 8. Evaluate relations through `skills/_shared/relation-authoring.md`. 9. WHEN the type's routing condition fails, report it in one result line naming the better-fitting type; ask no question.

Examples of a failed routing condition: a `journey` where a covering `spec` exists (`scenario` fits), a `plan` composed without the conductor (it carries no Declared Delta), or a `rule` with no `adr` recording its reason.

When to use

• "We decided to go with microservices" — settled decision
• "Record the decision to use PostgreSQL"
• "Document why we chose JWT over sessions"
• "Make this our team standard for error handling"
• "Draft an RFC for switching from REST to gRPC"
• "Should we switch to Kubernetes?" — open choice: one question offers an `adr`, an `rfc` (resolved into an `adr` later), or investigating first
• "We accepted the proposal — resolve the RFC" — proposal resolution
• "Document the auth module"
• "Capture how the payment system works"
• "Create reference docs for the config system" — reference material
• "Write a guide for the release process" — how-to instructions
• "Write down how the agent cuts a release" — a repeated agent procedure (`task-type`)
• "Scenario for checkout over the checkout spec" — a user flow with examples over an existing spec
• "File this benchmark report" — a ready investigation
• "File this vendor PDF as evidence" — one external material

**Not document:**

• Planning a feature, an initiative, or an intended user journey the request does not name as a `journey` → `/archcore:plan`
• Checking documents against code, reviewing branch changes, or a documentation audit → `/archcore:review`
• First-time setup → `/archcore:init`

Routing table