godpowers 3.0.1 → 3.11.0

package/skills/god-first-run.md

@@ -0,0 +1,64 @@
+---
+name: god-first-run
+description: |
+  Guide a first-time user through the first 10 minutes of Godpowers with one
+  recommended command and a few concrete alternatives. Never list the full
+  command catalog by default.
+
+  Triggers on: "god first run", "/god-first-run", "first time",
+  "getting started", "start using godpowers"
+---
+
+# /god-first-run
+
+Guide the user through the first 10 minutes. Keep the response short,
+decisive, and state-aware. Do not list the full catalog unless the user asks
+for `/god-help all`.
+
+## Process
+
+1. Check whether `.godpowers/state.json` exists.
+2. If no project state exists, recommend `/god-demo` first when the user wants
+   proof, otherwise recommend `/god-init`.
+3. If project state exists, recommend `/god-next`.
+4. Mention at most three alternatives.
+5. End with `Next commands:`.
+
+## Output Shape
+
+For a fresh directory:
+
+```text
+You have not initialized Godpowers here yet, so the first useful move is a safe proof or project init.
+
+Next commands:
+- /god-demo: Try the shipped sandbox without touching this repo.
+- /god-init: Initialize Godpowers in this project now.
+- /god-surface --profile=core --dry-run: Preview the smallest installed command surface.
+- /god-help all: Show the complete catalog only if you want it.
+```
+
+For an initialized project:
+
+```text
+Godpowers state already exists here, so continue from disk instead of starting over.
+
+Next commands:
+- /god-next: Continue with the safest state-derived next step.
+- /god-status --full: Inspect the complete dashboard and proactive checks.
+- /god-help continue: See continue commands only.
+```
+
+## Rules
+
+- Do not explain routing internals.
+- Do not show more than four commands.
+- Do not show every installed command.
+- Prefer `/god-demo` when the user asks for proof or is unsure.
+- Prefer `/god-init` when the user says they are ready to use the current repo.
+- Prefer `/god-next` when `.godpowers/state.json` exists.
+
+## Implementation
+
+Built-in, no spawned agent. Reads `.godpowers/state.json` and may call
+`<runtimeRoot>/lib/dashboard.js` for the next route when state exists.

package/skills/god-harden.md

@@ -21,8 +21,11 @@ Spawn the **god-harden-auditor** agent in a fresh context via the host platform'
 
 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:
