godpowers 2.6.0 → 3.0.0

package/skills/god-fix.md

@@ -0,0 +1,43 @@
+---
+name: god-fix
+description: |
+  Fix verb dispatcher. Routes bug, regression, and production outage intent
+  to the existing debug or hotfix leaf commands.
+
+  Triggers on: "god fix", "/god-fix", "fix this bug", "debug this",
+  "production is broken", "hotfix"
+---
+
+# /god-fix
+
+Route fix intent to the smallest existing repair command.
+
+## Runtime module resolution
+
+Resolve the Godpowers runtime root before inspecting routes:
+
+1. If `<projectRoot>/routing/god-debug.yaml` exists, use the repository checkout runtime at `<projectRoot>`.
+2. Otherwise use the installed bundle at `<tool-config-dir>/godpowers-runtime`.
+3. Read routing metadata from `<runtimeRoot>/routing/`.
+
+## Dispatch
+
+| Signal | Hand off to |
+|---|---|
+| `hotfix`, `production`, `outage`, `urgent`, `down` | `/god-hotfix` |
+| `debug`, `bug`, `failing`, `error`, `regression` | `/god-debug` |
+
+Default to `/god-debug` when urgency is unclear.
+
+## Process
+
+1. Select the target leaf command from the table.
+2. Read the selected leaf route YAML so prerequisites and next-step metadata stay source-controlled.
+3. Show the selected command, the matched signal, and whether production urgency was detected.
+4. Hand off to the selected leaf command after user confirmation.
+
+## Guardrails
+
+- Do not edit code directly from this dispatcher.
+- Do not skip regression-test expectations from `/god-debug` or `/god-hotfix`.
+- Keep both leaf commands callable as direct shortcuts.

package/skills/god-harden.md

@@ -13,7 +13,7 @@ Spawn the **god-harden-auditor** agent in a fresh context via the host platform'
 
 ## Setup
 
-1. Verify build is complete (`.godpowers/build/STATE.md` exists).
+1. Verify build is complete through `.godpowers/state.json` `tier-2.build.status == done`.
 2. Spawn god-harden-auditor with full code access.
 3. The agent writes `.godpowers/harden/FINDINGS.md`.
 
@@ -23,8 +23,8 @@ After god-harden-auditor returns:
 1. Verify FINDINGS.md exists on disk
 2. Run `npx godpowers gate --tier=harden --project=.` and do not proceed on a non-zero exit
 3. Read findings classification:
-   - If any Critical: PROGRESS.md status = failed, launch is BLOCKED
-   - If only High/Medium/Low: PROGRESS.md status = done
+   - If any Critical: run `npx godpowers state advance --step=harden --status=failed --project=.` and keep launch BLOCKED
+   - If only High/Medium/Low: run `npx godpowers state advance --step=harden --status=done --project=.`
 
 ## Have-Nots
 

package/skills/god-hotfix.md

@@ -72,7 +72,7 @@ Spawn **god-observability-engineer** briefly:
 - Confirm recovery in metrics
 
 ### Phase 7: Schedule Postmortem
-Update PROGRESS.md with a TODO:
+Record a state-backed follow-up TODO through the owning command wrapper:
 "Run /god-postmortem within 48 hours for incident <id>"
 
 Hotfix doesn't replace postmortem; it precedes it.

package/skills/god-init.md

@@ -3,7 +3,8 @@ name: god-init
 description: |
   Initialize a Godpowers project. Detects operating mode (greenfield, gap-fill,
   audit, multi-repo) and project scale. Creates native Pillars project context
-  plus the .godpowers/ workflow state directory with PROGRESS.md.
+  plus the .godpowers/ workflow state directory with state.json and generated
+  PROGRESS.md.
 
   Triggers on: "god init", "start a project", "new project", "initialize"
 ---
@@ -18,9 +19,11 @@ This skill is a thin wrapper. Detection happens automatically; user never
 needs to specify a mode.
 
 1. Check if `.godpowers/` already exists:
-   - If yes: read PROGRESS.md, call `lib/pillars.pillarizeExisting(projectRoot)`
-     to ensure the existing Godpowers project is also Pillar-ized, report
-     current state, ask if user wants to reset or resume
+   - If yes: read `.godpowers/state.json`, use generated `.godpowers/PROGRESS.md`
+     only as a legacy fallback, call
+     `lib/pillars.pillarizeExisting(projectRoot)` to ensure the existing
+     Godpowers project is also Pillar-ized, report current state, ask if user
+     wants to reset or resume
    - If no: proceed with initialization
 
 2. **Auto-detect what kind of project this is** (background, no user prompt):
