godpowers 1.6.9 → 1.6.11

package/CHANGELOG.md

@@ -5,6 +5,74 @@ 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.11] - 2026-05-16
+
+Auto-invoke visibility and platform-neutral spawning patch.
+
+### Added
+- Added a core auto-invoke visibility rule requiring Godpowers to show when it
+  automatically runs a command, spawns an agent, or calls a local runtime
+  helper.
+- Added a proactive auto-invoke policy with four levels: read-only
+  suggestions, visible local helpers, bounded specialist agent spawns, and
+  explicit-approval-only actions.
+- Added proactive checks to `/god-next`, `/god-status`, and God Mode closeouts
+  so users can see checkpoint, review, sync, docs, runtime, security,
+  dependency, and hygiene opportunities without asking.
+- Added docs drift, runtime verification, and review queue guidance for
+  proactive closeouts.
+- Added `docs/auto-invoke-visibility.md` as a local design note for the
+  auto-invoke policy.
+
+### Changed
+- Replaced Claude-specific "Task tool" spawning wording in high-traffic skills
+  with platform-neutral host-agent spawning language.
+- Clarified that Claude, Codex, Cursor, Windsurf, Gemini, OpenCode, Copilot,
+  Augment, Trae, Cline, Kilo, Antigravity, Qwen, CodeBuddy, and Pi may expose
+  specialist spawning differently while sharing the same Markdown agent
+  contracts.
+- Updated the Codex installer path to replace skill directories before copying
+  `SKILL.md`, preventing stale nested files from older install shapes.
+- `/god-sync`, `/god-scan`, `god-updater`, and `god-orchestrator` now describe
+  local sync helpers separately from spawned agents.
+
+### Guardrails
+- Production launch, guessed staging URLs, provider dashboards, credentials,
+  destructive repair, review clearing, Critical security acceptance, git
+  staging, commits, pushes, packages, releases, and npm publishing still require
+  explicit user intent.
+- If a host platform cannot provide a true fresh-context spawn, Godpowers must
+  say so instead of pretending a background agent ran.
+
+## [1.6.10] - 2026-05-16
+
+Progress visibility and plain-language closeout patch.
+
+### Added
+- Added a core user-facing vocabulary rule: visible output should say
+  "project run", "workflow", "phase", "current step", or "current milestone"
+  instead of unexplained internal "arc" jargon.
+- Added `Planning visibility` blocks to status, next-step, God Mode, and
+  orchestrator closeout guidance. These blocks surface PRD status, roadmap
+  status, current milestone, and completion basis when those artifacts exist or
+  are expected.
+
+### Changed
+- Reworded installer, session-start, `/god`, `/god-mode`, lifecycle, status,
+  routing, workflow, and specialist guidance to use plain project-run language
+  in user-visible text.
+- Checkpoint and session-start summaries now display lifecycle `in-arc` as
+  "in progress" while preserving the internal state key for compatibility.
+- God Mode completion guidance now ends with current status, planning
+  visibility, open items, and a concrete next recommendation.
+
+### Guardrails
+- Internal workflow names and state constants such as `full-arc.yaml` and
+  `in-arc` remain unchanged for compatibility.
+- The patch changes guidance and display wording only. It does not add slash
+  commands, specialist agents, workflows, recipes, schemas, or public artifact
+  formats.
+
 ## [1.6.9] - 2026-05-16
 
 Proposal closeout patch. Makes Godpowers end exploratory, diagnostic, audit,

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.9-blue)](CHANGELOG.md)
+[![Version](https://img.shields.io/badge/version-1.6.11-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,9 +12,10 @@ 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.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.
+Version 1.6.11 keeps the stable Godpowers surface while making automatic work
+more visible and portable: syncs, proactive checks, and specialist spawning now
+report what ran, what changed, and which host-platform agent mechanism is being
+used.
 
 It fuses four disciplines into one unified workflow:
 
@@ -49,6 +50,13 @@ The installer copies:
 - Codex agent metadata to `<runtime>/agents/*.toml`
 - SessionStart hook (Claude Code only) to `<runtime>/hooks/`
 
+Agent spawning is host-native. Claude uses its native agent/task interface,
+Codex uses installed `agents/*.toml` metadata backed by the same Markdown agent
+contracts, and the other runtimes use their supported agent or subagent
+mechanism against the installed `agents/god-*.md` files. If a host cannot
+provide a true fresh-context spawn, Godpowers must report that limitation
+instead of pretending a background agent ran.
+
 ## Usage
 
 Open your AI coding tool in any project directory and type:
@@ -57,7 +65,7 @@ Open your AI coding tool in any project directory and type:
 /god-mode
 ```
 
-That's the autonomous arc. It will run all tiers from idea to hardened
+That starts the autonomous project run. It will run all tiers from idea to hardened
 production, pausing only when it has a real question for you.
 
 ### Just describe what you want
@@ -66,7 +74,7 @@ If you don't know which command to run, type free text after `/god`:
 
 ```
 /god production is broken
-/god add a feature without breaking the current arc
+/god add a feature without breaking the current project run
 /god I'm coming back after a week
 ```
 
@@ -106,7 +114,7 @@ when you open a new session in a Godpowers project.
 | Command | What it does | Spawns agent |
 |---------|--------------|--------------|
 | `/god` | Front door: match free-text intent to a command sequence | (built-in) |
-| `/god-mode` | Full autonomous arc | god-orchestrator |
+| `/god-mode` | Full autonomous project run | god-orchestrator |
 | `/god-next` | Auto-detect and suggest the next command | (built-in) |
 | `/god-init` | Start a project, detect mode and scale | (built-in) |
 | `/god-prd` | Write the PRD | god-pm |
@@ -121,7 +129,7 @@ when you open a new session in a Godpowers project.
 | `/god-launch` | Launch (gated on harden) | god-launch-strategist |
 | `/god-harden` | Adversarial security review | god-harden-auditor |
 | `/god-status` | Re-derive state from disk | (built-in) |
-| `/god-preflight` | Read-only intake audit before arc-ready and pillars | god-auditor |
+| `/god-preflight` | Read-only intake audit before project-run readiness and pillars | god-auditor |
 | `/god-audit` | Score artifacts against have-nots | god-auditor |
 | `/god-debug` | 4-phase systematic debug | god-debugger |
 | `/god-review` | Two-stage code review | god-spec-reviewer + god-quality-reviewer |

package/RELEASE.md

@@ -1,11 +1,11 @@
-# Godpowers 1.6.9 Release
+# Godpowers 1.6.11 Release
 
 Date: 2026-05-16
 
-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.
+Godpowers 1.6.11 makes automatic work easier to trust across supported AI
+coding tools. The release keeps the existing 106 slash commands, 39 specialist
+agents, 13 workflows, and 36 recipes, while clarifying when Godpowers spawned
+an agent, called a local runtime helper, or only suggested the next action.
 
 ## What is stable
 
@@ -14,7 +14,8 @@ moves.
 - 13 executable workflows
 - 36 intent recipes
 - 15-runtime installer
-- Codex installs with 39 generated `god-*.toml` agent metadata files
+- Codex installs with generated `god-*.toml` agent metadata files
+- Markdown specialist agent contracts at `<runtime>/agents/god-*.md`
 - Safe-sync routing before deploy, observe, harden, launch, or god-mode work
 - Critical harden finding gate before launch
 - Native Pillars project context through `AGENTS.md` and `agents/*.md`
@@ -22,68 +23,67 @@ moves.
 - Core schemas: intent, state, events, workflow, routing, recipes, extension
   manifests
 - 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
+- Plain-language project-run wording in user-facing reports
+- Planning visibility blocks for PRD, roadmap, milestone, and completion basis
 
 ## What is new
 
-- 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.
-
-## 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.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:
-
-- Critical bug fixes
-- Documentation clarity
-- Test coverage for frozen behavior
-- Compatibility fixes for supported AI coding tools
-- Small fixes that make existing 1.x behavior work as documented
-
-Deferred changes:
-
-- New lifecycle phases
-- New schema versions
-- Pillars format changes
-- Major routing semantics
-- Large extension API changes
-
-## Adoption ask
-
-Run `npm run release:check` before publishing changes. Report any release path
-step that still depends on memory, manual inspection, or local machine state.
+- The master skill now defines a proactive auto-invoke policy with four levels:
+  read-only suggestions, visible local helpers, bounded specialist agent spawns,
+  and explicit-approval-only actions.
+- `/god-next`, `/god-status`, and God Mode closeouts now include proactive
+  checks for checkpoint freshness, pending reviews, sync state, docs drift,
+  runtime verification, security, dependencies, and hygiene.
+- `/god-sync`, `/god-scan`, `god-updater`, and `god-orchestrator` now distinguish
+  spawned agents from local runtime helpers such as reverse-sync, Pillars sync,
+  checkpoint sync, and context refresh.
+- Docs drift, runtime verification, and review queue workflows now document when
+  they may be suggested or auto-invoked.
+- Spawning instructions now use platform-neutral host-agent language instead of
+  Claude-specific "Task tool" wording.
+- The installer now replaces Codex skill directories before writing `SKILL.md`,
+  which removes stale nested files from older Codex install shapes.
+
+## Platform behavior
+
+Claude Code, Codex, Cursor, Windsurf, Gemini, OpenCode, Copilot, Augment,
+Trae, Cline, Kilo, Antigravity, Qwen, CodeBuddy, and Pi all receive the same
+portable Markdown agent contracts. Codex also receives `god-*.toml` files as
+its registry adapter.
+
+If a host platform cannot provide a true fresh-context agent spawn, Godpowers
+must say so visibly and report the work as local runtime only or simulated in
+current context. It must not imply that a detached background agent ran.
+
+## Safety policy
+
+Godpowers may proactively suggest next steps and may run directly evidenced
+local helpers. It may spawn bounded agents only when the current workflow owns
+that surface.
+
+Godpowers still must not auto-run these without explicit user intent:
+
+- deployed staging verification against a guessed URL
+- production launch
+- provider dashboard, admin console, DNS, credential, or secret checks
+- broad dependency upgrades
+- destructive repair, rollback, reset, delete, or cleanup
+- clearing `.godpowers/REVIEW-REQUIRED.md`
+- accepting Critical security findings
+- git stage, commit, push, package, release, or publish
+
+## Validation
+
+Release validation should include:
+
+- `node scripts/validate-skills.js`
+- `bash scripts/smoke.sh`
+- `node scripts/test-agent-validator.js`
+- `node scripts/test-install-smoke.js`
+- `node scripts/check-package-contents.js`
+- `npm run release:check`
+
+The `v1.6.11` git tag should point to the release commit that matches the npm
+`godpowers@1.6.11` package.

package/SKILL.md

@@ -49,6 +49,19 @@ unresolved Critical security findings.
 Every execution agent gets a fresh context window. The orchestrator is thin; it
 spawns workers with full context budgets. This defeats context rot.
 
+Spawning is platform-neutral. Use the host platform's native agent spawning
+mechanism and the installed `agents/god-*.md` contract:
+- Claude Code: spawn the matching Markdown agent from `~/.claude/agents/`.
+- Codex: spawn the matching Codex agent type from `~/.codex/agents/*.toml`;
+  the Markdown copy remains the source contract.
+- Cursor, Windsurf, Gemini, OpenCode, Copilot, Augment, Trae, Cline, Kilo,
+  Antigravity, Qwen, CodeBuddy, and Pi: use the platform's supported agent or
+  subagent mechanism against the installed Markdown files.
+
+When a platform cannot spawn a true fresh-context agent, say so plainly,
+preserve the same role contract, and report `Agent: none, local runtime only`
+or `Agent: simulated in current context` in the visible auto-invoked card.
+
 ### 6. TDD Enforcement
 Tests are written before implementation. Code written before its test is flagged
 and must be rewritten. RED-GREEN-REFACTOR is not optional.
@@ -82,7 +95,7 @@ Use this shape:
 ```
 Proposition:
   1. Implement partial: <smallest safe slice and command>
-  2. Implement complete: <larger command or arc>
+  2. Implement complete: <larger command or project run>
   3. Discuss more: <focused question or /god-discuss topic>
   4. Run God Mode: /god-mode <optional flags or scope>
 Recommended: <one option and why>
@@ -92,11 +105,172 @@ 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.
 
+### 10. Completion Closeout
+When you complete work, especially from `/god-mode`, `/god-build`,
+`/god-feature`, `/god-hotfix`, `/god-refactor`, `/god-quick`, or any command
+that edits code or artifacts, do not stop at "complete" plus validation. End
+with a disk-derived closeout that tells the user the current state and what is
+next.
+
+Use this shape:
+
+```
+Current status:
+  State: <complete | partial | blocked | complete with deferred item>
+  Progress: <pct>% (<done> of <total> steps complete; current step <n> of <total>) when available
+  Worktree: <clean | modified files unstaged | staged changes | mixed>
+  Index: <untouched | staged files listed>
+
+Planning visibility:
+  PRD: <done | pending | missing | deferred> <artifact path when present>
+  Roadmap: <done | pending | missing | deferred> <artifact path when present>
+  Current milestone: <roadmap milestone, tier, or next planning gate when known>
+  Completion: <pct>% <brief basis, for example done steps over total tracked steps>
+
+What changed:
+  1. <highest-signal change>
+  2. <highest-signal change>
+
+Validation:
+  + <command>: <result>
+
+Open items:
+  1. <deferred staging, unstaged files, pending review, or none>
+
+Next:
+  Recommended: <one concrete command or user decision>
+  Why: <one sentence tied to current state>
+```
+
+If the command intentionally did not stage, commit, push, or deploy, say that
+plainly and explain what the user can do next. If deployed staging is deferred,
+include the deferred artifact path or exact missing input. If the worktree has
+pre-existing unrelated changes, say the index was left untouched and recommend
+a scoped review or staging command rather than implying the project is fully
+shipped.
+
+### 11. User-Facing Vocabulary
+Godpowers may use internal words such as "arc" in routing, recipes, and agent
+implementation notes. Do not require the user to decode that word in visible
+output.
+
+Use these plain-language substitutions in user-facing responses:
+- Say "project run" or "workflow" instead of "arc".
+- Say "phase" or "current step" instead of "tier" unless the user has asked
+  for tier details. If tier detail helps, say both, for example
+  "Planning, Tier 1".
+- Say "current milestone" or "roadmap step" when ROADMAP.md has a matching
+  milestone.
+- If you must use "arc", define it once as "the end-to-end project workflow"
+  and then return to plain language.
+
+Every status, completion, lifecycle, and next-step report should include PRD
+and roadmap visibility when those files exist or are expected. Show whether
+the PRD is done, whether the roadmap exists, which milestone or tier is active,
+how close the tracked workflow is to completion, and the next concrete move.
+
+### 12. Auto-Invoke Visibility
+When Godpowers automatically runs another command, agent, or local runtime
+helper, show the user what happened. Do not describe these as "background"
+unless they are truly detached from the current run. Most Godpowers sync work
+is auto-invoked but still part of the current workflow.
+
+Use this shape whenever an automatic step runs or is skipped:
+
+```
+Auto-invoked:
+  Trigger: <what caused this automatic step>
+  Agent: <god-updater | god-context-writer | none, local runtime only>
+  Local syncs:
+    + <reverse-sync | pillars-sync | checkpoint-sync | context-refresh>: <result or skipped reason>
+  Artifacts: <changed files, no-op, or deferred>
+  Log: <SYNC-LOG.md, CHECKPOINT.md, REVIEW-REQUIRED.md, or none>
+```
+
+If no agent was spawned, say so plainly:
+
+```
+Agent: none, local runtime only
+Why: this path calls lib/reverse-sync.run directly
+```
+
+Automatic steps that especially need visible reporting:
+- `/god-sync` spawning `god-updater`
+- `god-updater` calling reverse-sync, Pillars sync, checkpoint sync, or
+  AI-tool context refresh
+- `/god-mode` mandatory final sync
+- standards checks between routed stages
+- brownfield and bluefield automatic `/god-preflight`
+- DESIGN/PRODUCT change detection that spawns `god-design-reviewer`
+- `/god-scan` when it runs reverse-sync directly without an agent
+- checkpoint refresh after state mutations
+
+### 13. Proactive Auto-Invoke Policy
+Godpowers should be proactive from disk evidence, not from guesswork. Before
+auto-invoking anything, classify the action by risk and apply the safest
+allowed behavior.
+
+#### Level 1: Auto-suggest, read-only
+Run or apply these by default in every relevant closeout:
+- Compute `/god-next` routing after successful commands.
+- Show `/god-status` style progress after `/god-sync`, `/god-scan`, and
+  `/god-mode`.
+- Suggest `/god-review-changes` when `.godpowers/REVIEW-REQUIRED.md` has
+  pending items.
+- Suggest `/god-hygiene` after a full project run, after 30 days, or when
+  status shows stale docs, deps, or review queues.
+- Suggest `/god-locate` when `.godpowers/CHECKPOINT.md` is missing, stale, or
+  conflicts with `state.json`.
+
+#### Level 2: Auto-run local helpers, visible and logged
+Run these local runtime helpers automatically when their trigger is present:
+- `lib/checkpoint.syncFromState` after every `state.json` or
+  `PROGRESS.md` mutation.
+- Lightweight reverse-sync or linkage scan after code or artifact edits.
+- Pillars sync planning after durable artifact truth changes.
+- Context refresh dry-run after `AGENTS.md`, `CLAUDE.md`, `GEMINI.md`,
+  `.cursor/rules/`, `.windsurfrules`, `.github/copilot-instructions.md`,
+  `.clinerules`, `.roo/`, or `.continue/` changes.
+- Progress recomputation after every command that changes artifacts.
+
+#### Level 3: Auto-spawn scoped specialist agents
+Spawn these agents only when the trigger is direct and scope is bounded:
+- `god-design-reviewer` when `DESIGN.md` or `PRODUCT.md` changed.
+- `god-updater` after feature, hotfix, refactor, build, deploy, observe,
+  launch, harden, docs, upgrade, or dependency workflows change code or
+  artifacts.
+- `god-docs-writer` in drift-check mode when docs changed after code changed,
+  or code changed after docs that claim current behavior.
+- `god-browser-tester` when frontend-visible files changed and a known local,
+  preview, staging, or production URL is evidenced.
+- `god-harden-auditor` suggestion after security-sensitive files changed;
+  auto-spawn only inside `/god-harden`, `/god-hotfix`, `/god-launch`, or
+  `/god-mode`.
+- `god-deps-auditor` suggestion after dependency files changed; auto-spawn only
+  inside `/god-update-deps`, `/god-hygiene`, or an explicitly approved project
+  workflow.
+
+#### Level 4: Explicit approval required
+Never auto-run these from inference alone:
+- deployed staging verification against a guessed URL
+- production launch
+- provider dashboard, admin console, DNS, credential, or secret checks
+- broad dependency upgrades
+- destructive repair, rollback, reset, delete, or cleanup
+- clearing `.godpowers/REVIEW-REQUIRED.md`
+- accepting Critical security findings
+- git stage, commit, push, package, release, or publish
+
+Every auto-invoke decision must be explainable from one of these inputs:
+changed files, Godpowers artifacts, `state.json`, `PROGRESS.md`,
+`CHECKPOINT.md`, `SYNC-LOG.md`, `REVIEW-REQUIRED.md`, routing YAML, recipe YAML,
+or explicit user intent.
+
 ---
 
 ## Operating Modes
 
-### Mode A: Full Arc (greenfield)
+### Mode A: Full Project Run (greenfield)
 Default. Idea to hardened production. All four tiers, all gates.
 
 ### Mode B: Gap Fill (existing codebase)
@@ -456,7 +630,7 @@ On resume:
 - `--conservative`: Lower threshold for pausing. More human touchpoints.
 - `--from=<tier>`: Start from a specific tier. Re-derives earlier state from disk.
 - `--audit`: Score existing artifacts. Build nothing. Report gaps.
-- `--dry-run`: Plan everything. Build nothing. Show the full arc.
+- `--dry-run`: Plan everything. Build nothing. Show the full project run.
 
 ---
 

package/agents/god-auditor.md

@@ -35,7 +35,7 @@ why.
 6. If running with `mode: preflight`, do not run the artifact linter as the
    main task. Inspect the repo and write `.godpowers/preflight/PREFLIGHT.md`.
 7. If running with `mode: greenfield-simulation`, do not build anything.
-   Simulate the canonical Godpowers greenfield arc and compare it against the
+   Simulate the canonical Godpowers greenfield project run and compare it against the
    current project evidence or org constraints.
 
 ## Mechanical vs interpretive split
@@ -252,16 +252,16 @@ Mode: [brownfield | bluefield]
   bluefield workflows when the user wants the audit acted on.
 - This audit does not treat imported GSD, Superpowers, BMAD, or org context as
   source of truth.
-- This audit does not block the arc unless it finds a Critical security or
+- This audit does not block the project run unless it finds a Critical security or
   impossible planning contradiction.
 ```
 
 Greenfield simulation rules:
 - Brownfield: compare reconstructed artifacts, archaeology, debt assessment,
   repo shape, tests, CI, deploy, observability, hardening, and launch evidence
-  against what the canonical greenfield arc would have created.
+  against what the canonical greenfield project run would have created.
 - Bluefield: compare org context and constraints against the canonical
-  greenfield arc before PRD so downstream agents know which choices are
+  greenfield project run before PRD so downstream agents know which choices are
   constrained, missing, or open.
 - Label every finding as DECISION, HYPOTHESIS, or OPEN QUESTION.
 - Do not invent missing intent. Mark unknowns as OPEN QUESTION.

package/agents/god-coordinator.md

@@ -5,7 +5,7 @@ description: |
   coordination: byte-identical file sync, cross-repo releases,
   meta-linter findings, suite-level state aggregation. NEVER bypasses
   individual orchestrators (the Quarterback rule holds per-repo);
-  spawns per-repo god-orchestrator for arc work inside each repo.
+  spawns per-repo god-orchestrator for project-run work inside each repo.
 
   Spawned by: /god-suite-init, /god-suite-status, /god-suite-sync,
   /god-suite-release, /god-suite-patch
@@ -30,7 +30,7 @@ suite (the collection of repos), not individual repos.
 
 ## What you do NOT do
 
-- Run an arc inside a single repo (that's the per-repo
+- Run a project run inside a single repo (that's the per-repo
   `god-orchestrator`'s job)
 - Make Quarterback-level decisions inside a repo (mode detection,
   scale detection, tier orchestration)
@@ -82,7 +82,7 @@ If a handoff path is provided:
 2. Run impact analysis: which sibling repos depend on this one?
 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)
+   `version-bump` directive (NOT a full project run)
 4. Aggregate results into a release report
 5. Update `.godpowers/suite-config.yaml` version-table
 6. Append to SYNC-LOG.md
@@ -114,7 +114,7 @@ If a handoff path is provided:
   only, you write the `suite.hubPath` field into each newly-registered
   sibling's state.json. Any other field, in any other mode, is the
   per-repo orchestrator's domain.
-- You run a full arc on a sibling (that's beyond your scope)
+- You run a full project run on a sibling (that's beyond your scope)
 - You promote `--strict` byte-identical drift to non-blocking when
   user passed `--strict` (gate must hold)
 - You write `.godpowers/suite-config.yaml` without user confirmation
@@ -134,7 +134,7 @@ For each operation, return to the spawning skill with:
 
 When you need work done IN a repo (version bump, patch slice, etc.),
 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.
+`god-orchestrator` via the host platform's native agent spawning mechanism with only a display-safe pointer.
 
 Per-repo handoff path:
 `.godpowers/runs/<run-id>/COORDINATOR-ORCHESTRATOR-HANDOFF.md`

package/agents/god-deploy-engineer.md

@@ -65,7 +65,7 @@ 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 behavior: do not pause mid-arc only to ask for
+- Default behavior: do not pause mid-run 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.

package/agents/god-greenfieldifier.md

@@ -63,7 +63,7 @@ The plan must include:
 
 - DECISION: Which findings are safe to action.
 - DECISION: Which artifacts would change.
-- HYPOTHESIS: Why each change better matches the canonical greenfield arc.
+- HYPOTHESIS: Why each change better matches the canonical greenfield project run.
 - OPEN QUESTION: Any product, org, risk, or architecture choice that needs the
   user.
 - A per-artifact impact table for PRD, DESIGN, PRODUCT, ARCH, ROADMAP, STACK,

package/agents/god-launch-strategist.md

@@ -86,7 +86,7 @@ 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, do not pause mid-arc for the staging URL. Record deployed
+  origin is known, do not pause mid-run 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.

package/agents/god-observability-engineer.md

@@ -71,7 +71,7 @@ For each PRD success metric, define an SLO:
   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. Do not pause
-  mid-arc just to request the deployed staging origin unless the user has
+  mid-run 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.