Astrolabe
OpenSpec + Superpowers + CodeGraph
中文版：README-zh.md B站视频介绍
OpenSpec + Superpowers + CodeGraph development workflow — one command from idea to archive.
OpenSpec handles WHAT (outlines, proposals, spec lifecycle, archiving).
Superpowers handles HOW (technical design, planning, execution, wrap-up).
Astrolabe chains both into a five-phase automated pipeline.
CodeGraph provides a local code knowledge graph and MCP tools, so agents can query the code index before requirements analysis, design, and implementation instead of repeatedly exploring the same files with grep/read loops.
OpenSpec excels at managing requirements, creating proposals, managing Spec lifecycles, and archiving, but its proposals and tasks lack the detail of Superpowers brainstorming.
Superpowers generates Spec documents after brainstorming, but these documents typically lack stateful design — after completing requirements, Specs only have tasks checked off in the document, and Agents even forget to check them off. This causes the Agent to re-examine documents and project code to verify on resumption, wasting many tokens.
Astrolabe combines the strengths of both, integrating the core workflow into 5 phases
The main entry /ast supports current Spec state detection, suitable for long tasks — after completing and closing CC midway, just /ast continue and Astrolabe will automatically read the active Spec (lists multiple for selection), dynamically identify which phase is currently executing, and continue.
At the same time, Astrolabe provides full Spec lifecycle management. During execution, it links OpenSpec change/spec artifacts with Superpowers design and planning documents, then automates handoff, state updates, validation, and archive sync so users do not have to repeatedly remind the Agent to keep documents synchronized and connected.
Many excellent Skill projects exist in the current Skill market, but they generally have preference issues — users may only like some features. For example, when using both OpenSpec and Superpowers, one might only use OpenSpec's Spec management capabilities, but prefer Superpowers' TDD-driven approach for coding.
Long-term Skill users know these capabilities can be freely combined, but exactly how to do so still requires real practice. The Astrolabe project can serve as a reference:
-
How to reliably trigger nested Skills — Not letting the Agent rely on document descriptions to perform "look-alike Skill trigger" operations (like writing files based on Skill descriptions), but truly triggering Skills (key feature: Skill trigger prints on CC). Astrolabe triggers many capabilities from OpenSpec and Superpowers. How is this Prompt written?
-
How to make combined Skills flow automatically across phases — Not relying on manual intervention. Astrolabe's 5-phase flow can automatically trigger Skills for the core process except for necessary user choices, while the state machine also protects state transition reliability.
-
How to turn the Spec lifecycle into a resumable workflow — Astrolabe links OpenSpec change/spec artifacts with Superpowers design and planning documents, then records phase, execution mode, verification results, and archive status in
.astrolabe.yaml, so the Agent can resume after interruption instead of rereading documents and guessing progress. -
How to turn document synchronization from "user reminders" into automation — Astrolabe puts handoff, state updates, validation, and archive sync into scripted flows, reducing repeated prompts like "remember to update the design doc", "remember to sync the spec", and "remember to archive the change".
-
How to design guard conditions that Agents can execute — Astrolabe does not simply trust the Agent saying "done" at phase exits. Scripts such as
ast-guard.sh,ast-yaml-validate.sh, andast-state.shcheck tasks, state fields, verification evidence, and archive conditions before allowing the workflow to advance. -
How to distribute and install Skills across platforms — Astrolabe supports multiple AI coding platforms, project/global installation, Chinese/English Skill choices, and platform-specific directory differences such as Antigravity using different project-level and global paths. It can be a reference for CLI installers and Skill package structure.
-
How to turn shell scripts into Agent workflow infrastructure — Astrolabe's scripts need to work across macOS, Linux, and Windows Git Bash while handling hashes, YAML fields, state machines, and archive flows. It shows how to move fragile workflow control out of scattered Prompt text and into testable, reusable tools.
npm install -g @wping/astrolabecd your-project
ast initast init will:
- Prompt you to select AI platforms (auto-detects existing configs)
- Choose install scope: project-level (current directory) or global (home directory)
- Select language for Astrolabe skills: English or 中文
- Install OpenSpec skills
- Install Superpowers skills
- Configure CodeGraph MCP and initialize a
.codegraph/index for project-scope installs - Deploy Astrolabe skills (in your chosen language) to selected platforms
- Create
docs/superpowers/specs/anddocs/superpowers/plans/working directories for project-scope installs
Tip
update version
ast update or npm install -g @wping/astrolabe@latest to get the latest features and fixes.
npx skills add ddddddddwp/astrolabe
Auto-install OpenSpec & Superpowers, one-click dev environment setup
Multi-phase Skill entry, auto-detects current Spec stage, auto-triggers core flow, manual review at key nodes
ast init [path] — Initialize Astrolabe workflow
Initializes OpenSpec, Superpowers, CodeGraph, and Astrolabe skills for selected AI coding platforms.
| Option | Description |
|---|---|
--yes |
Non-interactive mode, auto-select detected platforms (or all if none detected) |
--scope <scope> |
Install scope: project or global |
--skip-existing |
Skip already installed components |
--overwrite |
Overwrite already installed components |
--skip-codegraph |
Skip CodeGraph MCP and project index setup |
--json |
Output structured JSON |
When multiple existing components are found on the same platform, interactive init offers one bulk choice: overwrite all, skip all, or choose per component.
ast status [path] — Show active changes and next workflow command
Displays active changes, task progress, and the recommended next Astrolabe workflow command.
| Option | Description |
|---|---|
--json |
Output active changes with nextCommand |
ast doctor [path] — Diagnose Astrolabe installation health
Checks project/global installation health, working directories, installed skills, scripts, and Astrolabe state files.
| Option | Description |
|---|---|
--json |
Output structured diagnostic results |
--scope <scope> |
Diagnose auto, project, or global scope (default: auto) |
ast update [path] — Update Astrolabe package and skills
Updates the npm package and refreshes installed Astrolabe skills in detected project/global targets.
| Option | Description |
|---|---|
--json |
Output npm and skill update results as JSON |
--language <lang> |
Override detected skill language (en, zh) |
--scope <scope> |
Update only global or project scope |
| Command | Description |
|---|---|
ast --help |
Show help |
ast --version |
Show version |
ast init supports 28 AI coding platforms:
View full platform list
| Platform | Skills Dir | Platform | Skills Dir |
|---|---|---|---|
| Claude Code | .claude/ |
Cursor | .cursor/ |
| Codex | .codex/ |
OpenCode | .opencode/ |
| Windsurf | .windsurf/ |
Cline | .cline/ |
| RooCode | .roo/ |
Continue | .continue/ |
| GitHub Copilot | .github/ |
Gemini CLI | .gemini/ |
| Amazon Q Developer | .amazonq/ |
Qwen Code | .qwen/ |
| Kilo Code | .kilocode/ |
Auggie | .augment/ |
| Kiro | .kiro/ |
Lingma | .lingma/ |
| Junie | .junie/ |
CodeBuddy | .codebuddy/ |
| CoStrict | .cospec/ |
Crush | .crush/ |
| Factory Droid | .factory/ |
iFlow | .iflow/ |
| Pi | .pi/ |
Qoder | .qoder/ |
| Antigravity | .agents/ |
Bob Shell | .bob/ |
| ForgeCode | .forge/ |
Trae | .trae/ |
After ast init, three groups of skills are installed to the selected platform's skills/ directory; CodeGraph is configured as an MCP/indexing tool in each supported platform's standard config files, and project-scope installs create a .codegraph/ code index.
View Astrolabe skills
| Skill | Description |
|---|---|
/ast |
Main entry — auto-detects phase and dispatches to sub-commands |
/ast-open |
Phase 1: Open a change (proposal, design, task breakdown) |
/ast-design |
Phase 2: Deep design (brainstorming, Design Doc) |
/ast-build |
Phase 3: Plan and build (implementation plan, code commits) |
/ast-verify |
Phase 4: Verify and finish (testing, verification report) |
/ast-archive |
Phase 5: Archive (delta spec sync, status annotation) |
/ast-hotfix |
Preset: Quick bug fix (skips brainstorming) |
/ast-tweak |
Preset: Small change (skips brainstorming and full plan) |
View script list
| Script | Purpose |
|---|---|
ast-guard.sh |
Phase transition guard — validates exit conditions, --apply auto-updates .astrolabe.yaml |
ast-handoff.sh |
Design handoff — generates deterministic context packages from OpenSpec artifacts with SHA256 tracing |
ast-archive.sh |
One-command archive — validates state, syncs specs, moves to archive, updates status |
ast-yaml-validate.sh |
Schema validator — validates .astrolabe.yaml structure and field values |
ast-state.sh |
Unified state management — init/set/get/check/scale, agents' exclusive YAML interface |
Spec lifecycle management: propose, explore, sync, verify, archive, and more.
Development methodology: brainstorming, TDD, subagent-driven development, code review, plan writing, and more.
Local code knowledge graph: codegraph_context, codegraph_search, codegraph_impact, codegraph_explore, codegraph affected, and more. Astrolabe uses CodeGraph during requirement exploration, technical design, planning, implementation, and verification to retrieve existing code structure, call flows, impact scope, and affected test candidates.
/ast
↓ auto-detect
/ast-open --> /ast-design --> /ast-build --> /ast-verify --> /ast-archive
(OpenSpec) (Superpowers) (Superpowers) (Both) (OpenSpec)
↑ ↑ ↑ ↑
└──────────── CodeGraph: code context, call flows, impact, affected tests ────────────┘
/ast-hotfix (preset path, skips brainstorming)
open --> build --> verify --> archive
(CodeGraph assists root-cause localization, impact scope, and related tests)
/ast-tweak (preset path, skips brainstorming and full plan)
open --> lightweight build --> light verify --> archive
(CodeGraph assists target discovery, references, and related tests)
| Phase | Command | Owner | CodeGraph Usage | Artifacts |
|---|---|---|---|---|
| 1. Open | /ast-open |
OpenSpec | When the request touches existing code, gather modules, entry files, key symbols, and risks before OpenSpec exploration | proposal.md, design.md, tasks.md |
| 2. Deep Design | /ast-design |
Superpowers | Pass architecture entry points, call flows, existing patterns, and impact scope into brainstorming | Design Doc, delta spec |
| 3. Plan & Build | /ast-build |
Superpowers | Query implementation context and impact before planning; query target symbols, callers, and files before each task | Implementation plan, code commits |
| 4. Verify & Finish | /ast-verify |
Both | Use impact analysis and codegraph affected to guide related tests and verification scope |
Verification report, branch handling |
| 5. Archive | /ast-archive |
OpenSpec | Not an archive source of truth; used only for implementation impact lookup when needed | delta→main spec sync, archive |
- Brainstorming is non-skippable — every change must go through deep design (except hotfix/tweak)
- Code index first — when existing code is involved, query CodeGraph first and pass the index summary to OpenSpec / Superpowers; if CodeGraph is unavailable, degrade without blocking
- Delta specs are living documents — freely editable during Phase 3, synced at archive
- Keep tasks.md in sync — check off each task as completed
- Commit frequently — one commit per task, message reflects design intent
- Verify before archive —
/ast-verifymust pass before/ast-archive
Astrolabe uses a decoupled state architecture with separate YAML files:
| File / Directory | Owner | Purpose |
|---|---|---|
.openspec.yaml |
OpenSpec | Spec lifecycle, change metadata |
.astrolabe.yaml |
Astrolabe | Workflow phase, execution mode, verification status |
.codegraph/ |
CodeGraph | Local code knowledge graph index, structural queries, impact analysis, and affected-test analysis |
All OpenSpec / Astrolabe states and execution phases are updated via scripts, and each phase verifies that tasks are truly complete before advancing. CodeGraph is not part of the state machine and does not write .astrolabe.yaml; it maintains the code index and provides code context through MCP/CLI at each phase. Compared to storing complex state rules only in Skill text, this script-backed state machine gives Astrolabe more reliable phase transitions, correct YAML, and easier breakpoint recovery; agents can read the current Spec situation through Astrolabe's built-in commands, then query CodeGraph when they need to understand existing implementation.
View key .astrolabe.yaml fields
Key Fields in .astrolabe.yaml:
workflow: full
phase: build
build_mode: subagent-driven-development
isolation: branch
verify_mode: null
design_doc: docs/superpowers/specs/YYYY-MM-DD-topic-design.md
plan: docs/superpowers/plans/YYYY-MM-DD-feature.md
verify_result: pending
verification_report: null
branch_status: pending
verified_at: null
archived: false
direct_override: false
build_command: null
verify_command: null
handoff_context: openspec/changes/<name>/.astrolabe/handoff/design-context.json
handoff_hash: <sha256>In full workflow, build_mode, isolation, and verify_mode may temporarily be null; build_mode and isolation must be resolved before build → verify. verification_report stays null until verification writes a report, and verify-pass requires that report to exist plus branch_status: handled. Fields after archived in the example are optional or script-derived: direct_override is only needed for full-workflow direct builds, project commands may be absent unless configured, and handoff_context / handoff_hash are recorded by ast-handoff.sh before leaving design. Projects can configure build_command / verify_command in the change or repo root, and guard will run those commands first and print failure output.
Astrolabe ensures agent execution reliability through automated state transitions:
View reliability features
-
Entry Verification — Each phase validates preconditions before execution
- Checks file existence, state consistency, and phase transitions
- Outputs
[HARD STOP]with actionable suggestions if validation fails
-
Automated State Transitions —
ast-guard.sh --applyupdates.astrolabe.yamlautomatically- All phase transitions (open → design/build → verify → archive) use
guard --apply - No manual state editing required — eliminates write-verification errors
ast-state.shis the agents' exclusive interface for state operations- Guard and archive scripts use
ast-state.shinternally for state management
- All phase transitions (open → design/build → verify → archive) use
-
Schema Validation —
ast-yaml-validate.shensures data integrity- Validates required and optional fields
- Validates enum values, including
direct_override - Validates
design_doc,plan, andhandoff_contextpaths exist, plushandoff_hashformat - Detects unknown/typos fields
-
Build Decision Enforcement — Guard and state transitions both block skipped build choices
isolationmust bebranchorworktreebuild_modemust be selected before leaving build- Full workflow
build_mode: directrequiresdirect_override: true
-
Verification Evidence — Guard enforces proof before phase advance
verify-passtransition requiresverification_reportpointing to an existing report filebranch_statusmust behandledbefore verify can pass- Guard checks
verification_report existsandbranch_status=handledas hard prerequisites - Prevents false phase advances when verification or branch handling was skipped
-
Archive Automation —
ast-archive.shhandles the full archive flow in one command- Validates entry state, syncs delta specs to main specs
- Annotates design doc and plan frontmatter
- Moves change to archive directory and updates
archived: true - Supports
--dry-runfor preview
your-project/
├── .claude/skills/ # Platform skills dir (Astrolabe + OpenSpec + Superpowers)
│ ├── ast/SKILL.md
│ │ └── scripts/
│ │ ├── ast-guard.sh # Phase transition guard (--apply auto-updates state)
│ │ ├── ast-handoff.sh # Design handoff (OpenSpec → Superpowers context tracing)
│ │ ├── ast-archive.sh # One-command archive automation
│ │ ├── ast-yaml-validate.sh # Schema validator
│ │ └── ast-state.sh # Unified state management (init/set/get/check/scale)
│ ├── astrolabe-*/SKILL.md
│ ├── openspec-*/SKILL.md
│ └── brainstorming/SKILL.md
├── openspec/ # OpenSpec — WHAT
│ ├── config.yaml
│ └── changes/
│ └── <name>/
│ ├── .openspec.yaml # OpenSpec state
│ ├── .astrolabe.yaml # Astrolabe workflow state (decoupled)
│ ├── proposal.md
│ ├── design.md
│ ├── specs/<capability>/spec.md
│ └── tasks.md
└── docs/superpowers/ # Superpowers — HOW
├── specs/ # Design documents
└── plans/ # Implementation plans
See CONTRIBUTING.md for development setup, commit conventions, PR process, and guidance for adding platforms or skills.
See CHANGELOG.md for version history and updates.
Track our development progress and upcoming features on the Astrolabe issues.