Agent skill

Planning

by atopile in 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.

MITAuto-check passedAgent Workflows

Install Planning

skills CLI
$ npx skills add atopile/atopile --skill planning -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install atopile/atopile planning --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ 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-src

Use ~/.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/

Facts

Skill name
planning
GitHub stars
4k
Token cost
~4k tokens
SKILL.md length
1,342 words
Files
1
Skills in repo
19
Repo updated
First seen
Licence
MIT

At a glance

Spec-driven planning for complex design tasks: when to plan, how to write specs as .ato files, and how to verify against requirements.

  • Works in 4 steps: Spec & Ask (end turn after this) → Lock decisions (brief) → Implement end-to-end (do not stop) → …
  • Tasks that involve Spec-driven development
  • SKILL.md covers What goes where, Key rules, ato.yaml format and Package wrapper pattern, plus 6 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

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.

When your agent uses it

  • Tasks that involve Spec-driven development

Example prompts

  • “/planning”

Workflow steps

4 steps, taken from the step headings in SKILL.md.

  1. Spec & Ask (end turn after this)
  2. Lock decisions (brief)
  3. Implement end-to-end (do not stop)
  4. Report results

What it can do on your machine

Read from SKILL.md and the folder at commit 619eda7. It shows what the files ask for, not the result of running them.

  • Tool permissions

    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.

  • Runs code

    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.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

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.

Always · name and description, kept in context so the agent knows when to use it
~36
When it runs · the whole SKILL.md, loaded when a task matches
~4k

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.

Safety

Auto-check passed

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.

SKILL.md

The full file from atopile/atopile at commit 619eda7, republished under its MIT licence (© atopile). 1,342 words, ~3,951 tokens.

Download SKILL.mdSave it as .claude/skills/planning/SKILL.md (or your agent's skills folder).
name
planning
description
Spec-driven planning for complex design tasks: when to plan, how to write specs as .ato files, and how to verify against requirements.

When to Plan

Simple tasks — just do it:

  • Single component add/remove/change, value change, rename
  • Read/explain code or design
  • Fix a specific build error
  • Any task with a single clear action

Complex tasks — always plan first:

  • Multi-component system design (2+ ICs interacting)
  • New board or subsystem from scratch
  • Unclear or function-level requirements ("I need a motor driver", "design me a sensor board")
  • Tasks where you need to make multiple architectural choices

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 IS the Design

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.

Project Structure

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/

What goes where

ItemLocationWhy
IC wrapper modulespackages/<name>/<name>.atoComplex pin mapping, reusable
All raw partsparts/ (project root)Installed by parts_install
Simple self-contained partsUsed directly in main.atoNo supporting components or high-level interfaces needed (e.g. connectors, LEDs, test points)
Generic passivesstdlib (import Resistor)No package needed
Top-level designmain.atoImports wrappers, never raw _package

Key rules

  • ICs always get wrapper packages — MCU, gate driver, transceiver, anything with complex pin mapping
  • Wrapper modules expose standard interfaces — ElectricPower, I2C, SPI, CAN, UART, SWD, USB2_0, USB2_0_IF, ElectricLogic, ElectricSignal, not raw pins
  • Check stdlib before defining new interfaces — if stdlib already has the right interface, or the boundary can be modeled as arrays/composition of stdlib interfaces, use that instead of inventing a project-local interface
  • Wrapper packages are generic — package boundaries should reflect chip capability, not one board's exact subsystem decomposition or role naming
  • Self-contained parts don't need wrappers — anything that doesn't need supporting components and doesn't expose high-level interfaces (connectors, LEDs, test points, mounting holes)
  • No ato.yaml inside package directories — package targets are discovered automatically
  • Do not add manual package wrapper build targets to the top-level ato.yaml — use workspace_list_targets to discover package targets exposed by local packages

ato.yaml format

yaml
requires-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

Package wrapper pattern

ato
#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.PB15

Clean main.ato

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.pwm

The 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.

Requirements in Docstrings

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.

ato
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.

Spec Format

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.

ato
#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

How spec concepts map to ato

Spec Conceptato Mechanism
OverviewModule docstring ("""...""")
ArchitectureSub-modules + connections (~)
Requirements- R<id>: <text> — <criteria> in module docstring
Formal constraintsassert statements
Component selectionnew instantiations
Sub-system descriptionsChild module docstrings
Open questionsSection in docstring

Checklist for Tracking Progress

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"},
  ]
})

