godpowers 1.6.11 → 1.6.13

package/CHANGELOG.md

@@ -5,6 +5,67 @@ 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.13] - 2026-05-16
+
+Host automation provider discovery and opt-in setup planning.
+
+### Added
+- Added `lib/automation-providers.js`, a shared provider detector for
+  host-native automation support.
+- Added `godpowers automation-status --project .` and
+  `godpowers automation-setup --project .` for opt-in automation support.
+- Added `/god-automation-status` and `/god-automation-setup` slash commands.
+- Added `docs/automation-providers.md` with provider classes, safe templates,
+  and approval rules.
+- Added automation provider tests covering provider classification, active
+  automation config, setup-plan rendering, and CLI JSON output.
+
+### Changed
+- The dashboard engine now reports automation support when host-native
+  automation providers are available.
+- The installer help now documents automation-status and automation-setup as
+  first-class read-only helper commands.
+- Godpowers command guidance now recommends automation setup when provider
+  support exists and no approved automation template is active.
+
+### Guardrails
+- Automation setup is opt-in only. Godpowers must not create schedules,
+  routines, background agents, API triggers, or CI workflows during install.
+- Default automation templates are read-only and must not commit, push,
+  publish, deploy, clear reviews, accept Critical security findings, or access
+  provider dashboards without explicit user approval.
+
+## [1.6.12] - 2026-05-16
+
+Executable dashboard CLI and shared runtime status engine.
+
+### Added
+- Added `lib/dashboard.js`, a shared executable engine for project status,
+  progress percentage, tier position, planning visibility, proactive checks,
+  open items, and recommended next command.
+- Added `godpowers status --project .` for human, CI, and host-runtime status
+  checks outside the slash command layer.
+- Added `godpowers next --project .` for direct next-action routing from disk
+  state.
+- Added `--json` output for the new status and next commands.
+- Added dashboard behavioral tests, CLI status and next tests, and git
+  porcelain parsing tests.
+
+### Changed
+- `/god-status`, `/god-next`, `/god-mode`, and `god-orchestrator` now point to
+  the shared dashboard engine when local runtime execution is available.
+- The installer help now documents status and next as first-class commands.
+- Release documentation now names the executable dashboard contract instead of
+  treating progress visibility as Markdown-only guidance.
+
+### Fixed
+- Fixed git porcelain parsing so leading-space worktree entries such as
+  ` M README.md` do not clip filenames in dashboard output.
+
+### Validation
+- Added tests prove dashboard computation, dashboard rendering, CLI JSON
+  output, proactive review suggestions, and staged path reporting.
+
 ## [1.6.11] - 2026-05-16
 
 Auto-invoke visibility and platform-neutral spawning patch.

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.11-blue)](CHANGELOG.md)
+[![Version](https://img.shields.io/badge/version-1.6.13-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,14 @@ 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.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.
+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.
 
 It fuses four disciplines into one unified workflow:
 
@@ -109,6 +113,16 @@ This reads `.godpowers/PROGRESS.md`, scans disk, reconciles any drift, and
 suggests the next logical command. The SessionStart hook does the same thing
 when you open a new session in a Godpowers project.
 
+The same status engine is available from the installer CLI for humans, CI,
+Codex, Claude, Cursor, Gemini, OpenCode, Windsurf, Antigravity, and any host
+runtime that can execute Node:
+
+```bash
+npx godpowers status --project=.
+npx godpowers next --project=.
+npx godpowers status --project=. --json
+```
+
 ### Slash Commands
 
 | Command | What it does | Spawns agent |
@@ -129,6 +143,8 @@ 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-automation-status` | Show host automation provider support | (built-in) |
+| `/god-automation-setup` | Prepare opt-in automation setup | (built-in) |
 | `/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 |
@@ -179,6 +195,26 @@ Under `--yolo`, Godpowers also auto-applies Pillars sync proposals when
 durable `.godpowers` artifacts change project truth. The decision is logged to
 `.godpowers/YOLO-DECISIONS.md`.
 
+Every completing command now ends with a **Godpowers Dashboard**. It shows the
+current phase, tier, step count, percent complete, PRD and roadmap visibility,
+recent work, proactive checks, open items, and the single recommended next
+action. `/god-status` and `/god-next` use the same shape so the project never
+ends in a vague "done" state. The dashboard is backed by
+`lib/dashboard.js`, so status and next-step commands share one executable
+source of disk truth instead of parallel Markdown-only contracts.
+
+Godpowers can also inspect automation support:
+
+```bash
+npx godpowers automation-status --project=.
+npx godpowers automation-setup --project=.
+```
+
+Automation setup is opt-in. The installer does not create schedules, routines,
+background agents, API triggers, or CI workflows. Safe starting templates are
+read-only status, checkpoint, review queue, hygiene, and release readiness
+reports.
+
 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
@@ -301,7 +337,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 106 skills + 39 agents)](docs/reference.md)
+- [Command reference (all 108 skills + 39 agents)](docs/reference.md)
 - [Roadmap](docs/ROADMAP.md)
 - [1.5 Release Notes](RELEASE.md)
 - [Changelog](CHANGELOG.md)

