@open-agent-toolkit/cli 0.0.42 → 0.0.50

package/assets/docs/workflows/projects/implementation-execution.md

@@ -0,0 +1,161 @@
+---
+title: Implementation Execution
+description: 'Phase-subagent dispatch, tier detection, bounded fix loop, plan-declared parallelism, and dry-run mode in oat-project-implement v2.0.'
+---
+
+# Implementation Execution
+
+This page covers how `oat-project-implement` actually runs a plan: tier selection, phase-level subagent dispatch, the review + fix loop, plan-declared parallelism with worktree fan-in, and dry-run.
+
+## Quick Look
+
+- **When to use:** you have a plan ready and want to understand what happens during `oat-project-implement`.
+- **Unit of dispatch:** one phase at a time (not one task). A phase implementer executes all tasks in the phase, commits per task, and returns a single summary.
+- **Two tiers, one lock:** capability detection picks Tier 1 (native subagents) or Tier 2 (inline) at start. The tier is locked for the whole run — no mid-run downgrades.
+
+## Execution model
+
+### Tier selection
+
+At skill start, `oat-project-implement` detects whether the host supports native subagent dispatch for `oat-phase-implementer` and `oat-reviewer`.
+
+- **Claude Code / Cursor:** native subagent dispatch → Tier 1.
+- **Codex multi-agent:** Tier 1 if `spawn_agent` is allowed without authorization, or after an explicit single prompt at skill start if authorization is required. Codex subagent dispatch should use self-contained scope packets with fresh context; do not assume pinned OAT roles can also inherit the full parent thread.
+- **Authorization declined or agents do not resolve:** Tier 2 (inline). The orchestrator reads `.agents/agents/oat-phase-implementer.md` and `.agents/agents/oat-reviewer.md` as reference and executes that process itself.
+
+The approval decision covers both phase implementation and checkpoint review for the run. The orchestrator should not drift into a mixed mode based on conversational emphasis alone; if Tier 1 was not approved, stay inline throughout unless the user explicitly requests mixed execution.
+
+The selected tier is reported to the user and locked for the remainder of the run:
+
+```
+[preflight] Checking subagent availability…
+  → oat-phase-implementer + oat-reviewer: available
+  → Selected: Tier 1 — Subagents
+```
+
+### Per-phase loop
+
+For each phase in the plan (whether sequential or inside a parallel group):
+
+1. **Dispatch `oat-phase-implementer`** with a Phase Scope block (project path, phase id, artifact paths, commit convention, workflow mode).
+2. **Receive the summary:** `DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED`.
+   - `BLOCKED` stops the run and surfaces the blocker to the user.
+3. **Dispatch `oat-reviewer`** with a Review Scope block (phase id, commit range, optional files-changed hint). The commit range is authoritative; the file list is only orientation metadata. In Codex, pass this as a self-contained packet and keep fresh context (`fork_context: false`) so the reviewer reads git/OAT artifacts directly instead of inheriting the orchestration thread. If the reviewer does not conclude on the first wait, poll once more, then send a concise "return now with current findings" nudge before falling back inline for that phase.
+4. **Parse the verdict:** zero Critical + zero Important findings → `pass`; otherwise `fail`.
+5. **On fail, run the bounded fix loop** (see below).
+6. **Update artifacts** (`implementation.md`, `plan.md` review row, `state.md`) and make the mandatory bookkeeping commit.
+7. **HiLL checkpoint** if the phase id is listed in `oat_plan_hill_phases`.
+
+### Bounded fix loop
+
+On a `fail` verdict:
+
+- Read `oat_orchestration_retry_limit` from `state.md` frontmatter (default `2`, range `0–5`).
+- For each retry: re-dispatch the implementer in `fix` mode with the review artifact and findings, then re-dispatch the reviewer.
+- On `pass` → exit the loop; the phase disposition becomes `merged` (sequential) or `merged` (parallel, after fan-in).
+- On retries exhausted:
+  - **Sequential mode:** STOP the run with phase id, unresolved findings, and review artifact path.
+  - **Parallel group mode:** mark the phase `excluded`, do not merge its worktree, continue the remaining phases in the group, and report it in Outstanding Items.
+
+Tier is never silently downgraded. If a Tier 1 dispatch has a transient failure, the orchestrator retries exactly once; a second failure is treated the same as fix-loop exhaustion for that phase.
+
+## Plan-declared parallelism
+
+Phases whose task file sets do not overlap may execute concurrently. Declare this in `plan.md` frontmatter:
+
+```yaml
+oat_plan_parallel_groups: [['p02', 'p03'], ['p04', 'p05']]
+```
+
+- Each inner array is a group of phases that run concurrently — one worktree per phase.
+- Phases not listed in any group run sequentially in plan order.
+- Groups themselves run sequentially — group `[p02, p03]` merges before group `[p04, p05]` starts.
+- Empty or missing field → fully sequential, no worktrees created, behavior identical to today's `oat-project-implement`.
+
+### How a parallel group runs
+
+1. **Bootstrap worktrees** via `oat-worktree-bootstrap-auto`, one per phase, branch name `{project-name}/{pNN}`.
+   - If any bootstrap fails, cancel successful worktrees and **degrade the entire group** to sequential inline execution.
+2. **Concurrent dispatch** of `oat-phase-implementer` into each worktree (Tier 1 only — Tier 2 cannot run concurrently and also degrades to sequential).
+3. **Wait for terminal verdicts** (`pass` or `failed`) across every phase in the group.
+4. **Fan-in reconciliation in plan order:** for each passing phase, `git merge --no-ff {project-name}/{pNN}`. Integration verification (`pnpm test && pnpm lint && pnpm type-check`) runs after each merge.
+5. **Failed phases are excluded** — their worktrees are preserved and logged in `implementation.md` Outstanding Items. Passing phases still merge (partial merge-back, not atomic).
+6. **Worktree cleanup** runs for merged phases; preserved for excluded phases.
+7. **Bookkeeping commit** + HiLL checkpoint check after the group finishes.
+
+### Merge-conflict handling
+
+When a merge produces a conflict:
+
+1. `git merge --no-ff` is aborted.
+2. `git cherry-pick` of the phase's commits is attempted.
+3. If cherry-pick also conflicts, an **inline conflict-resolution subagent** is dispatched via the Task tool. The orchestrator **never reads conflicted files itself** — that context belongs in a fresh subagent.
+4. The subagent reads conflicted files and project artifacts (`plan.md`, `design.md`, `spec.md`), applies a resolution, runs integration verification, and returns:
+   - `RESOLVED` → merge is committed; orchestrator proceeds.
+   - `UNRESOLVABLE` or `VERIFICATION_FAILED` → STOP the run with phase id, conflicting files, worktree path, and the subagent's reasoning summary.
+
+The orchestrator does not proceed past a broken merge.
+
+## Validating plan metadata
+
+Before dispatching, `oat-project-implement` invokes the validator CLI:
+
+```bash
+oat project validate-plan --project-path "${PROJECT_PATH}"
+```
+
+The command enforces:
+
+- `oat_plan_parallel_groups` is either missing/empty (treated as fully sequential) or a non-empty nested array of phase ID strings.
+- Every referenced phase id exists in the plan body.
+- No phase id appears in more than one group.
+- No singleton groups (each group must contain at least 2 phases).
+- Frontmatter YAML parses cleanly — malformed frontmatter fails with exit 1.
+
+Non-zero exit stops the run. The skill does not re-implement validation in prose — the CLI is the single source of truth.
+
+## Dry-run mode
+
+Run with `--dry-run` to preview a run without dispatching anything:
+
+```bash
+oat-project-implement --dry-run
+```
+
+Dry-run:
+
+- Performs tier selection and plan validation.
+- Builds the execution schedule (singleton phases + parallel groups in plan order).
+- Prints the planned dispatches and worktree layout.
+- Exits 0 without dispatching subagents, creating worktrees, or modifying files.
+
+Use dry-run as a sanity check after editing `oat_plan_parallel_groups` to confirm the schedule matches your intent.
+
+## Resumption
+
+On re-invocation after a partial run:
+
+1. Read `implementation.md` for the most recent orchestration-runs entry.
+2. Compare phase counts against the plan's phase list; phases not covered by any run are the resume targets.
+3. Read `state.md` for `oat_current_task` and cross-check with git log.
+4. If a phase committed implementer output but has no review verdict recorded, the reviewer is re-dispatched for that phase's current HEAD.
+5. If un-cleaned worktrees remain from a prior parallel group, the orchestrator lists them and asks whether to resume or clean up.
+
+First-ever invocations skip resumption detection.
+
+## State and artifact updates
+
+After each phase (or parallel group) completes, `oat-project-implement` updates:
+
+- `implementation.md` — appends a `### Run N` entry between the `<!-- orchestration-runs-start -->` markers with tier, policy, phase outcomes, parallel groups, and outstanding items.
+- `plan.md` — updates the reviews table lifecycle (`pending` → `passed` or `fixes_added` → `fixes_completed` → `passed`).
+- `state.md` — updates `oat_current_task`, `oat_last_commit`, `oat_project_state_updated`, and persists `oat_orchestration_retry_limit` if the user overrode the default.
+
+Legacy `oat_execution_mode: subagent-driven` in existing projects is silently ignored and removed on the next bookkeeping write.
+
+## Related
+
+- [Lifecycle](lifecycle.md) — where implementation sits in the full project flow.
+- [Artifacts](artifacts.md) — `plan.md` frontmatter contract, including `oat_plan_parallel_groups`.
+- [HiLL Checkpoints](hill-checkpoints.md) — orthogonal pause semantics; fires after a phase or group completes and merges.
+- [CLI Reference](../../reference/cli-reference.md) — `oat project validate-plan` and other commands.