+2. Record the executed security check as evidence so the gate has a passing
+   verification record, for example:
+   `npx godpowers verify "npm audit --omit=dev" --substep tier-3.harden --claim "dependency audit clean" --project=.`
+3. Run `npx godpowers gate --tier=harden --project=.` and do not proceed on a non-zero exit
+4. Read findings classification:
    - 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=.`
 

package/skills/god-help.md

@@ -1,10 +1,8 @@
 ---
 name: god-help
 description: |
-  Discoverable contextual help for Godpowers. Lists all skills grouped
-  by category, with the current project state and what's suggested next.
-  Different from /god (front door): /god proposes a command sequence;
-  /god-help lists the catalog.
+  Discoverable contextual help for Godpowers. Shows a short guided view by
+  default, with the full catalog available only through /god-help all.
 
   Triggers on: "god help", "/god-help", "what can godpowers do",
   "list commands", "show help"
@@ -12,21 +10,55 @@ description: |
 
 # /god-help
 
-List Godpowers commands organized by family first, then by full catalog
-category. Show the map without hiding any installed command.
+Show the smallest useful help view for the current project state. Do not dump
+the installed command catalog unless the user asks for `all`, a family, a
+category, a keyword search, or one command.
 
-## Output sections
+## Default Output
 
-### 1. Where you are
-One line summary of project state from `state.json`:
-- Mode (A/B/C/E + suite flag), scale, current tier, last command
+### 1. Where You Are
 
-### 2. Suggested next
-The same suggestion `/god-next` would make. One command.
+Render one plain sentence from disk state:
 
-### 3. Command families
-Load `<runtimeRoot>/lib/command-families.js` and render family cards before the
-full catalog:
+```text
+You are <not initialized | in planning | building | shipping | complete>; the likely next move is <command>.
+```
+
+If no `.godpowers/` directory exists, treat the user as first-run and recommend
+`/god-first-run`.
+
+### 2. Likely Next Area
+
+Show 3 to 6 commands. Put the best command first. Use the family map from
+`<runtimeRoot>/lib/command-families.js` and the state-derived recommendation
+from `<runtimeRoot>/lib/router.js` or `<runtimeRoot>/lib/dashboard.js`.
+
+Example for an initialized project:
+
+```text
+Likely next area: continue
+
+Next commands:
+- /god-next: Continue with the safest state-derived next step.
+- /god-status --full: See the complete dashboard and proactive checks.
+- /god-help build: See build commands only.
+```
+
+Example for first-run:
+
+```text
+You have not initialized Godpowers here yet.
+
+Next commands:
+- /god-first-run: Walk through the first 10 minutes with one recommendation at a time.
+- /god-demo: Try the shipped sandbox before touching this repo.
+- /god-init: Start this project now.
+- /god-help all: Show the complete catalog.
+```
+
+### 3. Families
+
+Show family hubs without leaf commands:
 
 - Start: start or import a project.
 - Continue: understand state and choose the next move.
@@ -40,65 +72,59 @@ full catalog:
 - Collaborate: coordinate people, workstreams, suites, sprints, and pull requests.
 - Configure: tune settings, budgets, cache, profiles, help, and version info.
 
-### 4. Decision ladders
-Show the compact ladders when the user asks about capture, work size, or
-verification:
-
-- Capture ladder: `/god-note`, `/god-add-todo`, `/god-add-backlog`, `/god-plant-seed`.
-- Work size ladder: `/god-fast`, `/god-quick`, `/god-story`, `/god-feature`, `/god-build`, `/god-debug`, `/god-hotfix`.
-- Verification ladder: `/god-lint`, `/god-standards`, `/god-review`, `/god-test-runtime`, `/god-audit`, `/god-hygiene`, `/god-preflight`, `/god-dogfood`.
+End with `Next commands:` and never more than four commands.
 
-### 5. Status views
-Present `/god-status` as the hub view and list the direct shortcuts:
-`/god-progress`, `/god-lifecycle`, `/god-locate`, and `/god-next`.
+## Subcommands
 
-### 6. Full catalog
-All installed skills grouped by category. Categories match
-`docs/reference.md` order.
+### `/god-help`
 
-### 7. Where to go for more
-- Full reference: https://github.com/aihxp/godpowers/blob/main/docs/reference.md
-- Concepts: https://github.com/aihxp/godpowers/blob/main/docs/concepts.md
-- Roadmap: https://github.com/aihxp/godpowers/blob/main/docs/ROADMAP.md
-- Installed have-nots catalog: `<runtime>/godpowers-references/HAVE-NOTS.md`
+Contextual help with 3 to 6 likely next commands.
 
-## Subcommands
+### `/god-help all`
 
-### `/god-help`
-Full catalog with categories.
+Full installed catalog grouped by category. This is the only default path that
+lists every command.
 
 ### `/god-help <command>`
-Description of one specific command (reads the skill's frontmatter description).
+
+Description of one command from the skill frontmatter.
 
 ### `/god-help search <keyword>`
-Filter the catalog by keyword match against descriptions.
+
+Filter the catalog by keyword match against names and descriptions.
 
 ### `/god-help <family>`
+
 Show one family card plus its leaf commands. Valid families are start,
 continue, build, verify, operate, maintain, capture, recover, extend,
 collaborate, and configure.
 
 ### `/god-help --category=<name>`
-Show only one category (lifecycle, planning, building, shipping, etc.).
+
+Show only one category, such as lifecycle, planning, building, shipping, or
+configuration.
 
 ## Implementation
 
 Built-in, no spawned agent. Reads:
 - `<runtime>/skills/*.md` frontmatter
-- `.godpowers/state.json` (for current state line)
-- `<runtimeRoot>/lib/recipes.js` (for suggested next)
-- `<runtimeRoot>/lib/command-families.js` (for family cards and ladders)
+- `.godpowers/state.json` for current state
+- `<runtimeRoot>/lib/dashboard.js` for the next route when available
+- `<runtimeRoot>/lib/command-families.js` for family cards and ladders
 
-Resolve `<runtimeRoot>` as `<projectRoot>` when `<projectRoot>/lib/recipes.js` exists. Otherwise use the installed bundle at `<tool-config-dir>/godpowers-runtime`, where `<tool-config-dir>` is the directory that contains this installed skill.
+Resolve `<runtimeRoot>` as `<projectRoot>` when
+`<projectRoot>/lib/dashboard.js` exists. Otherwise use the installed bundle at
+`<tool-config-dir>/godpowers-runtime`, where `<tool-config-dir>` is the
+directory that contains this installed skill.
 
-## When to use
+## When To Use
 
-- First time using Godpowers and need an overview
-- Forgot the exact name of a command
-- Want to discover commands relevant to the current state
+- First time using Godpowers and needing one next move.
+- Forgot the exact name of a command.
+- Want commands relevant to the current state without seeing the whole catalog.
 
-## When NOT to use
+## When Not To Use
 
-- You know exactly what you want -> just run that command
-- You want intent-to-command matching -> use `/god` (front door)
-- You want a single next-step suggestion -> use `/god-next`
+- You know exactly what you want: run that command.
+- You want intent-to-command matching: use `/god`.
+- You want the next state-derived action only: use `/god-next`.

package/skills/god-hygiene.md

@@ -94,12 +94,11 @@ Suggested next actions (in priority order):
 
 Schedule next hygiene check in [N days] (default: 30).
 
-Proposition:
-  1. Implement partial: [highest-priority action]
-  2. Implement complete: [all P0/P1 hygiene actions in order]
-  3. Discuss more: /god-discuss hygiene remediation
-  4. Inspect status: /god-status after fixes
-Recommended: [one option and why]
+Next commands:
+- /god-next: Run the highest-priority hygiene follow-up from disk state.
+- /god-hygiene: Re-run the health check after P0 and P1 fixes.
+- /god-discuss hygiene remediation: Resolve the open question before continuing.
+- /god-status after fixes: Inspect status before continuing.
 ```
 
 ## Have-Nots

package/skills/god-lifecycle.md

@@ -121,29 +121,27 @@ Suggested next: /god-spike with narrower question
 Or: archive the spike if no longer relevant
 ```
 
-## Proposition Closeout
+## Next Commands Closeout
 
-Every lifecycle report must end with a proposition block. Use the detected
+Every lifecycle report must end with a Next commands block. Use the detected
 phase to fill in concrete commands:
 
 ```
-Proposition:
-  1. Implement partial: [smallest safe next command from the lifecycle report]
-  2. Implement complete: /god-mode [resume or scope] when the phase is safe for an autonomous project run
-  3. Discuss more: /god-discuss [unclear phase, blocker, or choice]
-  4. Inspect status: /god-status or /god-next
-Recommended: [one option and why it matches the detected phase]
+Next commands:
+- /god-next: Run the smallest safe next command from the lifecycle report.
+- /god-mode [resume or scope] when the phase is safe for an autonomous project run: Run the full recommended path.
+- /god-discuss [unclear phase, blocker, or choice]: Resolve the open question before continuing.
+- /god-status or /god-next: Inspect status before continuing.
 ```
 
 For hard blockers, such as post-incident pending, replace the broad options
 with the required next command plus inspect and discuss alternatives:
 
 ```
-Proposition:
-  1. Resolve required next: /god-postmortem
-  2. Inspect first: /god-status
-  3. Discuss blocker: /god-discuss incident follow-up
-Recommended: /god-postmortem because the incident learning loop is still open.
+Next commands:
+- /god-postmortem: Resolve the required incident follow-up before continuing.
+- /god-status --full: Inspect full status before acting.
+- /god-discuss incident follow-up: Resolve the blocker with a focused discussion.
 ```
 
 ## Have-Nots

package/skills/god-list-assumptions.md

@@ -48,17 +48,16 @@ Assumptions Claude is operating under:
 Any of these wrong? Flag them now before they cement into decisions.
 ```
 
-## Proposition Closeout
+## Next Commands Closeout
 
-After listing assumptions, end with a proposition block:
+After listing assumptions, end with a Next commands block:
 
 ```
-Proposition:
-  1. Implement partial: correct or confirm the low-confidence assumptions only
-  2. Implement complete: confirm assumptions and continue to [queued command]
-  3. Discuss more: /god-discuss assumptions before planning
-  4. Inspect status: /god-status to re-ground before deciding
-Recommended: [one option and why]
+Next commands:
+- /god-discuss assumptions: Correct or confirm low-confidence assumptions.
+- /god-next: Continue to the queued command after assumptions are confirmed.
+- /god-discuss assumptions before planning: Resolve the open question before continuing.
+- /god-status to re-ground before deciding: Inspect status before continuing.
 ```
 
 ## Have-Nots

package/skills/god-locate.md

@@ -80,17 +80,16 @@ Drift check:
 - If gap > 1 hour, run /god-context-scan
 ```
 
-## Proposition Closeout
+## Next Commands Closeout
 
-The orientation summary must end with a compact proposition block:
+The orientation summary must end with a compact Next commands block:
 
 ```
-Proposition:
-  1. Implement partial: [next suggested command]
-  2. Implement complete: /god-mode to continue the project run when no drift is flagged
-  3. Discuss more: /god-discuss [unclear state or stale checkpoint]
-  4. Inspect status: /god-status for the full report
-Recommended: [one option and why]
+Next commands:
+- /god-next: Run the next suggested command from disk state.
+- /god-mode to continue the project run when no drift is flagged: Run the full recommended path.
+- /god-discuss [unclear state or stale checkpoint]: Resolve the open question before continuing.
+- /god-status for the full report: Inspect status before continuing.
 ```
 
 If drift is flagged, recommend `/god-context-scan` or `/god-repair` before

package/skills/god-map-codebase.md

@@ -43,11 +43,10 @@ Codebase mapped.
 
 Suggested next: /god-init Mode B (gap-fill) or /god-feature
 
-Proposition:
-  1. Implement partial: /god-intel or /god-tech-debt on the riskiest mapped area
-  2. Implement complete: /god-init Mode B to gap-fill project artifacts
-  3. Discuss more: /god-discuss the unclear architecture or quality findings
-  4. Run God Mode: /god-mode after Mode B context exists
-Recommended: /god-init Mode B when the codebase is real but Godpowers artifacts
+Next commands:
+- /god-intel or /god-tech-debt on the riskiest mapped area: Run the smallest safe next step.
+- /god-init Mode B to gap-fill project artifacts: Run the full recommended path.
+- /god-discuss the unclear architecture or quality findings: Resolve the open question before continuing.
+- /god-mode after Mode B context exists: Run the full autonomous project workflow when it fits.
 are missing.
 ```

package/skills/god-migrate.md

@@ -26,28 +26,19 @@ Detect and migrate adjacent planning systems into Godpowers.
 
 ## Auto-Invoke Contract
 
-`/god-init` auto-invokes the import path when it detects legacy planning, BMAD, or
-Superpowers context. It must show this visible status card:
+`/god-init` auto-invokes the import path when it detects legacy planning, BMAD,
+or Superpowers context. It shows this concise note when import writes happen:
 
 ```
-Auto-invoked:
-  Trigger: /god-init planning-system detection
-  Agent: none, local runtime only
-  Local syncs:
-    + planning-system-import: <detected systems, written seeds, or no-op>
-  Artifacts: .godpowers/prep/IMPORTED-CONTEXT.md and optional seed artifacts
+Imported adjacent planning context into .godpowers/prep/IMPORTED-CONTEXT.md.
 ```
 
 `/god-sync` auto-invokes sync-back when `state.json` contains enabled
-`source-systems` entries. It must show this visible status card:
+`source-systems` entries. It shows this concise note when companion files are
+written:
 
 ```
-Auto-invoked:
-  Trigger: /god-sync source-system sync-back
-  Agent: none, local runtime only
-  Local syncs:
-    + source-sync: <written companion files, pointer fences, or no-op>
-  Artifacts: <.planning/GODPOWERS-SYNC.md, _bmad-output/GODPOWERS-SYNC.md, docs/superpowers/GODPOWERS-SYNC.md>
+Synced Godpowers progress back to the source planning system.
 ```
 
 If the import has low confidence, multiple conflicting systems, or missing

package/skills/god-next.md

@@ -1,10 +1,9 @@
 ---
 name: god-next
 description: |
-  Decision engine. For any command intent, checks prerequisites, proposes
-  auto-completion of missing prerequisites, runs standards checks at gates,
-  and suggests next commands after success. Backed by runtime routing YAML
-  configurations.
+  Decision engine. For any command intent, checks prerequisites, runs safe
+  read-only continuation when possible, and suggests the next concrete command
+  after success. Backed by runtime routing YAML configurations.
 
   Triggers on: "god next", "/god-next", "what's next", "what should I do next",
   "next step", "continue"
@@ -13,7 +12,9 @@ description: |
 # /god-next
 
 The unified decision engine. Route between commands based on disk state,
-routing definitions, recipes, command families, and user intent.
+routing definitions, recipes, command families, and user intent. Explain what
+you are about to do in one plain sentence, then run the safe next step when the
+step is read-only or an explicit local check.
 
 ## Runtime module resolution
 
@@ -21,22 +22,22 @@ routing definitions, recipes, command families, and user intent.
 2. Otherwise use the installed bundle at `<tool-config-dir>/godpowers-runtime`.
 3. Read routing definitions from `<runtimeRoot>/routing/*.yaml` and recipes from `<runtimeRoot>/routing/recipes/*.yaml`.
 4. Load `<runtimeRoot>/lib/command-families.js` before resolving broad intent.
-5. Load `<runtimeRoot>/lib/dashboard.js` and render the shared dashboard before route-specific detail.
+5. Load `<runtimeRoot>/lib/dashboard.js` and render only the compact action brief unless the user asks for `--full`.
 6. Prefer the MCP `next` tool when it is available, and fall back to the CLI or runtime module when it is not.
-7. If no dashboard module is available, say `Dashboard engine: unavailable, manual scan used`.
+7. If no dashboard module is available, use a manual disk scan quietly and suggest `/god-doctor` only when the fallback changes the recommendation.
 
 ## Required references
 
 Read these references before producing a route recommendation:
 
 - `<runtimeRoot>/references/orchestration/GOD-NEXT-RUNBOOK.md` for invocation modes, route detail, and edge cases.
-- `<runtimeRoot>/references/shared/DASHBOARD-CONTRACT.md` for the shared status and proposition shape.
+- `<runtimeRoot>/references/shared/DASHBOARD-CONTRACT.md` for the shared status and `Next commands:` shape.
 
 ## Invocation modes
 
 - Post-completion: after a command finishes, read its routing file and announce the next gate.
 - Pre-flight: before a target command runs, evaluate prerequisites and offer auto-completion when available.
-- Standalone: when the user asks what is next, derive the recommendation from disk state.
+- Standalone: when the user asks what is next, derive the recommendation from disk state and run the safe read-only next step when it has no destructive effect.
 - Intent-based: when the user uses fuzzy text, match recipes and command families before raw route order.
 
 ## Decision rules
@@ -54,12 +55,10 @@ Read these references before producing a route recommendation:
 
 Render this sequence:
 
-1. `Godpowers Next` heading.
-2. Shared Godpowers Dashboard from `DASHBOARD-CONTRACT.md`.
-3. Suggested next command and one-line reason.
-4. Optional three-line path ahead when state allows it.
-5. Optional pre-flight, standards, or blocker detail.
-6. Proactive checks using the shared labels.
-7. Proposition block unless the selected command already launched.
+1. One plain sentence describing the selected next step.
+2. Suggested next command and one-line reason.
+3. Optional blocker detail only when it changes the recommendation.
+4. `Next commands:` with the selected command first.
 
-Keep the route preview to three lines unless the user asks for the full plan.
+Keep the route preview to three lines unless the user asks for the full plan or
+`--full`. Do not print the full dashboard by default.

package/skills/god-preflight.md

@@ -137,18 +137,17 @@ Use the report to choose the next pass:
 | Tests are absent before refactor | `/god-add-tests` |
 | Refactor path is obvious and bounded | `/god-refactor` |
 
-## Proposition Closeout
+## Next Commands Closeout
 
-End the user-facing response with a proposition block based on the recommended
+End the user-facing response with a Next commands block based on the recommended
 sequence:
 
 ```
-Proposition:
-  1. Implement partial: [first recommended command or task]
-  2. Implement complete: [full recommended sequence]
-  3. Discuss more: /god-discuss [highest uncertainty or blocker]
-  4. Run God Mode: /god-mode only when the preflight says the repo is ready or the remaining gaps are acceptable
-Recommended: [first command and why it should happen before the rest]
+Next commands:
+- /god-next: Run the first recommended command from the preflight result.
+- /god-mode: Continue the full recommended sequence when preflight is clear.
+- /god-discuss [highest uncertainty or blocker]: Resolve the open question before continuing.
+- /god-mode only when the preflight says the repo is ready or the remaining gaps are acceptable: Run the full autonomous project workflow when it fits.
 ```
 
 ## Guardrails

package/skills/god-progress.md

@@ -78,17 +78,16 @@ Open the full checklist any time: .godpowers/REQUIREMENTS.md
 Use plain text. No emoji, no box-drawing. Ledger marks are `[x]` done, `[~]`
 in progress, `[ ]` not started, matching the ledger file.
 
-## Proposition Closeout
+## Next Commands Closeout
 
-End every progress report with a proposition block:
+End every progress report with a Next commands block:
 
 ```text
-Proposition:
-  1. Implement partial: [single next command, e.g. /god-build]
-  2. Implement complete: /god-mode to continue the project run when unblocked
-  3. Inspect deeper: open .godpowers/REQUIREMENTS.md or run /god-status
-  4. Discuss more: /god-discuss [a gap, a blocked requirement, or scope]
-Recommended: [one option and one sentence on why it fits the disk state]
+Next commands:
+- /god-build: Continue the next build step when the roadmap is unblocked.
+- /god-mode: Continue the project run when the current phase is safe to resume.
+- /god-status --full: Inspect the complete dashboard and proactive checks.
+- /god-discuss <blocked requirement>: Resolve a gap before continuing.
 ```
 
 If `derived.gaps` is non-empty, make `/god-review-changes` (or fixing the gap)

package/skills/god-reconcile.md

@@ -83,12 +83,11 @@ Recommended sequence:
   Main work:  [/god-feature scoped to Milestone 2]
   Post-work:  [/god-sync]
 
-Proposition:
-  1. Implement partial: [run only the first preflight command]
-  2. Implement complete: [run the full recommended sequence]
-  3. Discuss more: /god-discuss [ambiguous overlap or artifact conflict]
-  4. Cancel: leave artifacts unchanged
-Recommended: [one option and why]
+Next commands:
+- /god-next: Run only the first preflight command.
+- /god-sync: Run the full recommended sync sequence after reconciliation.
+- /god-discuss [ambiguous overlap or artifact conflict]: Resolve the open question before continuing.
+- stop: Leave artifacts unchanged.
 ```
 
 ## Difference from /god-roadmap-check

package/skills/god-reconstruct.md

@@ -59,13 +59,11 @@ Suggested next:
   /god-feature     - now you can add features with reconciliation
   /god-tech-debt   - assess what needs paying down
 
-Proposition:
-  1. Implement partial: /god-audit the reconstructed artifacts first
-  2. Implement complete: /god-audit then /god-feature with reconciliation
-  3. Discuss more: /god-discuss stakeholder review questions
-  4. Run God Mode: /god-mode after stakeholder review or audit accepts the reconstruction
-Recommended: /god-audit before new feature work because reconstruction is
-evidence-derived, not stakeholder-approved.
+Next commands:
+- /god-audit the reconstructed artifacts first: Run the smallest safe next step.
+- /god-audit then /god-feature with reconciliation: Run the full recommended path.
+- /god-discuss stakeholder review questions: Resolve the open question before continuing.
+- /god-mode after stakeholder review or audit accepts the reconstruction: Run the full autonomous project workflow when it fits.
 ```
 
 ## Caveats

package/skills/god-refactor.md

@@ -92,18 +92,17 @@ Suggested next: /god-status or continue with /god-feature
 
 When the user asks for a proposal, recommendation, or performance-improvement
 approach and no files are edited, do not stop after the advice. End with a
-proposition block that turns the recommendation into user-selectable next
+Next commands block that turns the recommendation into user-selectable next
 moves.
 
 Use this shape:
 
 ```
-Proposition:
-  1. Implement partial: /god-spike <measurement or smallest safe slice>
-  2. Implement complete: /god-refactor <full scoped refactor>
-  3. Discuss more: /god-discuss <unresolved scope question>
-  4. Run God Mode: /god-mode <scope> if the user wants the full autonomous project run
-Recommended: <one option and why>
+Next commands:
+- /god-spike <measurement or smallest safe slice>: Run the smallest safe next step.
+- /god-refactor <full scoped refactor>: Run the full recommended path.
+- /god-discuss <unresolved scope question>: Resolve the open question before continuing.
+- /god-mode <scope> if the user wants the full autonomous project run: Run the full autonomous project workflow when it fits.
 ```
 
 For performance refactors, prefer partial implementation when measurement is

package/skills/god-roadmap-check.md

@@ -64,15 +64,14 @@ After `god-reconciler` returns:
 1. Verify the verdict has a status from the canonical 6
 2. Verify recommendation has a concrete action
 3. Display to user; await decision before proceeding
-4. End with a proposition block:
+4. End with a Next commands block:
 
 ```
-Proposition:
-  1. Implement partial: [smallest command from the recommendation]
-  2. Implement complete: [roadmap update plus feature work when needed]
-  3. Discuss more: /god-discuss roadmap overlap
-  4. Defer: /god-add-backlog [intent]
-Recommended: [one option and why]
+Next commands:
+- /god-roadmap-update: Apply the smallest roadmap correction from the recommendation.
+- /god-feature <feature-name>: Start feature work after roadmap overlap is clear.
+- /god-discuss roadmap overlap: Resolve the open question before continuing.
+- /god-add-backlog [intent]: Defer the work for later review.
 ```
 
 ## When called manually