Planning Flow

The goal is to front-load all questions and decisions, then implement without interruption.

Phase 1: Spec & Ask (end turn after this)

Do steps 1-5 in a SINGLE turn — do not end your turn after announcing you will plan.

  1. Read existing project files to understand current state.
  2. Set up project structure — create the project-level ato.yaml and packages/ directories. Do not add manual package-wrapper build targets for generated local packages.
  3. Write the spec as 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.
  4. Create checklist with items for each package wrapper + integration + build.
  5. Call 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.

Show full SKILL.md (508 more words)Show less

Phase 2: Lock decisions (brief)

  1. Wait for user answers. Incorporate all decisions into the spec and checklist in one pass.

Phase 3: Implement end-to-end (do not stop)

  1. Create package wrappers — one per IC. Install parts, inspect vendor datasheets/design guides with web_search, map pins to interfaces.
    • Before committing to an unfamiliar IC, motor driver, PMIC, RF part, or other high-risk part, do a brief web_search pass to inspect the vendor datasheet/design guide, compare families, confirm the typical topology, and find reference-circuit guidance.
    • Keep wrappers reusable across projects. Expose generic chip capabilities and keep board-specific grouping and role naming in main.ato or project modules above the wrapper.
    • Start each wrapper as a basic reusable boundary with the minimum standard interfaces needed to validate the package target and integrate the design. Add more interfaces or alternate pin mappings later only if integration proves they are needed.
    • If a wrapper needs new supporting passives, crystals, or connectors while you are validating that package target, install them into the package project itself with parts_install(project_path="packages/<name>").
    • Once a package project exists and the work is independent, delegate it with package_agent_spawn(project_path="packages/<name>", goal=..., comments=...) so the main agent can keep moving on integration and architecture.
  2. Validate package targets first — use workspace_list_targets to discover package targets automatically exposed by local packages, then build/fix wrappers and other submodules before attempting the full design.
    • Build smaller design sections first because they are much faster to validate.
    • Run independent package/submodule builds in parallel where practical to get faster feedback.
    • Do not mark wrapper creation blocked just because the full ideal interface set is not exposed yet. Build the basic wrapper, validate it, and continue expanding it during integration.
    • Use the full-design build only after those smaller targets are green so it serves as an integration check, not the first debugging loop.
  3. Wire up main.ato — connect packages through their interfaces. No raw _package imports here.
  4. Build and verify the full design last — once package and submodule targets are green, run the top-level build and fix integration issues.

Do not end your turn to ask follow-up questions — make reasonable assumptions and note them. The user can course-correct via steering messages.

Phase 4: Report results

  1. Return results with a concise summary of what changed, build status, and any assumptions you made.