package/assets/docs/workflows/projects/lifecycle.md

@@ -13,7 +13,7 @@ OAT lifecycle order:
 2. Spec (`oat-project-spec`)
 3. Design (`oat-project-design`)
 4. Plan (`oat-project-plan`)
-5. Implement (`oat-project-implement` or `oat-project-subagent-implement`)
+5. Implement (`oat-project-implement`)
 6. Review loop (`oat-project-review-provide` / `oat-project-review-receive`)
 7. Summary (`oat-project-summary`) — generates `summary.md` as institutional memory; `oat-project-pr-final` and `oat-project-complete` auto-refresh it when missing or stale
 8. PR (`oat-project-pr-progress` / `oat-project-pr-final`) — sets `pr_open` status
@@ -34,12 +34,8 @@ OAT lifecycle order:
 ```mermaid
 flowchart LR
   D["Discovery"] --> S["Spec"] --> G["Design"] --> P["Plan"]
-  P --> M{"Implementation mode"}
-  M --> I1["Sequential"]
-  M --> I2["Subagent-driven"]
-  I1 --> R["Review loop"]
-  I2 --> R
-  R --> PR["PR flow"]
+  P --> I["Implement (oat-project-implement)"]
+  I --> R["Review loop"] --> PR["PR flow"]
   PR --> DOC["Docs sync (optional)"]
   DOC --> C["Complete"]
 ```