package/RELEASE.md

@@ -1,50 +1,43 @@
-# Godpowers 1.6.11 Release
+# Godpowers 1.6.13 Release
 
 Date: 2026-05-16
 
-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.
+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.
 
 ## What is stable
 
-- 106 slash commands
+- 108 slash commands
 - 39 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`
-- Safe-sync routing before deploy, observe, harden, launch, or god-mode work
-- Critical harden finding gate before launch
+- Shared runtime bundle at `<runtime>/godpowers-runtime`
 - Native Pillars project context through `AGENTS.md` and `agents/*.md`
 - `.godpowers/` workflow state and artifact layout
-- Core schemas: intent, state, events, workflow, routing, recipes, extension
-  manifests
-- Extension pack compatibility range for the 1.x line
+- Safe-sync routing before deploy, observe, harden, launch, or god-mode work
+- Critical harden finding gate before launch
 - 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 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.
+- 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
 
@@ -53,9 +46,12 @@ 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.
+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
 
@@ -68,6 +64,7 @@ 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`
@@ -76,14 +73,14 @@ Godpowers still must not auto-run these without explicit user intent:
 
 ## Validation
 
-Release validation should include:
+Release validation includes:
 
-- `node scripts/validate-skills.js`
-- `bash scripts/smoke.sh`
-- `node scripts/test-agent-validator.js`
-- `node scripts/test-install-smoke.js`
+- `node scripts/test-dashboard.js`
+- `node scripts/test-automation-providers.js`
+- `npm test`
+- `npm run test:audit`
 - `node scripts/check-package-contents.js`
-- `npm run release:check`
+- `git diff --check`
 
-The `v1.6.11` git tag should point to the release commit that matches the npm
-`godpowers@1.6.11` package.
+The `v1.6.13` git tag points to the release commit that matches the npm
+`godpowers@1.6.13` package.

package/SKILL.md

@@ -112,12 +112,28 @@ 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.
 
+Every closeout must include a **Godpowers Dashboard**. This dashboard is the
+same mental model across `/god-status`, `/god-next`, `/god-mode`, and every
+command that completes, pauses, or proposes work.
+
+When the runtime bundle is available, compute this with
+`lib/dashboard.compute(projectRoot)` and render it with
+`lib/dashboard.render(result)`. The executable dashboard engine is the shared
+source for phase, tier, step, progress, PRD and roadmap visibility, proactive
+checks, open items, and the next route. If the runtime module is unavailable,
+fall back to a manual disk scan and say `Dashboard engine: unavailable, manual
+scan used`.
+
 Use this shape:
 
 ```
+Godpowers Dashboard
+
 Current status:
   State: <complete | partial | blocked | complete with deferred item>
-  Progress: <pct>% (<done> of <total> steps complete; current step <n> of <total>) when available
+  Phase: <plain-language phase> (tier <human ordinal> of <human total>) when available
+  Step: <sub-step label> (<step n> of <total steps>) when available
+  Progress: <pct>% (<done> of <total> steps complete) when available
   Worktree: <clean | modified files unstaged | staged changes | mixed>
   Index: <untouched | staged files listed>
 
@@ -134,8 +150,19 @@ What changed:
 Validation:
   + <command>: <result>
 
+Proactive checks:
+  Checkpoint: <fresh | refreshed | missing | stale | conflicts with state.json>
+  Reviews: <none | N pending, suggest /god-review-changes>
+  Sync: <fresh | missing | stale | local helper ran | suggest /god-sync>
+  Docs: <fresh | possible drift, suggest /god-docs>
+  Runtime: <not-applicable | known URL, suggest /god-test-runtime | no known URL, defer deployed verification>
+  Automation: <not configured | N active | available via provider, suggest /god-automation-setup>
+  Security: <clear | sensitive files changed, suggest /god-harden>
+  Dependencies: <clear | dependency files changed, suggest /god-update-deps>
+  Hygiene: <fresh | stale, suggest /god-hygiene>
+
 Open items:
-  1. <deferred staging, unstaged files, pending review, or none>
+  1. <deferred staging, unstaged files, pending review, blocker, or none>
 
 Next:
   Recommended: <one concrete command or user decision>
@@ -149,6 +176,11 @@ 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.
 
+When the command only recommends work, keep the same dashboard but set
+`State: proposal` and end with the proposition block from Section 9. When the
+command pauses, set `State: blocked` or `State: paused` and make `Next` the
+one exact user decision needed to continue.
+
 ### 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
@@ -158,7 +190,7 @@ 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".
+  "Planning phase, tier 2 of 4".
 - 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"
@@ -204,6 +236,8 @@ Automatic steps that especially need visible reporting:
 - 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
+- automation provider detection in `/god-status`, `/god-next`,
+  `/god-automation-status`, and `/god-automation-setup`
 
 ### 13. Proactive Auto-Invoke Policy
 Godpowers should be proactive from disk evidence, not from guesswork. Before
@@ -221,6 +255,9 @@ Run or apply these by default in every relevant closeout:
   status shows stale docs, deps, or review queues.
 - Suggest `/god-locate` when `.godpowers/CHECKPOINT.md` is missing, stale, or
   conflicts with `state.json`.
+- Suggest `/god-automation-status` or `/god-automation-setup` when host-native
+  automation support is available and `.godpowers/automations.json` has no
+  active read-only templates.
 
 #### Level 2: Auto-run local helpers, visible and logged
 Run these local runtime helpers automatically when their trigger is present:
@@ -260,6 +297,8 @@ Never auto-run these from inference alone:
 - clearing `.godpowers/REVIEW-REQUIRED.md`
 - accepting Critical security findings
 - git stage, commit, push, package, release, or publish
+- schedule, routine, background agent, API trigger, or CI workflow creation
+  without explicit user approval
 
 Every auto-invoke decision must be explainable from one of these inputs:
 changed files, Godpowers artifacts, `state.json`, `PROGRESS.md`,

package/agents/god-orchestrator.md

@@ -310,12 +310,15 @@ Use this trigger map:
 | frontend-visible files changed and no known URL exists | suggest `/god-test-runtime` with local URL setup, defer deployed URL | proposition |
 | 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 |
 | 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
 guessed URL, production launch, provider dashboard access, broad dependency
 upgrades, destructive repair, review clearing, Critical security acceptance, or
-git stage, commit, push, package, release, or publish.
+git stage, commit, push, package, release, publish, schedule creation, routine
+creation, background agent creation, API trigger creation, or CI workflow
+creation.
 
 Every auto action must emit either `Auto-invoked:`, `Sync status:`, or a
 proposition explaining why it did not run.
@@ -676,12 +679,16 @@ across all 14 categories.
 
 After Launch completes, write a transition message:
 
-```
+```text
 Godpowers project run complete.
 
+Godpowers Dashboard
+
 Current status:
   State: complete
-  Progress: <pct>% (<done> of <total> steps complete; current step <n> of <total>)
+  Phase: <plain-language phase> (tier <human ordinal> of <human total>)
+  Step: <sub-step label> (step <n> of <total steps>)
+  Progress: <pct>% (<done> of <total> steps complete)
   Worktree: <clean | modified files unstaged | staged changes | mixed>
   Index: <untouched | staged files listed>
 
@@ -737,6 +744,11 @@ Proposition:
   4. Run deployed staging: provide STAGING_APP_URL=<deployed staging origin> when needed
 ```
 
+Generate the dashboard with `lib/dashboard.compute(projectRoot)` and
+`lib/dashboard.render(result)` when the runtime bundle is available. If the
+runtime module cannot be loaded, fall back to a manual disk scan and say
+`Dashboard engine: unavailable, manual scan used`.
+
 Update PROGRESS.md status to `steady-state-active`.
 
 For focused brownfield, hotfix, refactor, or build workflows that finish without a
@@ -860,7 +872,8 @@ Show:
 - commands being run and whether they passed or failed
 - scoped file changes
 - final validation summary
-- final current status from disk, including progress, lifecycle, open items,
+- final Godpowers Dashboard from disk, including phase, tier, step, progress,
+  lifecycle, planning visibility, proactive checks, open items,
   worktree/index state, and recommended next action
 - plain-language workflow names. Say "project run" or "workflow" instead of
   unexplained "arc" in visible output
@@ -918,11 +931,11 @@ one compact card.
 
 Before starting a tier/sub-step:
 
-```
+```text
 Next step
-Progress: <pct>% (<done> of <total> steps complete; current step <n> of <total>)
-Tier: <tier-number> <tier-label>
+Phase: <plain-language phase> (tier <human ordinal> of <human total>)
 Step: <sub-step-label>
+Progress: <pct>% (<done> of <total> steps complete; step <n> of <total>)
 Why this now: <one sentence tied to disk state or the prior gate>
 What will happen:
   1. <first observable action>
@@ -933,11 +946,11 @@ Expected output: <artifact path or verification result>
 
 After a tier/sub-step completes or pauses:
 
-```
+```text
 Step result
-Progress: <pct>% (<done> of <total> steps complete; current step <n> of <total>)
-Tier: <tier-number> <tier-label>
+Phase: <plain-language phase> (tier <human ordinal> of <human total>)
 Step: <sub-step-label>
+Progress: <pct>% (<done> of <total> steps complete; step <n> of <total>)
 Result: <done | blocked | failed | skipped | imported>
 What happened:
   1. <observable action completed>

package/bin/install.js

@@ -300,6 +300,9 @@ function removeSkillEntry(skillsDir, entry) {
 function parseArgs(argv) {
   const args = argv.slice(2);
   const opts = {
+    command: null,
+    project: process.cwd(),
+    json: false,
     runtimes: [],
     global: false,
     local: false,
@@ -308,8 +311,24 @@ function parseArgs(argv) {
     uninstall: false,
   };
 
-  for (const arg of args) {
+  for (let i = 0; i < args.length; i++) {
+    const arg = args[i];
     switch (arg) {
+      case 'status':
+      case 'next':
+      case 'automation-status':
+      case 'automation-setup':
+        opts.command = arg;
+        break;
+      case '--json':
+        opts.json = true;
+        break;
+      case '--project':
+        if (args[i + 1]) {
+          opts.project = path.resolve(args[i + 1]);
+          i++;
+        }
+        break;
       case '-g':
       case '--global':
         opts.global = true;
@@ -330,7 +349,9 @@ function parseArgs(argv) {
         opts.uninstall = true;
         break;
       default:
-        if (arg.startsWith('--') && RUNTIMES[arg.slice(2)]) {
+        if (arg.startsWith('--project=')) {
+          opts.project = path.resolve(arg.slice('--project='.length));
+        } else if (arg.startsWith('--') && RUNTIMES[arg.slice(2)]) {
           opts.runtimes.push(arg.slice(2));
         }
         break;
@@ -548,8 +569,16 @@ function uninstallForRuntime(runtimeKey, opts = {}) {
 
 function showHelp() {
   console.log(BANNER);
-  log('Usage: npx godpowers [options]\n');
+  log('Usage: npx godpowers [command] [options]\n');
+  log('Commands:');
+  log('  status               Show the Godpowers Dashboard for a project');
+  log('  next                 Show the dashboard and recommended next command');
+  log('  automation-status    Show host automation provider support');
+  log('  automation-setup     Show an opt-in automation setup plan');
+  log('');
   log('Options:');
+  log('  --project=<path>     Project root for status, next, or automation commands');
+  log('  --json               Emit JSON for status, next, or automation commands');
   log('  -g, --global         Install globally (to config directory)');
   log('  -l, --local          Install locally (to current directory)');
   log('  --claude             Install for Claude Code');
@@ -572,11 +601,44 @@ function showHelp() {
   log('  -h, --help           Show this help message');
   log('');
   log('Examples:');
+  log('  npx godpowers status --project=.');
+  log('  npx godpowers next --project=.');
+  log('  npx godpowers automation-status --project=.');
+  log('  npx godpowers automation-setup --project=.');
   log('  npx godpowers --claude --global');
   log('  npx godpowers --all');
   log('  npx godpowers --codex --cursor');
 }
 
+function runAutomationCommand(opts) {
+  const automation = require('../lib/automation-providers');
+  const result = opts.command === 'automation-setup'
+    ? automation.setupPlan(opts.project)
+    : automation.detect(opts.project);
+  if (opts.json) {
+    console.log(JSON.stringify(result, null, 2));
+  } else if (opts.command === 'automation-setup') {
+    console.log(automation.renderSetupPlan(result));
+  } else {
+    console.log(automation.render(result));
+  }
+}
+
+function runDashboardCommand(opts) {
+  const dashboard = require('../lib/dashboard');
+  const result = dashboard.compute(opts.project);
+  if (opts.json) {
+    console.log(JSON.stringify(result, null, 2));
+  } else {
+    console.log(dashboard.render(result));
+    if (opts.command === 'next') {
+      console.log('');
+      console.log('Suggested next command:');
+      console.log(`  ${result.next && result.next.command ? result.next.command : 'describe the next intent'}`);
+    }
+  }
+}
+
 // ---------------------------------------------------------------------------
 // Main
 // ---------------------------------------------------------------------------
@@ -589,6 +651,16 @@ function main() {
     process.exit(0);
   }
 
+  if (opts.command === 'status' || opts.command === 'next') {
+    runDashboardCommand(opts);
+    return;
+  }
+
+  if (opts.command === 'automation-status' || opts.command === 'automation-setup') {
+    runAutomationCommand(opts);
+    return;
+  }
+
   console.log(BANNER);
 
   const srcDir = path.resolve(__dirname, '..');