From archcore
Records finalized software decisions as ADRs (optionally with rules/guides) or open proposals as RFCs. Routes based on intent like 'we decided X' or 'proposing Y'; checks existing docs first.
npx claudepluginhub archcore-ai/plugin --plugin archcoreThis skill uses the workspace's default tool permissions.
Record a decision or a proposal for one. Routes between:
Creates Nygard-format ADRs to document significant technical decisions, context, and consequences. Use for system architecture, technology selection, or development patterns.
Generates Architecture Decision Records (ADRs) capturing context, rationale, alternatives, and consequences in numbered, status-tracked Markdown format.
Writes Architecture Decision Records (ADRs) with context, decision, consequences, and alternatives sections. Use for new ADRs, recording design decisions, or discussing trade-offs.
Share bugs, ideas, or general feedback.
Record a decision or a proposal for one. Routes between:
Not decide:
/archcore:plan/archcore:standard/archcore:capture/archcore:context/archcore:context| Signal | Route | Documents |
|---|---|---|
| User describes a finalized decision (default) | → adr | Single ADR |
| User describes an open proposal ("thinking about", "should we", "proposing") | → rfc | Single RFC |
| User says "and make it a standard" or implies enforcement | → adr + standard-track continuation | ADR, then offer rule + guide |
Default for finalized decisions: create a single ADR. After creation, offer: "Want to codify this into a team standard? (rule + guide)".
mcp__archcore__list_documents(types=["adr", "rfc"]) — check for existing decisions or proposals on this topic.
If user language suggests the decision is still open ("thinking about", "should we", "proposing", "design proposal"), confirm with the user: "This sounds like an open proposal — draft an RFC for team review?" If yes, proceed to Step 3b. Otherwise continue with Step 3 (ADR).
skills/_shared/precision-rules.md and skills/_shared/adr-contract.md once before composing. The contract specifies required structure; the rules specify forbidden lexicon and authoring conventions.[assumption] if forward-looking), Decision in one specific sentence, Alternatives Considered with ≥2 named items each carrying an explicit rejection reason, Consequences split into positive + tradeoff with falsifiable claims (or [expected]), and Superseded when with ≥2 measurable conditions when feasible. Avoid forbidden lexicon from the rules.mcp__archcore__create_document(type="adr")Then continue to Step 4.
mcp__archcore__create_document(type="rfc")extends existing ADR (if revising a past decision), or rfc related idea (if an idea inspired it).RFC flow ends here — no rule + guide continuation (those belong to finalized decisions).
mcp__archcore__add_relation — link the ADR to existing RFCs, specs, plans, or other relevant documents.
Ask: "Want to codify this into a team standard? I can create a rule (mandatory behavior) and guide (how-to) based on this decision."
If yes:
Rule:
skills/_shared/precision-rules.md if not already loaded.mcp__archcore__create_document(type="rule")mcp__archcore__add_relation — rule implements adrGuide:
mcp__archcore__create_document(type="guide")mcp__archcore__add_relation — guide related ruleMinimum: one ADR or one RFC. Maximum: ADR + rule + guide (the standard chain). Report: paths, relations, recommended next actions.