| name | platonic-coding |
| description | Intelligent orchestrator for the Platonic Coding lifecycle. Auto-detects the user's intent and project state, then routes to the right next step—brainstorm a design, initialize a project, run the recovery flow for existing code, formalize drafts into RFCs, refine specs, implement from guides with tests, or review code compliance. Single entry point for the complete specification-driven development lifecycle, with structured design exploration built in. |
| license | MIT |
| metadata | {"version":"2.6.0","author":"Xiaming Chen","category":"workflow","replaces":["platonic-init","platonic-specs","platonic-impl","platonic-code-review","platonic-workflow","platonic-brainstorming"]} |
Platonic Coding
Intelligent orchestrator for the complete specification-driven development lifecycle. Auto-detects the user's intent and project state, then executes the appropriate workflow phase—brainstorming, initialization, specification management, implementation, or review. Structured design exploration (formerly the standalone platonic-brainstorming skill) is built in as BRAINSTORM mode.
When to Use This Skill
Use this skill when you need to:
- Brainstorm a design through collaborative dialogue before committing to an RFC
- Bootstrap a new project with Platonic Coding infrastructure
- Adopt Platonic Coding for an existing codebase (recover specs from code)
- Manage RFC specifications (validate, refine, generate indices)
- Implement features from RFC specs with guides and tests
- Review code for spec compliance
- Run the full workflow from design → RFC → code → review
Keywords: platonic coding, brainstorm, discuss, investigate, specs, RFC, implementation, review, workflow, spec-driven, initialization
Intelligent Auto-Detection
Auto-detects intent and project state when invoked without specific instructions. See references/REFERENCE.md for the full decision tree.
Intention Detection (runs first)
Before inspecting project state, scan the user's natural-language request for intent keywords that signal a desire to explore rather than immediately produce an artifact:
- Trigger words (case-insensitive):
brainstorm, discuss, investigate, explore, deep analysis, deep dive, think through, design exploration, trade-offs, what's the best approach.
- Match → enter BRAINSTORM mode (
references/BRAINSTORM/brainstorm.md), regardless of project state. The user wants to explore first; project-state detection resumes at handoff.
- Exception: if the request uses a canonical operation name (
impl-full, review, specs-refine, init-scaffold, workflow --phase <N>, brainstorm), the explicit operation wins — don't reroute it.
Project-State Detection (when no intent keywords)
Quick Reference:
- No Platonic infrastructure (no
.platonic.yml and no docs/specs/) → INIT mode (scaffold new or recover existing)
- RFCs but no guides → Phase 2 (implementation)
- Guides + code → Phase 3 (review) or resume Phase 2
Note: .platonic.yml is optional. The skill auto-detects project metadata (name, language, framework) from host manifests and uses built-in default paths (docs/specs, docs/impl, docs/drafts). A .platonic.yml is only needed to override defaults or set custom spec stages.
Override with canonical operations: brainstorm, init-scaffold, init-scan, specs-refine, impl-full, review, workflow --phase <N>.
Confirmation Gates & Clarifications
Many operations pause for user input — design approval, confirmation gates, routing menus, ambiguity blockers. At every such gate, call the ask_user tool with the question(s). Do not write questions as plain text.
Plain-text questions are invisible to the runtime clarification relay: the loop will not pause, the goal will finalize, and the user's reply will start a brand-new goal instead of resuming the paused one. The ask_user tool emits a structured interrupt that pauses the loop and resumes on the same turn once the user answers.
- One question per call when the questions are independent (aligns with "one question at a time" in BRAINSTORM mode).
- Present multiple-choice options as the content of a single question (e.g. "Which design: A) ... B) ... C) ...?") so the user picks one.
- Skip the gate only when the user explicitly said "no confirmations" or auto/quick-pass mode is active — but even then, if ambiguity blocks progress, call
ask_user rather than guessing.
See references/BRAINSTORM/brainstorm.md for the full gate taxonomy.
Core Workflow Phases
| Phase | Focus | Output | Brainstorming |
|---|
| 1 | RFC Specification | Draft → RFC → specs-refine | ✅ Optional (BRAINSTORM mode) |
| 2 | Implementation | Guide → Code + Tests | ✅ Optional (BRAINSTORM mode) |
| 3 | Review | Compliance report | ❌ |
Phases run sequentially (full workflow) or independently (explicit invocation). BRAINSTORM mode is an optional entry ramp to Phases 1 and 2. See references/WORKFLOW/workflow-overview.md for details.
Operation Modes
BRAINSTORM Mode
Structured design exploration through collaborative dialogue. Produces an approved design draft (docs/drafts/), then presents post-draft alternative paths (see below). Entered by intent keywords, or explicitly. No code, RFC, or scaffolding is produced until the design is approved.
Examples: brainstorm the message queue design, discuss how auth should work, investigate options for caching.
INIT Mode
Bootstrap Platonic Coding infrastructure. Operations: init-scaffold, init-scan, init-plan-modular-specs, init-recover-*.
Note: init-scaffold creates directories and templates but does not create .platonic.yml by default — project metadata is auto-detected from host manifests and default paths are used. A .platonic.yml is only created when the user explicitly requests non-default paths or custom spec stages.
Examples: init-scaffold for project "Acme", init-scan then recover specs.
SPECS Mode
Manage RFC specifications. Operations: specs-refine (comprehensive), specs-generate-*, specs-validate-*, specs-check-*.
Examples: specs-refine, specs-generate-index.
IMPL Mode
Translate RFCs to guides and code. Operations: impl-full (default), impl-create-guide, impl-code, impl-validate-guide, impl-update-guide.
Confirmation Gates: Pauses after the impl guide (which includes the coding plan). Override with "no confirmations".
Examples: impl-full for RFC-042, impl-code from IG-001.
REVIEW Mode
Validate code against specs. Generates report-only by default (no code changes). 6-step process: understand specs → checklist → map → review → discrepancies → report.
Examples: review src/auth/ against RFC-001, review for gap analysis.
WORKFLOW Mode
Orchestrate full 3-phase flow. See references/WORKFLOW/workflow-overview.md.
Examples: workflow --phase 1, workflow starting with brainstorm.
For detailed guides, see references/REFERENCE.md.
Post-Draft Alternative Paths
After BRAINSTORM mode produces an approved design draft, the skill does not assume "create a new RFC" is the only next step. It checks docs/specs/ and docs/impl/ for related existing RFCs/IGs, then presents a routing menu (full table in references/BRAINSTORM/brainstorm.md):
- Pause at each phase gate — careful, default; approve every confirmation gate
- Quick pass — run multiple phases straight through, no further confirmations (quick fixes)
- Update an existing RFC — revise a related RFC instead of spawning a new one
- Create a new RFC — formalize the draft into a fresh
RFC-NNN (next sequential NNN unless user overrides)
- Update an existing IG — refine an existing implementation guide via
impl-update-guide
- Create a new IG — generate a fresh
IG-XXX via impl-create-guide (next sequential XXX unless user overrides)
The menu leads with a recommendation based on what was found. The user picks by number; each path maps to existing canonical operations.
Default Paths & Templates
| Artifact | Path | Naming |
|---|
| Drafts | docs/drafts/ | YYYY-MM-DD-<topic>-design.md |
| RFCs | docs/specs/ | RFC-NNN-<name>.md (NNN = exactly 3 digits; strict sequence) |
| Guides | docs/impl/ | IG-XXX-<name>.md (XXX = exactly 3 digits; strict sequence) |
Templates in assets/ use {{PLACEHOLDER}} syntax.
Best Practices
- Trust auto-detection; override with explicit operations when needed
- Review generated artifacts (all Draft status)
- Run
specs-refine regularly
- Use confirmation gates—don't skip unless confident (or use quick-pass routing)
- Review mode is report-only by default
Dependencies
- Read/write to project directories
- Access to host manifests (
Cargo.toml, package.json, pyproject.toml, go.mod, etc.) for auto-detection
.platonic.yml is optional — only read if present for path/stage overrides- Understanding of target language/framework