@@ -83,16 +79,23 @@ Actual PR existence is tracked separately from `oat_phase_status`:
 
 This distinction matters during completion: `oat-project-complete` can skip the "Open a PR?" prompt when `oat_pr_status: open` is already present.
 
-### Auto-review at checkpoints
+### Auto-review at HiLL checkpoints
 
-When `autoReviewAtCheckpoints` is enabled (via `.oat/config.json` or `plan.md` frontmatter `oat_auto_review_at_checkpoints`), completing a plan phase checkpoint automatically spawns a subagent code review scoped to every implementation phase not already covered by a passed whole-phase code review, through the just-completed checkpoint. Mid-implementation multi-phase reviews use inclusive phase-range scopes such as `p02-p03`; the final implementation checkpoint uses `code final`. The review uses auto-disposition mode (minors auto-converted to fix tasks, no user prompts). Disabled by default.
+When `workflow.autoReviewAtHillCheckpoints` is enabled or `plan.md` frontmatter sets `oat_auto_review_at_hill_checkpoints`, completing a HiLL checkpoint automatically runs the extra lifecycle review scoped to every implementation phase not already covered by a passed whole-phase code review, through the just-completed checkpoint. Mid-implementation multi-phase reviews use inclusive phase-range scopes such as `p02-p03`; the final implementation checkpoint uses `code final`. The review uses auto-disposition mode (minors auto-converted to fix tasks, no user prompts). Disabled by default. Legacy `autoReviewAtCheckpoints` and `oat_auto_review_at_checkpoints` are still read as fallbacks. This does not control Tier 1 per-phase `oat-reviewer` gates.
 
 ## Implementation modes
 
