plan

Solid

Plan a feature or initiative through a computed route: the conductor derives the canon delta and assembles the document package — from a zero-document null route for small fixes to an umbrella PRD with one spec per capability for large initiatives. Modes, named as the first word: sdd (full package), sources (MRD → BRD → URD) for market research, customer discovery, and business or user requirements, iso (BRS → StRS → SyRS → SRS) for ISO 29148 and regulated work, research for a technical investigation — never market research — that the research instrument closes either by scope coverage (a research document) or by a recommendation (an rnd). Explicit form: plan research <topic>. Use for 'plan the X redesign', 'create a roadmap', 'plan a new feature', 'I need market research before we plan', 'we're regulated — start the ISO requirements cascade', 'investigate X before we plan', 'compare the alternatives for Y' — a new investigation, not a finished report already in hand. Not for recording a decision or documenti

AI & Automation 64 stars 10 forks Updated yesterday Apache-2.0

Install

View on GitHub

Quality Score: 84/100

Stars 20%
60
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# /archcore:plan Plan a feature or initiative through a computed route. The conductor (`skills/_shared/delta-routing.md`) derives the canon delta Δ, the gap profile Π, the zone maturity M, and the risk flags R, then assembles the document package; instruments produce the documents. Vision types are the primary output. Reads cover all three categories: vision supplies intent and resumption targets, knowledge supplies constraints, experience supplies precedent. ## When to use - "Plan the auth redesign" → computed route — typically `capability`: one spec plus one plan - "Create a roadmap for the API migration" → computed route - "Plan a new feature for CSV export" → computed route - "Plan the notifications platform" → computed route — typically `umbrella`: prd, one spec per capability, one plan - "I need market research before we plan" → acquisition instrument (`sources` mode) - "We're regulated — start the ISO requirements cascade" → iso links (`iso` mode) - "Investigate X before we plan" → research instrument, `research`; "Compare the alternatives for Y" → research instrument, `rnd` — a named pending decision or candidate set selects `rnd`, otherwise `research` - `plan research <topic>` → research instrument; the instrument selects `research` (closed by scope coverage) or `rnd` (closed by a recommendation) by its closing test **Not plan:** - Recording a decision → `/archcore:document` - Documenting existing code → `/archcore:document` - Codifying a team standard → `/archc...

Details

Author
archcore-ai
Repository
archcore-ai/archcore
Created
5 months ago
Last Updated
yesterday
Language
Shell
License
Apache-2.0

Similar Skills

Semantically similar based on skill content — not just same category

Code & Development Listed

plan

Primary router for planning, architecture, and track management workflows. Analyzes user intent and dispatches to new-track, decompose, adr, tech-debt, change (and related). Use for starting features, breaking down work, recording decisions, managing debt, or handling scope changes.

40 Updated 2 days ago
drafthq
AI & Automation Listed

plan

Greenfield planning intake — for projects that have NEITHER code NOR documentation. Interviews the owner section by section (a five-field kernel: Why, Capabilities, Constraints, Non-goals, Success signal), with a one-round elicitation menu after every drafted section → writes a BRIEF, then a PRD whose requirement rows carry gate-compatible codes, then an optional architecture spine → registers the PRD as a SOURCE document (specs.sources) so the verbatim gate guards everything /ba later shards from it. Writes planning documents only — never product code, never tickets, never the config itself.

6 Updated 5 days ago
connorpham
Code & Development Listed

plan

Use when implementation work should become a written `.context/` plan before coding starts — either multi-phase work (a feature build, a migration, a refactor spanning backend/frontend/infra) or a single scoped change where only the file list and acceptance criteria need pinning down; a triage step picks which. Fires on "create a plan for X", "let's plan X", "I want to plan X", "we need to plan X", "plan the migration of X", "let's build a multi-phase plan", "implement X minimally", "a small scoped change to X", "just the minimum to ship X". Not for: fixing a bug or regression, which needs a failing test (/aidex:bugfix); deferring or parking an idea for later (/aidex:backlog); ADRs (/aidex:decision), requests (/aidex:request), research (/aidex:research), or references (/aidex:reference); ecosystem audits (/aidex:aidex); project-state audits (/aidex:audit); coding without a plan doc.

2 Updated 4 days ago
yacb2