Tracks

Plugin

A track is a multi-step workflow that orchestrates several documents at once. Each step builds on the previous one, and relations between documents are created automatically so the graph stays consistent.

Use a track when one document is not enough — when a decision needs a rule and a guide, when a feature needs discovery and a plan, when a regulated system needs the full ISO 29148 cascade.

The six tracks

Track	Flow	Use when
product-track	idea → prd → plan	Lightweight product flow — simple and fast.
sources-track	mrd → brd → urd	Discovery-focused — market, business, then user inputs.
iso-track	brs → strs → syrs → srs	Formal ISO 29148 cascade with traceability.
architecture-track	adr → spec → plan	Design decisions flowing into implementation.
standard-track	adr → rule → guide	Decision → codified standard → how-to.
feature-track	prd → spec → plan → task-type	Full feature lifecycle.

Invoke any track:

/archcore:product-track auth redesign
/archcore:architecture-track event-driven orders
/archcore:iso-track payment gateway compliance

How a track runs

1. The skill asks a short framing question (scope, constraints, stakeholders).
2. It creates the first document through MCP.
3. It creates each subsequent document, passing context forward, and wires implements / depends_on / related relations automatically.
4. You review each step — no document is final until you say so.

You can stop at any step. A product-track that only needs an idea and a PRD simply ends after step two.

Track in detail

Product track

Lightweight flow for individual features or small teams.

Flow: idea → prd → plan Relations created: prd implements idea, plan implements prd. Use when: you don’t need formal requirements decomposition — just capture, scope, and go.

Sources track

Discovery-focused flow for product teams doing research and stakeholder alignment.

Flow: mrd → brd → urd Relations created: brd related mrd, urd related mrd, brd. Use when: you need to understand the market, business case, and user context before writing requirements.

ISO track

Formal ISO 29148 cascade.

Flow: brs → strs → syrs → srs Relations created: strs implements brs, urd; syrs implements strs; srs implements syrs. Use when: regulated systems, multi-team projects, or any time you need traceability from business intent down to software requirements.

Architecture track

Design decisions flowing into implementation.

Flow: adr → spec → plan Relations created: spec implements adr, plan implements spec. Use when: a significant technical decision needs formal specification and an implementation plan. No rule/guide layer — that’s what standard-track is for.

Standard track

Decision codified as a mandatory practice.

Flow: adr → rule → guide Relations created: rule implements adr, guide related rule. Use when: the decision implies a team standard that needs enforcement and instructions. The classic chain for “we decided X, now everyone needs to follow it”.

Feature track

Full feature lifecycle with repeatable delivery pattern.

Flow: prd → spec → plan → task-type Relations created: spec implements prd, plan implements spec, task-type related plan. Use when: a well-scoped feature needs formal specification and a delivery pattern you can apply to similar features later.

Product-track vs sources-track vs ISO-track

All three start in the Vision layer, but they answer different questions:

• product-track — “what are we building?” (fast, informal)
• sources-track — “what do we know about the problem space?” (discovery)
• iso-track — “how is this formally specified and traceable?” (compliance)

You can run them in sequence (sources-track → product-track → architecture-track), or only the ones you need.

Architecture-track vs standard-track

Both start from an ADR.

• architecture-track — the decision leads to a formal spec and an implementation plan.
• standard-track — the decision is codified as a rule and explained in a guide.

Often a single ADR benefits from both.

Next steps

• Intent commands — /archcore:standard and /archcore:plan often delegate to tracks.
• Skills — tracks sit alongside intent commands and document-type skills.
• Track reference — one-page summary of all 6 tracks.