godpowers 0.15.0

package/skills/god-mode.md

@@ -0,0 +1,159 @@
+---
+name: god-mode
+description: |
+  Full autonomous arc orchestrator. Spawns the god-orchestrator agent in a
+  fresh context which runs the entire workflow: idea to hardened production.
+  Pauses only for legitimate human-only decisions.
+
+  Triggers on: "god mode", "/god-mode", "autonomous build", "one-shot",
+  "full arc", "idea to production", "build everything"
+---
+
+# /god-mode
+
+You are receiving a /god-mode invocation. Your job is to spawn the
+**god-orchestrator** agent in a fresh context to run the autonomous arc.
+
+## Process
+
+1. Greet the user briefly: "God Mode engaged. Describe what you want to build."
+
+2. **Auto-detect project type in background** (no jargon to user):
+   - Scan working directory for code presence (package.json, src/, etc.)
+   - Look for org-context.yaml (current dir + parents)
+   - Decide: greenfield / brownfield / bluefield (internally A/B/C/E)
+   - Announce in plain English what was detected (see god-orchestrator
+     "How to announce" section)
+
+3. Wait for the user's project description (any format).
+
+4. Parse flags from the invocation:
+   - `--yolo` (skip pauses, pick defaults)
+   - `--conservative` (more checkpoints)
+   - `--from=<tier>` (resume from specific tier)
+   - `--audit` (score only, build nothing)
+   - `--dry-run` (plan only, no agent dispatch)
+   - `--workflow=<name>` (v0.14 workflow runtime; load
+     `workflows/<name>.yaml`, run via `lib/workflow-runner`)
+   - `--plan` (v0.14; emit plan to `.godpowers/runs/<id>/plan.yaml`
+     and stop. Same effect as `--dry-run`. Use with `--workflow` for
+     a specific arc's plan.)
+   - `--brownfield` (force brownfield path even if detection says greenfield)
+   - `--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
+   - The detected mode (A/B/C/E)
+   - The active flags
+   - Instruction to read `.godpowers/PROGRESS.md` from disk if it exists
+
+6. Orchestrator runs the appropriate workflow:
+   - Greenfield -> full-arc
+   - Brownfield -> brownfield-arc (archaeology -> reconstruct -> debt-assess -> proceed)
+   - Bluefield -> bluefield-arc (org-context -> arc with constraints)
+
+7. Relay the orchestrator's output to the user.
+
+8. When the orchestrator pauses, present the question to the user using the
+   pause format (What / Why / Options / Default).
+
+9. When the user answers, re-spawn god-orchestrator with the answer.
+
+## Pause Format (relay from orchestrator)
+
+```
+PAUSE: [one-sentence question]
+
+Why only you can answer: [one sentence]
+
+| Option | Tradeoff |
+|--------|----------|
+| A: ... | ... |
+| B: ... | ... |
+
+Default: If you say "go", I'll pick [X] because [Y].
+```
+
+## Flags
+
+### --yolo
+Pass through to orchestrator. Orchestrator picks defaults at every pause point
+and logs decisions to `.godpowers/YOLO-DECISIONS.md`.
+
+### --conservative
+Pass through. Orchestrator pauses at every tier boundary.
+
+### --from=<tier>
+Pass through. Orchestrator re-derives state from disk and starts from named tier.
+
+### --audit
+Pass through. Orchestrator skips building, runs god-auditor on existing artifacts.
+
+### --dry-run
+Pass through. Orchestrator plans but writes nothing.
+
+### --with-hygiene
+After Launch, run a post-launch hygiene pass: god-auditor + god-deps-auditor +
+god-docs-writer verification. Catches pre-existing CVEs, doc drift, artifact
+quality drift before declaring complete.
+
+### --skip-hygiene
+Default. Skip the hygiene pass. Use when iterating quickly.
+
+## Mandatory final sync
+
+Regardless of flags, `/god-mode` always runs `/god-sync` before declaring
+complete. This ensures all 14 artifact categories are in a consistent state:
+
+- 10 Tier 0-3 artifacts validated (have-nots passing)
+- 4 capture artifacts noted as `not-yet-created` (graceful handling)
+- SYNC-LOG.md updated with arc completion entry
+- state.json reflects final tier statuses
+
+Under `--yolo`, the sync step auto-applies (no pause). Under
+`--conservative`, it pauses for confirmation. Under `--with-hygiene`,
+it runs alongside the hygiene pass.
+
+The sync step is what closes the loop between greenfield arc creation and
+the comprehensive 14-artifact reconciliation system. See
+`docs/greenfield-coverage.md` for what's created when.
+
+## Completion
+
+When orchestrator returns "complete", display:
+
+```
+Godpowers full-arc complete.
+
+Artifacts on disk:
+  + PRD           .godpowers/prd/PRD.md
+  + Architecture  .godpowers/arch/ARCH.md
+  + Roadmap       .godpowers/roadmap/ROADMAP.md
+  + Stack         .godpowers/stack/DECISION.md
+  + Repo          .godpowers/repo/AUDIT.md
+  + Build         .godpowers/build/STATE.md
+  + Deploy        .godpowers/deploy/STATE.md
+  + Observe       .godpowers/observe/STATE.md
+  + Launch        .godpowers/launch/STATE.md
+  + Harden        .godpowers/harden/FINDINGS.md
+
+Built. Tested. Shipped. Hardened.
+
+Project is now in STEADY STATE. From here, use these workflows:
+
+  Adding features:        /god-feature
+  Production bugs:        /god-hotfix
+  Code cleanup:           /god-refactor
+  Research questions:     /god-spike
+  Post-incident:          /god-postmortem
+  Framework upgrades:     /god-upgrade
+  Documentation:          /god-docs
+  Dependency updates:     /god-update-deps
+
+Periodic hygiene:
+  Quality audit:          /god-audit
+  Health check:           /god-hygiene
+
+Or describe what you want and /god-next will route.
+```

package/skills/god-next.md

@@ -0,0 +1,257 @@
+---
+name: god-next
+description: |
+  Decision engine. For any command intent, checks prerequisites, proposes
+  auto-completion of missing prerequisites, runs standards checks at gates,
+  and suggests next commands after success. Backed by routing/<command>.yaml
+  configurations.
+
+  Triggers on: "god next", "/god-next", "what's next", "what should I do next",
+  "next step", "continue"
+---
+
+# /god-next
+
+The unified decision engine. Routes between commands based on disk state,
+routing definitions, and user intent.
+
+## Three modes of invocation
+
+### Mode 1: After a command (post-completion routing)
+The completing skill calls /god-next to determine what's next.
+Reads `routing/<just-completed>.yaml`, gets `success-path.next-recommended`,
+suggests it.
+
+### Mode 2: Before a command (pre-flight)
+User wants to run /god-X. /god-next checks prerequisites first.
+Reads `routing/<X>.yaml`, evaluates prerequisites, proposes auto-completion
+if any are missing.
+
+### Mode 3: Standalone (state-driven)
+User just ran /god-next. Auto-detects current project phase and suggests
+the next logical command.
+
+## Process for Mode 1 (post-completion)
+
+```
+A skill completes (e.g., /god-prd just finished)
+   |
+   v
+Skill calls: /god-next --after=/god-prd
+   |
+   v
+Read routing/god-prd.yaml
+   |
+   v
+Get success-path.next-recommended (e.g., "/god-arch")
+   |
+   v
+Display: "PRD complete: .godpowers/prd/PRD.md
+          Suggested next: /god-arch (design the architecture)"
+```
+
+If standards-check is configured at the gate:
+```
+   |
+   v
+Spawn god-standards-check on the produced artifact
+   |
+   v
+If standards FAIL:
+   - Display failures with line refs and suggested fixes
+   - Suggest /god-redo with feedback OR /god-skip with reason
+   - Do NOT auto-progress
+   |
+If standards PASS:
+   - Update state.json: tier.sub-step.status = done
+   - Display "Suggested next: /god-arch"
+```
+
+## Process for Mode 2 (pre-flight)
+
+```
+User types: /god-arch
+   |
+   v
+The /god-arch skill calls: /god-next --before=/god-arch
+   |
+   v
+Read routing/god-arch.yaml
+   |
+   v
+For each prerequisite in prerequisites.required:
+   - Evaluate the check predicate
+   - If false: prerequisite is missing
+   |
+   v
+If all prereqs satisfied: proceed with /god-arch
+   |
+If some prereqs missing AND auto-completable:
+   - Display:
+     "/god-arch requires PRD to be complete (prereq missing).
+      The routing has auto-complete: /god-prd
+      Run /god-prd first? (yes/no)"
+   - If yes: invoke /god-prd, then return to /god-arch
+   - If no: abort or show what user needs to do manually
+   |
+If prereqs missing and NOT auto-completable:
+   - Display what's needed
+   - Show how to fix manually
+   - Suggest /god-doctor for diagnosis
+```
+
+## Process for Mode 3 (standalone)
+
+```
+User types: /god-next
+   |
+   v
+Read .godpowers/state.json (or PROGRESS.md as fallback)
+   |
+   v
+Use lib/router.suggestNext(projectRoot)  <- structural next
+   |
+   v
+For each tier in order:
+   - Find first non-done sub-step
+   - That's the suggested next command
+   |
+   v
+If all tiers done:
+   - Use lib/recipes.suggestForState(projectRoot)  <- scenario-aware
+   - Returns recipes matching current lifecycle phase
+   |
+   v
+Display: "Suggested next: /god-arch
+          Why: PRD is complete; architecture is the next gate"
+```
+
+## Process for Mode 4 (intent-based)
+
+```
+User says: "I need to add a new feature mid-development"
+   |
+   v
+/god-next consults lib/recipes.matchIntent(text, projectRoot)
+   |
+   v
+Returns ranked recipes matching:
+   - Intent keywords ("add new feature", "mid-development")
+   - State conditions (lifecycle-phase == in-arc)
+   |
+   v
+Display top match with the recipe's sequence:
+   "Best match: add-feature-mid-arc-pause
+    Sequence:
+      1. /god-pause-work  (Save current /god-mode arc state)
+      2. /god-feature     (Run feature workflow)
+      3. /god-resume-work (Restore arc)
+    
+    Run this sequence? Or see other matches?"
+```
+
+This is the recipe-driven decision support: agents consult `routing/recipes/`
+when user intent is fuzzy or doesn't map to a single command.
+
+## Routing data
+
+Routing definitions live in `routing/*.yaml`. Each command has a file:
+- `routing/god-prd.yaml`
+- `routing/god-arch.yaml`
+- ...
+
+These define prerequisites, execution, success-path, failure-path, and
+endoff for each command.
+
+The `lib/router.js` JS module provides programmatic queries:
+- `getRouting(command)` - load a command's routing
+- `checkPrerequisites(command, projectRoot)` - prereq check
+- `getNextCommand(command)` - get success-path next
+- `getStandards(command)` - get standards checks
+- `suggestNext(projectRoot)` - state-driven suggestion
+
+## Decision Tree
+
+```
+                    /god-next invoked
+                          |
+                          v
+              ┌────── What flag? ──────┐
+              |                          |
+              v                          v
+          --before=X              --after=X        (no flag)
+              |                          |              |
+              v                          v              v
+        Check X's prereqs       Get X's next      Use suggestNext
+              |                          |              |
+              v                          v              |
+        Pass: proceed           Standards check        |
+        Fail+autocomp:            on artifact          |
+        offer to run                   |                |
+        prereq cmd                Pass: announce next  |
+        Fail no autocomp:        Fail: pause           |
+        explain                                         |
+              |                          |              |
+              └──────────────┬───────────┴──────────────┘
+                             v
+                 Display suggestion + why
+```
+
+## Edge cases
+
+### User wants to skip a prereq
+`/god-arch --skip-prereqs` (advanced flag)
+- Logs the skip with reason in events.jsonl
+- Proceeds anyway
+- Marks state as `re-invoked` flag if upstream artifacts are stale
+
+### Multiple non-done sub-steps (parallel-safe)
+e.g., after /god-arch, both /god-roadmap and /god-stack are eligible.
+Display both with: "Run in any order. /god-roadmap is critical-path."
+
+### State drift (artifact missing but state says done)
+Detected by lib/state.detectDrift(). Suggest /god-repair.
+
+### Steady state with multiple workflow options
+If lifecycle-phase = steady-state-active, route by user intent if provided
+(use the User Intent Map below).
+
+## Steady-state User Intent Map
+
+When in steady state, match keywords to workflows:
+
+| Keyword | Suggest |
+|---------|---------|
+| feature, add, new functionality | /god-feature |
+| production down, urgent, p0 | /god-hotfix |
+| bug, broken, doesn't work | /god-debug |
+| refactor, clean up, rename | /god-refactor |
+| POC, prototype, spike, research | /god-spike |
+| postmortem, RCA, incident review | /god-postmortem |
+| upgrade, migrate, bump major | /god-upgrade |
+| docs, documentation, README | /god-docs |
+| deps, dependencies, audit | /god-update-deps |
+| audit, score, quality check | /god-audit |
+| health check, hygiene | /god-hygiene |
+
+## Output Format
+
+```
+Godpowers Next
+
+Current state: [where we are]
+Suggested next: [/god-X]
+
+Why: [one-line reason]
+
+[If prereqs missing]:
+Pre-flight: missing [prereq]
+Auto-complete available: /god-Y
+Run /god-Y first? (yes/no/manual-info)
+
+[If standards-check on previous tier failed]:
+Previous tier had standards failures. Address before proceeding:
+  - [failure 1]
+  - [failure 2]
+Suggested: /god-redo [tier] OR /god-skip [tier] --reason="..."
+```

package/skills/god-note.md

@@ -0,0 +1,39 @@
+---
+name: god-note
+description: |
+  Zero-friction idea capture. Append a note to .godpowers/notes/NOTES.md
+  with timestamp. Optionally promote to a todo.
+
+  Triggers on: "god note", "/god-note", "capture this", "remember this"
+---
+
+# /god-note
+
+Capture an idea with zero ceremony.
+
+## Process
+
+1. Take the user's note text
+2. Append to `.godpowers/notes/NOTES.md` with timestamp:
+
+```markdown
+- 2026-05-09 14:23:45: [note text]
+```
+
+3. Brief confirmation, no questions asked unless user wants to promote.
+
+## Subcommands
+
+### `/god-note <text>`
+Append the note.
+
+### `/god-note list`
+Show recent notes (last 20).
+
+### `/god-note promote <n>`
+Promote note #n to a todo (calls /god-add-todo with the note as source).
+
+## Why this exists
+
+Mid-flow ideas need a fast capture point. /god-add-todo is heavier (asks
+priority). /god-note is just "save this thought".

package/skills/god-observe.md

@@ -0,0 +1,76 @@
+---
+name: god-observe
+description: |
+  Wire observability. Spawns the god-observability-engineer agent in a fresh
+  context. Gated on Deploy.
+
+  Triggers on: "god observe", "/god-observe", "add monitoring", "SLOs", "alerting"
+---
+
+# /god-observe
+
+Spawn the **god-observability-engineer** agent in a fresh context via Task tool.
+
+## Setup
+
+1. Verify `.godpowers/deploy/STATE.md` exists. App is deployed.
+2. Spawn god-observability-engineer with PRD (for success metrics) and ARCH paths.
+3. The agent writes `.godpowers/observe/STATE.md`.
+
+## Verification
+
+After god-observability-engineer returns:
+1. Verify STATE.md exists on disk
+2. Verify each SLO has an error budget policy
+3. Verify each alert has a runbook
+4. Update `.godpowers/PROGRESS.md`: Observe status = done
+
+## On Completion
+
+```
+Observability complete: .godpowers/observe/STATE.md
+
+Suggested next: /god-harden (adversarial security review, gates Launch)
+```
+
+
+## Re-invocation contract
+
+What happens if `/god-observe` is run when `.godpowers/observe/STATE.md` already exists:
+
+| Existing state | Behavior |
+|---|---|
+| File does not exist | Spawn god-observability-engineer; produce file; mark sub-step done |
+| File exists, passes lint, state.json says `done` | Pause: ask user (A) re-run anyway with diff preview, (B) treat as imported (no-op), (C) cancel |
+| File exists, fails lint or have-nots | Spawn god-observability-engineer in update mode with current file + findings as input. Diff preview before overwrite. |
+| File exists, state.json says `pending` | Treat as imported: hash + register, no agent spawn. User can `/god-observe --force` to re-run. |
+| `--force` flag passed | Snapshot existing file to `.godpowers/.trash/god-observe-<ts>/`. Spawn agent fresh. |
+| `--dry-run` flag passed | Show what would happen; touch nothing |
+
+Snapshots in `.trash/` are recoverable via `/god-restore` for 30 days.
+The reflog records every god-observe invocation as `op:god-observe` for `/god-undo`.
+
+### Idempotency guarantees
+
+- Running `/god-observe` twice with no user input between them is a no-op
+  (second call detects the artifact and pauses).
+- Running `/god-observe --dry-run` is always read-only.
+- An interrupted `/god-observe` (agent crashes mid-run) leaves state.json
+  with `status: failed` and the artifact path either missing or marked
+  for `/god-repair` review. Re-running picks up cleanly.
+
+
+## Locking
+
+The orchestrator acquires a state-lock before this skill mutates anything,
+scoped to the smallest affected unit (e.g. `tier-1.prd` for `/god-prd`,
+`linkage` for `/god-scan`). Lock TTL is 5 minutes; reentrant for the
+same holder; force-reclaimable if stale via `/god-repair`.
+
+Read-only inspection commands (`/god-status`, `/god-doctor`,
+`/god-locate`) do NOT block on the lock. Concurrent writers on
+non-overlapping scopes are allowed; on overlapping scopes, the second
+writer pauses or routes elsewhere via `/god-next`.
+
+See [ARCHITECTURE.md "Concurrency contract"](../ARCHITECTURE.md) for
+the full contract.

package/skills/god-org-context.md

@@ -0,0 +1,81 @@
+---
+name: god-org-context
+description: |
+  Bluefield support. Set up or read organization-level context: shared
+  standards, conventions, infrastructure, libraries. Constrains downstream
+  agents to respect org-wide decisions when building new code in an
+  established context.
+
+  Triggers on: "god org context", "/god-org-context", "org standards",
+  "bluefield setup", "shared conventions"
+---
+
+# /god-org-context
+
+Bluefield: new code, established context.
+
+## When to use
+
+- Starting a new service in a microservices architecture
+- Adding a new module to an existing monorepo
+- Building within an organization that has shared standards
+- Any greenfield-feeling project that lives within constraints
+
+## Subcommands
+
+### `/god-org-context init`
+Create `.godpowers/org-context.yaml` from user input. Asks:
+- Language and tooling standards
+- Cloud provider and deploy platform
+- Shared libraries available
+- Shared services to integrate with
+- Team conventions (branching, releases)
+- Constraints (e.g., "must emit OpenTelemetry")
+
+### `/god-org-context show`
+Display current org context.
+
+### `/god-org-context update <key>=<value>`
+Update a specific value.
+
+### `/god-org-context validate`
+Check the project's decisions against org context. Flag conflicts.
+
+## Process
+
+Spawn god-org-context-loader in fresh context. Agent creates or reads
+`.godpowers/org-context.yaml`.
+
+## Effect on other commands
+
+Once org-context.yaml exists, downstream agents respect it:
+- /god-stack-selector prefers org-standard tools (won't choose Python if org-standard is TypeScript without explicit override)
+- /god-arch respects org infrastructure (won't propose Kubernetes if org uses Vercel)
+- /god-deploy uses org's deploy platform
+- /god-observe uses org's observability stack
+- /god-harden checks against org security standards
+
+## On Completion
+
+```
+Org context [created/updated]: .godpowers/org-context.yaml
+
+Constraints that will apply to this project:
+  - Language: TypeScript
+  - Cloud: AWS
+  - Auth: shared auth-service
+  - Observability: Datadog
+  ...
+
+Downstream agents will respect these throughout the arc.
+
+Suggested next: /god-init (or /god-mode if you're ready to build)
+```
+
+## Have-Nots
+
+Org context FAILS if:
+- Created without user-confirmed standards (would be guessing)
+- Constraints not enforced by downstream agents
+- Conflicts surface at code time instead of at decision time
+- Multiple sources of truth (org-context.yaml + scattered notes)

package/skills/god-party.md

@@ -0,0 +1,87 @@
+---
+name: god-party
+description: |
+  Multi-persona collaboration session. Spawn multiple specialist agents in
+  parallel to discuss a topic from different angles, then synthesize their
+  views. Real multi-agent (separate fresh contexts), not simulated.
+
+  Triggers on: "god party", "/god-party", "party mode", "multi-perspective",
+  "what would the team say"
+---
+
+# /god-party
+
+Get multiple specialist perspectives on a single question.
+
+## When to use
+
+- Cross-cutting design decision (affects multiple disciplines)
+- Trade-off analysis (security vs UX, performance vs cost)
+- Stakeholder simulation before a real meeting
+
+## Process
+
+1. Ask the user for the topic/question
+2. Ask which personas should weigh in (or auto-select based on topic):
+   - PM (god-pm) - user impact, prioritization
+   - Architect (god-architect) - structural implications
+   - Executor (god-executor mindset) - implementation cost
+   - Quality reviewer (god-quality-reviewer) - code health risk
+   - Harden auditor (god-harden-auditor) - security implications
+   - Launch strategist (god-launch-strategist) - go-to-market implications
+
+3. Spawn each selected persona IN PARALLEL via Task tool:
+   - Each gets fresh context
+   - Each receives ONLY the question and the relevant artifact subset
+   - Each is instructed: respond as your specialist, do not soften or hedge
+
+4. Collect all responses
+
+5. Synthesize:
+   - Areas of agreement (consensus)
+   - Areas of disagreement (with the trade-off)
+   - Recommendation (with rationale)
+   - Open questions for human decision
+
+## Output
+
+Write to `.godpowers/party/[topic-slug]-[timestamp].md`:
+
+```markdown
+# Party Discussion: [Topic]
+
+## Question
+[The question that was asked]
+
+## Personas Consulted
+[Who weighed in]
+
+## Perspectives
+
+### god-pm
+[Verbatim response]
+
+### god-architect
+[Verbatim response]
+
+### [other personas]
+
+## Synthesis
+
+### Consensus
+- [Where they all agreed]
+
+### Disagreements
+- [Specific tradeoff: PM said X, Architect said Y because Z]
+
+### Recommendation
+[The synthesized view, with rationale]
+
+### Open Questions for Human
+- [Decision the personas could not resolve]
+```
+
+## On Completion
+
+Present the synthesis to the user. Do NOT auto-implement; this is advisory.
+The user decides what to do with the perspectives.