godpowers 1.6.4 → 1.6.6

package/CHANGELOG.md

@@ -5,6 +5,60 @@ 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.6] - 2026-05-16
+
+Non-God-Mode handoff privacy patch. Extends the display-safe handoff pattern
+from `/god-mode` to other orchestrator entrypoints.
+
+### Added
+- Added private handoff guidance for `/god-init` before it spawns
+  `god-orchestrator`.
+- Added private handoff guidance for `/god-suite-init`,
+  `/god-suite-release`, and `/god-suite-patch` before they spawn
+  `god-coordinator`.
+- Added `god-coordinator` guidance for display-safe per-repo
+  `god-orchestrator` spawns.
+- Added regression coverage for non-`/god-mode` handoff entrypoints.
+
+### Changed
+- `god-orchestrator` now documents handoff files from `/god-init`,
+  `god-coordinator`, or any other caller, not only `/god-mode`.
+- `/god-hygiene` routing no longer lists `god-orchestrator` as a secondary
+  spawn because the skill only runs the three hygiene audits.
+
+### Guardrails
+- This patch does not add slash commands, agents, workflows, recipes, schemas,
+  or public artifact formats.
+- The handoff change affects transcript hygiene only. It does not weaken
+  release-truth gates or per-repo Quarterback ownership.
+
+## [1.6.5] - 2026-05-16
+
+God Mode handoff privacy patch. Keeps the 1.6 command surface stable while
+making Codex-spawned `god-orchestrator` runs display a small safe pointer
+instead of detailed orchestration payloads.
+
+### Added
+- Added a private `.godpowers/runs/<run-id>/ORCHESTRATOR-HANDOFF.md` handoff
+  pattern for `/god-mode` orchestration context.
+- Added `god-orchestrator` instructions to read handoff files before planning
+  or mutation and keep handoff contents out of the visible transcript.
+- Added regression coverage proving agent validation ignores non-specialist
+  Pillars files under `agents/`.
+
+### Changed
+- `/god-mode` now spawns `god-orchestrator` with only a display-safe project
+  root, flags, and handoff file path.
+- Agent validation and smoke tests now inspect `agents/god-*.md` specialist
+  files while allowing Pillars context files like `agents/context.md` and
+  `agents/repo.md` to coexist.
+
+### Guardrails
+- This patch does not add slash commands, agents, workflows, recipes, schemas,
+  or public artifact formats.
+- `--yolo` still respects safe-sync and Critical harden blockers. The handoff
+  change affects transcript hygiene, not gate policy.
+
 ## [1.6.4] - 2026-05-16
 
 Release gate propagation patch. Keeps the 1.6 command surface stable while

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.4-blue)](CHANGELOG.md)
+[![Version](https://img.shields.io/badge/version-1.6.6-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,11 @@ 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.4 hardens Godpowers routing around release truth: safe-sync
-blockers and unresolved Critical harden findings now gate direct Tier 3
-commands, `/god-mode`, and `/god-mode --yolo`, while Codex installs keep
-per-agent TOML metadata for all 39 specialist agents.
+Version 1.6.6 keeps the stable Godpowers surface while making more Codex
+orchestrator spawns transcript-safe: `/god-mode`, `/god-init`, and Mode D
+suite coordinator paths now use private handoff files with small display-safe
+pointers. Safe-sync and unresolved Critical harden findings still gate direct
+Tier 3 commands, `/god-mode`, and `/god-mode --yolo`.
 
 It fuses four disciplines into one unified workflow:
 

package/RELEASE.md

@@ -1,11 +1,11 @@
-# Godpowers 1.6.4 Release
+# Godpowers 1.6.6 Release
 
 Date: 2026-05-16
 
-Godpowers 1.6.4 hardens release-truth routing around the stable 1.6 surface.
-The goal of this patch is to make safe sync and unresolved Critical harden
-findings block direct Tier 3 commands, `/god-mode`, and `/god-mode --yolo`,
-without changing the public command surface.
+Godpowers 1.6.6 extends transcript-safe spawn handling beyond `/god-mode`.
+The goal of this patch is to keep Codex-visible spawn messages small and safe
+for `/god-init` and Mode D suite coordination while preserving the same
+orchestrator and coordinator behavior.
 
 ## What is stable
 
@@ -27,33 +27,40 @@ without changing the public command surface.
 
 ## What is new
 
-- `/god-next` detects `.godpowers/sync/SAFE-SYNC-PLAN.md` and routes to
-  `/god-reconcile Release Truth And Safe Sync` before `/god-deploy`.
-- Direct `/god-observe`, `/god-harden`, `/god-launch`, and `/god-mode`
-  invocations also require `safe-sync-clear`.
-- `/god-launch` now executes the `no-critical-findings` prerequisite instead
-  of treating it as an unknown pass-through check.
-- `god-orchestrator` now checks router prerequisites before command dispatch,
-  including under `--yolo`.
-- Router tests cover unresolved safe sync plans, checkpoint blockers, direct
-  Tier 3 gates, `/god-mode`, unresolved Critical findings, and resolved gates.
-
-## What 1.6.4 means
-
-Godpowers 1.6.4 does not expand the public command surface. It tightens the
-runtime decision path so project truth can override structural tier order for
-safe sync and harden Critical gates.
-
-The domain glossary remains preparation context. PRD, ARCH, ROADMAP, STACK,
-docs, and Pillars files still carry durable decisions for their own domains.
+- `/god-init` now writes detailed initialization context to
+  `.godpowers/runs/<run-id>/INIT-ORCHESTRATOR-HANDOFF.md` before spawning
+  `god-orchestrator`.
+- `/god-suite-init`, `/god-suite-release`, and `/god-suite-patch` now write
+  suite coordination context to
+  `.godpowers/runs/<run-id>/COORDINATOR-HANDOFF.md` before spawning
+  `god-coordinator`.
+- `god-coordinator` now writes per-repo orchestrator context to
+  `.godpowers/runs/<run-id>/COORDINATOR-ORCHESTRATOR-HANDOFF.md` before
+  spawning a target repo's `god-orchestrator`.
+- `god-orchestrator` now treats handoff files as a general caller protocol,
+  not only as a `/god-mode` protocol.
+- `/god-hygiene` routing no longer lists `god-orchestrator` as a secondary
+  spawn because the skill only runs artifact, dependency, and documentation
+  audits.
+
+## What 1.6.6 means
+
+Godpowers 1.6.6 does not expand the public command surface. It fixes more
+Codex spawn integration paths so the right agent is still started, but the host
+UI only sees a small pointer to disk state instead of raw project description,
+suite metadata, release notes, patch directives, dependency graphs, routing
+rules, or local-file details.
+
+Safe sync and unresolved Critical harden findings remain release-truth gates.
+Per-repo Quarterback ownership remains intact for Mode D suite work.
 
 ## Stability policy
 
 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.4` git tag points to the release commit that matches the npm
-`godpowers@1.6.4` package. Public publishes should prefer the tag-triggered
+The `v1.6.6` git tag points to the release commit that matches the npm
+`godpowers@1.6.6` package. Public publishes should prefer the tag-triggered
 GitHub workflow so npm provenance, git history, and release notes stay aligned.
 
 Allowed changes:

package/agents/god-coordinator.md

@@ -44,6 +44,20 @@ suite (the collection of repos), not individual repos.
 - Per-repo `state.json` files
 - Optionally: a specific operation (sync, release, patch, status)
 
+## Coordinator Handoff
+
+When spawned by a suite command, the visible spawn message may include only a
+display-safe operation summary plus a path like
+`.godpowers/runs/<run-id>/COORDINATOR-HANDOFF.md`.
+
+If a handoff path is provided:
+1. Read the handoff file before planning, spawning, or mutating suite state.
+2. Treat the handoff as private suite coordination context.
+3. Do not quote, summarize, or expose the full handoff in the visible
+   transcript.
+4. If the handoff conflicts with durable suite artifacts, prefer disk
+   artifacts and record the conflict as an open question or repair target.
+
 ## Process per operation
 
 ### Mode 1: status (`/god-suite-status`)
@@ -66,7 +80,8 @@ suite (the collection of repos), not individual repos.
 
 1. User provides repo + new version
 2. Run impact analysis: which sibling repos depend on this one?
-3. For each affected sibling: spawn its `god-orchestrator` with a
+3. For each affected sibling: write a per-repo orchestrator handoff file and
+   spawn its `god-orchestrator` with only a display-safe pointer for the
    `version-bump` directive (NOT a full arc)
 4. Aggregate results into a release report
 5. Update `.godpowers/suite-config.yaml` version-table
@@ -75,8 +90,9 @@ suite (the collection of repos), not individual repos.
 ### Mode 4: patch (`/god-suite-patch`)
 
 1. User describes a change that touches multiple repos
-2. For each repo in scope: spawn its `god-orchestrator` with the
-   patch description
+2. For each repo in scope: write a per-repo orchestrator handoff file and
+   spawn its `god-orchestrator` with only a display-safe pointer for the
+   patch directive
 3. Coordinate atomicity: if any repo fails, mark the suite-level
    patch as incomplete and report
 4. Append to SYNC-LOG.md
@@ -117,8 +133,25 @@ For each operation, return to the spawning skill with:
 ## Coordination with per-repo orchestrators
 
 When you need work done IN a repo (version bump, patch slice, etc.),
-spawn that repo's `god-orchestrator` via the Task tool with the
-specific directive. Do not bypass it. The Quarterback rule:
+create a private handoff in that repo first, then spawn that repo's
+`god-orchestrator` via the Task tool with only a display-safe pointer.
+
+Per-repo handoff path:
+`.godpowers/runs/<run-id>/COORDINATOR-ORCHESTRATOR-HANDOFF.md`
+
+Put the version-bump directive, patch directive, suite impact analysis,
+affected dependency facts, release notes, and repo-specific notes in the
+handoff file. The visible spawn message may include only:
+- The target repo root
+- The suite operation name
+- The handoff file path
+- "Read the handoff file first, then run the requested scoped work from disk
+  state. Return only user-facing progress and final status."
+
+Do not put suite metadata, dependency graphs, local file lists, release notes,
+patch descriptions, hidden routing rules, or detailed instructions in the
+visible spawn message. Do not bypass the target repo orchestrator. The
+Quarterback rule:
 
 > Each repo has exactly one orchestrator. The coordinator is a peer
 > at suite scope, not a higher-tier overseer.

package/agents/god-orchestrator.md

@@ -21,6 +21,25 @@ You orchestrate the full Godpowers arc. You DO NOT do the heavy lifting yourself
 Your job is to spawn the right specialist agent for each sub-step, verify their
 output passes the gate, update PROGRESS.md, and move to the next step.
 
+## Orchestrator Handoff
+
+When spawned by `/god-mode`, `/god-init`, `god-coordinator`, or any other
+caller, the visible spawn message may include only a display-safe summary plus
+a path like
+`.godpowers/runs/<run-id>/ORCHESTRATOR-HANDOFF.md`.
+
+If a handoff path is provided:
+1. Read the handoff file before any planning, spawning, or state mutation.
+2. Treat the handoff as private orchestration context and disk evidence.
+3. Do not quote, summarize, or expose the full handoff in the user-visible
+   transcript.
+4. If the handoff conflicts with durable artifacts, prefer disk artifacts and
+   record the conflict as an open question or repair target.
+
+If no handoff path is provided, recover from durable disk state. Do not ask the
+user to restate the project when `.godpowers` artifacts, Pillars files, or
+repository evidence identify the work.
+
 ## Quarterback responsibilities (Tier 0 ownership)
 
 You and only you are responsible for:

package/lib/agent-validator.js

@@ -230,14 +230,18 @@ function crossValidate(agents, opts = {}) {
 }
 
 /**
- * Walk agents/ and audit all.
+ * Walk agents/ and audit all shipped specialist agents.
+ *
+ * Godpowers projects may also have Pillars files under agents/ (for example
+ * agents/context.md and agents/repo.md). Those are project context, not
+ * specialist agent specs, so they are intentionally excluded here.
  */
 function auditAll(projectRoot, opts = {}) {
   const agentsDir = path.join(projectRoot, 'agents');
   if (!fs.existsSync(agentsDir)) {
     return { results: [], summary: { errors: 0, warnings: 0, infos: 0 } };
   }
-  const files = fs.readdirSync(agentsDir).filter(f => f.endsWith('.md'));
+  const files = fs.readdirSync(agentsDir).filter(f => /^god-.*\.md$/.test(f));
   const agents = files.map(f => parseAgentFile(path.join(agentsDir, f)));
 
   const allFindings = [];

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "godpowers",
-  "version": "1.6.4",
+  "version": "1.6.6",
   "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/routing/god-hygiene.yaml

@@ -12,7 +12,7 @@ prerequisites:
 execution:
   spawns: [god-auditor]
   context: fresh
-  secondary-spawns: [god-deps-auditor, god-docs-writer, god-orchestrator]
+  secondary-spawns: [god-deps-auditor, god-docs-writer]
   writes:
     - .godpowers/HYGIENE-REPORT.md
 

package/skills/god-doctor.md

@@ -48,7 +48,7 @@ GODPOWERS DOCTOR
 Install: claude (~/.claude/)
   [OK] 106 skills installed
   [OK] 39 agents installed
-  [OK] VERSION matches (1.6.4)
+  [OK] VERSION matches (1.6.6)
   [WARN] routing/god-doctor.yaml exists but skill file did not until now
 
 Project: /Users/.../my-project/.godpowers/

package/skills/god-init.md

@@ -81,10 +81,27 @@ needs to specify a mode.
    - Code present + org context: "Detected: existing codebase + org standards.
      I'll archaeology, reconstruct, and respect your org's standards."
 
-4. Ask the user to describe what they want to build. Accept any format.
-
-5. Spawn **god-orchestrator** in fresh context with the user's description and
-   the detected mode/context.
+5. Ask the user to describe what they want to build. Accept any format.
+
+6. Create a private disk handoff before spawning the orchestrator:
+   - Path: `.godpowers/runs/<run-id>/INIT-ORCHESTRATOR-HANDOFF.md`
+   - Create parent directories if needed.
+   - Put the user's description, detected mode, detected context, initial
+     findings summary, imported context summary, Pillars status, and next-step
+     routing notes in this file.
+
+7. Spawn **god-orchestrator** in fresh context with only a display-safe
+   payload:
+   - Name the project root.
+   - Name the invocation as `/god-init`.
+   - Name the handoff file path.
+   - Say: "Read the handoff file first, then initialize or resume from disk
+     state. Return only user-facing progress and final status."
+
+   Do not put recovered planning context, local file lists, org standards,
+   imported planning-system summaries, hidden routing rules, or detailed
+   instructions in the visible spawn message. Assume the host UI may display
+   the raw spawn message to the user.
 
    The orchestrator will:
    - Run Mode Detection (announced in plain English; stored as A/B/C/E internally)
@@ -100,14 +117,14 @@ needs to specify a mode.
    - Write PROGRESS.md with mode, scale, timestamp, tier states
    - Return mode/scale/announcement to this skill
 
-4. Detect scale by analyzing the description:
+8. Detect scale by analyzing the description:
    - **Trivial**: Single file change, bug fix, config tweak
    - **Small**: One feature, one service, <1 week
    - **Medium**: Multiple features, 1-3 services, 1-4 weeks
    - **Large**: Multiple services, team coordination, 1-3 months
    - **Enterprise**: Multiple teams, compliance, 3+ months
 
-5. Create the directory structure:
+9. Create the directory structure:
    ```
    AGENTS.md
    agents/
@@ -140,9 +157,9 @@ needs to specify a mode.
      harden/
    ```
 
-6. Write PROGRESS.md with mode, scale, timestamp, all tiers set to `pending`
+10. Write PROGRESS.md with mode, scale, timestamp, all tiers set to `pending`
 
-7. Report to the user:
+11. Report to the user:
    - Detected mode and scale
    - Which tiers and personas will activate
    - What to run next (suggest `god prd` or `god mode`)

package/skills/god-mode.md

@@ -69,75 +69,94 @@ You are receiving a /god-mode invocation. Your job is to spawn the
    - `--bluefield` (force bluefield path)
    - `--greenfield` (force greenfield, skip archaeology even if code exists)
 
-5. Spawn the **god-orchestrator** agent via Task tool with:
-   - The user's project description, or durable intent recovered from disk
-   - 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/prep/INITIAL-FINDINGS.md` and
-     `.godpowers/prep/IMPORTED-CONTEXT.md` if present before choosing the
-     first planning or build step
-   - Instruction to read `.godpowers/preflight/PREFLIGHT.md` if present before
-     choosing the first brownfield or bluefield action
-   - Instruction to compute and load the Pillars load set before every major
-     command, because Pillars is the native project context layer
-   - Instruction to run `/god-design` after `/god-prd` and before `/god-arch`
-     when initial findings, imported planning context, the PRD, or the
-     codebase show UI or product-experience signals
-   - Instruction that a red test, typecheck, lint, build, or check command is
-     not a completed arc. It must enter the autonomous repair loop and continue
-     the same `/god-mode` run until green, except for Critical 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.
-   - 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.
-   - 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>`.
-   - 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
-     artifact rewrites, and updates every affected artifact after approval.
-   - Instruction that brownfield and bluefield arcs run `/god-preflight`
-     automatically when `.godpowers/preflight/PREFLIGHT.md` is absent.
-     Greenfield arcs skip preflight unless the user explicitly requests it.
-   - Instruction to run routing prerequisites through `lib/router.js`
-     `checkPrerequisites` before every direct command dispatch. If
-     `safe-sync-clear` fails, run
-     `/god-reconcile Release Truth And Safe Sync` before deploy, observe,
-     harden, launch, broad migration, or resume work.
-   - Instruction that `--yolo` cannot bypass safe sync blockers or unresolved
-     Critical harden findings. These are release-truth gates, not preference
-     pauses.
-
-6. Keep the spawn payload private. Do not echo or summarize raw Task input,
+5. Create a private disk handoff before spawning the orchestrator:
+   - Path: `.godpowers/runs/<run-id>/ORCHESTRATOR-HANDOFF.md`
+   - Create parent directories if needed.
+   - Put all detailed orchestration context in this file, including:
+     - The user's project description, or durable intent recovered from disk
+     - 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/prep/INITIAL-FINDINGS.md` and
+       `.godpowers/prep/IMPORTED-CONTEXT.md` if present before choosing the
+       first planning or build step
+     - Instruction to read `.godpowers/preflight/PREFLIGHT.md` if present
+       before choosing the first brownfield or bluefield action
+     - Instruction to compute and load the Pillars load set before every major
+       command, because Pillars is the native project context layer
+     - Instruction to run `/god-design` after `/god-prd` and before
+       `/god-arch` when initial findings, imported planning context, the PRD,
+       or the codebase show UI or product-experience signals
+     - Instruction that a red test, typecheck, lint, build, or check command
+       is not a completed arc. It must enter the autonomous repair loop and
+       continue the same `/god-mode` run until green, except for Critical
+       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.
+     - 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.
+     - 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>`.
+     - 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
+       artifact rewrites, and updates every affected artifact after approval.
+     - Instruction that brownfield and bluefield arcs run `/god-preflight`
+       automatically when `.godpowers/preflight/PREFLIGHT.md` is absent.
+       Greenfield arcs skip preflight unless the user explicitly requests it.
+     - Instruction to run routing prerequisites through `lib/router.js`
+       `checkPrerequisites` before every direct command dispatch. If
+       `safe-sync-clear` fails, run
+       `/god-reconcile Release Truth And Safe Sync` before deploy, observe,
+       harden, launch, broad migration, or resume work.
+     - Instruction that `--yolo` cannot bypass safe sync blockers or
+       unresolved Critical harden findings. These are release-truth gates, not
+       preference pauses.
+
+6. Spawn the **god-orchestrator** agent via Task tool with only a
+   display-safe payload:
+   - Name the project root.
+   - Name the invocation flags.
+   - Name the handoff file path.
+   - Say: "Read the handoff file first, then run the autonomous arc from disk
+     state. Return only user-facing progress and final status."
+
+   Do not put recovered checkpoint facts, safe-sync plans, local file lists,
+   hidden routing rules, or detailed instructions in the spawn message.
+   Assume the host UI may display the raw spawn message to the user.
+
+7. Keep the spawn payload display-safe. Do not echo or summarize raw Task input,
    "Hard instructions", hidden orchestration rules, agent prompts, file
    loadout lists, or internal routing payloads into the user-visible transcript.
    The visible transcript may say only what phase is running, what durable state
    was detected, what commands are running, what changed, and the final
    `Arc complete` or `PAUSE: external access required` block.
 
-7. Orchestrator runs the appropriate workflow:
+8. Orchestrator runs the appropriate workflow:
    - Greenfield -> full-arc
    - Brownfield -> brownfield-arc (preflight -> archaeology -> reconstruct -> debt-assess -> greenfield simulation audit -> greenfieldify plan and approved artifact updates -> proceed)
    - Bluefield -> bluefield-arc (org-context -> preflight -> greenfield simulation audit -> greenfieldify plan and approved artifact updates -> arc with constraints)
 
-8. Relay only the orchestrator's user-facing output to the user. If the
-   platform displays raw spawn details automatically, immediately follow with a
-   clean public summary and never repeat the leaked payload.
+9. Relay only the orchestrator's user-facing output to the user. If the
+   platform displays raw spawn details automatically, the displayed payload
+   should already be safe. Immediately follow with a clean public summary and
+   never repeat detailed handoff contents.
 
-9. When the orchestrator pauses, present the question to the user using the
+10. When the orchestrator pauses, present the question to the user using the
    pause format (What / Why / Options / Default).
 
-10. When the user answers, re-spawn god-orchestrator with the answer.
+11. When the user answers, append the answer to the existing handoff file or
+    create a new handoff file, then re-spawn god-orchestrator with only the
+    display-safe pointer.
 
 ## User-Visible Transcript Contract
 
@@ -153,6 +172,7 @@ Hide:
 - raw Task input
 - "Hard instructions" sections
 - spawned-agent prompt text
+- detailed handoff file contents
 - system, developer, or AGENTS.md rule recitations
 - complete file loadout lists
 - internal routing metadata unless it directly affects a user decision

package/skills/god-suite-init.md

@@ -32,12 +32,23 @@ are listed manually; godpowers does NOT auto-walk parent dirs.
    - Byte-identical files to track (one per line; e.g., LICENSE, .editorconfig)
    - Version-table entries (optional; can be added later)
    - Shared standards (node-version, linter; optional)
-3. Spawn `god-coordinator` agent in `init` mode with collected inputs.
-4. god-coordinator writes `.godpowers/suite-config.yaml` and updates
+3. Create `.godpowers/runs/<run-id>/COORDINATOR-HANDOFF.md` with the
+   collected suite name, sibling paths, byte-identical files, version-table
+   entries, shared standards, and init-mode instruction.
+4. Spawn `god-coordinator` agent in `init` mode with only a display-safe
+   payload:
+   - Name the hub path.
+   - Name the operation as `init`.
+   - Name the handoff file path.
+   - Say: "Read the handoff file first, then perform suite init from disk
+     state. Return only user-facing progress and final status."
+   Do not put sibling paths, version-table entries, shared standards, local
+   file lists, or detailed instructions in the visible spawn message.
+5. god-coordinator writes `.godpowers/suite-config.yaml` and updates
    each sibling's state.json with `suite.hubPath`.
-5. Initial `lib/suite-state.refreshFromRepos` runs to populate
+6. Initial `lib/suite-state.refreshFromRepos` runs to populate
    `.godpowers/suite/state.json` and `STATE.md`.
-6. Report registration complete; suggest `/god-suite-status` next.
+7. Report registration complete; suggest `/god-suite-status` next.
 
 ## Output
 

package/skills/god-suite-patch.md

@@ -22,11 +22,23 @@ locally; the coordinator tracks atomicity.
    - Patch description (what's the change)
    - Repos in scope (defaults: all siblings; user can subset)
    - Per-repo any specific notes
-3. Spawn `god-coordinator` in `patch` mode.
-4. For each repo in scope:
-   - Spawn that repo's `god-orchestrator` with the patch directive
+3. Create `.godpowers/runs/<run-id>/COORDINATOR-HANDOFF.md` with the patch
+   description, repos in scope, per-repo notes, dry-run flag, and patch-mode
+   instruction.
+4. Spawn `god-coordinator` in `patch` mode with only a display-safe payload:
+   - Name the hub path.
+   - Name the operation as `patch`.
+   - Name the handoff file path.
+   - Say: "Read the handoff file first, then coordinate the suite patch from
+     disk state. Return only user-facing progress and final status."
+   Do not put patch descriptions, per-repo notes, sibling paths, local file
+   lists, or detailed instructions in the visible spawn message.
+5. For each repo in scope:
+   - Write a per-repo orchestrator handoff file and spawn that repo's
+     `god-orchestrator` with only a display-safe pointer for the patch
+     directive
    - Track success/failure
-5. Coordinator aggregates results:
+6. Coordinator aggregates results:
    - All succeeded: report success; append to SYNC-LOG.md
    - Some failed: report partial; suggest manual continuation OR
      rollback (`/god-suite-patch --rollback <patch-id>`)

package/skills/god-suite-release.md

@@ -17,15 +17,27 @@ A version bump that knows about dependents. Different from `/god-launch`
 
 1. Verify suite is registered.
 2. Prompt for: which repo, new version, release notes.
-3. Spawn `god-coordinator` in `release` mode.
-4. god-coordinator:
+3. Create `.godpowers/runs/<run-id>/COORDINATOR-HANDOFF.md` with the repo,
+   new version, release notes, propagation flags, and suite release
+   instruction.
+4. Spawn `god-coordinator` in `release` mode with only a display-safe
+   payload:
+   - Name the hub path.
+   - Name the operation as `release`.
+   - Name the handoff file path.
+   - Say: "Read the handoff file first, then coordinate the suite release
+     from disk state. Return only user-facing progress and final status."
+   Do not put release notes, dependency impact, sibling paths, local file
+   lists, or detailed instructions in the visible spawn message.
+5. god-coordinator:
    - Scans suite version-table for repos that depend on the bumped repo
-   - For each dependent: spawns its `god-orchestrator` with a
+   - For each dependent: writes a per-repo orchestrator handoff file and
+     spawns its `god-orchestrator` with only a display-safe pointer for the
      `version-bump` directive (NOT a full arc)
    - Aggregates results per-repo
    - Updates `.godpowers/suite-config.yaml` version-table to match
    - Appends to `.godpowers/suite/SYNC-LOG.md`
-5. Reports aggregated outcome (bumped + propagated repos).
+6. Reports aggregated outcome (bumped + propagated repos).
 
 ## Forms
 

package/skills/god-version.md

@@ -14,7 +14,7 @@ Print version and a short capability summary.
 ## Output
 
 ```
-Godpowers v1.6.4
+Godpowers v1.6.6
 Install: /Users/.../.claude/  (matches package.json)
 Surface: 106 skills, 39 agents, 13 workflows, 36 recipes
 Schema: intent.v1, state.v1, events.v1, workflow.v1, routing.v1, recipe.v1