-- **Sequential (default):** `oat-project-implement`
-- **Parallel/subagent-driven:** `oat-project-subagent-implement`
-- Use `oat project set-mode <single-thread|subagent-driven>` to persist mode in project state.
-- `oat-project-implement` remains the canonical consumer and redirects when mode is `subagent-driven`.
+`oat-project-implement` v2.0 dispatches one subagent per phase (not per task). Capability detection at skill start selects a tier, locked for the run:
+
+- **Tier 1 (subagents):** native subagent dispatch via Claude Code, Cursor, or Codex with spawn authorization.
+- **Tier 2 (inline):** orchestrator reads the agent files and executes the process itself when subagents are unavailable or authorization is declined.
+
+Within either tier, parallelism is expressed as plan metadata:
+
+- **Sequential (default):** plans with no `oat_plan_parallel_groups` field, or with an empty array. Phases run in plan order on the orchestration branch.
+- **Parallel groups:** phases listed together in `oat_plan_parallel_groups` run concurrently in worktrees (Tier 1 only) and merge back to the orchestration branch in plan order. Groups themselves execute sequentially.
+
+See [Implementation Execution](implementation-execution.md) for the full execution model — tier detection, bounded fix loop, fan-in, merge-conflict handling, dry-run, and resumption.
 
 ## Review receive behavior
 
