plan
SolidPlan 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
Install
Quality Score: 84/100
Skill Content
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
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.
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.
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.