Rules

  • Do not ask whether to plan — for complex tasks, just do it. The user sees the spec and can steer.
  • The spec IS the design file — same modules, same names, same structure. It just starts abstract and gets filled in.
  • Do not rename modules when transitioning from spec to implementation. PowerSupply stays PowerSupply.
  • Place requirements in the docstring of whichever module owns them, not all on the top-level.
  • IC wrappers go in packages/, not in main.ato. Raw _package components are never imported in main.ato.
  • Update the spec as you learn things (it's a living document).
  • If a build fails during implementation, check if the fix still meets requirements before moving on.
  • For simple tasks, skip all of this — just implement directly.
  • Keep requirements verifiable, not vague.

© atopile, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .claude/skills/planning of atopile/atopile.

Open the folder on GitHubat commit 619eda7

Compare with similar skills

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.

Planning compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Planning this skillatopile/atopile4k—~4kAutomated safety check: PassMIT
OpenSpec Guided OnboardingFission-AI/OpenSpec71k1 repos~4.5kAutomated safety check: PassMIT
Readyprekuter/dryforge4131 repos~6.8kAutomated safety check: PassApache-2.0
Spec Driven Developzhu1090093659/deepseek-pp1.9k—~6.9kAutomated safety check: PassApache-2.0
MoAI Foundation Coremodu-ai/moai-adk1.2k—~5kAutomated safety check: PassApache-2.0
Goprekuter/dryforge4131 repos~7.2kAutomated safety check: PassApache-2.0

Similar skills

  • OpenSpec Guided Onboarding

    Fission-AI/OpenSpec

    Walks you through a complete OpenSpec workflow cycle with narration while doing real work in your codebase.

    71k GitHub starsUsed in 1 repo~4.5k tokens
    Agent WorkflowsAuto-check passed
  • Ready

    prekuter/dryforge

    Understand what you mean before anything is built. An agent skill from prekuter/dryforge.

    413 GitHub starsUsed in 1 repo~6.8k tokens
    Agent WorkflowsAuto-check passed
  • Spec Driven Develop

    zhu1090093659/deepseek-pp

    Automates pre-development workflow for large-scale complex tasks.

    1.9k GitHub stars~6.9k tokensUpdated 1 mo ago
    Agent WorkflowsAuto-check passed
  • MoAI Foundation Core

    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.

    1.2k GitHub stars~5k tokensUpdated today
    Agent WorkflowsAuto-check passed
  • Go

    prekuter/dryforge

    Carry out the intent approved in ready, as meant, and prove it with checks that actually ran.

    413 GitHub starsUsed in 1 repo~7.2k tokens
    Agent WorkflowsAuto-check passed
  • agtx Execute Phase

    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.

    1.7k GitHub stars~439 tokensUpdated 6 days ago
    Agent WorkflowsAuto-check passed

More from atopile/atopile

All 19 skills in this repo
  • Ato Language

    atopile/atopile

    Reference for the .ato declarative DSL: type system, connection semantics, constraint model, and standard library.

    4k GitHub stars~3.5k tokensUpdated 3 mo ago
    Auto-check passed
  • Compiler

    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.

    4k GitHub stars~1k tokensUpdated 3 mo ago
    Auto-check passed
  • Domain Layer

    atopile/atopile

    Instructions for electronics-specific logic and build processes: netlists, PCBs, build steps, and exporters.

    4k GitHub stars~791 tokensUpdated 3 mo ago
    Auto-check passed
  • Fabll

    atopile/atopile

    How FabLL (faebryk.core.node) maps Python node/trait declarations into the TypeGraph + instance graph, including field/trait invariants and instantiation patterns.

    4k GitHub stars~1.1k tokensUpdated 3 mo ago
    Auto-check passed
  • Faebryk

    atopile/atopile

    How Faebryk's TypeGraph works (GraphView + Zig edges), how to traverse/resolve references, and how FabLL types/traits map onto edge types.

    4k GitHub stars~861 tokensUpdated 3 mo ago
    Auto-check passed
  • Graph

    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.

    4k GitHub stars~952 tokensUpdated 3 mo ago
    Auto-check passed

Questions about Planning

What does Planning do?

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.

When should I use Planning?

Planning fits situations like: tasks that involve Spec-driven development.

How do I install Planning in Claude Code?

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.

How do I install Planning in Codex?

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.

Can I use Planning in Cursor, Gemini CLI or GitHub Copilot?

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.

What does Planning need to run?

SKILL.md names no scripts, command-line tools or credentials: Planning is instructions for the agent only.

Does Planning access the network?

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.

Is Planning safe to install?

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.

What licence does Planning use?

Planning is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Planning use?

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.

What are the alternatives to Planning?

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.

Who maintains Planning?

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.