@@ -106,18 +109,14 @@ When `autoReviewAtCheckpoints` is enabled (via `.oat/config.json` or `plan.md` f
 
 1. `oat-project-quick-start` (adaptive discovery — provide a project name and optional description; if only the name is provided, quick-start asks for the missing description before discovery. Well-understood requests synthesize quickly, exploratory requests invest in solution space exploration)
 2. Decision point: straight to plan, optional lightweight `design.md`, or promote to spec-driven
-3. Implement:
-   - `oat-project-implement` (sequential)
-   - `oat-project-subagent-implement` (parallel/subagent-driven)
+3. Implement: `oat-project-implement` (sequential by default; parallel when `oat_plan_parallel_groups` is declared)
 4. `oat-project-review-provide` / `oat-project-pr-final`
 5. Optional `oat-project-promote-spec-driven` to backfill spec-driven lifecycle artifacts in-place
 
 ### Import lane diagram
 
 1. `oat-project-import-plan`
-2. Implement:
-   - `oat-project-implement` (sequential)
-   - `oat-project-subagent-implement` (parallel/subagent-driven)
+2. Implement: `oat-project-implement` (sequential by default; parallel when `oat_plan_parallel_groups` is declared)
 3. `oat-project-review-provide` / `oat-project-pr-final`
 4. Optional `oat-project-promote-spec-driven` to switch project mode to spec-driven lifecycle
 
@@ -128,10 +127,8 @@ When `autoReviewAtCheckpoints` is enabled (via `.oat/config.json` or `plan.md` f
 ```mermaid
 flowchart LR
   D["Discover"] --> S["Spec"] --> G["Design"] --> P["Plan"]
-  P --> I1["Implement (oat-project-implement)"]
-  P --> I2["Implement (oat-project-subagent-implement)"]
-  I1 --> R["Review"] --> PR["PR"] --> Doc["Docs (optional)"] --> C["Complete"]
-  I2 --> R
+  P --> I["Implement (oat-project-implement)"]
+  I --> R["Review"] --> PR["PR"] --> Doc["Docs (optional)"] --> C["Complete"]
 ```
 
 ### Quick lane
@@ -142,10 +139,8 @@ flowchart LR
   D -->|Straight to plan| P["Plan"]
   D -->|Lightweight design| LD["Design (quick)"] --> P
   D -->|Promote| SD["→ Spec-Driven lane"]
-  P --> QI1["Implement (oat-project-implement)"]
-  P --> QI2["Implement (oat-project-subagent-implement)"]
-  QI1 --> QR["Review / PR"]
-  QI2 --> QR
+  P --> QI["Implement (oat-project-implement)"]
+  QI --> QR["Review / PR"]
 ```
 
 ### Import lane
@@ -153,9 +148,7 @@ flowchart LR
 ```mermaid
 flowchart LR
   I["Import Plan"] --> II1["Implement (oat-project-implement)"]
-  I --> II2["Implement (oat-project-subagent-implement)"]
   II1 --> IR["Review / PR"]
-  II2 --> IR
 ```
 
 ### Capture lane

package/assets/docs/workflows/projects/reviews.md

@@ -56,9 +56,11 @@ Status progression in `plan.md` Reviews table:
 - Minor (non-final scopes): do not auto-defer by default. Convert when likely future cleanup or when the fix is trivial; defer only with recorded rationale.
 - Minor (final scope): not auto-deferred; require explicit user disposition (defer vs convert), and recommend convert when likely future cleanup or trivial to fix.
 
-## Auto-review at checkpoints
+## Auto-review at HiLL checkpoints
 
-When `autoReviewAtCheckpoints` is enabled (via `oat config set autoReviewAtCheckpoints true` or per-project in `plan.md` frontmatter), completing a plan phase checkpoint automatically spawns a subagent review. The review scope covers every implementation phase not already covered by a passed whole-phase code review, through the just-completed checkpoint. Mid-implementation multi-phase checkpoint reviews use inclusive phase-range scopes such as `p02-p03`. The final phase checkpoint triggers a `code final` review.
+When `workflow.autoReviewAtHillCheckpoints` is enabled (for example, `oat config set workflow.autoReviewAtHillCheckpoints true --user`) or per-project `plan.md` frontmatter sets `oat_auto_review_at_hill_checkpoints`, completing a HiLL checkpoint automatically runs the extra lifecycle review. The review scope covers every implementation phase not already covered by a passed whole-phase code review, through the just-completed checkpoint. Mid-implementation multi-phase checkpoint reviews use inclusive phase-range scopes such as `p02-p03`. The final phase checkpoint triggers a `code final` review.
+
+This is separate from Tier 1 phase gate reviews. Tier 1 implementation always runs `oat-reviewer` after each phase; `workflow.autoReviewAtHillCheckpoints` only controls the additional lifecycle review when a HiLL checkpoint is reached. Legacy `autoReviewAtCheckpoints` and `oat_auto_review_at_checkpoints` are still read as fallbacks.
 
 Auto-triggered reviews use `oat_review_invocation: auto` in the review artifact frontmatter. In auto mode, `oat-project-review-receive` auto-converts all findings to fix tasks without user prompts (Minor findings that are clearly out of scope are deferred with a note).
 

package/assets/docs/workflows/skills/index.md

@@ -52,7 +52,6 @@ Use this section when you want to choose the right OAT skill for a task. If you
     - `oat-project-plan`
     - `oat-project-plan-writing`
     - `oat-project-implement`
-    - `oat-project-subagent-implement`
     - `oat-project-progress`
     - `oat-project-next`
     - `oat-project-capture`

package/assets/public-package-versions.json

@@ -1,6 +1,6 @@
 {
-  "cli": "0.0.42",
-  "docs-config": "0.0.42",
-  "docs-theme": "0.0.42",
-  "docs-transforms": "0.0.42"
+  "cli": "0.0.50",
+  "docs-config": "0.0.50",
+  "docs-theme": "0.0.50",
+  "docs-transforms": "0.0.50"
 }

package/assets/skills/oat-docs-bootstrap/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: oat-docs-bootstrap
-version: 1.0.0
+version: 1.0.1
 description: Use when bootstrapping a new OAT docs app in a repo. Guides the user through preflight detection, richer input gathering than the raw CLI, `oat docs init` invocation with labeled post-patches for open CLI gaps, build verification, post-scaffold config inspection, and an educational walkthrough. Supports Fumadocs (full path) and MkDocs (lean path with defined minimum contract).
 argument-hint: '<optional-target-dir>'
 disable-model-invocation: true
@@ -473,6 +473,7 @@ Capture both stdout and stderr. **Do not** stream output directly to the user; t
     createdFiles: string[]           // paths relative to appRoot
     capabilities: { siteNameFlag: boolean, ... } // from Capability Detection (3b)
     cliLogs: { stdout: string, stderr: string }  // retained for Walkthrough
+    rootBuildPatch: { status, reason?, diff?, manualSnippet? } | null // parsed from CLI output when available
     patchesApplied: []               // populated by 3c/3d site-identity + scaffold-integrity sub-procedures
   ```
 
@@ -655,7 +656,7 @@ Four sub-findings, each with its own gate, target, and idempotency check. All su
   - **D.2 — Generated `index.md` header comment.** The header to prepend:
 
     ```markdown
-    <!-- generated by oat docs generate-index; do not hand-edit. Source: docs/index.md -->
+    <!-- AUTOGENERATED by `oat docs generate-index`. Do not hand-edit; changes are clobbered on every `predev` / `prebuild`. -->
     ```
 
     **Two-pass strategy. Both passes MUST run — do not treat the second as optional.**
@@ -931,6 +932,13 @@ Narrate each field actually present in their config (skip fields that are absent
 - **`documentation.config`** (MkDocs only) — path to `mkdocs.yml`. Present for MkDocs because its chrome/nav is YAML-configured; absent for Fumadocs because chrome is code.
 - **`documentation.requireForProjectCompletion`** — the opt-in collected in Step 5e. If `true`, `oat-project-complete` will block project completion until `oat-docs-analyze` reports no open recommendations. Explain whichever value is set on this project.
 
+If `Scaffold Result.rootBuildPatch` is present, narrate it here before moving on:
+
+- **When `status` is `applied`, `dry-run`, or `already-configured`:** explain why the root `package.json` changed. The point is not cosmetics; it's to keep repo-root `pnpm build` from pulling the new docs app into the consumer's default Turbo build, where React / Next type collisions can break CI. Show the exact script diff from `rootBuildPatch.diff` when available; if the diff was not retained, at minimum quote the before/after values for `scripts.build` and `scripts["build:docs"]`.
+- Make the behavior concrete: `build` now excludes `{appName}` from the default Turbo build graph, and `build:docs` is the explicit root-level command that builds only the docs app.
+- Document the adjustment/revert path explicitly: "If you want different scope behavior, edit the root `package.json` `scripts.build` and `scripts["build:docs"]` entries together. Removing the extra `--filter='!{appName}'` restores the old all-packages build; changing `build:docs` changes the docs-only target."
+- **When `status` is `skipped`:** surface the skip reason in plain language, then print `rootBuildPatch.manualSnippet` verbatim as the recommended manual Turbo snippet to add. Explain that OAT intentionally left the root scripts alone because it could not prove the existing root build was a Turbo build it was safe to rewrite.
+
 End with: "This config is how every OAT docs tool finds your docs. Editing it by hand is supported — but changes to `root` or `config` paths need to match reality on disk."
 
 #### Section B (both frameworks) — The two `index.md` files
@@ -941,7 +949,7 @@ Narrate:
 
 - **The authored source** at `<appRoot>/docs/index.md`. This is the file the user edits. It has frontmatter (`title`, `description`) and a `## Contents` section listing direct children of the docs root. It is the top of a fractal: every directory has its own `index.md`, each with its own `## Contents`.
 - **The generated map** at `<appRoot>/index.md` (when Fumadocs — the path differs for MkDocs; use the `documentation.index` path resolved by the Inspector if it differs). Regenerated on every `predev` / `prebuild` by the `oat docs generate-index` command. Machine-shaped: rolls up every `## Contents` section in the tree into a single searchable map that tools consume. **Hand-edits are silently clobbered.**
-- **How to tell them apart when opening a file.** If the file sits inside `docs/`, it's authored. If it sits at `<appRoot>/index.md` (outside `docs/`), it's generated — and if Scaffold-integrity FP-13/D.2 patched it, the first line is a `<!-- generated … -->` banner confirming so.
+- **How to tell them apart when opening a file.** If the file sits inside `docs/`, it's authored. If it sits at `<appRoot>/index.md` (outside `docs/`), it's generated — and when the CLI or Scaffold-integrity FP-13/D.2 wrote the warning correctly, the first line is `<!-- AUTOGENERATED by \`oat docs generate-index\`... -->`.
 
 End with: "Always edit `docs/index.md` and the `## Contents` sections. Never edit the root-level `index.md` — your edits will disappear next build."
 

package/assets/skills/oat-doctor/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: oat-doctor
-version: 1.0.0
+version: 1.0.2
 description: Use when you need to diagnose your OAT setup, check for outdated skills, identify misconfigurations, or get a summary of installed tools and config. Runs health checks and recommends corrective actions.
 argument-hint: '[--summary]'
 disable-model-invocation: true
@@ -160,7 +160,7 @@ Workflow pack skills:
 - oat-project-promote-spec-driven, oat-project-quick-start
 - oat-project-reconcile, oat-project-revise, oat-project-review-provide
 - oat-project-review-receive, oat-project-review-receive-remote
-- oat-project-spec, oat-project-subagent-implement, oat-project-summary
+- oat-project-spec, oat-project-summary
 - oat-repo-knowledge-index, oat-worktree-bootstrap, oat-worktree-bootstrap-auto
 
 Ideas pack skills:
@@ -263,7 +263,7 @@ Read config key descriptions from `~/.oat/docs/reference/file-locations.md` and
 - **documentation.config:** Path to docs config file (e.g., mkdocs.yml).
 - **documentation.tooling:** Docs tooling in use (e.g., mkdocs, fumadocs).
 - **documentation.requireForProjectCompletion:** Whether docs update is required before project completion.
-- **autoReviewAtCheckpoints:** When true, completing a plan phase checkpoint auto-triggers a subagent code review. Default false. Can be overridden per-project via `oat_auto_review_at_checkpoints` in plan.md frontmatter.
+- **workflow.autoReviewAtHillCheckpoints:** When true, completing a HiLL checkpoint auto-triggers the lifecycle review. Default unset. This does not control Tier 1 per-phase `oat-reviewer` gates. Can be overridden per-project via `oat_auto_review_at_hill_checkpoints` in plan.md frontmatter. Legacy `autoReviewAtCheckpoints` and `oat_auto_review_at_checkpoints` are still read as fallbacks.
 - **worktrees.root:** Base directory for git worktrees. Used by worktree-bootstrap skills.
 
 ## Sync Status