OpenSpec Guided Onboarding
Fission-AI/OpenSpec
Walks you through a complete OpenSpec workflow cycle with narration while doing real work in your codebase.
Spec-driven planning for complex design tasks: when to plan, how to write specs as .ato files, and how to verify against requirements.
$ npx skills add atopile/atopile --skill planning -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install atopile/atopile planning --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/atopile/atopile.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/planning .claude/skills/planning && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "planning" agent skill from https://github.com/atopile/atopile/tree/main/.claude/skills/planning into .claude/skills/planning/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "planning", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/atopile/atopile/tree/main/.claude/skills/planningType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add atopile/atopile --skill planning -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install atopile/atopile planning --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/atopile/atopile.git skills-src && mkdir -p .agents/skills && cp -r skills-src/.claude/skills/planning .agents/skills/planning && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "planning" agent skill from https://github.com/atopile/atopile/tree/main/.claude/skills/planning into .agents/skills/planning/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "planning", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add atopile/atopile --skill planning -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install atopile/atopile planning --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/atopile/atopile.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/.claude/skills/planning .cursor/skills/planning && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "planning" agent skill from https://github.com/atopile/atopile/tree/main/.claude/skills/planning into .cursor/skills/planning/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "planning", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/atopile/atopile.git --path .claude/skills/planning--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add atopile/atopile --skill planning -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install atopile/atopile planning --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/atopile/atopile.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/.claude/skills/planning .gemini/skills/planning && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "planning" agent skill from https://github.com/atopile/atopile/tree/main/.claude/skills/planning into .gemini/skills/planning/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "planning", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install atopile/atopile planningInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add atopile/atopile --skill planning -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/atopile/atopile.git skills-src && mkdir -p .github/skills && cp -r skills-src/.claude/skills/planning .github/skills/planning && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "planning" agent skill from https://github.com/atopile/atopile/tree/main/.claude/skills/planning into .github/skills/planning/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "planning", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add atopile/atopile --skill planning -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install atopile/atopile planning --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/atopile/atopile.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/.claude/skills/planning .opencode/skills/planning && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "planning" agent skill from https://github.com/atopile/atopile/tree/main/.claude/skills/planning into .opencode/skills/planning/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "planning", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
planningSpec-driven planning for complex design tasks: when to plan, how to write specs as .ato files, and how to verify against requirements.
Planning is an agent skill from atopile/atopile. Spec-driven planning for complex design tasks: when to plan, how to write specs as .ato files, and how to verify against requirements.
Its SKILL.md is about 4k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.
It sits in Agent Workflows, covering Spec-driven development. The repository describes itself as: Design circuit boards with code! ✨ Get software-like design reuse 🚀, validation, version control and collaboration in hardware; starting with electronics ⚡️. The licence is MIT.
4 steps, taken from the step headings in SKILL.md.
Read from SKILL.md and the folder at commit 619eda7. It shows what the files ask for, not the result of running them.
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
No scripts in the folder and no shell commands in SKILL.md (its code samples are ato and yaml).
From the folder's file list and the shell code blocks in SKILL.md.
No URLs in SKILL.md.
From URLs in SKILL.md, links to its own repository left out.
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Planning loads about 4k tokens when it runs. Until then it costs about 36 tokens; SKILL.md has 1,342 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
The full file from atopile/atopile at commit 619eda7, republished under its MIT licence (© atopile). 1,342 words, ~3,951 tokens.
.claude/skills/planning/SKILL.md (or your agent's skills folder).Simple tasks — just do it:
Complex tasks — always plan first:
Do not ask whether to plan. For complex tasks, go straight into planning. Write the spec, create the checklist, call design_questions — all in one turn. The user sees the spec and questions, and can steer from there. This is faster than a back-and-forth about whether to plan.
The spec and the design are one and the same .ato file. A spec is just the design at a high level of abstraction — skeleton modules, interfaces, constraints, and requirements. As you implement, you fill in real components, pin mappings, and values. The file grows; the structure stays.
Do not create separate spec files. The main .ato file IS the spec.
Do not suffix module names with "Spec". PowerSupply, not PowerSupplySpec. These names persist into the final design — name them for what they are, not for the fact that they started as a spec. See the ato skill §1.9 for naming guidance.
Every project with ICs should follow this structure. IC wrapper packages are separate from the main design.
my-project/
├── ato.yaml # Project-level builds defined here
├── main.ato # Top-level design — imports packages, not raw parts
├── packages/
│ ├── stm32g474/
│ │ └── stm32g474.ato # Wrapper: raw pins → standard interfaces
│ ├── drv8317/
│ │ └── drv8317.ato
│ └── tcan3414/
│ └── tcan3414.ato
├── parts/ # All raw parts (ICs + connectors)
│ ├── STMicroelectronics_STM32G474CBT6/
│ ├── TEXAS_INSTRUMENTS_DRV8317HREER/
│ ├── Changzhou_Amass_Elec_XT30U_M/
│ └── ...
└── layouts/| Item | Location | Why |
|---|---|---|
| IC wrapper modules | packages/<name>/<name>.ato | Complex pin mapping, reusable |
| All raw parts | parts/ (project root) | Installed by parts_install |
| Simple self-contained parts | Used directly in main.ato | No supporting components or high-level interfaces needed (e.g. connectors, LEDs, test points) |
| Generic passives | stdlib (import Resistor) | No package needed |
| Top-level design | main.ato | Imports wrappers, never raw _package |
ElectricPower, I2C, SPI, CAN, UART, SWD, USB2_0, USB2_0_IF, ElectricLogic, ElectricSignal, not raw pinsato.yaml inside package directories — package targets are discovered automaticallyato.yaml — use workspace_list_targets to discover package targets exposed by local packagesato.yaml formatrequires-atopile: ^0.14.0
paths:
src: ./
layout: ./layouts
builds:
default:
entry: main.ato:DualBLDCController
# Package builds — for independent testing
stm32g474:
entry: packages/stm32g474/stm32g474.ato:STM32G474
hide_designators: true
drv8317:
entry: packages/drv8317/drv8317.ato:DRV8317
hide_designators: true#pragma experiment("BRIDGE_CONNECT")
import ElectricPower
import CAN
import ElectricLogic
import Capacitor
from "parts/STMicroelectronics_STM32G474CBT6/STMicroelectronics_STM32G474CBT6.ato" import STMicroelectronics_STM32G474CBT6_package
module STM32G474:
"""STM32G474 MCU with decoupling and standard interfaces.
Exposes:
- power: 3.3V rail
- can: CAN FD interface (PA11/PA12)
- pwm_a: 3x PWM for motor A (TIM1: PA8/PA9/PA10)
- pwm_b: 3x PWM for motor B (TIM8: PB13/PB14/PB15)
"""
# ── External interfaces ──
power = new ElectricPower
can = new CAN
pwm_a = new ElectricLogic[3]
pwm_b = new ElectricLogic[3]
# ── Package ──
package = new STMicroelectronics_STM32G474CBT6_package
# ── Power ──
power.hv ~ package.VDD
power.hv ~ package.VDDA
power.lv ~ package.VSS
power.lv ~ package.VSSA
assert power.voltage within 3.3V +/- 10%
# ── Decoupling ──
decoupling = new Capacitor[3]
for cap in decoupling:
cap.capacitance = 100nF +/- 10%
cap.package = "C0402"
power ~> cap ~> power.lv
# ── CAN ──
can.tx.line ~ package.PA11
can.rx.line ~ package.PA12
can.tx.reference ~ power
can.rx.reference ~ power
# ── PWM ──
pwm_a[0].line ~ package.PA8
pwm_a[1].line ~ package.PA9
pwm_a[2].line ~ package.PA10
pwm_b[0].line ~ package.PB13
pwm_b[1].line ~ package.PB14
pwm_b[2].line ~ package.PB15main.ato#pragma experiment("BRIDGE_CONNECT")
import ElectricPower
from "packages/stm32g474/stm32g474.ato" import STM32G474
from "packages/drv8317/drv8317.ato" import DRV8317
from "packages/tcan3414/tcan3414.ato" import TCAN3414
from "parts/Changzhou_Amass_Elec_XT30U_M/Changzhou_Amass_Elec_XT30U_M.ato" import Changzhou_Amass_Elec_XT30U_M_package
module DualBLDCController:
"""Dual BLDC motor controller for robot drivetrain."""
mcu = new STM32G474
motor_a = new DRV8317
motor_b = new DRV8317
can_phy = new TCAN3414
power = new ElectricPower
power ~ mcu.power
power ~ motor_a.motor_supply
power ~ motor_b.motor_supply
mcu.can ~ can_phy.can
mcu.pwm_a ~ motor_a.pwm
mcu.pwm_b ~ motor_b.pwmThe file at packages/<name>/<name>.ato is the canonical wrapper boundary for that part or subsystem.
Refine that file in place. main.ato should import those wrapper packages directly rather than routing through an extra wrapper aggregator file.
Capture natural-language requirements directly in the module's docstring under a Requirements: section. Place requirements on whichever module owns them — top-level for system-wide requirements, on a specific subsystem for module-specific ones.
module PowerStage:
"""Three-phase MOSFET bridge sized for continuous motor current.
Requirements:
- R1: 20A continuous — FET stage rated for 20A with thermal margin
"""Format: - R<id>: <short text> — <criteria>
These requirements stay in the design permanently. They document design intent alongside the implementation.
The spec is the skeleton of the design. It defines architecture, requirements, and constraints — but leaves out implementation details (pin mappings, support circuits). Those get filled in during implementation.
#pragma experiment("BRIDGE_CONNECT")
import ElectricPower
import CAN
import ElectricLogic
module BLDCController:
"""
# BLDC Motor Controller
Dual-motor BLDC controller using STM32G474 and two DRV8317 drivers.
## Key Decisions
- STM32G474 MCU — motor control timers + CAN FD
- DRV8317 gate driver — 3-phase, integrated LDO
## Requirements
- R1: MCU platform — Uses STM32G474
- R2: 5-18V input — Operating voltage range
- R3: Dual motor — 2x DRV8317 in 3-PWM mode
## Open Questions
- Current sensing: phase shunt vs low-side?
"""
# ── Architecture ──
power = new PowerSupply
control = new MCU
motor_a = new MotorDrive
motor_b = new MotorDrive
comms = new CANTransceiver
power.rail_3v3 ~ control.power
power.motor_supply ~ motor_a.supply
power.motor_supply ~ motor_b.supply
control.pwm_a ~ motor_a.pwm
control.pwm_b ~ motor_b.pwm
control.can ~ comms.can
assert power.vin.voltage within 5V to 18V
module PowerSupply:
"""Power input and regulation."""
vin = new ElectricPower
rail_3v3 = new ElectricPower
motor_supply = new ElectricPower
module MCU:
"""STM32G474 with timers and comms peripherals."""
power = new ElectricPower
can = new CAN
pwm_a = new ElectricLogic[3]
pwm_b = new ElectricLogic[3]
module MotorDrive:
"""DRV8317 3-phase gate driver."""
supply = new ElectricPower
pwm = new ElectricLogic[3]
module CANTransceiver:
"""CAN FD transceiver with UAVCAN connector.
Requirements:
- R4: CAN FD transceiver with UAVCAN connector
"""
can = new CAN| Spec Concept | ato Mechanism |
|---|---|
| Overview | Module docstring ("""...""") |
| Architecture | Sub-modules + connections (~) |
| Requirements | - R<id>: <text> — <criteria> in module docstring |
| Formal constraints | assert statements |
| Component selection | new instantiations |
| Sub-system descriptions | Child module docstrings |
| Open questions | Section in docstring |
When creating a spec, also create a checklist to track implementation progress. Link checklist items to spec requirements:
checklist_create({
items: [
{id: "spec", description: "Write spec and project structure", criteria: "main.ato with architecture and project-level ato.yaml"},
{id: "questions", description: "Gather design decisions", criteria: "design_questions called with all open questions"},
{id: "pkg-mcu", description: "Create MCU wrapper package", criteria: "packages/stm32g474/stm32g474.ato with standard interfaces"},
{id: "pkg-driver", description: "Create gate driver wrapper package", criteria: "packages/drv8317/drv8317.ato with standard interfaces"},
{id: "integrate", description: "Wire up top-level design", criteria: "main.ato connects packages through interfaces"},
{id: "build", description: "Build and verify", criteria: "Build passes or issues clearly identified"},
]
})The goal is to front-load all questions and decisions, then implement without interruption.
Do steps 1-5 in a SINGLE turn — do not end your turn after announcing you will plan.
ato.yaml and packages/ directories. Do not add manual package-wrapper build targets for generated local packages.main.ato — architecture with sub-modules, requirements in docstrings, interface connections, and formal constraints. Use standard library interfaces (CAN, I2C, SPI, SWD, USB2_0, ElectricPower, ElectricLogic, ElectricSignal) in the spec instead of inventing local interfaces unless there is a real reusable boundary not covered by stdlib.design_questions with ALL open questions at once. Include suggested options and recommended defaults where possible — make it easy for the user to answer quickly. Your turn ends automatically after this call.Use design_questions any time you have multiple design decisions to gather. It presents structured questions with bullet-point options that the user can answer or override with freeform text. Do not trickle questions across multiple turns — batch them all into one design_questions call.
web_search, map pins to interfaces.web_search pass to inspect the vendor datasheet/design guide, compare families, confirm the typical topology, and find reference-circuit guidance.main.ato or project modules above the wrapper.parts_install(project_path="packages/<name>").package_agent_spawn(project_path="packages/<name>", goal=..., comments=...) so the main agent can keep moving on integration and architecture.workspace_list_targets to discover package targets automatically exposed by local packages, then build/fix wrappers and other submodules before attempting the full design.main.ato — connect packages through their interfaces. No raw _package imports here.Do not end your turn to ask follow-up questions — make reasonable assumptions and note them. The user can course-correct via steering messages.
PowerSupply stays PowerSupply.packages/, not in main.ato. Raw _package components are never imported in main.ato.© atopile, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
Just SKILL.md in .claude/skills/planning of atopile/atopile.
Open the folder on GitHubat commit 619eda7
Planning next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Planning this skillatopile/atopile | 4k | — | ~4k | Automated safety check: Pass | MIT | |
| OpenSpec Guided OnboardingFission-AI/OpenSpec | 71k | 1 repos | ~4.5k | Automated safety check: Pass | MIT | |
| Readyprekuter/dryforge | 413 | 1 repos | ~6.8k | Automated safety check: Pass | Apache-2.0 | |
| Spec Driven Developzhu1090093659/deepseek-pp | 1.9k | — | ~6.9k | Automated safety check: Pass | Apache-2.0 | |
| MoAI Foundation Coremodu-ai/moai-adk | 1.2k | — | ~5k | Automated safety check: Pass | Apache-2.0 | |
| Goprekuter/dryforge | 413 | 1 repos | ~7.2k | Automated safety check: Pass | Apache-2.0 |
Fission-AI/OpenSpec
Walks you through a complete OpenSpec workflow cycle with narration while doing real work in your codebase.
prekuter/dryforge
Understand what you mean before anything is built. An agent skill from prekuter/dryforge.
zhu1090093659/deepseek-pp
Automates pre-development workflow for large-scale complex tasks.
modu-ai/moai-adk
Reference for MoAI-ADK's core development principles: TRUST 5 quality gates, SPEC-first domain-driven workflow, agent delegation and token budgeting.
prekuter/dryforge
Carry out the intent approved in ready, as meant, and prove it with checks that actually ran.
fynnfluegge/agtx
Carries out an approved plan for an agtx-managed task: implements the changes, runs tests, commits, writes a summary to .agtx/execute.md and then stops.
atopile/atopile
Reference for the .ato declarative DSL: type system, connection semantics, constraint model, and standard library.
atopile/atopile
How the atopile compiler builds and links TypeGraphs from .ato (ANTLR front-end → AST → TypeGraph → Linker → DeferredExecutor), plus the key invariants and test entrypoints.
atopile/atopile
Instructions for electronics-specific logic and build processes: netlists, PCBs, build steps, and exporters.
atopile/atopile
How FabLL (faebryk.core.node) maps Python node/trait declarations into the TypeGraph + instance graph, including field/trait invariants and instantiation patterns.
atopile/atopile
How Faebryk's TypeGraph works (GraphView + Zig edges), how to traverse/resolve references, and how FabLL types/traits map onto edge types.
atopile/atopile
How the Zig-backed instance graph works (GraphView/NodeReference/EdgeReference), the real Python API surface, and the invariants around allocation, attributes, and cleanup.
Categories
Spec-driven planning for complex design tasks: when to plan, how to write specs as .ato files, and how to verify against requirements. Planning is an agent skill from atopile/atopile.ato files, and how to verify against requirements.
Planning fits situations like: tasks that involve Spec-driven development.
Run `npx skills add atopile/atopile --skill planning -a claude-code`. Or copy the skill folder (.claude/skills/planning in atopile/atopile) into .claude/skills/planning in your project. Claude Code loads it when a task matches its description.
Run `npx skills add atopile/atopile --skill planning -a codex`. Or copy the skill folder (.claude/skills/planning in atopile/atopile) into .agents/skills/planning in your project. Codex loads it when a task matches its description.
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add atopile/atopile --skill planning -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/planning, .gemini/skills/planning, .github/skills/planning and .opencode/skills/planning in your project.
SKILL.md names no scripts, command-line tools or credentials: Planning is instructions for the agent only.
SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
Planning is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
About 4k tokens (SKILL.md is roughly 16k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.
Skills that share tags, products or a category with Planning: OpenSpec Guided Onboarding (Fission-AI/OpenSpec, 71k stars), Ready (prekuter/dryforge, 413 stars), Spec Driven Develop (zhu1090093659/deepseek-pp, 1.9k stars) and MoAI Foundation Core (modu-ai/moai-adk, 1.2k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
atopile (a GitHub organization) maintains it in atopile/atopile, which has 3,979 GitHub stars. The repository holds 19 skills in this directory. The repository was last updated on June 13, 2026.
Source: atopile/atopile on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.