MCP Prompts Reference
The Archcore MCP server exposes 5 prompts in addition to its tools. Each prompt orchestrates a full document cascade in a single call — the agent creates and links every document in the chain for you, with a confirmation gate between phases.
Most MCP-aware clients surface prompts as slash commands. The exact prefix depends on the client (e.g. /product_track in some hosts, archcore.product_track in others).
MCP prompts vs plugin track skills
Section titled “MCP prompts vs plugin track skills”These MCP prompts are different from the plugin’s /archcore:product-track skill commands.
| MCP prompts | Plugin track skills | |
|---|---|---|
| Where they live | Archcore CLI’s MCP server | Archcore Plugin (Claude Code, Cursor) |
| Invocation | Slash command in any MCP-aware client (host-namespaced) | /archcore:<track-name> (plugin-scoped) |
| Available in | Any MCP client — Gemini CLI, Copilot, Codex, OpenCode, Roo Code, Cursor, Claude Code, … | Claude Code and Cursor only |
| Tracks shipped | 5 (product, architecture, standard, sources, iso) | 6 — adds feature-track |
Both exist by design. Use plugin tracks when you’re on a plugin host and want the richer skill experience. Use MCP prompts when you’re on a host the plugin doesn’t support yet, or when you want a host-agnostic way to drive cascades.
See Plugin tracks reference for the plugin-side equivalents.
Prompt catalog
Section titled “Prompt catalog”| Prompt | Chain | Relations created |
|---|---|---|
product_track | PRD → Plan | plan implements prd |
architecture_track | ADR → Spec → Plan | spec implements adr, plan implements spec |
standard_track | ADR → Rule → Guide | rule implements adr, guide related rule |
sources_track | MRD → BRD → URD | brd related mrd, urd related brd |
iso_track | BRS → StRS → SyRS → SRS | strs implements brs, syrs implements strs, srs implements syrs |
Each prompt’s last phase is followed by a verification step that lists every document and the wired relations.
How a prompt runs
Section titled “How a prompt runs”- The prompt frames the cascade with a short context message.
- For each phase, the agent calls
create_document(andadd_relationfor non-root phases). - Every phase ends with a confirmation gate (
ok to continue?) — you review the document before the next is generated. - After the final phase, the agent verifies the chain and reports the full set of documents.
You can stop at any gate. Documents already created stay; nothing is rolled back.
product_track
Section titled “product_track”Lightweight feature flow. PRD captures the requirements; Plan turns them into phased work.
Arguments:
| Name | Required | Description |
|---|---|---|
feature_name | Yes | Short name of the feature being specified. |
scope | No | One-line scope statement. |
Chain: PRD → Plan (plan implements prd).
Use when: an individual feature needs requirements and a delivery plan, but no formal architecture work.
Example:
/product_track feature_name="user notifications"architecture_track
Section titled “architecture_track”Technical design followed by implementation. ADR records the decision; Spec defines the contract; Plan delivers it.
Arguments:
| Name | Required | Description |
|---|---|---|
feature_name | Yes | Short name of the feature being specified. |
scope | No | One-line scope statement. |
component_name | No | Specific component the architecture targets. |
Chain: ADR → Spec → Plan (spec implements adr, plan implements spec).
Use when: a significant technical decision needs a normative spec and a delivery plan.
Example:
/architecture_track feature_name="event-driven orders" component_name="order-service"standard_track
Section titled “standard_track”Codify a team standard. ADR captures the decision; Rule is the imperative version teams follow; Guide is the how-to.
Arguments:
| Name | Required | Description |
|---|---|---|
feature_name | Yes | Short name of the standard topic (e.g. logging-conventions). |
scope | No | One-line scope statement. |
Chain: ADR → Rule → Guide (rule implements adr, guide related rule).
Use when: turning a one-off decision into a repeatable team practice with documented examples.
Example:
/standard_track feature_name="logging-conventions"sources_track
Section titled “sources_track”Discovery cascade for requirements that need explicit sources. MRD captures market context, BRD captures business intent, URD captures user requirements.
Arguments:
| Name | Required | Description |
|---|---|---|
feature_name | Yes | Short name of the feature being discovered. |
scope | No | One-line scope statement. |
Chain: MRD → BRD → URD (linked via related, since sources are peers — not implementations of each other).
Use when: a feature needs structured requirement discovery — market analysis, business objectives, user research — before product specs are written.
Example:
/sources_track feature_name="payments expansion"iso_track
Section titled “iso_track”Formal ISO/IEC/IEEE 29148:2018 cascade. Each level decomposes the one above it.
Arguments:
| Name | Required | Description |
|---|---|---|
feature_name | Yes | Short name of the feature being specified. |
scope | No | One-line scope statement. |
Chain: BRS → StRS → SyRS → SRS (each linked via implements).
Use when: regulated systems, multi-team programs, or any domain that needs formal traceability between business, stakeholder, system, and software requirements.
Example:
/iso_track feature_name="payment gateway compliance"See also
Section titled “See also”- MCP tools — the underlying tool API each prompt drives.
- MCP server — how the CLI exposes prompts to agents.
- Plugin tracks — the plugin-side equivalents (host-scoped under
/archcore:).