@@ -124,7 +127,8 @@ needs to specify a mode.
    - For brownfield: schedule preflight before archaeology + reconstruction
    - For bluefield: load org-context, then schedule preflight as constraint intake
    - Create directory structure
-   - Write PROGRESS.md with mode, scale, timestamp, tier states
+   - Write `.godpowers/state.json` with mode, scale, timestamp, tier states,
+     then regenerate the managed `.godpowers/PROGRESS.md` view
    - Return mode/scale/announcement to this skill
 
 8. Detect scale by analyzing the description:
@@ -150,7 +154,7 @@ needs to specify a mode.
      deploy.md
      observe.md
    .godpowers/
-     PROGRESS.md
+     PROGRESS.md              # generated managed view
      prep/
        INITIAL-FINDINGS.md
        IMPORTED-CONTEXT.md   # only when legacy planning / Superpowers / BMAD context exists
@@ -167,7 +171,7 @@ needs to specify a mode.
      harden/
    ```
 
-10. Write PROGRESS.md with mode, scale, timestamp, all tiers set to `pending`
+10. Write `state.json` with mode, scale, timestamp, and all tiers set to `pending`, then regenerate `.godpowers/PROGRESS.md`
 
 11. Report to the user:
    - Detected mode and scale
@@ -186,7 +190,7 @@ needs to specify a mode.
 
 ## Output
 
-`.godpowers/PROGRESS.md` created with initial state.
+`.godpowers/state.json` created with initial state and `.godpowers/PROGRESS.md` generated as a managed human view.
 
 Always create `.godpowers/prep/INITIAL-FINDINGS.md`. This is Godpowers'
 durable answer to "what did init find in this codebase?" It captures codebase
@@ -201,7 +205,7 @@ as hypothesis-level input only.
 
 ## Native Pillars context and AI-tool context
 
-After PROGRESS.md is written, Pillars context is already present. Every
+After `state.json` is written and the progress view is generated, Pillars context is already present. Every
 Godpowers project uses `AGENTS.md` plus `agents/*.md` as its native project
 truth layer.
 
@@ -243,7 +247,7 @@ If the user later wants to enable it manually, they run `/god-context on`.
 
 ## Mode D detection (multi-repo workspace)
 
-After PROGRESS.md is written, also check whether this directory is
+After `state.json` is written, also check whether this directory is
 part of a multi-repo suite:
 
 1. Call `lib/multi-repo-detector.detect(projectRoot)`.

package/skills/god-launch.md

@@ -17,21 +17,23 @@ Spawn the **god-launch-strategist** agent in a fresh context via the host platfo
 2. If Critical findings exist: REFUSE to proceed. Tell user to resolve or
    explicitly accept the risk first.
 3. Spawn god-launch-strategist with PRD path and harden FINDINGS.md path.
-4. The agent writes `.godpowers/launch/STATE.md` plus landing copy artifacts.
+4. The agent returns structured launch evidence for `.godpowers/state.json` plus landing copy artifacts; the generated `.godpowers/launch/STATE.md` view refreshes after state mutation.
 
 ## Verification
 
 After god-launch-strategist returns:
-1. Verify STATE.md exists on disk
+1. Verify launch evidence is recorded in `.godpowers/state.json`
 2. Verify landing copy passes substitution test
 3. Verify OG cards rendered (not just meta tags)
 4. Verify one of:
    - launch target is live and smoke checked
    - local launch-readiness harness passed and external access bundle is the
      only missing item
-5. Update `.godpowers/PROGRESS.md`: Launch status = done only when live launch
-   or explicit local launch-readiness scope is complete. If external access is
-   missing, mark Launch = waiting-for-external-access.
+5. Run `npx godpowers state advance --step=launch --status=done --project=.`
+   only when live launch or explicit local launch-readiness scope is complete.
+   If external access is missing, record the waiting artifact path in launch
+   state through the owning command wrapper rather than editing the generated
+   progress or launch state views.
 
 ## Pause Conditions
 
@@ -41,7 +43,7 @@ approval require human input.
 ## On Completion
 
 ```
-Launch complete: .godpowers/launch/STATE.md
+Launch complete: .godpowers/launch/STATE.md (generated view)
 
 All Godpowers tiers done. Project is live.
 
@@ -71,15 +73,15 @@ approval.
 
 ## Re-invocation contract
 
-What happens if `/god-launch` is run when `.godpowers/launch/STATE.md` already exists:
+What happens if `/god-launch` is run when launch state evidence already exists:
 
 | Existing state | Behavior |
 |---|---|
-| File does not exist | Spawn god-launch-strategist; produce file; mark sub-step done |
-| File exists, passes lint, state.json says `done` | Pause: ask user (A) re-run anyway with diff preview, (B) treat as imported (no-op), (C) cancel |
-| File exists, fails lint or have-nots | Spawn god-launch-strategist in update mode with current file + findings as input. Diff preview before overwrite. |
-| File exists, state.json says `pending` | Treat as imported: hash + register, no agent spawn. User can `/god-launch --force` to re-run. |
-| `--force` flag passed | Snapshot existing file to `.godpowers/.trash/god-launch-<ts>/`. Spawn agent fresh. |
+| State evidence does not exist | Spawn god-launch-strategist; record launch evidence; mark sub-step done |
+| State evidence exists and state.json says `done` | Pause: ask user (A) re-run anyway with diff preview, (B) treat as imported (no-op), (C) cancel |
+| State evidence fails checks or the owning wrapper reports a generated view checksum warning | Spawn god-launch-strategist in update mode with current evidence plus findings as input. Diff preview before overwrite. |
+| State evidence exists, state.json says `pending` | Treat as imported: hash + register, no agent spawn. User can `/god-launch --force` to re-run. |
+| `--force` flag passed | Snapshot existing evidence to `.godpowers/.trash/god-launch-<ts>/`. Spawn agent fresh. |
 | `--dry-run` flag passed | Show what would happen; touch nothing |
 
 Snapshots in `.trash/` are recoverable via `/god-restore` for 30 days.

package/skills/god-lifecycle.md

@@ -1,5 +1,7 @@
 ---
 name: god-lifecycle
+deprecated: true
+successor: god-status --lifecycle
 description: |
   Show where the project is in its lifecycle and what workflows make sense
   next. Distinguishes: pre-init, planning, building, shipping, steady state,
@@ -11,13 +13,18 @@ description: |
 
 # /god-lifecycle
 
+Deprecated: prefer `/god-status --lifecycle` for new workflows. This command
+remains callable in the full profile for one minor release as a compatibility
+alias.
+
 Show project phase and contextually appropriate workflows.
 
 ## Process
 
 1. Detect lifecycle phase from disk:
    - **No `.godpowers/`** -> Pre-init
-   - **`.godpowers/PROGRESS.md` exists, not all tiers done** -> In progress
+   - **`.godpowers/state.json` exists, not all tracked steps done** -> In progress
+   - **Only generated legacy `.godpowers/PROGRESS.md` exists** -> In progress after re-deriving state from disk
    - **All tiers done, no special markers** -> Steady state
    - **`.godpowers/postmortems/<id>/` exists with no POSTMORTEM.md** -> Post-incident pending
    - **`.godpowers/migrations/<slug>/MIGRATION.md` exists, status != complete** -> In-migration

package/skills/god-locate.md

@@ -1,5 +1,7 @@
 ---
 name: god-locate
+deprecated: true
+successor: god-status --locate
 description: |
   Orient a new chat session or new AI tool. Reads CHECKPOINT.md +
   state.json + events.jsonl tail + intent.yaml + reflog tail and
@@ -12,6 +14,10 @@ description: |
 
 # /god-locate
 
+Deprecated: prefer `/god-status --locate` for new workflows. This command
+remains callable in the full profile for one minor release as a compatibility
+alias.
+
 Orient a new session against disk reality. Single-screen output.
 
 ## When to use

package/skills/god-mode.md

@@ -19,8 +19,9 @@ workflow.
 
 1. Resolve whether this is a new project run or a resume:
    - If `.godpowers/state.json`, `.godpowers/PROGRESS.md`, or
-     `.godpowers/CHECKPOINT.md` exists, this is a resume. Do not ask the user
-     to describe the project again. Call
+     `.godpowers/CHECKPOINT.md` exists, this is a resume. Treat `state.json`
+     as the source of truth and `PROGRESS.md` as a generated legacy fallback.
+     Do not ask the user to describe the project again. Call
      `lib/pillars.pillarizeExisting(projectRoot)` first, then rehydrate intent
      from disk and continue.
    - If no durable Godpowers state exists and no project description was
@@ -41,7 +42,7 @@ workflow.
      starting with `agents/context.md` and `agents/repo.md`
    - `.godpowers/CHECKPOINT.md` first, when present
    - `.godpowers/state.json`
-   - `.godpowers/PROGRESS.md`
+   - `.godpowers/PROGRESS.md` only as a generated legacy fallback when state is missing
    - `.godpowers/intent.yaml`, when present
    - `.godpowers/prep/INITIAL-FINDINGS.md`, when present
    - `.godpowers/prep/IMPORTED-CONTEXT.md`, when present
@@ -78,7 +79,7 @@ workflow.
      - The detected mode (A/B/C/E)
      - The active flags
      - Instruction that existing `.godpowers` state means resume, not prompt
-     - Instruction to read `.godpowers/PROGRESS.md` from disk if it exists
+     - Instruction to read `.godpowers/state.json` from disk, using `.godpowers/PROGRESS.md` only as generated legacy fallback when state is missing
      - Instruction to read `.godpowers/prep/INITIAL-FINDINGS.md` and
        `.godpowers/prep/IMPORTED-CONTEXT.md` if present before choosing the
        first planning or build step

package/skills/god-observe.md

@@ -13,14 +13,14 @@ Spawn the **god-observability-engineer** agent in a fresh context via the host p
 
 ## Setup
 
-1. Verify `.godpowers/deploy/STATE.md` exists. App is deployed.
+1. Verify `.godpowers/state.json` records `tier-3.deploy.status == done`.
 2. Spawn god-observability-engineer with PRD (for success metrics) and ARCH paths.
-3. The agent writes `.godpowers/observe/STATE.md`.
+3. The agent returns structured observability evidence for `.godpowers/state.json`; the generated `.godpowers/observe/STATE.md` view refreshes after state mutation.
 
 ## Verification
 
 After god-observability-engineer returns:
-1. Verify STATE.md exists on disk
+1. Verify observability evidence is recorded in `.godpowers/state.json`
 2. Verify each SLO has an error budget policy
 3. Verify each alert has a runbook
 4. Verify provider work is one of:
@@ -28,14 +28,16 @@ After god-observability-engineer returns:
    - provider-neutral definitions as code created and locally checked
    - missing dashboard/API credentials appended to the single external access
      bundle
-5. Update `.godpowers/PROGRESS.md`: Observe status = done only for verified
-   real provider config or local definitions as code. If external access is
-   missing, mark Observe = waiting-for-external-access.
+5. Run `npx godpowers state advance --step=observe --status=done --project=.`
+   only for verified real provider config or local definitions as code. If
+   external access is missing, record the missing access bundle in deploy or
+   observe state through the owning command wrapper rather than editing the
+   generated progress or observe state views.
 
 ## On Completion
 
 ```
-Observability complete: .godpowers/observe/STATE.md
+Observability complete: .godpowers/observe/STATE.md (generated view)
 
 Suggested next: /god-harden (adversarial security review, gates Launch)
 ```
@@ -53,15 +55,15 @@ named command cannot run without one exact credential.
 
 ## Re-invocation contract
 
-What happens if `/god-observe` is run when `.godpowers/observe/STATE.md` already exists:
+What happens if `/god-observe` is run when observe state evidence already exists:
 
 | Existing state | Behavior |
 |---|---|
-| File does not exist | Spawn god-observability-engineer; produce file; mark sub-step done |
-| File exists, passes lint, state.json says `done` | Pause: ask user (A) re-run anyway with diff preview, (B) treat as imported (no-op), (C) cancel |
-| File exists, fails lint or have-nots | Spawn god-observability-engineer in update mode with current file + findings as input. Diff preview before overwrite. |
-| File exists, state.json says `pending` | Treat as imported: hash + register, no agent spawn. User can `/god-observe --force` to re-run. |
-| `--force` flag passed | Snapshot existing file to `.godpowers/.trash/god-observe-<ts>/`. Spawn agent fresh. |
+| State evidence does not exist | Spawn god-observability-engineer; record observability evidence; mark sub-step done |
+| State evidence exists and state.json says `done` | Pause: ask user (A) re-run anyway with diff preview, (B) treat as imported (no-op), (C) cancel |
+| State evidence fails checks or the owning wrapper reports a generated view checksum warning | Spawn god-observability-engineer in update mode with current evidence plus findings as input. Diff preview before overwrite. |
+| State evidence exists, state.json says `pending` | Treat as imported: hash + register, no agent spawn. User can `/god-observe --force` to re-run. |
+| `--force` flag passed | Snapshot existing evidence to `.godpowers/.trash/god-observe-<ts>/`. Spawn agent fresh. |
 | `--dry-run` flag passed | Show what would happen; touch nothing |
 
 Snapshots in `.trash/` are recoverable via `/god-restore` for 30 days.

package/skills/god-pause-work.md

@@ -15,7 +15,7 @@ Create a context handoff so you can resume cleanly later.
 
 ## Process
 
-1. Read `.godpowers/PROGRESS.md` to capture current state
+1. Read `.godpowers/state.json` to capture current state; use `.godpowers/PROGRESS.md` only as a generated legacy fallback when state is missing.
 2. Identify what was actively being worked on:
    - Which slice? Which agent was running?
    - What was the next step?
@@ -53,7 +53,7 @@ Paused: [timestamp]
 `/god-resume-work` to load this context, then continue.
 ```
 
-5. Update PROGRESS.md to mark current sub-step as `in-flight` if not already
+5. Run `npx godpowers state advance --step=<current-step> --status=in-flight --project=.` if the current sub-step is not already in flight.
 
 ## On Completion
 

package/skills/god-plan.md

@@ -0,0 +1,51 @@
+---
+name: god-plan
+description: |
+  Planning verb dispatcher. Routes planning intent to PRD, design,
+  architecture, roadmap, stack, or reconstruction leaf commands without
+  replacing those commands.
+
+  Triggers on: "god plan", "/god-plan", "plan this", "write the prd",
+  "choose architecture", "roadmap this", "pick stack"
+---
+
+# /god-plan
+
+Route planning intent to the smallest existing planning command.
+
+## Runtime module resolution
+
+Resolve the Godpowers runtime root before inspecting routes:
+
+1. If `<projectRoot>/routing/god-prd.yaml` exists, use the repository checkout runtime at `<projectRoot>`.
+2. Otherwise use the installed bundle at `<tool-config-dir>/godpowers-runtime`.
+3. Read routing metadata from `<runtimeRoot>/routing/`.
+
+## Dispatch
+
+Use the first explicit argument when present. Otherwise classify the user text.
+
+| Signal | Hand off to |
+|---|---|
+| `prd`, `requirements`, `spec` | `/god-prd` |
+| `design`, `product`, `ux` | `/god-design` |
+| `arch`, `architecture`, `system` | `/god-arch` |
+| `roadmap`, `milestone`, `sequence` | `/god-roadmap` |
+| `stack`, `technology`, `dependency choice` | `/god-stack` |
+| `reconstruct`, `brownfield plan`, `existing code` | `/god-reconstruct` |
+
+Default to `/god-prd` when no stronger signal exists.
+
+## Process
+
+1. Select the target leaf command from the table.
+2. Read the selected leaf route YAML so prerequisites and next-step metadata stay source-controlled.
+3. Show the selected command, the matched signal, and the next command from the selected route.
+4. Hand off to the selected leaf command after user confirmation.
+
+## Guardrails
+
+- Do not create planning artifacts directly.
+- Do not spawn planning agents from this dispatcher.
+- Do not bypass executable gates declared by the selected leaf route.
+- Keep the selected leaf command callable as a direct shortcut.

package/skills/god-prd.md

@@ -13,11 +13,12 @@ Spawn the **god-pm** agent in a fresh context via the host platform's native age
 
 ## Setup
 
-1. If `.godpowers/PROGRESS.md` does not exist: tell the user to run `/god-init` first
+1. If `.godpowers/state.json` does not exist: tell the user to run `/god-init` first.
 2. Read `.godpowers/prep/INITIAL-FINDINGS.md` if present.
 3. Read `.godpowers/prep/IMPORTED-CONTEXT.md` if present.
-4. Spawn god-pm with the user's project description from PROGRESS.md plus any
-   prep artifacts. Prep artifacts are context, not source of truth.
+4. Spawn god-pm with the user's project description from `state.json`,
+   `.godpowers/intent.yaml`, and any prep artifacts. Prep artifacts are
+   context, not source of truth.
 5. The agent writes `.godpowers/prd/PRD.md`
 6. The agent runs have-nots checks before declaring done
 7. If god-pm pauses for a human question: relay to user using pause format
@@ -31,7 +32,7 @@ After god-pm returns:
 1. Verify `.godpowers/prd/PRD.md` exists on disk
 2. Spawn god-auditor briefly to verify have-nots pass
 3. Run `npx godpowers gate --tier=prd --project=.` and do not proceed on a non-zero exit
-4. Update `.godpowers/PROGRESS.md`: PRD status = done
+4. Run `npx godpowers state advance --step=prd --status=done --project=.` to update `state.json` and regenerate `.godpowers/PROGRESS.md`.
 
 ## Pause Format
 

package/skills/god-quick.md

@@ -39,7 +39,7 @@ workflow.
 
 - Planning tier (PRD/ARCH/ROADMAP/STACK)
 - Build planning into waves (single slice only)
-- PROGRESS.md updates if no `.godpowers/` exists
+- State mutation if no `.godpowers/` exists
 
 ## On Completion
 

package/skills/god-repo.md

@@ -23,7 +23,7 @@ After god-repo-scaffolder returns:
 1. Verify AUDIT.md exists on disk
 2. Verify CI passes on the empty scaffold
 3. Run `npx godpowers gate --tier=repo --project=.` and do not proceed on a non-zero exit
-4. Update `.godpowers/PROGRESS.md`: Repo status = done
+4. Run `npx godpowers state advance --step=repo --status=done --project=.` to update `state.json` and regenerate `.godpowers/PROGRESS.md`.
 
 ## On Completion
 

package/skills/god-resume-work.md

@@ -2,8 +2,9 @@
 name: god-resume-work
 description: |
   Resume work from a previous session. Reads .godpowers/HANDOFF.md if it
-  exists, otherwise re-derives state from PROGRESS.md and disk. Continues
-  from the last incomplete sub-step.
+  exists, otherwise re-derives state from state.json and disk, with
+  PROGRESS.md as a generated legacy fallback. Continues from the last
+  incomplete sub-step.
 
   Triggers on: "god resume", "/god-resume-work", "resume work", "continue",
   "pick up where I left off"
@@ -24,9 +25,9 @@ Load context and continue.
    - Confirm with user: "Pick up here?"
    - If yes: route to the specific next action
 
-3. If only PROGRESS.md exists:
+3. If only generated legacy PROGRESS.md exists:
    - Run the same logic as /god-next
-   - Suggest the next command based on state
+   - Suggest the next command based on re-derived state
 
 4. After resuming, archive HANDOFF.md:
    - Move to `.godpowers/archive/HANDOFF-[timestamp].md` so the trail is preserved

package/skills/god-roadmap-check.md

@@ -2,6 +2,7 @@
 name: god-roadmap-check
 deprecated: true
 replacement: god-reconcile
+successor: god-reconcile
 description: |
   Check if user intent overlaps with the existing ROADMAP.md before doing
   feature work. Returns: already-done, in-progress, enhancement,

package/skills/god-roadmap-update.md

@@ -43,7 +43,7 @@ Agent updates the roadmap and re-validates have-nots.
 After god-roadmap-updater returns:
 1. Verify ROADMAP.md still passes have-nots (R-01 through R-07)
 2. Verify Roadmap Changelog section is appended
-3. Update PROGRESS.md if applicable
+3. If the update changes tracked roadmap completion, run `npx godpowers state advance --step=roadmap --status=done --project=.` or the owning command wrapper.
 
 ## On Completion
 

package/skills/god-roadmap.md

@@ -24,7 +24,7 @@ After god-roadmapper returns:
 1. Verify ROADMAP.md exists on disk
 2. Spawn god-auditor to verify have-nots pass
 3. Run `npx godpowers gate --tier=roadmap --project=.` and do not proceed on a non-zero exit
-4. Update `.godpowers/PROGRESS.md`: Roadmap status = done
+4. Run `npx godpowers state advance --step=roadmap --status=done --project=.` to update `state.json` and regenerate `.godpowers/PROGRESS.md`.
 
 ## On Completion
 

package/skills/god-rollback.md

@@ -38,7 +38,7 @@ Examples:
 5. Mark each tier `status: pending` in state.json.
 6. Append a `op:rollback` event to the reflog with the full closure.
 7. Truncate the linkage map entries belonging to rolled-back artifacts.
-8. Update PROGRESS.md.
+8. Regenerate managed state views from `state.json`.
 
 ## Difference from /god-undo
 

package/skills/god-ship.md

@@ -0,0 +1,44 @@
+---
+name: god-ship
+description: |
+  Ship verb dispatcher. Routes release, deploy, observability, and launch
+  closure intent to existing deploy, observe, and launch leaf commands.
+
+  Triggers on: "god ship", "/god-ship", "ship this", "deploy this",
+  "launch this", "wire observability"
+---
+
+# /god-ship
+
+Route shipping intent to the smallest existing shipping command.
+
+## Runtime module resolution
+
+Resolve the Godpowers runtime root before inspecting routes:
+
+1. If `<projectRoot>/routing/god-deploy.yaml` exists, use the repository checkout runtime at `<projectRoot>`.
+2. Otherwise use the installed bundle at `<tool-config-dir>/godpowers-runtime`.
+3. Read routing metadata from `<runtimeRoot>/routing/`.
+
+## Dispatch
+
+| Signal | Hand off to |
+|---|---|
+| `deploy`, `pipeline`, `environment` | `/god-deploy` |
+| `observe`, `observability`, `slo`, `alert`, `runbook` | `/god-observe` |
+| `launch`, `release copy`, `go live` | `/god-launch` |
+
+Default to `/god-deploy` when no stronger signal exists.
+
+## Process
+
+1. Select the target leaf command from the table.
+2. Read the selected leaf route YAML so prerequisites and next-step metadata stay source-controlled.
+3. Show the selected command, the matched signal, and the release gate implied by that leaf.
+4. Hand off to the selected leaf command after user confirmation.
+
+## Guardrails
+
+- Do not publish, tag, deploy, or create release notes directly from this dispatcher.
+- Do not bypass safe-sync, harden, or launch prerequisites from the selected route.
+- Keep deploy, observe, and launch callable as direct shortcuts.

package/skills/god-skip.md

@@ -32,7 +32,7 @@ The reason is required. Skips without reason are rejected.
    mandatory; e.g. /god-mode rejects skipping the final /god-sync).
 3. Mark the sub-step `status: skipped` in state.json with `skipped-reason`.
 4. Append a `op:skip` event to the reflog.
-5. Update PROGRESS.md so the user sees the skip annotated.
+5. Regenerate the managed progress view from `state.json` so the user sees the skip annotated.
 
 ## What skip does NOT do
 
@@ -59,7 +59,7 @@ Reverse a previous skip. Marks the sub-step `pending` again.
 
 ## Implementation
 
-Built-in. Reads + writes `state.json` and PROGRESS.md. Appends to reflog.
+Built-in. Reads and writes `state.json`, regenerates the managed progress view, and appends to reflog.
 
 
 ## Locking

package/skills/god-stack.md

@@ -22,7 +22,7 @@ Spawn the **god-stack-selector** agent in a fresh context via the host platform'
 After god-stack-selector returns:
 1. Verify DECISION.md exists on disk
 2. Run `npx godpowers gate --tier=stack --project=.` and do not proceed on a non-zero exit
-3. Update `.godpowers/PROGRESS.md`: Stack status = done
+3. Run `npx godpowers state advance --step=stack --status=done --project=.` to update `state.json` and regenerate `.godpowers/PROGRESS.md`.
 
 ## On Completion
 

package/skills/god-standards.md

@@ -22,7 +22,7 @@ Run quality gate check on an artifact.
 
 ## Process
 
-1. Identify the artifact to check (user provides, or auto-detect from PROGRESS.md)
+1. Identify the artifact to check, using the user-provided path first, then `state.json`, then generated progress view fallback.
 2. Resolve the Godpowers runtime root: use `<projectRoot>` when `<projectRoot>/lib/router.js` exists, otherwise use the installed bundle at `<tool-config-dir>/godpowers-runtime`
 3. Look up the routing for the relevant tier (`<runtimeRoot>/lib/router.js` getStandards)
 4. Spawn god-standards-check in fresh context with: