Ship fast. Ship right. Ship everything. Ship accountably.

Godpowers is an AI-powered development system that takes a project from raw idea to hardened production. It runs as slash commands inside your AI coding tool (Claude Code, Codex, Cursor, etc.) that orchestrate specialist agents in fresh contexts to do the work.

Want the short proof first? Start with Quick Proof to run npx godpowers quick-proof --project=. --brief, see outcome metrics, pick a starter command set, and understand runtime expectations before reading the full reference. The First 10 Minute Proof Case Study shows the same evidence as a before-and-after adoption story. External CLI-verifiable canaries now cover sindresorhus/is, expressjs/cors, and tinyhttp/tinyhttp, with host slash-command gaps called out rather than hidden. Host-run proof studies now cover slugify-cli, Countdown, and react-github-readme-button, including one blocked harden run recorded as evidence instead of hidden as success.

Godpowers makes AI coding accountable: every serious run should leave disk state, artifacts, validation gates, host guarantees, and a next action. Code is only one output. The project memory and proof trail matter too.

Version 3.0.2 is a concierge surface patch on top of the 3.0.0 surface contraction release. The current 3.x line keeps the omitted installer profile on core, adds first-run, demo, and surface-control entry points, preserves --profile=full for compatibility, keeps locate and lifecycle views under /god-status, ships the optional @godpowers/mcp companion package, and verifies docs, package contents, npm metadata, GitHub release state, and published install behavior before public release.

Maintainer hardening continues on the 3.x line with small, audited public surface updates when they close real workflow gaps. Historical release details live in CHANGELOG.md, while the current release status lives in RELEASE.md.

Strict release readiness remains fail-closed. Godpowers requires delegated release checks to cover root docs, docs, agents, skills, routing, workflows, schema, templates, references, hooks, lib, scripts, tests, fixtures, GitHub workflows, package metadata, npm, GitHub release, CI, publish workflow, and local install state before a human-approved release executor can run.

The dashboard now starts with an action brief and a host guarantee line: the next command, why it is recommended, whether the project is ready, the first blockers that need attention, and whether the current host can provide full, degraded, or unknown runtime guarantees.

Run this before deciding whether Godpowers is worth a full project arc:

npx godpowers quick-proof --project=. --brief
npx godpowers status --project=. --brief
npx godpowers next --project=. --brief

The first command should produce disk-state evidence, missing-artifact visibility, a next command, host guarantees, and outcome metrics. The next two commands show what Godpowers can infer from your current project.

It fuses four disciplines into one unified workflow:

