godpowers 1.6.7 → 1.6.9

package/CHANGELOG.md

@@ -5,6 +5,69 @@ All notable changes to Godpowers will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [1.6.9] - 2026-05-16
+
+Proposal closeout patch. Makes Godpowers end exploratory, diagnostic, audit,
+status, lifecycle, and decision-support answers with concrete choices instead
+of leaving the user to infer the next action.
+
+### Added
+- Added a core Proposal Closeout rule requiring a `Proposition:` block when
+  Godpowers gives a recommendation, proposal, exploratory plan, diagnostic
+  report, status report, audit report, lifecycle report, reconciliation report,
+  or decision-support response without directly launching work.
+- Added proposition closeouts to `/god`, `/god-next`, `/god-status`,
+  `/god-lifecycle`, `/god-locate`, `/god-context-scan`, `/god-preflight`,
+  `/god-doctor`, `/god-audit`, `/god-hygiene`, `/god-standards`, and
+  `/god-agent-audit`.
+- Added proposition closeouts to proposal-heavy planning and analysis commands:
+  `/god-discuss`, `/god-explore`, `/god-list-assumptions`, `/god-refactor`,
+  `/god-spike`, `/god-tech-debt`, `/god-archaeology`, `/god-map-codebase`,
+  `/god-reconstruct`, `/god-design-impact`, `/god-reconcile`, and
+  `/god-roadmap-check`.
+
+### Changed
+- Proposal-style outputs now mirror the clearer GSD pattern: implement a small
+  slice, implement the full route, discuss more, inspect status, or run
+  `/god-mode` only when that is safe.
+- `/god-next` and `/god-status` now explicitly distinguish partial progress,
+  full autonomous continuation, discussion, and inspection choices.
+- Diagnostic commands now avoid recommending broad automation when blockers or
+  disk-state inconsistencies make that unsafe.
+
+### Guardrails
+- Pure completion commands can still use their normal `Suggested next` line
+  after a verified artifact is produced.
+- `/god-mode` is not offered as a blanket answer when a blocker, failing gate,
+  manual repair, or unresolved ambiguity should be addressed first.
+- The patch changes guidance only. It does not add slash commands, specialist
+  agents, workflows, recipes, schemas, or public artifact formats.
+
+## [1.6.8] - 2026-05-16
+
+Staging deferral patch. Keeps Godpowers moving through local and CI-verifiable
+shipping work instead of pausing early for a deployed staging URL.
+
+### Changed
+- `god-orchestrator` now treats deployed staging verification as deferred by
+  default when no live target URL is evidenced and the user did not request
+  staging.
+- `/god-mode`, `/god-deploy`, and `/god-launch` now ask for
+  `STAGING_APP_URL` only when the user explicitly requests staging, invokes
+  deployed verification, or reaches final project sign-off.
+- Deploy, observe, and launch specialists now record missing deployed access in
+  `.godpowers/deploy/WAITING-FOR-EXTERNAL-ACCESS.md` while continuing through
+  local and CI-verifiable gates.
+
+### Guardrails
+- Godpowers still never invents staging or production domains from names,
+  brands, titles, or common TLDs.
+- Provider keys, dashboards, DNS tokens, production secrets, and admin consoles
+  are requested only after a named scripted check proves that exact access is
+  needed.
+- Final sign-off can still run deployed smoke immediately when the user
+  provides `STAGING_APP_URL=<deployed staging origin>`.
+
 ## [1.6.7] - 2026-05-16
 
 Progress visibility patch. Makes Godpowers easier to follow while preserving

package/README.md

