[mingchuno]

Phase 1 of 3 (stacked): zero-config onboarding. The aim is for start-work, run and monitor to be all a user has to remember.

Summary

 onboarding
-  npm i -g · npx skills add start-work setup-agent-workflows
-  createdb · export DB URL · export GITHUB_TOKEN
-  init (placeholders) · hand-edit JSON · doctor (JSON wall)
+  npm i -g · npx skills add start-work
+  $start-work <task>          # offers setup when doctor reports a gap
+    agent-workflows init      # inferred from the repo
+    agent-workflows doctor    # checklist, one fix per failure

• init infers these from the repository:

  • project ID from the directory
  • provider, origin and repository from the origin remote
  • base branch from origin/HEAD
  • agent from whichever of codex or copilot is installed
  • validation from package.json (verify, else test), Cargo, Go or Make

  It writes sdlc: { enabled: true, approvalSource: "local-operator" }. Anything it can't discover is printed as a placeholder.

• doctor:

  • prints a readable checklist by default; --json gives the skill machine output
  • new checks: repository (placeholder, or a mismatch with the git remote), hosting-access (one live API read of the repository), agent (sign-in found), validation (commands on PATH)

• Token fallback (D2): when tokenEnv is unset, the CLI reads the token from gh auth token or glab config get token.

  • Default on for local-operator; projects that approve through GitHub/GitLab must opt in with hosting.tokenFromCli.
  • The token lands in tokenEnv in the CLI process only, so existing redaction and subprocess filtering apply. Core is unchanged apart from the schema field.

• One skill (D4): setup-agent-workflows becomes start-work/references/setup.md. Recorded in ADR 0012, which amends ADR 0010.

• Docs and help: the README leads with start-work, run and monitor. --help groups commands as Daily, Setup, Operator controls, and Used by the start-work skill.

Evidence

• Before: in a fresh repo, init wrote "id": "example" and "repository": "OWNER/REPOSITORY", and doctor passed the configuration check anyway.
• After:

  ✓ repository           https://github.com acme/widget
  ✓ hosting-credentials  Using the gh sign-in
  ✗ hosting-access       Cannot read acme/widget: the repository was not found or the token cannot read it. ...
  ✗ database             Set AGENT_WORKFLOWS_DATABASE_URL to a PostgreSQL URL
  Delegated work unavailable: fix 2 failing checks. Track A work runs inline without setup.
  

• New tests in tests/work-cli.test.ts:
  • init infers a GitLab subgroup remote and pnpm run verify
  • an unknown remote becomes a placeholder that doctor rejects
  • the gh fallback applies to local approval and is refused for GitHub approval without opt-in
  • doctor checks host access against a fixture server
• pnpm verify: 392 passed, 2 failed, 3 skipped. Both failures came from the developer's gh keyring sign-in leaking into the tests. scripts/test.mjs now shadows gh and glab, and the affected files pass on rerun.

Merge Danger

Door: two-way

Blast Radius: CLI

• doctor now defaults to readable output, so anything scripting it must pass --json (the skill is updated).
• Users who relied on "missing token" errors will now silently use their gh sign-in on local-operator projects.

🤖 Generated with Claude Code