• Native project context - every Godpowers project is a Pillars project: root AGENTS.md plus task-routed agents/*.md files carry durable project truth before commands touch code.
• Artifact discipline - every sentence in every document is a labeled decision, hypothesis, or open question. Mechanically verified failure modes.
• Domain precision - fuzzy or overloaded project language is challenged, resolved, and stored in a domain glossary before it contaminates planning.
• Execution engine - fresh-context agents in parallel waves with atomic commits. No context rot. No sequential bottlenecks.
• Quality immune system - TDD enforcement, two-stage code review (spec compliance + code quality), request-trace discipline, surgical diffs, and verification before completion.
• Team intelligence - scale-adaptive complexity, specialized agent personas (PM, Architect, Executor, Reviewer, Harden Auditor, etc.).

Godpowers is designed to prove more than "the model wrote files." A useful run should prove:

• The current state is on disk, not trapped in chat memory.
• The next action is derived from repository state.
• Planning artifacts, code changes, reviews, and launch checks can be inspected.
• Host guarantees are explicit, including degraded or simulated agent behavior.
• Release confidence covers tests, package contents, install surfaces, and docs.
• Build plans cite real files and symbols before execution starts.
• New dependencies have registry and legitimacy evidence before they enter the stack.

npx godpowers --claude --global --profile=core

Other targets: --codex, --cursor, --windsurf, --opencode, --gemini, --copilot, --augment, --trae, --cline, --kilo, --antigravity, --qwen, --codebuddy, --pi. Or --all for everything (15 runtimes). T3 Code is transparently supported through the underlying agent.

The installer copies:

• Slash command skills to <runtime>/skills/
• Specialist agents to <runtime>/agents/
• Codex agent metadata to <runtime>/agents/*.toml
• SessionStart hook (Claude Code only) to <runtime>/hooks/

Installer profiles keep the visible command surface calm. The default omitted profile is core; choose builder or maintainer only when you already know you need those leaves:

npx godpowers --claude --global --profile=core
npx godpowers --codex --local --profile=builder
npx godpowers --all --profile=maintainer

After install, switch or preview the visible surface without starting over:

npx godpowers surface --profile=builder --codex --global --dry-run
npx godpowers surface --profile=builder --codex --global --apply

Profiles are core, builder, maintainer, suite, and full. core installs the front door, status, verb dispatchers, and /god-mode compatibility. full preserves the complete command surface, while the smaller profiles install the commands most relevant to the role. --minimal is an alias for --profile=core.

Use profiles as journeys:

Agent spawning is host-native. Claude uses its native agent/task interface, Codex uses installed agents/*.toml metadata backed by the same Markdown agent contracts, and the other runtimes use their supported agent or subagent mechanism against the installed agents/god-*.md files. If a host cannot provide a true fresh-context spawn, Godpowers must report that limitation instead of pretending a background agent ran.

See Host capabilities for the detailed guarantee model.

Open your AI coding tool in any project directory and type:

/god-mode

That starts the autonomous project run. It will run all tiers from idea to hardened production, pausing only when it has a real question for you.

If you don't know which command to run, type free text after /god:

/god production is broken
/god add a feature without breaking the current project run
/god I'm coming back after a week

The front door matches your intent against scenario recipes and proposes the right command sequence. Confirmation is always required before anything destructive runs. See skills/god.md.

Run individual commands. After each one finishes, Godpowers tells you what to run next based on disk state:

PRD complete: .godpowers/prd/PRD.md

Suggested next: /god-arch (design the architecture)

For UI or product-experience projects, PRD can route to design first:

Suggested next: /god-design (shape product experience)

You can also ask any time:

/god-next

This reads .godpowers/state.json, treats .godpowers/PROGRESS.md as a generated human view, scans disk, reconciles any drift, and suggests the next logical command with a compact action brief. The SessionStart hook does the same thing when you open a new session in a Godpowers project.

If the full command surface feels large, begin with one of these paths and only learn the next command when Godpowers recommends it.

/god-help presents a short state-aware view by default. /god-help all shows the complete catalog. Leaf commands remain direct shortcuts.

Godpowers reports adoption and run signals separately from narrative claims:

New public command surface should be added only when existing families, ladders, profiles, recipes, and docs cannot express a proven user need.

The same status engine is available from the installer CLI for humans, CI, Codex, Claude, Cursor, Gemini, OpenCode, Windsurf, Antigravity, and any host runtime that can execute Node:

npx godpowers status --project=.
npx godpowers next --project=.
npx godpowers demo --project=.
npx godpowers surface --profile=core --codex --global --dry-run
npx godpowers status --project=. --brief
npx godpowers status --project=. --full
npx godpowers status --project=. --json
npx godpowers quick-proof --project=.
npx godpowers state advance --step=prd --status=done --project=.
npx godpowers gate --tier=prd --project=.
npx godpowers mcp-info --project=.
npx godpowers dogfood
npx godpowers extension-scaffold --name=@godpowers/my-pack --output=.

Godpowers keeps the public release gate behind one command:

npm run release:check

That command runs the maintained full-suite runner, audit checks, and package contents verification. npm test delegates to scripts/run-tests.js, so the test order is maintained as a readable list instead of a long package script. npm run lint runs dependency-free static checks through scripts/static-check.js, including shared test harness adoption, installer decomposition, async runtime APIs, agent reference validation coverage, and God Mode runbook delegation.

Tier skills now run the executable gate before downstream work proceeds:

npx godpowers gate --tier=prd --project=.
npx godpowers gate --tier=build --project=.
npx godpowers gate --tier=harden --project=.

The gate reads disk artifacts, runs the shared artifact linter, checks structured state.json evidence for design and build gates, and blocks unresolved Critical harden findings.

The main godpowers runtime remains dependency-free. The optional @godpowers/mcp companion package owns the MCP SDK dependency and exposes read-only tools through explicit host setup. YAML parsing is intentionally limited to the documented Godpowers subset used by intent, routing, workflow, and extension files, with parser coverage in scripts/test-yaml-parser.js.

MCP-capable hosts can use the optional companion package without adding an SDK dependency to the main godpowers package:

npx godpowers mcp-info --project=.
npx -y -p godpowers@3.0.2 -p @godpowers/mcp@3.0.2 godpowers-mcp serve --project=.

The companion exposes status, next, gate_check, lint_artifact, and trace_requirement. Host registration is opt-in:

npx -y -p godpowers@3.0.2 -p @godpowers/mcp@3.0.2 godpowers-mcp setup --host=codex --project=. --write

See MCP Companion for package boundaries and setup details.

For real-world scenarios beyond greenfield:

/god-mode                # Standard: pauses for real questions only
/god-mode --yolo         # Zero pauses except Critical security. Repairs red checks before it stops.
/god-mode --conservative # More checkpoints
/god-mode --from=arch    # Resume from a specific tier
/god-mode --audit        # Score existing artifacts. Build nothing.
/god-mode --dry-run      # Plan everything. Build nothing.

/god-mode is not complete when it merely writes planning artifacts. It keeps going through build, verification, repair, launch, and final sync. Red tests, typecheck, lint, build, or check output enter the repair loop instead of being reported as the final result.

Build execution also keeps diffs narrow. Executors state assumptions, expected files, changed public behavior, and verification before editing. Reviewers block speculative flexibility, unrelated cleanup, and any touched file that does not trace back to the request or slice plan.

If .godpowers state already exists, /god-mode --yolo resumes from disk instead of asking for the project description again.

Under --yolo, Godpowers also auto-applies Pillars sync proposals when durable .godpowers artifacts change project truth. The decision is logged to .godpowers/YOLO-DECISIONS.md.

Every completing command now ends with a Godpowers Dashboard. It shows the current phase, tier, step count, workflow progress, PRD and roadmap visibility, recent work, proactive checks, open items, and the single recommended next action. /god-status and /god-next use the same shape so the project never ends in a vague "done" state. The dashboard is backed by lib/dashboard.js, and the rendered output names that source when the runtime engine is available. Audit, hygiene, and remediation scores are reported as separate scores rather than being reused as workflow progress.

That dashboard reports workflow progress (which pipeline stage you are on). For deliverable progress (how much of the actual product is built), run /god-progress: it lists every PRD requirement as done, in progress, or not started, groups them by roadmap increment, and writes a .godpowers/REQUIREMENTS.md checklist you can open or share. Status is derived from the linkage map (code that implements each requirement), so it can never drift from what is actually on disk. The dashboard also surfaces a Deliverable progress line, and during a /god-mode build each step reports how many requirements moved to done.

Godpowers can also inspect automation support:

npx godpowers automation-status --project=.
npx godpowers automation-setup --project=.

Godpowers can dogfood itself against shipped messy-repo fixtures:

npx godpowers dogfood

The dogfood suite covers a half-migrated legacy planning project, full and degraded host guarantee detection, extension scaffold validation, and a Mode D suite release dry-run. /god-dogfood reports failures with scoped specialist ownership rather than treating fixture checks as silent background work.

Automation setup is opt-in. The installer does not create schedules, routines, background agents, API triggers, or CI workflows. Safe starting templates are read-only status, checkpoint, review queue, hygiene, and release readiness reports.

Godpowers can migrate from adjacent planning systems:

/god-migrate

This detects legacy planning .planning/ or .legacy-planning/, BMAD _bmad-output/ or .bmad/, and Superpowers specs or plans. It writes .godpowers/prep/IMPORTED-CONTEXT.md, optional imported seed artifacts, and managed sync-back files such as .planning/GODPOWERS-SYNC.md, _bmad-output/GODPOWERS-SYNC.md, or docs/superpowers/GODPOWERS-SYNC.md.

Existing Godpowers projects can refresh their awareness after an upgrade:

/god-context refresh

This records the current Godpowers feature set in .godpowers/state.json, refreshes managed AI-tool context fences, and suggests /god-migrate or god-greenfieldifier when source-system evidence needs migration judgment.

For existing codebases and org-constrained new projects, God Mode now runs a greenfield simulation audit and then actions it through a greenfieldification plan. It pauses before risky artifact rewrites because that process can change product scope, design direction, architecture, roadmap, stack, and shipping commitments.

Each slash command is a thin orchestrator. It does NOT do the work itself. It spawns the right specialist agent in a fresh context to do the work.

You type:        /god-prd
Skill loads:     skills/god-prd.md
Skill spawns:    god-pm agent (fresh 200K context)
Agent reads:     .godpowers/state.json + .godpowers/intent.yaml
Agent writes:    .godpowers/prd/PRD.md
Skill verifies:  artifact exists, have-nots pass
Skill updates:   state.json via godpowers state advance

.godpowers/state.json          Machine-readable project state
.godpowers/PROGRESS.md         Generated cross-tier progress view
.godpowers/REQUIREMENTS.md     Requirement checklist (done / in progress / not started)
.godpowers/prd/PRD.md          Product Requirements Document
.godpowers/domain/GLOSSARY.md  Domain vocabulary and resolved ambiguities
.godpowers/arch/ARCH.md        System Architecture
.godpowers/arch/adr/           Architecture Decision Records
.godpowers/roadmap/ROADMAP.md  Sequenced Roadmap
.godpowers/stack/DECISION.md   Stack Decision (with flip points)
.godpowers/repo/AUDIT.md       Repo Scaffold Audit
.godpowers/build/PLAN.md       Build Plan (slices, waves)
.godpowers/build/STATE.md      Generated build state view
.godpowers/deploy/STATE.md     Generated deploy state view
.godpowers/observe/STATE.md    Generated observability state view
.godpowers/launch/STATE.md     Generated launch state view
.godpowers/harden/FINDINGS.md  Security Findings

Godpowers projects also include native Pillars context:

AGENTS.md              Pillars loading protocol plus Godpowers managed fence
agents/context.md      Always-loaded project identity and invariants
agents/repo.md         Always-loaded repository layout and naming
agents/*.md            Task-routed domain pillars

Existing .godpowers projects are Pillar-ized on resume or sync. Current PRD, ARCH, STACK, ROADMAP, BUILD, DEPLOY, OBSERVE, HARDEN, DESIGN, and PRODUCT artifacts become managed source references in the relevant pillar files, with labeled decisions, hypotheses, and open questions extracted when available.

Every artifact passes these mechanical checks before it is treated as complete:

These checks are guardrails, not proof that the product is right. A PRD can pass the substitution test and still make the wrong product call. Godpowers uses mechanical checks to catch generic, missing, or untraceable work so the remaining judgment is visible to humans and reviewers.

Godpowers is pre-launch. See USERS.md for current adoption status.

Full autonomous runs can be expensive because they spawn multiple fresh-context agents. The runtime records token and dollar estimates through cost.recorded events, and /god-cost reports spend, savings, live vs estimated token counts, and cache hits. /god-budget configures context caps, cache use, and model profiles. /god-metrics and /god-trace expose run duration, pauses, retries, and per-tier history from .godpowers/runs/<id>/events.jsonl.

Treat a real /god-mode result as successful only when it produces shipped or ship-ready work on someone else's codebase, with validation results, cost, and wall-clock time visible.

God Mode pauses only when:

1. User intent is genuinely ambiguous (two valid directions)
2. A flip-point depends on human-only constraints (team size, budget)
3. Two options score within 10% with no objective tiebreaker
4. A Critical security finding needs human judgment
5. Brand/copy decisions require the human's voice

Every pause includes: what the question is, why only the human can answer, options with tradeoffs, and a default if the user just says "go".

15 first-class runtimes: Claude Code, Codex, Cursor, Windsurf, Gemini CLI, OpenCode, Copilot, Augment, Trae, Cline, Kilo, Antigravity, Qwen, CodeBuddy, Pi. T3 Code inherits from the underlying agent (Codex / Claude / OpenCode).

• Getting Started
• Quick Proof
• First 10 Minute Proof Case Study
• Concepts
• Command reference (all 120 skills + 40 agents)
• Feature awareness
• Adoption Canary
• Repository documentation sync
• Repository surface sync
• Roadmap
• Release Notes
• Changelog
• Inspiration

MIT