godpowers 1.6.13 → 1.6.15

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.15] - 2026-05-16
+
+Planning-system migration and sync-back.
+
+### Added
+- Added `lib/planning-systems.js` to detect GSD, BMAD, and Superpowers
+  planning context and convert useful signals into Godpowers prep and seed
+  artifacts.
+- Added `lib/source-sync.js` to write current Godpowers progress back into
+  managed companion files for imported planning systems.
+- Added `/god-migrate` as the explicit command for planning-system detection,
+  import, sync-back, and specialist escalation when migration evidence is
+  ambiguous.
+- Added `docs/planning-system-migration.md` with detection signals, import
+  mapping, sync-back destinations, conflict rules, and return-path guidance.
+- Added behavioral tests for GSD, BMAD, Superpowers, imported seed artifacts,
+  state recording, and idempotent sync-back.
+
+### Changed
+- `/god-init` now auto-invokes planning-system import when GSD, BMAD, or
+  Superpowers evidence is detected.
+- `/god-sync` now auto-invokes source-system sync-back when `state.json`
+  records enabled source systems.
+- `reverse-sync` now includes source-system sync-back in its runtime result.
+- `state.v1.json` now records imported source systems, import hashes,
+  sync-back hashes, conflict counts, and sync-back policy.
+
+### Guardrails
+- Imported planning context remains `[HYPOTHESIS]` until confirmed by the user
+  or a Godpowers artifact.
+- Existing Godpowers artifacts are preserved unless the user explicitly forces
+  overwrite.
+- Source-system files are not rewritten outside Godpowers-owned fences or
+  companion files.
+- Low-confidence or conflicting imports route to `god-greenfieldifier` for a
+  controlled migration plan.
+
+## [1.6.14] - 2026-05-16
+
+Approved automation setup execution.
+
+### Added
+- Added `god-automation-engineer`, a specialist agent for approved host-native
+  automation setup.
+- Added automation execution-plan metadata to `lib/automation-providers.js`.
+- Added gated automation state recording helpers:
+  `buildAutomationRecord(...)` and `recordAutomation(...)`.
+- Added tests for host tool execution plans, complex setup delegation, and
+  post-success automation recording.
+
+### Changed
+- `/god-automation-setup` now distinguishes simple direct host tool calling
+  from complex setup that should spawn `god-automation-engineer`.
+- Setup plans now show method, action, host tool availability, specialist
+  agent routing, and the state file written after success.
+- Automation docs now explain that CLI commands are deterministic and
+  read-only, while slash-command hosts can use LLM tool calling after approval.
+
+### Guardrails
+- `.godpowers/automations.json` is written only after host setup succeeds.
+- Complex, write-capable, background-agent, scriptable-scheduler, or uncertain
+  setup routes through `god-automation-engineer`.
+
 ## [1.6.13] - 2026-05-16
 
 Host automation provider discovery and opt-in setup planning.

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.13-blue)](CHANGELOG.md)
+[![Version](https://img.shields.io/badge/version-1.6.15-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,14 +12,13 @@ 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.13 builds on the executable dashboard engine and CLI status surface:
-`godpowers status --project .` and `godpowers next --project .` now compute the
-same disk-derived progress, planning visibility, proactive checks, and next
-action used by `/god-status`, `/god-next`, and God Mode closeouts.
-It adds an opt-in automation-provider layer so Godpowers can detect host
-automation surfaces such as Codex App automations, Claude Routines, Cline
-schedules, Qwen loops, Cursor Background Agents, Copilot cloud agent, and
-scriptable CLI providers without silently creating background work.
+Version 1.6.15 adds planning-system migration for teams arriving from GSD,
+BMAD, or Superpowers. `/god-init` now auto-detects those systems, imports
+useful context into Godpowers prep and seed artifacts, and records source
+systems in `state.json`. `/god-sync` now syncs current Godpowers progress back
+to managed companion files so teams can return to the prior system with a clear
+handoff trail. Ambiguous imports can auto-spawn `god-greenfieldifier` for a
+controlled migration plan.
 
 It fuses four disciplines into one unified workflow:
 
@@ -145,6 +144,7 @@ npx godpowers status --project=. --json
 | `/god-status` | Re-derive state from disk | (built-in) |
 | `/god-automation-status` | Show host automation provider support | (built-in) |
 | `/god-automation-setup` | Prepare opt-in automation setup | (built-in) |
+| `/god-migrate` | Detect GSD, BMAD, and Superpowers context; import and sync back | god-greenfieldifier when needed |
 | `/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 |
@@ -215,6 +215,19 @@ background agents, API triggers, or CI workflows. Safe starting templates are
 read-only status, checkpoint, review queue, hygiene, and release readiness
 reports.
 
+Godpowers can migrate from adjacent planning systems:
+
+```bash
+/god-migrate
+```
+
+This detects GSD `.planning/` or `.gsd/`, BMAD `_bmad-output/` or `.bmad/`,
+and Superpowers specs or plans. It writes
+`.godpowers/prep/IMPORTED-CONTEXT.md`, optional imported seed artifacts, and
+managed sync-back files such as `.planning/GODPOWERS-SYNC.md`,
+`_bmad-output/GODPOWERS-SYNC.md`, or
+`docs/superpowers/GODPOWERS-SYNC.md`.
+
 For existing codebases and org-constrained new projects, God Mode now runs a
 greenfield simulation audit and then actions it through a greenfieldification
 plan. It pauses before risky artifact rewrites because that process can change
@@ -337,7 +350,7 @@ Pi. T3 Code inherits from the underlying agent (Codex / Claude / OpenCode).
 
 - [Getting Started](docs/getting-started.md)
 - [Concepts](docs/concepts.md)
-- [Command reference (all 108 skills + 39 agents)](docs/reference.md)
+- [Command reference (all 109 skills + 40 agents)](docs/reference.md)
 - [Roadmap](docs/ROADMAP.md)
 - [1.5 Release Notes](RELEASE.md)
 - [Changelog](CHANGELOG.md)

package/RELEASE.md

@@ -1,21 +1,18 @@
-# Godpowers 1.6.13 Release
+# Godpowers 1.6.15 Release
 
 Date: 2026-05-16
 
-Godpowers 1.6.13 adds host automation provider discovery and opt-in setup
-planning. The same local runtime surface can now report Codex App automations,
-Claude Routines, Cline schedules, Qwen loops, Cursor Background Agents,
-Copilot cloud agent support, and scriptable CLI options without silently
-creating background work.
+Godpowers 1.6.15 adds automatic migration from GSD, BMAD, and Superpowers
+projects into Godpowers. The release also adds managed sync-back so a team can
+return to its prior planning system with current Godpowers progress visible.
 
 ## What is stable
 
-- 108 slash commands
-- 39 specialist agents
+- 109 slash commands
+- 40 specialist agents
 - 13 executable workflows
 - 36 intent recipes
 - 15-runtime installer
-- 458 package files in the npm tarball
 - Codex installs with generated `god-*.toml` agent metadata files
 - Markdown specialist agent contracts at `<runtime>/agents/god-*.md`
 - Shared runtime bundle at `<runtime>/godpowers-runtime`
@@ -29,58 +26,68 @@ creating background work.
 
 ## What is new
 
-- Added `lib/automation-providers.js`, a shared automation provider detector.
-- Added `godpowers automation-status --project .`.
-- Added `godpowers automation-setup --project .`.
-- Added `/god-automation-status` and `/god-automation-setup`.
-- Added `docs/automation-providers.md`.
-- Dashboard output now reports automation support when a host-native provider
-  is available.
-- Tests now cover provider classification, active automation config,
-  setup-plan rendering, and CLI JSON output.
-
-## 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.
-
-The dashboard and automation provider engines ship in the installed runtime
-bundle so host tools can use shared implementation code instead of parallel
-command-specific Markdown contracts. If a host platform cannot provide a true
-fresh-context agent spawn or durable scheduler, Godpowers must say so visibly
-and report the work as local runtime only, manual workflow only, or simulated
-in current context.
-
-## 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
-- schedule, routine, background agent, API trigger, or CI workflow creation
-- 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
+- Added `lib/planning-systems.js` for GSD, BMAD, and Superpowers detection.
+- Added `lib/source-sync.js` for managed sync-back companion files.
+- Added `/god-migrate` as the explicit migration command.
+- `/god-init` now auto-invokes planning-system import when source systems are
+  detected.
+- `/god-sync` now auto-invokes source-system sync-back when enabled source
+  systems are recorded in `state.json`.
+- `reverse-sync` now returns source-system sync-back results.
+- `state.v1.json` now records source-system import and sync-back state.
+- Added `docs/planning-system-migration.md`.
+
+## Migration behavior
+
+Godpowers detects:
+
+- GSD: `.planning/`, `.gsd/`, `GSD.md`, and `gsd*.md`
+- BMAD: `_bmad/`, `_bmad-output/`, `.bmad-core/`, `.bmad/`, and `BMAD.md`
+- Superpowers: `docs/superpowers/`, `.superpowers/`, `SUPERPOWERS.md`, and
+  project-local skills
+
+Imported context is written to `.godpowers/prep/IMPORTED-CONTEXT.md`.
+Missing Godpowers seed artifacts are created only when source evidence exists.
+Existing Godpowers artifacts are preserved unless the user explicitly forces an
+overwrite.
+
+## Sync-back behavior
+
+Godpowers writes managed companion files:
+
+- GSD: `.planning/GODPOWERS-SYNC.md` or `.gsd/GODPOWERS-SYNC.md`
+- BMAD: `_bmad-output/GODPOWERS-SYNC.md` or `.bmad/GODPOWERS-SYNC.md`
+- Superpowers: `docs/superpowers/GODPOWERS-SYNC.md` or
+  `.superpowers/GODPOWERS-SYNC.md`
+
+Pointer fences are written only when a safe native state file already exists.
+Godpowers never rewrites source-system prose outside managed fences.
+
+## Auto-invoke and auto-spawn policy
+
+The import path is local runtime work and must be reported as:
+
+```
+Agent: none, local runtime only
+```
+
+The sync-back path is also local runtime work and must be reported the same
+way.
+
+Godpowers spawns `god-greenfieldifier` only when import confidence is low,
+multiple source systems conflict, or canonical seed artifacts cannot be safely
+created from available evidence.
 
 ## Validation
 
 Release validation includes:
 
-- `node scripts/test-dashboard.js`
-- `node scripts/test-automation-providers.js`
+- `node scripts/test-planning-systems.js`
+- `node scripts/test-reverse-sync.js`
 - `npm test`
 - `npm run test:audit`
 - `node scripts/check-package-contents.js`
 - `git diff --check`
 
-The `v1.6.13` git tag points to the release commit that matches the npm
-`godpowers@1.6.13` package.
+The `v1.6.15` git tag points to the release commit that matches the npm
+`godpowers@1.6.15` package.

package/SKILL.md

@@ -214,7 +214,7 @@ 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>
+    + <planning-system-import | reverse-sync | source-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>
 ```
@@ -238,6 +238,8 @@ Automatic steps that especially need visible reporting:
 - checkpoint refresh after state mutations
 - automation provider detection in `/god-status`, `/god-next`,
   `/god-automation-status`, and `/god-automation-setup`
+- planning-system import during `/god-init` or `/god-migrate`
+- source-system sync-back during `/god-sync`, `/god-scan`, or `/god-migrate`
 
 ### 13. Proactive Auto-Invoke Policy
 Godpowers should be proactive from disk evidence, not from guesswork. Before
@@ -265,6 +267,11 @@ Run these local runtime helpers automatically when their trigger is present:
   `PROGRESS.md` mutation.
 - Lightweight reverse-sync or linkage scan after code or artifact edits.
 - Pillars sync planning after durable artifact truth changes.
+- `lib/planning-systems.importPlanningContext` when GSD, BMAD, or
+  Superpowers planning context is detected during `/god-init` or
+  `/god-migrate`.
+- `lib/source-sync.run` when `state.json` records enabled `source-systems`
+  entries and `/god-sync`, `/god-scan`, or `/god-migrate` closes a workflow.
 - Context refresh dry-run after `AGENTS.md`, `CLAUDE.md`, `GEMINI.md`,
   `.cursor/rules/`, `.windsurfrules`, `.github/copilot-instructions.md`,
   `.clinerules`, `.roo/`, or `.continue/` changes.
@@ -286,6 +293,12 @@ Spawn these agents only when the trigger is direct and scope is bounded:
 - `god-deps-auditor` suggestion after dependency files changed; auto-spawn only
   inside `/god-update-deps`, `/god-hygiene`, or an explicitly approved project
   workflow.
+- `god-automation-engineer` after the user approves provider, template,
+  cadence, and scope for multi-template, write-capable, background-agent,
+  scriptable-scheduler, or provider-uncertain automation setup.
+- `god-greenfieldifier` when imported GSD, BMAD, or Superpowers context has
+  low confidence, conflicting systems, or missing canonical Godpowers seed
+  artifacts after local import.
 
 #### Level 4: Explicit approval required
 Never auto-run these from inference alone:
@@ -299,6 +312,8 @@ Never auto-run these from inference alone:
 - git stage, commit, push, package, release, or publish
 - schedule, routine, background agent, API trigger, or CI workflow creation
   without explicit user approval
+- `.godpowers/automations.json` writes before the host automation setup
+  reports success
 
 Every auto-invoke decision must be explainable from one of these inputs:
 changed files, Godpowers artifacts, `state.json`, `PROGRESS.md`,

package/agents/god-automation-engineer.md

@@ -0,0 +1,103 @@
+---
+name: god-automation-engineer
+description: |
+  Configures approved host-native Godpowers automation after the user chooses
+  provider, template, cadence, and scope. Verifies the host setup and records
+  only successful automations in .godpowers/automations.json.
+
+  Spawned by: /god-automation-setup
+tools: Read, Write, Edit, Bash, Glob
+---
+
+# God Automation Engineer
+
+Configure approved host-native automation without pretending a background
+surface exists when it does not.
+
+## Gate Check
+
+The user explicitly approved:
+
+- provider id
+- template ids
+- cadence
+- project or repository scope
+- whether the automation is read-only or write-capable
+
+If any approval field is missing, stop and return the missing field list.
+
+## Process
+
+1. Read `.godpowers/automations.json` if it exists.
+2. Load `lib/automation-providers.js` from the installed runtime bundle or
+   repository.
+3. Call `automation.setupPlan(projectRoot, { templates })`.
+4. Confirm the chosen provider is installed and matches the approved provider.
+5. Execute only through a confirmed host surface:
+   - Codex App: call the host automation tool when available.
+   - Claude Code: use the host schedule or routine surface.
+   - Cline: use `cline schedule` only when that CLI is available.
+   - Qwen: use `/loop` only for session-scoped recurring prompts.
+   - Cursor or Copilot: use branch or PR scoped background agent setup.
+   - Scriptable CLIs: use an approved scheduler. Do not invent OS scheduling.
+6. After host setup succeeds, call `automation.buildAutomationRecord(...)`.
+7. Call `automation.recordAutomation(projectRoot, record, {
+   confirmedHostSuccess: true
+   })`.
+8. Run `/god-automation-status` or the equivalent local helper and report the
+   active state.
+
+## Tool Calling Policy
+
+Use direct host tool calling only when all of these are true:
+
+- one approved read-only template
+- one detected provider
+- no provider dashboard, credential, billing, DNS, production, or repository
+  write scope is required
+- the host exposes a native scheduling or automation tool in the current
+  session
+
+If the host lacks a callable tool, return exact manual setup steps. Do not
+claim setup succeeded.
+
+## Hard Stops
+
+Never create or approve automation that can do these unless the user explicitly
+approved that exact write-capable action:
+
+- stage, commit, push, merge, package, publish, or release
+- deploy to staging or production
+- access provider dashboards, DNS, credentials, secrets, or billing
+- clear `.godpowers/REVIEW-REQUIRED.md`
+- accept Critical security findings
+- run broad dependency upgrades
+- delete files, reset branches, or clean worktrees
+
+Never write `.godpowers/automations.json` before the host setup succeeds.
+
+## Output
+
+Return:
+
+```text
+Automation setup result:
+  Provider: <provider id>
+  Templates: <template ids>
+  Host surface: <tool, command, routine, or manual>
+  Status: <created | manual steps required | blocked>
+  Recorded: <yes | no>
+  Config: .godpowers/automations.json
+  Next: /god-automation-status
+```
+
+## Have-Nots
+
+- Records automation before host setup succeeds
+- Creates background work during install
+- Treats a manual workflow as durable scheduling
+- Uses OS or CI scheduling without explicit approval
+- Grants write scope for a read-only template
+- Uses provider dashboards or credentials without explicit approval
+- Claims an automation is active without re-checking status
+- Hides provider limitations from the user

package/agents/god-orchestrator.md

@@ -311,6 +311,7 @@ Use this trigger map:
 | security-sensitive files changed | auto-spawn only inside harden, hotfix, launch, or project run; otherwise suggest `/god-harden` | proposition |
 | dependency files changed | auto-spawn only inside update-deps, hygiene, or approved project run; otherwise suggest `/god-update-deps` | proposition |
 | host automation support detected and no active templates are recorded | suggest `/god-automation-status` or `/god-automation-setup` | proposition |
+| user approves complex automation setup | spawn `god-automation-engineer` | approval card plus setup result |
 | full project run complete or hygiene stale | suggest `/god-hygiene` | proposition |
 
 Never use this matrix to auto-run Level 4 actions: deployed staging against a
@@ -318,7 +319,7 @@ guessed URL, production launch, provider dashboard access, broad dependency
 upgrades, destructive repair, review clearing, Critical security acceptance, or
 git stage, commit, push, package, release, publish, schedule creation, routine
 creation, background agent creation, API trigger creation, or CI workflow
-creation.
+creation without explicit user approval.
 
 Every auto action must emit either `Auto-invoked:`, `Sync status:`, or a
 proposition explaining why it did not run.