@@ -2,7 +2,7 @@
 
 [![CI](https://github.com/aihxp/godpowers/actions/workflows/ci.yml/badge.svg)](https://github.com/aihxp/godpowers/actions/workflows/ci.yml)
 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](LICENSE)
-[![Version](https://img.shields.io/badge/version-1.6.7-blue)](CHANGELOG.md)
+[![Version](https://img.shields.io/badge/version-1.6.9-blue)](CHANGELOG.md)
 [![npm](https://img.shields.io/npm/v/godpowers.svg)](https://www.npmjs.com/package/godpowers)
 
 **Ship fast. Ship right. Ship everything. Ship accountably.**
@@ -12,10 +12,9 @@ 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.
 
-Version 1.6.7 keeps the stable Godpowers surface while making the live arc
-easier to follow: progress reports now show percent complete, current step,
-recent work, and what happens next. The orchestrator also documents compact
-"Next step" and "Step result" cards around visible tier/sub-step work.
+Version 1.6.9 keeps the stable Godpowers surface while making proposal and
+status outputs easier to act on: exploratory, diagnostic, audit, lifecycle, and
+decision-support commands now end with explicit proposition choices.
 
 It fuses four disciplines into one unified workflow:
 

package/RELEASE.md

@@ -1,10 +1,11 @@
-# Godpowers 1.6.7 Release
+# Godpowers 1.6.9 Release
 
 Date: 2026-05-16
 
-Godpowers 1.6.7 makes the live workflow easier to track. The goal of this
-patch is to answer "what is Godpowers doing, how far along is it, what just
-happened, and what happens next" from disk state.
+Godpowers 1.6.9 makes proposal and report outputs easier to act on. The goal of
+this patch is to keep Godpowers from ending a recommendation, audit, lifecycle
+report, status report, or exploratory answer without offering concrete next
+moves.
 
 ## What is stable
 
@@ -23,39 +24,36 @@ happened, and what happens next" from disk state.
 - Extension pack compatibility range for the 1.x line
 - Domain precision through `.godpowers/domain/GLOSSARY.md` and DG-01 through
   DG-05 checks
+- GSD-style proposition closeouts for exploratory, diagnostic, audit,
+  lifecycle, status, reconciliation, and decision-support outputs
 
 ## What is new
 
-- `lib/state.progressSummary` computes percentage complete, completed step
-  count, total step count, current step number, and current tier/sub-step from
-  `state.json`.
-- `CHECKPOINT.md` can persist progress frontmatter and now includes
-  "What happened recently" and "What happens next" sections.
-- `god-orchestrator` now has a Step Narration Protocol for compact
-  "Next step" and "Step result" cards around visible tier/sub-step work.
-- `/god-mode`, `/god-next`, `/god-status`, and `/god-locate` now document
-  progress, path-ahead, recent-work, and next-action summaries.
-- `templates/PROGRESS.md` now includes a current step plan and recent step
-  result shape.
-- Package publication now allowlists `agents/god-*.md`, preventing local
-  Pillars files under `agents/` from entering the npm payload.
-- Package contents checks now fail if non-specialist files under `agents/`
-  would be published.
-- `AGENTS.md` now includes the Pillars Protocol for loading durable project
-  context and workflow-state files.
-- Installer local mode now resolves runtime destinations under the current
-  directory and installs only `god-*.md` specialist agent files.
-
-## What 1.6.7 means
-
-Godpowers 1.6.7 does not expand the public command surface. It makes the
-existing arc more legible by showing a disk-derived progress report, a short
-plan before visible work starts, and a short result after work completes or
-pauses.
-
-The release also tightens npm packaging around specialist agents. Local
-project Pillars can live under `agents/` during development, but only
-`agents/god-*.md` files are packaged as Godpowers specialist agents.
+- The core Godpowers skill now requires a `Proposition:` block after
+  recommendations, proposals, exploratory plans, diagnostics, status reports,
+  audits, lifecycle reports, reconciliations, and decision-support answers
+  when no command was launched.
+- `/god`, `/god-next`, `/god-status`, `/god-lifecycle`, `/god-locate`,
+  `/god-context-scan`, `/god-preflight`, `/god-doctor`, `/god-audit`,
+  `/god-hygiene`, `/god-standards`, and `/god-agent-audit` now close with
+  concrete next choices.
+- Planning and analysis commands such as `/god-discuss`, `/god-explore`,
+  `/god-list-assumptions`, `/god-refactor`, `/god-spike`, `/god-tech-debt`,
+  `/god-archaeology`, `/god-map-codebase`, `/god-reconstruct`,
+  `/god-design-impact`, `/god-reconcile`, and `/god-roadmap-check` now make
+  their next move explicit.
+- Proposition blocks separate partial implementation, full implementation,
+  discussion, status inspection, and `/god-mode` continuation when safe.
+
+## What 1.6.9 means
+
+Godpowers 1.6.9 does not expand the public command surface. It changes how
+Godpowers exits proposal-like work: the user should see useful routes forward
+instead of only a recommendation.
+
+Pure completion commands can still end with a normal `Suggested next` line when
+an artifact was actually produced. Proposal, diagnostic, audit, lifecycle,
+status, and decision-support commands must offer a proposition block.
 
 Safe sync and unresolved Critical harden findings remain release-truth gates.
 Per-repo Quarterback ownership remains intact for Mode D suite work.
@@ -65,8 +63,8 @@ Per-repo Quarterback ownership remains intact for Mode D suite work.
 During the 1.x stability window, do not add broad new command families, change
 schema formats, or rename public artifacts without evidence from real use.
 
-The `v1.6.7` git tag points to the release commit that matches the npm
-`godpowers@1.6.7` package. Public publishes should prefer the tag-triggered
+The `v1.6.9` git tag points to the release commit that matches the npm
+`godpowers@1.6.9` package. Public publishes should prefer the tag-triggered
 GitHub workflow so npm provenance, git history, and release notes stay aligned.
 
 Allowed changes:

package/SKILL.md

@@ -67,6 +67,31 @@ answer a question, inspect first. When a term is resolved, record it in
 `.godpowers/domain/GLOSSARY.md` with canonical spelling, avoided aliases,
 relationships, and any unresolved ambiguity.
 
+### 9. Proposal Closeout
+When you answer with a recommendation, proposal, or exploratory plan and do not
+make file edits, run commands, or hand off to another command, end with a
+proposition block. The block must give the user concrete next moves instead of
+leaving them at a dead stop.
+
+This also applies to diagnostic, status, audit, lifecycle, reconciliation, and
+decision-support reports when they end with suggestions, options, or a
+recommended sequence.
+
+Use this shape:
+
+```
+Proposition:
+  1. Implement partial: <smallest safe slice and command>
+  2. Implement complete: <larger command or arc>
+  3. Discuss more: <focused question or /god-discuss topic>
+  4. Run God Mode: /god-mode <optional flags or scope>
+Recommended: <one option and why>
+```
+
+Only include options that actually fit the situation. If `/god-mode` is too
+broad or unsafe for the request, say so and offer `/god-feature`,
+`/god-refactor`, `/god-spike`, or `/god-discuss` instead.
+
 ---
 
 ## Operating Modes

package/agents/god-deploy-engineer.md

@@ -65,11 +65,16 @@ Build is complete. All tests pass. `.godpowers/build/STATE.md` shows green.
   only when needed by the next command, exact provider links only when a failed
   check proves they are needed, and the command Godpowers will run after access
   exists.
-- Default first pause: ask only for `STAGING_APP_URL=<staging-origin>` so the
-  real smoke command can run. Do not ask for provider keys, API tokens,
-  dashboards, DNS tokens, production secrets, admin consoles, or test users
-  until a named deploy, smoke, rollback, health, callback, webhook, export, or
-  observability check cannot run without that exact item.
+- Default behavior: do not pause mid-arc only to ask for
+  `STAGING_APP_URL=<staging-origin>`. Record deployed staging as deferred, keep
+  the exact smoke command in the waiting artifact, and continue through local
+  and CI-verifiable deploy readiness.
+- Ask for `STAGING_APP_URL` only when the user explicitly requested deployed
+  staging, invokes `/god-deploy` for deployed verification, or reaches final
+  project sign-off. Do not ask for provider keys, API tokens, dashboards, DNS
+  tokens, production secrets, admin consoles, or test users until a named
+  deploy, smoke, rollback, health, callback, webhook, export, or observability
+  check cannot run without that exact item.
 - Treat a staging or production origin as known only when it appears in direct
   evidence: current user input, env/config values, deployment config, CI
   variable references, IaC output, hosting CLI output, or deployment docs that
@@ -122,6 +127,6 @@ Write `.godpowers/deploy/STATE.md`:
 - Paper canary (label without traffic split)
 - Broad provider checklist with no scripts or exact access bundle
 - Marks deploy done when the only verified target is missing
-- Requests all provider keys before the staging URL smoke check has run
+- Requests provider keys before an exact scripted check proves they are needed
 - Invents or guesses a staging or production domain
 - Treats production as staging without explicit user approval

package/agents/god-launch-strategist.md

@@ -71,7 +71,8 @@ For each channel:
   `.godpowers/observe/STATE.md`.
 - If deploy or observe is waiting on external access, do not create a broad
   dashboard checklist. Reference only the smallest next access item from the
-  waiting bundle and write launch state as `waiting-for-external-access`.
+  waiting bundle and write launch state as local-ready with deployed
+  verification deferred unless the user explicitly requested staging now.
 - If a staging or production URL is available, run or specify the exact smoke
   command and record the result.
 - If only local staging is available, run local launch-readiness checks and
@@ -85,7 +86,10 @@ For each channel:
   current. Never infer a launch URL from product name, repo name, package name,
   README title, brand name, or common TLDs.
 - If only production is known, do not treat it as staging. If no deployed
-  origin is known, pause for `STAGING_APP_URL=<deployed staging origin>`.
+  origin is known, do not pause mid-arc for the staging URL. Record deployed
+  launch verification as deferred and ask for
+  `STAGING_APP_URL=<deployed staging origin>` only when the user requests
+  staging or final project sign-off begins.
 
 ## Output
 

package/agents/god-observability-engineer.md

@@ -17,7 +17,8 @@ Wire observability.
 
 `.godpowers/deploy/STATE.md` exists. App is deployed and reachable, or deploy
 state documents a tested local staging harness plus a single external access
-bundle.
+bundle. A deferred staging URL must not block observability setup when local or
+CI-verifiable checks can still run.
 
 ## Process
 
@@ -69,7 +70,9 @@ For each PRD success metric, define an SLO:
   Prefer local definitions as code, runbook dry-runs, log-shape checks, and CI
   verification first.
 - If a credential is truly required, append one exact access item to the single
-  waiting access bundle, with the command that will run next.
+  waiting access bundle, with the command that will run next. Do not pause
+  mid-arc just to request the deployed staging origin unless the user has
+  explicitly asked to stage now.
 - Under `/god-mode --yolo`, continue through every local or CI-verifiable
   observability check before pausing for external access.
 

package/agents/god-orchestrator.md

@@ -382,6 +382,14 @@ The shipping tier must not end by listing a broad provider checklist. God Mode
 either ships, creates the automation needed to ship, or pauses on one precise
 external access bundle.
 
+Default behavior: do not pause mid-arc just to ask for a staging URL. If the
+user has not explicitly requested deployed staging verification and no live
+target URL is evidenced, complete every local and CI-verifiable shipping gate,
+write the missing deployed-origin item to
+`.godpowers/deploy/WAITING-FOR-EXTERNAL-ACCESS.md`, and continue. Ask for
+`STAGING_APP_URL` only when the user requests staging, invokes `/god-deploy`
+or `/god-launch` for deployed verification, or reaches final project sign-off.
+
 For deploy, observe, harden, and launch:
 1. Detect the target environment from deploy config, org context, env files,
    CI config, README, existing scripts, and provider CLIs.
@@ -399,29 +407,41 @@ For deploy, observe, harden, and launch:
      access bundle needed
 5. Under `--yolo`, auto-pick safe defaults for provider-neutral choices and
    continue through every local and CI-verifiable gate.
-6. Only pause when real external access is required and absent. The pause must
-   ask for the smallest next input needed to run the next concrete check. The
-   first pause should usually ask only for the deployed staging origin, for
-   example `STAGING_APP_URL=<staging-origin>`. Do not ask for API keys,
-   provider dashboards, DNS tokens, production secrets, or admin consoles until
-   a specific scripted check cannot run without that exact access.
-7. Do not say "Suggested next" for a blocked shipping tier. Say either
-   `Arc complete` or `PAUSE: external access required`, with the exact artifact
-   that lists the required bundle.
+6. If deployed verification is deferred by default, mark the shipping artifact
+   as local/CI ready and continue. Do not pause for `STAGING_APP_URL` yet.
+7. Only pause when the user explicitly requested deployed staging or final
+   sign-off requires a real deployed check. The pause must ask for the smallest
+   next input needed to run the next concrete check. The first external pause
+   should usually ask only for the deployed staging origin, for example
+   `STAGING_APP_URL=<staging-origin>`. Do not ask for API keys, provider
+   dashboards, DNS tokens, production secrets, or admin consoles until a
+   specific scripted check cannot run without that exact access.
+8. At final sign-off, if deployed verification is still deferred, present:
+   "Local and CI-verifiable closure is complete. Provide
+   `STAGING_APP_URL=<deployed staging origin>` to run deployed smoke now, say
+   `sign off local-only` to finish with deployed verification deferred, or run
+   `/god-deploy --stage` later."
+9. Do not say "Suggested next" for a blocked shipping tier. Say either
+   `Arc complete`, `Arc complete with deployed verification deferred`, or
+   `PAUSE: external access required`, with the exact artifact that lists the
+   required bundle.
 
 ### External Access Ladder
 
 Use this order when external access is missing:
 
-1. Ask for the deployed staging origin only if no live target URL is known from
-   explicit evidence.
-2. Run the real staging smoke command against that origin.
-3. Ask for a provider key, dashboard, admin console, or test user only when a
+1. If no live target URL is known from explicit evidence, defer the deployed
+   staging origin request unless the user asked to stage now or the arc has
+   reached final sign-off.
+2. When staging is requested or final sign-off begins, ask for the deployed
+   staging origin only.
+3. Run the real staging smoke command against that origin.
+4. Ask for a provider key, dashboard, admin console, or test user only when a
    named smoke, callback, webhook, export, observability, or rollback check
    fails or cannot execute without that exact item.
-4. Add at most one new access item per pause unless several items are required
+5. Add at most one new access item per pause unless several items are required
    by the same command invocation.
-5. Every access request must include the command that will run next and the
+6. Every access request must include the command that will run next and the
    artifact that will be updated after it runs.
 
 Never request every possible key or API at the start of shipping. Keys and API
@@ -441,8 +461,10 @@ evidence:
 Never invent domains from the product name, package name, repo name, README
 title, brand name, or common TLDs. Never turn `scriven` into
 `https://scriven.app`, or any similar guessed URL. If only production is known,
-do not call it staging. If only local URLs exist, run local smoke only and pause
-for `STAGING_APP_URL=<deployed staging origin>` before deployed staging smoke.
+do not call it staging. If only local URLs exist, run local smoke only, record
+deployed staging as deferred, and ask for
+`STAGING_APP_URL=<deployed staging origin>` only when staging is explicitly
+requested or final sign-off begins.
 
 ## YOLO Behavior with Design + Linkage
 
@@ -726,8 +748,8 @@ Hide:
 
 When a private rule affects a pause, translate it into the smallest
 user-facing question. Do not expose the rule itself. Example: ask for
-`STAGING_APP_URL=<deployed staging origin>` rather than showing the Shipping
-Closure Protocol.
+`STAGING_APP_URL=<deployed staging origin>` at final sign-off rather than
+showing the Shipping Closure Protocol.
 
 ## Step Narration Protocol
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "godpowers",
-  "version": "1.6.7",
+  "version": "1.6.9",
   "description": "AI-powered development system: 106 slash commands and 39 specialist agents that take a project from raw idea to hardened production. Runs inside Claude Code, Codex, Cursor, Windsurf, Gemini, and 10+ other AI coding tools.",
   "bin": {
     "godpowers": "./bin/install.js"

package/skills/god-agent-audit.md

@@ -62,6 +62,13 @@ Warnings:
 
 Infos: 90 missing-recommended-section suggestions across agents
        (run with --json for full list)
+
+Proposition:
+  1. Implement partial: fix the highest-priority error or warning
+  2. Implement complete: /god-agent-audit --fix for info-level placeholder sections only
+  3. Discuss more: /god-discuss agent contract findings
+  4. Inspect details: /god-agent-audit --json
+Recommended: [one option and why]
 ```
 
 ## Backward-compatibility promise

package/skills/god-archaeology.md

@@ -45,4 +45,11 @@ Suggested next:
   /god-reconstruct  - reverse-engineer planning artifacts from this code
   /god-tech-debt    - assess and prioritize debt revealed
   /god-feature      - now safe to add new work with archaeology in hand
+
+Proposition:
+  1. Implement partial: /god-tech-debt for only the highest-risk areas
+  2. Implement complete: /god-reconstruct then /god-audit for full brownfield alignment
+  3. Discuss more: /god-discuss the open tribal-knowledge questions
+  4. Run God Mode: /god-mode only after reconstruction or audit makes the state clear
+Recommended: /god-reconstruct when planning artifacts are missing or stale.
 ```

package/skills/god-audit.md

@@ -52,6 +52,16 @@ After god-auditor returns:
 1. Verify AUDIT-REPORT.md exists on disk
 2. Display the summary table to the user
 3. If any artifact scored below 80%: suggest re-running the failing tier
+4. End with a proposition block:
+
+```
+Proposition:
+  1. Implement partial: [rerun the single lowest-scoring tier or fix the top finding]
+  2. Implement complete: [rerun all failing tiers in priority order]
+  3. Discuss more: /god-discuss audit remediation plan
+  4. Run God Mode: /god-mode only when the audit has no blocking findings
+Recommended: [one option and why]
+```
 
 ## Output Format
 

package/skills/god-context-scan.md

@@ -89,6 +89,19 @@ Suggested next:
 2. Accept the 2 new todos: /god-check-todos
 ```
 
+## Proposition Closeout
+
+End every context scan report with a proposition block:
+
+```
+Proposition:
+  1. Implement partial: [first suggested action, usually /god-locate or /god-repair]
+  2. Implement complete: resolve all error and warn drifts, then rerun /god-context-scan
+  3. Discuss more: /god-discuss context drift
+  4. Inspect status: /god-status after re-orientation
+Recommended: [one option and why]
+```
+
 ## What this does NOT do
 
 - Does not modify state. Read-only.

package/skills/god-deploy.md

@@ -27,11 +27,12 @@ After god-deploy-engineer returns:
    - real staging or production target tested
    - local staging harness tested with equivalent health, smoke, and rollback
      commands
-   - paused on `.godpowers/deploy/WAITING-FOR-EXTERNAL-ACCESS.md` with one
-     exact missing access bundle
-4. Update `.godpowers/PROGRESS.md`: Deploy status = done only for a tested real
-   target or tested local staging harness. If external access is missing, mark
-   Deploy = waiting-for-external-access, not done.
+   - local/CI deploy readiness complete with deployed staging verification
+     deferred in `.godpowers/deploy/WAITING-FOR-EXTERNAL-ACCESS.md`
+4. Update `.godpowers/PROGRESS.md`: Deploy status can be done when a tested
+   real target or tested local staging harness exists. If deployed staging is
+   deferred, annotate Deploy as done-local with the waiting artifact path and
+   do not pause unless the user explicitly requested staging.
 
 ## On Completion
 
@@ -44,11 +45,14 @@ Suggested next: /god-observe (wire SLOs, alerts, runbooks)
 Under `/god-mode --yolo`, do not stop with a provider checklist. Create or
 update the deploy scripts, smoke command, rollback command, health endpoints,
 env manifest, and local staging harness first. If real external access is still
-required, pause on the single access bundle in
-`.godpowers/deploy/WAITING-FOR-EXTERNAL-ACCESS.md`.
-
-The single access bundle must be incremental. Ask for the smallest next item
-needed to run the next command. If no live target URL is known, ask only for
+required, record the single access bundle in
+`.godpowers/deploy/WAITING-FOR-EXTERNAL-ACCESS.md` and continue until the user
+requests staging or final sign-off begins.
+
+The single access bundle must be incremental. Do not ask for
+`STAGING_APP_URL` mid-arc unless the user requested deployed staging. At final
+sign-off or explicit staging, ask for the smallest next item needed to run the
+next command. If no live target URL is known, ask only for
 `STAGING_APP_URL=<staging-origin>` and the exact smoke command that will run.
 Do not ask for provider keys, API tokens, dashboards, DNS tokens, production
 secrets, admin consoles, or test users until a specific scripted check proves
@@ -59,8 +63,8 @@ values, deployment config, CI variable references, IaC output, hosting CLI
 output, or deployment docs that explicitly label the URL as owned and current.
 Never invent a domain from the product name, repo name, package name, README
 title, brand name, or common TLDs. If only local URLs exist, run local smoke
-only and pause for `STAGING_APP_URL=<deployed staging origin>`. If only
-production is known, do not use it as staging without explicit user approval.
+only, record deployed staging as deferred, and continue. If only production is
+known, do not use it as staging without explicit user approval.
 
 
 ## Re-invocation contract

package/skills/god-design-impact.md

@@ -65,6 +65,14 @@ Transitive (depth 2):
 
 Recommendation: Run /god-design with this change to apply.
 god-design-reviewer will gate via two-stage review.
+
+Proposition:
+  1. Implement partial: /god-design for only the lowest-risk token or component change
+  2. Implement complete: /god-design with the full proposed change
+  3. Discuss more: /god-discuss the design tradeoff before changing files
+  4. Run God Mode: /god-mode only if this design change is part of a wider arc
+Recommended: apply the smallest design change first when severity is warning
+or higher.
 ```
 
 ## When this skill helps

package/skills/god-discuss.md

@@ -67,4 +67,11 @@ Key findings:
   - [term or ambiguity resolved]
 
 Suggested next: [the planning command this discussion was for]
+
+Proposition:
+  1. Implement partial: [smallest safe slice or planning command]
+  2. Implement complete: [full command that consumes this brief]
+  3. Discuss more: /god-discuss [specific unresolved question]
+  4. Run God Mode: /god-mode [scope] if the user wants autonomous execution
+Recommended: [one option and why]
 ```

package/skills/god-doctor.md

@@ -65,6 +65,23 @@ Suggested next steps:
   2. /god-restore  (review trash)
 ```
 
+## Proposition Closeout
+
+End every human-readable doctor report with a proposition block:
+
+```
+Proposition:
+  1. Implement partial: [safest single fix or diagnostic follow-up]
+  2. Implement complete: /god-doctor --fix when all proposed fixes are safe categories
+  3. Discuss more: /god-discuss [highest-risk warning or unclear repair]
+  4. Inspect status: /god-status after repair
+Recommended: [one option and why it is safe]
+```
+
+If the report contains errors that need manual repair, do not recommend
+`/god-doctor --fix` as complete. Recommend the highest-priority manual repair
+or `/god-repair` instead.
+
 ## Subcommands
 
 ### `/god-doctor`

package/skills/god-explore.md

@@ -47,4 +47,12 @@ Idea explored. Suggested framing:
 
 Suggested next: /god-init (commit to this framing) or /god-explore again
                 (if you want to try another angle)
+
+Proposition:
+  1. Implement partial: /god-init with this framing and stop after PRD
+  2. Implement complete: /god-mode with this framing for the full arc
+  3. Discuss more: /god-explore again with the weakest assumption
+  4. Run God Mode: /god-mode if the user is ready to build now
+Recommended: /god-init when the framing feels stable enough to turn into
+requirements.
 ```

package/skills/god-hygiene.md

@@ -93,6 +93,13 @@ Suggested next actions (in priority order):
   3. [next]
 
 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]
 ```
 
 ## Have-Nots

package/skills/god-launch.md

@@ -52,12 +52,15 @@ Or: /god-status (see the final state)
 Under `/god-mode --yolo`, do not stop by listing provider dashboards. Create
 the launch runbook, smoke command, source attribution plan, and local
 launch-readiness checks. If real launch is blocked by missing external access,
-pause on the single access bundle from deploy or launch state.
+record the single access bundle from deploy or launch state and continue until
+the user requests staging or final sign-off begins.
 
 The launch pause must not expand into every possible channel, analytics, or
 provider credential. Ask only for the next missing access item needed to run a
-named live smoke, launch-readiness, attribution, or monitoring check. If no
-live target URL is known, ask only for `STAGING_APP_URL=<staging-origin>`.
+named live smoke, launch-readiness, attribution, or monitoring check. Do not
+ask mid-arc for `STAGING_APP_URL` unless the user requested deployed staging.
+At final sign-off, if no live target URL is known, ask only for
+`STAGING_APP_URL=<staging-origin>`.
 
 Live target URLs must be evidence-backed. Never invent a domain from the
 product name, repo name, package name, README title, brand name, or common TLDs.

package/skills/god-lifecycle.md

@@ -111,6 +111,31 @@ Suggested next: /god-spike with narrower question
 Or: archive the spike if no longer relevant
 ```
 
+## Proposition Closeout
+
+Every lifecycle report must end with a proposition 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 arc
+  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]
+```
+
+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.
+```
+
 ## Have-Nots
 
 Lifecycle check FAILS if:

package/skills/god-list-assumptions.md

@@ -48,6 +48,19 @@ Assumptions Claude is operating under:
 Any of these wrong? Flag them now before they cement into decisions.
 ```
 
+## Proposition Closeout
+
+After listing assumptions, end with a proposition 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]
+```
+
 ## Have-Nots
 
 - Assumptions are too vague to verify ("we're building a good product")

package/skills/god-locate.md

@@ -73,6 +73,22 @@ Drift check:
 - If gap > 1 hour, run /god-context-scan
 ```
 
+## Proposition Closeout
+
+The orientation summary must end with a compact proposition block:
+
+```
+Proposition:
+  1. Implement partial: [next suggested command]
+  2. Implement complete: /god-mode to continue the arc 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]
+```
+
+If drift is flagged, recommend `/god-context-scan` or `/god-repair` before
+continuing work.
+
 ## Process
 
 1. If `.godpowers/` does not exist: report "no Godpowers project here"

package/skills/god-map-codebase.md

@@ -42,4 +42,12 @@ Codebase mapped.
   + .godpowers/codebase/concerns.md
 
 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
+are missing.
 ```

package/skills/god-mode.md

@@ -94,18 +94,20 @@ You are receiving a /god-mode invocation. Your job is to spawn the
        security or a genuine human-only decision.
      - Instruction that deploy, observe, harden, and launch must follow the
        Shipping Closure Protocol: verify a real environment when available,
-       otherwise create local/CI-verifiable deploy automation and pause only
-       for one exact external access bundle.
+       otherwise create local/CI-verifiable deploy automation, defer deployed
+       staging by default, and continue until the user requests staging or the
+       arc reaches final sign-off.
      - Instruction that keys, API tokens, dashboards, admin consoles, and
-       provider-specific access are last-mile inputs. The first external pause
-       should ask only for the smallest next item needed by a concrete command,
-       usually `STAGING_APP_URL=<staging-origin>`. Ask for additional provider
-       access only after a named check proves it is needed.
+       provider-specific access are last-mile inputs. Do not pause mid-arc for
+       `STAGING_APP_URL` unless the user requested deployed staging. At final
+       sign-off, ask only for the smallest next item needed by a concrete
+       command, usually `STAGING_APP_URL=<staging-origin>`. Ask for additional
+       provider access only after a named check proves it is needed.
      - Instruction that staging, preview, and production URLs must come from
        direct evidence. Never infer or invent a domain from project name,
        package name, repo name, README title, or brand name. If no deployed
-       origin is evidenced, pause for
-       `STAGING_APP_URL=<deployed staging origin>`.
+       origin is evidenced, record deployed staging as deferred and continue
+       until staging is requested or final sign-off begins.
      - Instruction that brownfield and bluefield greenfield simulation audits
        must be acted on by god-greenfieldifier. The greenfieldifier writes
        `.godpowers/audit/GREENFIELDIFY-PLAN.md`, pauses before risky canonical
@@ -181,8 +183,8 @@ Hide:
 
 If an internal instruction must influence a pause, translate it into the
 smallest user-facing question. For example, ask for
-`STAGING_APP_URL=<deployed staging origin>` instead of exposing the full
-Shipping Closure Protocol.
+`STAGING_APP_URL=<deployed staging origin>` at final sign-off instead of
+exposing the full Shipping Closure Protocol.
 
 ## Step Cards
 

package/skills/god-next.md

@@ -312,3 +312,21 @@ Previous tier had standards failures. Address before proceeding:
   - [failure 2]
 Suggested: /god-redo [tier] OR /god-skip [tier] --reason="..."
 ```
+
+## Proposition Closeout
+
+Every `/god-next` response must end with a proposition block unless it already
+launched the selected command:
+
+```
+Proposition:
+  1. Implement partial: [single suggested command]
+  2. Implement complete: [recipe sequence or /god-mode when safe]
+  3. Discuss more: /god-discuss [routing ambiguity or missing prerequisite]
+  4. Inspect status: /god-status or /god-locate
+Recommended: [one option and why]
+```
+
+For missing prerequisites, the partial option is the auto-completable
+prerequisite. For standards failures, the partial option is `/god-redo` with
+feedback and the complete option is blocked until the gate passes.

package/skills/god-preflight.md

@@ -137,6 +137,20 @@ 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
+
+End the user-facing response with a proposition 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 arc-ready or the remaining gaps are acceptable
+Recommended: [first command and why it should happen before the rest]
+```
+
 ## Guardrails
 
 - Build nothing.

package/skills/god-reconcile.md

@@ -74,7 +74,12 @@ Recommended sequence:
   Main work:  [/god-feature scoped to Milestone 2]
   Post-work:  [/god-sync]
 
-Run? (yes / show alternatives / cancel)
+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]
 ```
 
 ## Difference from /god-roadmap-check

package/skills/god-reconstruct.md

@@ -58,6 +58,14 @@ Suggested next:
   /god-audit       - score the reconstructed artifacts
   /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.
 ```
 
 ## Caveats

package/skills/god-refactor.md

@@ -88,6 +88,29 @@ Behavior: unchanged
 Suggested next: /god-status or continue with /god-feature
 ```
 
+## Proposal Mode
+
+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
+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 arc
+Recommended: <one option and why>
+```
+
+For performance refactors, prefer partial implementation when measurement is
+missing. Example:
+`Implement partial: /god-spike startup timeline to measure load phases before
+refactoring.`
+
 ## Have-Nots
 
 Refactor FAILS if:

package/skills/god-roadmap-check.md

@@ -57,6 +57,16 @@ After god-roadmap-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:
+
+```
+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]
+```
 
 ## When called manually
 

package/skills/god-spike.md

@@ -84,6 +84,13 @@ Suggested next:
   - If rejecting: archive .godpowers/spikes/<question-slug>/
   - If unclear: /god-spike with narrower question
 
+Proposition:
+  1. Implement partial: /god-feature for the smallest proven slice
+  2. Implement complete: /god-feature with the full recommendation
+  3. Discuss more: /god-discuss the remaining uncertainty
+  4. Run God Mode: /god-mode only if this spike unblocks the full arc
+Recommended: proceed only when SPIKE.md has a clear DECISION and evidence.
+
 REMINDER: spike code is throwaway. Do NOT merge to main.
 ```
 

package/skills/god-standards.md

@@ -54,6 +54,13 @@ Verdict: PARTIAL (87%)
 Suggested next:
   /god-redo prd to address failures with feedback
   /god-skip prd --reason "..." to accept-as-is
+
+Proposition:
+  1. Implement partial: /god-redo [tier] with the listed failures
+  2. Implement complete: fix all failures, rerun /god-standards, then continue the gate
+  3. Discuss more: /god-discuss standards failure
+  4. Skip: /god-skip [tier] --reason "..." only with an explicit reason
+Recommended: [one option and why]
 ```
 
 ## Auto-invocation

package/skills/god-status.md

@@ -92,6 +92,23 @@ Suite (Mode D) status:
 Next: god roadmap
 ```
 
+## Proposition Closeout
+
+Every status report must end with a proposition block so the user can choose
+how much momentum to give Godpowers:
+
+```
+Proposition:
+  1. Implement partial: [single next command from "What happens next"]
+  2. Implement complete: /god-mode to continue the current arc when no blockers are present
+  3. Discuss more: /god-discuss [unclear state, blocker, or inconsistency]
+  4. Inspect status: /god-locate or /god-next for a smaller routing view
+Recommended: [one option and why it fits the disk-derived state]
+```
+
+If inconsistencies are present, make `/god-repair` the partial option and do
+not recommend `/god-mode` until disk state is coherent.
+
 ## Mode D awareness
 
 If `lib/multi-repo-detector.detect(projectRoot)` returns

package/skills/god-tech-debt.md

@@ -53,4 +53,12 @@ Suggested next:
   - /god-update-deps if dependency debt is a P0/P1 driver
   - /god-upgrade for major-version migrations
   - Re-run /god-tech-debt quarterly
+
+Proposition:
+  1. Implement partial: run the command for the top P0 item only
+  2. Implement complete: /god-feature or /god-refactor for the full P0 bundle
+  3. Discuss more: /god-discuss the highest-cost or highest-risk debt item
+  4. Run God Mode: /god-mode only if debt work should join the full arc
+Recommended: start with the top P0 item, then re-run /god-tech-debt after it
+lands.
 ```

package/skills/god.md

@@ -112,6 +112,22 @@ Recipes that fit your current state:
 Run structural next? (yes / pick recipe / cancel)
 ```
 
+If the answer is exploratory and proposes an approach instead of selecting or
+running a command, close with:
+
+```
+Proposition:
+  1. Implement partial: <smallest safe command or slice>
+  2. Implement complete: <full command sequence>
+  3. Discuss more: /god-discuss <topic or unresolved question>
+  4. Run God Mode: /god-mode <scope> if the user wants the full autonomous arc
+Recommended: <one option and why>
+```
+
+Do not include a God Mode option when the request is clearly a tiny fix,
+single-file change, or narrow question. In that case, replace it with the
+smallest matching command, such as `/god-fast`, `/god-spike`, or `/god-next`.
+
 ### Step 4: execute or hand off
 
 If user confirms a recipe: