@open-agent-toolkit/cli 0.2.58 → 0.2.62

package/assets/docs/workflows/projects/hill-checkpoints.md

@@ -38,6 +38,27 @@ Semantics:
 - Empty list: checkpoint after every phase boundary, but only after implementation has confirmed the choice and written `oat_plan_hill_phases: []` into `plan.md`.
 - Explicit list: checkpoint only after completing the named phases (`p01`, `p04`, etc).
 
+### Lite checkpoint bypass
+
+Lite projects have no HiLL checkpoints. `oat-project-implement` resolves
+`oat_workflow_mode` from project state before any checkpoint field read, and
+when the mode is `lite` it resolves checkpoint state as `none` without reading
+or interpreting `oat_plan_hill_phases`. An empty list cannot represent lite's
+policy, because for every other mode an empty list means "checkpoint after every
+phase". `oat-project-implement`'s Lite checkpoint bypass writes:
+
+```yaml
+oat_auto_review_at_hill_checkpoints: false # lite: no checkpoints
+```
+
+The workflow preference prompt, the standard checkpoint prompt, and the
+auto-review preference prompt are all skipped in both interactive and autonomous
+runs. Only HiLL approval pauses are absent — the root-owned per-phase review and
+the final review remain required.
+
+The rest of this section applies to `spec-driven`, `quick`, and `import`
+projects.
+
 On the first implementation run, `oat-project-implement` must summarize every plan phase, state the total phase count and final phase ID, and then ask an explicit three-option checkpoint question:
 
 - Stop after each phase

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

@@ -250,8 +250,11 @@ for another.
 
 Resolution and policy outcomes are explicit:
 
-- A null resolution persists `allowed/no_gate` for the current implementation
-  basis.
+- A `not_configured` resolution persists `allowed/no_gate` for the current
+  implementation basis; a null, missing, or unrecognized resolver result fails
+  closed as unresolved instead.
+- A gate the project disabled persists `allowed/configured` with
+  `disposition: project_disabled` and never launches.
 - A configured passing review persists `allowed/passed` after any eligible
   review receive is durably completed.
 - `warn` persists `allowed/warned`; `prompt` proceeds only after explicit
@@ -423,6 +426,11 @@ For a plan-declared parallel group, the root:
 Containment, ownership, base, or fixture-readiness failure in smoke mode aborts
 the run. It never authorizes replacement or sequential degradation.
 
+Lite plans never take this path. A lite `plan.md` must contain exactly one phase
+and declare no parallel groups, so lite implementation is always sequential;
+`oat project validate-plan` enforces both rules. Work that needs more than one
+phase should promote to quick rather than declare a parallel group.
+
 ## Synced projects in worktrees
 
 A tracked `.oat/projects/synced/<project>.json` record lets every repository

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

@@ -1,6 +1,6 @@
 ---
 title: Lifecycle
-description: 'End-to-end phase flow from discovery through completion: spec-driven, quick, and import paths.'
+description: 'End-to-end phase flow from discovery through completion: spec-driven, quick, lite, and import paths.'
 ---
 
 # Lifecycle
@@ -27,9 +27,9 @@ Full spec-driven design supports three interaction modes: collaborative, selecti
 
 ## Quick Look
 
-- What it does: explains the end-to-end lifecycle for tracked OAT projects, including alternate quick and import lanes.
+- What it does: explains the end-to-end lifecycle for tracked OAT projects, including alternate quick, lite, and import lanes.
 - When to use it: when you need the actual project execution model, not just a high-level overview of workflow mode.
-- Primary entry points: `oat-project-new`, `oat-project-quick-start`, `oat-project-import-plan`, `oat-project-implement`
+- Primary entry points: `oat-project-new`, `oat-project-quick-start`, `oat-project-lite`, `oat-project-import-plan`, `oat-project-implement`
 
 ## Lifecycle Map
 
@@ -42,6 +42,10 @@ flowchart LR
   DOC --> C["Complete"]
 ```
 
+This map shows the spec-driven default. The quick, lite, import, and capture
+lanes each skip part of it — see [Lane diagrams](#lane-diagrams) below. Lite in
+particular has no discovery, spec, or design step at all.
+
 ## Post-implementation flow
 
 Implementation closeout has one authoritative order:
@@ -56,9 +60,10 @@ Implementation closeout has one authoritative order:
 
 The configured exit gate is independent from the mandatory lifecycle review,
 root-owned phase reviews, and optional `oat_phase_review_gate`. It must reach an
-allowed and fresh disposition before pre-approval work starts. A null
-configuration is recorded explicitly as `allowed/no_gate`; it is not inferred
-from missing state.
+allowed and fresh disposition before pre-approval work starts. A
+`not_configured` resolution is recorded explicitly as `allowed/no_gate`; it is
+not inferred from missing state, and a null, missing, or unrecognized resolver
+result fails closed as unresolved instead.
 
 After implementation closeout finishes:
 
@@ -72,6 +77,37 @@ After implementation closeout finishes:
    - After revision tasks complete, state returns to `pr_open`
 5. **Complete** (`oat-project-complete`) — accepts any phase status (`pr_open`, `complete`, `in_progress`), auto-refreshes `summary.md` before closeout when needed, and archives when selected by the workflow preference or completion prompt
 
+### Project-recap gate (non-lite)
+
+The final-closeout orchestrator owns one project-recap gate. It runs after the
+final code review has passed and after any configured pre-approval summary and
+documentation steps, but before final HiLL approval. It neither replaces nor
+repeats the final review, and the stored order of the other pre-approval steps
+is preserved.
+
+Recap intent resolves through `oat-explainer-kit`. A fresh `project-recap`
+manifest for the current completed implementation is reused rather than
+regenerated — fresh means it names recipe `project-recap`, belongs to this
+project, has a terminal outcome, and its recorded source hashes match the
+current approved inputs. A present-but-incomplete, wrong-recipe, or stale
+manifest does not qualify.
+
+Recap outcomes are reported, not blocking: `failed` and `built-not-durable` are
+recorded as warnings and never block final approval, completion reporting, or
+later PR steps. The selected or attempted outcome and run path are included in
+the implementation completion report, and `summary.md` carries a single
+`Explainer Outcome` section when it exists.
+
+**Lite skips this gate entirely.** Lite sets `PROJECT_RECAP_REACHABLE=false` and
+does not resolve recap intent, inspect recap runs, invoke `oat-explainer-kit`,
+or run the terminal-outcome guard. It proceeds from the required reviews through
+its stored optional steps to `pr` and sequence completion.
+
+Lite mode collapses the default pre-approval sequence to PR creation only.
+`oat-project-pr-final` builds the body directly from the lite plan and
+`implementation.md`; summary and documentation remain explicit lite opt-ins,
+and retro is not added to the lite closeout sequence.
+
 ### Completion archive behavior
 
 On completion, OAT treats archive handling as an explicit closeout choice:
@@ -166,7 +202,9 @@ When `workflow.autoReviewAtHillCheckpoints` is enabled or `plan.md` frontmatter
 ### Phase-review setup during planning
 
 Spec-driven, quick, and import planning run one shared setup after stable phase
-IDs exist and before the plan artifact review. The target probe qualifies only
+IDs exist and before the plan artifact review. Lite omits this planning-time
+setup and prompt, while its built-in implementation phase and final reviews
+remain required. The target probe qualifies only
 an explicitly configured, enabled, and available review target, then offers all
 phases, selected phases, or disabled. Existing explicit
 `oat_phase_review_gate` values are preserved unchanged without re-prompting.
@@ -213,6 +251,13 @@ See [Implementation Execution](implementation-execution.md) for the full executi
 4. `oat-project-review-provide` / `oat-project-pr-final`
 5. Optional `oat-project-promote-spec-driven` to backfill spec-driven lifecycle artifacts in-place
 
+### Lite lane diagram
+
+1. `oat-project-lite` runs one batched interview, authors a single-phase `plan.md` with validation criteria, and pauses once for approval
+2. Implement: `oat-project-implement` runs the single phase without HiLL checkpoint prompts
+3. Pass the mandatory final review, then route directly to `oat-project-pr-final`
+4. Optional `oat project promote <project-path> --to quick` when the work no longer fits one sitting
+
 ### Import lane diagram
 
 1. `oat-project-import-plan` (checks inherited git state before import scaffolding so sync-generated or unrelated dirty files do not silently roll into project bookkeeping)
@@ -268,6 +313,75 @@ still read as compatibility capped-policy input, but new quick-start selections
 should use the dispatch-policy names, including explicit `Uncapped` and
 `Inherit Host Defaults`.
 
+### Lite lane
+
+```mermaid
+flowchart LR
+  L["Lite interview\n(one batched round)"] --> P["Single-phase plan\n(one approval)"]
+  P --> I["Implement (oat-project-implement)"]
+  I --> R["Final review"] --> PR["PR (default closeout)"]
+  P -->|Scope grows| Q["Promote to Quick"]
+```
+
+Lite keeps planning and validation in `plan.md`. The interview selects a
+`minimal`, `product`, `technical`, or `both` content shape and records the
+rationale. Product Behavior is required for user-visible changes; Technical
+Design is required for cross-module, data/state-format, or consumed-contract
+changes. It has no separate discovery, spec, or design artifact, skips
+implementation HiLL prompts, and routes a passed final review directly to PR
+creation. Summary and documentation run only when enabled through the
+lite-specific post-implementation sequence.
+
+Each task chooses evidence proportionate to its risk instead of requiring one
+test-first recipe. Behavioral changes need a proof that fails without the
+change; refactors default to characterization-first when existing coverage is
+insufficient; documentation-only work may use formatting, link, spelling, or
+build checks. UI changes require visual proof. In autonomous runs, available
+computer-use capability performs that proof; otherwise execution stops at an
+explicit proof boundary.
+
+### Promoting a lite project to quick
+
+When lite work outgrows one sitting, `oat project promote <project-path> --to quick`
+converts it in place. Each artifact has a different fate: the authored lite plan
+is **moved** to `references/lite-plan.md`, a new `discovery.md` is **derived**
+from its five core sections plus any adaptive Product Behavior and Technical
+Design, a **fresh** quick template takes over the `plan.md` path, and `state.md`
+is **rewritten** to quick mode.
+
+```mermaid
+flowchart LR
+  subgraph Before
+    LPLAN["plan.md\nfive core sections plus adaptive\nProduct Behavior / Technical Design"]
+    LSTATE["state.md\noat_workflow_mode: lite"]
+  end
+
+  CMD["oat project promote\n--to quick"]
+
+  subgraph After
+    DISC["discovery.md\nderived from the lite plan\noat_ready_for: oat-project-quick-start"]
+    REF["references/lite-plan.md\noriginal lite plan, preserved"]
+    QPLAN["plan.md\nfresh quick-start template"]
+    QSTATE["state.md\noat_workflow_mode: quick\noat_phase: discovery (complete)\noat_ready_for: oat-project-quick-start"]
+  end
+
+  LPLAN --> CMD
+  LSTATE --> CMD
+  CMD -->|derive| DISC
+  CMD -->|move| REF
+  CMD -->|scaffold| QPLAN
+  CMD -->|rewrite| QSTATE
+```
+
+The project slug, directory, and branch are untouched, so history and any open
+work continue uninterrupted. `oat_ready_for` is stamped on **both** `discovery.md`
+and `state.md`; the quick-start recommender reads artifact readiness, so
+consumers must preserve both. Promotion refuses rather than half-applying: a
+non-lite project, an existing `references/lite-plan.md`, invalid authored
+sections, an unresolved scope, or an unreadable template each return a stable
+categorical `reason` and exit non-zero. See
+[CLI Reference](../../reference/cli-reference.md) for the full refusal contract.
+
 ### Import lane
 
 ```mermaid
@@ -303,6 +417,10 @@ Quick lane progression:
 
 `discovery.md` -> [`design.md` (optional lightweight)] -> `plan.md` -> `implementation.md`
 
+Lite lane progression:
+
+`plan.md` -> `implementation.md` -> `pr/*.md` (`summary.md` and documentation are opt-in)
+
 Import lane progression:
 
 `references/imported-plan.md` -> `plan.md` -> `implementation.md` (`spec.md`/`design.md` optional)
@@ -359,15 +477,15 @@ actionable `oat pjm init` stop instead of scaffolding implicitly. See
 
 ### Seeding a new project from a brainstorm
 
-When the brainstorming destination is "promote to a new OAT project", the dispatcher confirms a project slug and a mode (`quick` vs `spec-driven`) with the user, runs `oat project new <slug> --mode <mode>` to scaffold the project, and writes the new project's `discovery.md` directly from the brainstorming payload — Initial Request, Solution Space with approaches considered, Chosen Direction, Key Decisions, Open Questions. It writes `discovery.md` only (never a partial `design.md`), so the design phase keeps its full collaborative cadence and consumes the brainstorm's architectural intent from discovery's Solution Space and Chosen Direction sections during approach reaffirmation. The dispatcher stops with a pointer to `oat-project-quick-start` or `oat-project-design` — it deliberately does not auto-chain into the next phase, so the user makes that transition consciously.
+When the brainstorming destination is "promote to a new OAT project", the dispatcher confirms a project slug and one of three modes: `lite`, `quick`, or `spec-driven`. For Quick and Spec-Driven projects, it runs `oat project new <slug> --mode <mode>` and writes `discovery.md` directly from the brainstorming payload — Initial Request, Solution Space with approaches considered, Chosen Direction, Key Decisions, and Open Questions. It writes only `discovery.md` (never a partial `design.md`), then points to `oat-project-quick-start` or `oat-project-design` without auto-chaining. For Lite projects, it instead seeds the five sections in `plan.md`, leaves `discovery.md` and `design.md` absent, and points to `oat-project-lite`.
 
-This is a parallel entry path into the Spec-Driven and Quick lanes, not a new lane: the resulting project follows the normal lane it was scaffolded into. The brainstorm-as-seed step is what changes — the user arrives at `oat-project-quick-start` (or `oat-project-design`) with discovery already populated rather than starting from a blank discovery template.
+This is a parallel entry path into all three lanes, not a new lane. Quick and Spec-Driven users arrive at `oat-project-quick-start` or `oat-project-design` with discovery already populated; Lite users arrive at `oat-project-lite` with the single-phase plan already seeded.
 
 ### Folding back into an active project
 
 When `oat-brainstorm` fires while a project is active, it offers a 3-way picker before any pack-filtered destination shows up:
 
-- **Related to the project** → fold the synthesized brainstorming content back into the most-specific upstream artifact (`design.md` if it exists, otherwise `discovery.md`), commit immediately, and print a handoff prompt for the right plan-authoring skill (`oat-project-plan` for spec-driven, `oat-project-quick-start` for quick, `oat-project-revise` when an open PR exists). The fold-back commit is safety-gated: a preflight `git status --porcelain -- "$ARTIFACT_PATH"` checks for dirty state, staging is exactly `git add -- "$ARTIFACT_PATH"` (never `-A`, never globs), and the handoff prompt only prints after the scoped commit succeeds.
+- **Related to the project** → for Lite, fold the synthesis into `plan.md` immediately above `## Phase 1` and hand off to `oat-project-lite`; for Quick and Spec-Driven, use the most-specific upstream artifact (`design.md` if it exists, otherwise `discovery.md`) and hand off to `oat-project-quick-start` or `oat-project-plan`. Any mode with an open PR hands off to `oat-project-revise`. The fold-back commit is safety-gated: a preflight `git status --porcelain -- "$ARTIFACT_PATH"` checks for dirty state, staging is exactly `git add -- "$ARTIFACT_PATH"` (never `-A`, never globs), and the handoff prompt only prints after the scoped commit succeeds.
 - **Independent of the project** → the active project is acknowledged but doesn't constrain the picker; brainstorm routes through its standard pack-filtered terminal-state options (new project, backlog item, idea, doc-to-path, inline).
 - **Related but supplementary** → write a brainstorming reference file at `.oat/projects/<scope>/<project>/brainstorming/YYYY-MM-DD-<topic>.md`, alongside `pr/` and `reviews/`. No lifecycle artifact is touched.
 

package/assets/docs/workflows/projects/pr-flow.md

@@ -17,10 +17,12 @@ Expected artifacts:
 - Required (all modes): `plan.md`
 - Required (spec-driven mode): `spec.md`, `design.md`
 - Optional (quick/import): `spec.md`, `design.md`
+- Not expected (lite): `discovery.md`, `spec.md`, or `design.md`
 - Recommended (quick mode): `discovery.md`
 - Recommended (import mode): `references/imported-plan.md`
 - Recommended: `implementation.md` final summary
 - Recommended: `summary.md` — pr-final treats it as the primary source for the PR Summary section and automatically refreshes it first when missing or stale
+- Lite source row: `oat-project-pr-final` uses the plan's Summary, Decisions, and Validation Criteria plus the `implementation.md` Final Summary; it does not create `summary.md` unless lite closeout explicitly opts in
 - Required gate for final PR: review table final row should be `passed`
 
 ## Output

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

@@ -173,7 +173,7 @@ This feature is opt-in and disabled by default (missing or `enabled: false`). Fo
 
 Generated planning and analysis artifacts have a separate review loop from code/phase reviews.
 
-For plans, `oat-project-plan`, `oat-project-quick-start`, and `oat-project-import-plan` run a bounded `plan.md` artifact review before marking the plan ready for implementation. The loop dispatches `oat-reviewer` in structured-output artifact mode with `scope: plan`, applies unambiguous Critical and Important artifact-local fixes, offers Medium and Minor fixes, and re-runs until clean or the retry bound is exhausted. A clean result records the `plan` row in the plan's `## Reviews` table as `passed`.
+For plans, `oat-project-plan`, `oat-project-quick-start`, `oat-project-lite`, and `oat-project-import-plan` run a bounded `plan.md` artifact review before marking the plan ready for implementation. The loop dispatches `oat-reviewer` in structured-output artifact mode with `scope: plan`, applies unambiguous Critical and Important artifact-local fixes, offers Medium and Minor fixes, and re-runs until clean or the retry bound is exhausted. A clean result records the `plan` row in the plan's `## Reviews` table as `passed`.
 
 For analysis artifacts, `oat-docs-analyze` and `oat-agent-instructions-analyze` run a bounded accuracy review after writing their severity-rated artifacts. The reviewer checks cited evidence, severity, and recommendations before the matching apply workflow consumes the artifact. The analysis loop updates tracking metadata to mark the artifact verified.
 

package/assets/docs/workflows/projects/state-machine.md

@@ -32,8 +32,14 @@ flowchart TD
   FA --> FC["Fixes completed"]
   FC --> PASSED["Review passed"]
   PASSED --> I
+
+  LITE["Lite: batched interview\n(no discovery/spec/design)"] -. entry point .-> P
 ```
 
+The solid chain is the spec-driven progression. Lite enters at **Plan in
+progress** and never sets `oat_phase` to `discovery`, `spec`, or `design`;
+quick and import projects also skip part of the leading chain.
+
 ## Phase status values
 
 `oat_phase_status` in `state.md`:
@@ -65,6 +71,20 @@ Typical progression:
 12. Revision loop (optional): `pr_open` → revise → `in_progress` → implement → `pr_open`
 13. Complete
 
+Lite progression:
+
+1. Plan in progress (`oat_workflow_mode: lite`, `oat_phase: plan`)
+2. Ready for implement (one approval; no discovery, spec, or design states)
+3. Implement in progress (single phase, no HiLL checkpoint pauses)
+4. Implement complete (final review passed)
+5. PR open (`pr_open`) — lite closeout routes straight to `oat-project-pr-final`
+6. Complete
+
+A lite project that outgrows one sitting can move to the quick chain with `oat
+project promote <project-path> --to quick`, which flips `oat_workflow_mode` to
+`quick` and sets `oat_phase: discovery` with `oat_phase_status: complete`. See
+[Lifecycle](lifecycle.md#promoting-a-lite-project-to-quick).
+
 ## Review progression
 
 In `plan.md` Reviews table:

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

@@ -18,7 +18,7 @@ Use this section when you want to choose the right OAT skill for a task. If you
 
 ## Key Skills by Use Case
 
-- Start a new tracked project: `oat-project-new` or `oat-project-quick-start` (quick start accepts a project name plus optional description; if you omit the description it should ask before discovery begins)
+- Start a new tracked project: `oat-project-new`, `oat-project-quick-start`, or `oat-project-lite` for a single-sitting change with one batched interview and one approval (quick start accepts a project name plus optional description; if you omit the description it should ask before discovery begins)
 - Resume an existing project: `oat-project-open` and `oat-project-progress`
 - Execute a ready plan: `oat-project-implement`
 - Import an existing plan: `oat-project-import-plan`
@@ -58,6 +58,7 @@ Use this section when you want to choose the right OAT skill for a task. If you
 
     - `oat-project-new`
     - `oat-project-quick-start`
+    - `oat-project-lite`
     - `oat-project-import-plan`
     - `oat-project-promote-spec-driven`
     - `oat-project-open`

package/assets/public-package-versions.json

@@ -1,6 +1,6 @@
 {
-  "cli": "0.2.58",
-  "docs-config": "0.2.58",
-  "docs-theme": "0.2.58",
-  "docs-transforms": "0.2.58"
+  "cli": "0.2.62",
+  "docs-config": "0.2.62",
+  "docs-theme": "0.2.62",
+  "docs-transforms": "0.2.62"
 }

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

@@ -1,6 +1,6 @@
 ---
 name: oat-brainstorm
-version: 1.3.5
+version: 1.3.6
 description: Use when the user explicitly invokes the `brainstorm` verb, including `/oat-brainstorm`, "let's brainstorm", "brainstorm this", "can we brainstorm X", or "help me brainstorm X". For ambiguous exploratory phrasing ("I've been thinking", "what if", "help me think through"), do NOT auto-enter; respond conversationally and offer mode only after ≥2 sustained exploratory turns. Do NOT use for review, debug, PR, status, implementation, or active-workflow questions.
 disable-model-invocation: false
 user-invocable: true
@@ -233,7 +233,7 @@ ACTIVE_PROJECT_PR_STATUS=""
 if [ -n "$ACTIVE_PROJECT" ] && [ -f "$ACTIVE_PROJECT/state.md" ]; then
   ACTIVE_PROJECT_VALID="true"
   # Read state.md frontmatter — extract:
-  #   oat_workflow_mode → ACTIVE_PROJECT_MODE        (e.g., "spec-driven", "quick")
+  #   oat_workflow_mode → ACTIVE_PROJECT_MODE        (e.g., "spec-driven", "quick", "lite")
   #   oat_phase         → ACTIVE_PROJECT_PHASE       (e.g., "discovery", "design", "plan", "implement")
   #   oat_pr_status     → ACTIVE_PROJECT_PR_STATUS   (e.g., "none", "open", "closed")
 fi
@@ -396,8 +396,8 @@ The payload is staged in memory only — it is not persisted between conversatio
   - Capture as new idea → confirm slug.
   - Extend existing idea → confirm which idea (slug or path).
   - Doc-to-path → confirm path.
-  - Promote to new project → confirm slug + workflow mode (`quick` vs `spec-driven`, with skill proposing a default based on the chosen direction and scope signals).
-  - Active-project fold-back → confirm which artifact (`design.md` if exists, else `discovery.md`; user signal can override toward `discovery.md` for foundational changes).
+  - Promote to new project → confirm slug + workflow mode (`lite`, `quick`, or `spec-driven`, with skill proposing a default based on the chosen direction and scope signals).
+  - Active-project fold-back → for lite confirm `plan.md`; otherwise confirm which artifact (`design.md` if exists, else `discovery.md`; user signal can override toward `discovery.md` for foundational changes).
   - Active-project reference file → confirm filename (default `YYYY-MM-DD-<topic>.md`).
 
 - **`none`** (currently `Inline only` and `Summarize idea directly`): no per-field confirmation at this layer. For `Inline only`, write the closing summary directly. For `Summarize idea directly`, hand off — the downstream `oat-idea-summarize` surfaces its own summary for accept/refine review.
@@ -505,13 +505,50 @@ End mode assertion when the backlog-add hands control back.
 
 #### 9g — Promote to new OAT project
 
-The slug and workflow mode (`quick` vs `spec-driven`) were confirmed at step 8. Run:
+The slug and workflow mode (`lite`, `quick`, or `spec-driven`) were confirmed at
+step 8. Run:
 
 ```bash
 oat project new <slug> --mode <mode>
 ```
 
-This scaffolds the project directory under `.oat/projects/<scope>/<slug>/` with the standard core files (state.md, discovery.md, etc.).
+This scaffolds the project directory under `.oat/projects/<scope>/<slug>/` with
+the files owned by the selected mode.
+
+**Lite branch:** When mode is `lite`, use and preserve `<project>/plan.md` as
+the canonical artifact. Fill its `Summary`, `Decisions`, `Assumptions`, `Out of
+Scope`, and `Validation Criteria` sections from the synthesized payload without
+replacing an already populated section or the scaffolded `## Phase 1`. Do not
+create, write, or complete `discovery.md` or `design.md`. Set the project state
+to plan/in-progress with `oat_ready_for: oat-project-lite`, print the
+`oat-project-lite` handoff, and stop.
+
+Use this branch contract to validate the lite scaffold before the handoff:
+
+```bash
+# BEGIN LITE PROJECT PROMOTION CONTRACT
+if [ "$PROMOTION_MODE" = "lite" ]; then
+  LITE_PLAN_PATH="$PROMOTED_PROJECT/plan.md"
+  if [ ! -f "$LITE_PLAN_PATH" ]; then
+    mkdir -p "$PROMOTED_PROJECT"
+    printf '%s\n' '# Plan' '' '## Summary' '' '## Decisions' '' \
+      '## Assumptions' '' '## Out of Scope' '' '## Validation Criteria' '' \
+      '## Phase 1' > "$LITE_PLAN_PATH"
+  fi
+  if [ -e "$PROMOTED_PROJECT/discovery.md" ]; then
+    echo "oat: lite promotion must not create discovery.md" >&2
+    exit 64
+  fi
+  NEXT_SKILL="oat-project-lite"
+else
+  LITE_PLAN_PATH=""
+  NEXT_SKILL="oat-project-quick-start-or-design"
+fi
+# END LITE PROJECT PROMOTION CONTRACT
+```
+
+**Quick/spec-driven branch:** Only for those two modes, continue with the
+discovery flow below.
 
 Then **write a field-filled `discovery.md`** at `<project>/discovery.md` using the synthesized payload:
 
@@ -536,7 +573,7 @@ Print a pointer to the next skill, e.g.:
 
 **Stop here. Do NOT inline-execute the next phase.** The deliberate transition is the point — the user runs the next skill at their own pace.
 
-End mode assertion.
+End mode assertion after the selected branch stops.
 
 #### 9h — Active-project router (3-way picker)
 
@@ -556,14 +593,25 @@ The 3-way router fires once per session. After convergence resumes (e.g., the us
 
 #### 9i — Active project: fold-back to upstream artifact
 
-Uniform across spec-driven and quick modes. Differs only in which plan-authoring skill the handoff prompt addresses (resolved by `ACTIVE_PROJECT_MODE` and `ACTIVE_PROJECT_PR_STATUS`).
+Uniform across spec-driven, quick, and lite modes. Differs only in which plan-authoring skill the handoff prompt addresses (resolved by `ACTIVE_PROJECT_MODE` and `ACTIVE_PROJECT_PR_STATUS`).
 
 **Step 1 — Pick upstream artifact.** Prefer the most-specific existing one:
 
+- For lite, always select `<ACTIVE_PROJECT>/plan.md`. Append `## Brainstorming Update` immediately above `## Phase 1`; lite has no discovery or design artifact.
 - `<ACTIVE_PROJECT>/design.md` if it exists (any mode — quick lightweight design counts).
 - Otherwise `<ACTIVE_PROJECT>/discovery.md`.
 - The user's signal during the conversation can override toward `discovery.md` even when `design.md` exists ("this is foundational" → discovery; "this is a design refinement" → design).
 
+Use this executable artifact-selection contract before confirming the path:
+
+```bash
+# BEGIN LITE FOLD-BACK CONTRACT
+if [ "$ACTIVE_PROJECT_MODE" = "lite" ]; then
+  ARTIFACT_PATH="$ACTIVE_PROJECT/plan.md"
+fi
+# END LITE FOLD-BACK CONTRACT
+```
+
 Confirm the chosen artifact with the user (minimal confirmation per `references/destinations.md`). Set `ARTIFACT_PATH` to the absolute path.
 
 **Persistence invariant:** shared and local project artifacts remain ordinary
@@ -602,7 +650,7 @@ beside another dirty project file must take Step 4.
    ## Brainstorming Update: YYYY-MM-DD — <topic>
    ```
 
-   Section body contains: `chosenDirection` (with rationale), key decisions (extracted from the conversation), and a transcript appendix (`transcriptSessionNote`). Optionally include `openQuestions` and `nextSteps` if surfaced.
+   Section body contains: `chosenDirection` (with rationale), key decisions (extracted from the conversation), and a transcript appendix (`transcriptSessionNote`). Optionally include `openQuestions` and `nextSteps` if surfaced. In lite mode, insert this section above `## Phase 1` in `plan.md` rather than appending after the task plan.
 
 2. Persist **only** the artifact under the scope guard:
 
@@ -621,7 +669,7 @@ beside another dirty project file must take Step 4.
 
    For non-synced projects, use the explicit `--` filename form. **Never `git add -A`. Never directory globs.** Other working-tree paths are not touched by this commit. For synced projects, `FOLD_BACK_COMMIT_SHA` comes from the push JSON rather than the parent branch.
 
-3. `<artifact-basename>` is `design.md` or `discovery.md` depending on which was chosen. `<project-name>` is the active project's slug.
+3. `<artifact-basename>` is `plan.md` for lite, otherwise `design.md` or `discovery.md` depending on which was chosen. `<project-name>` is the active project's slug.
 
 4. If the guarded persistence succeeded → proceed to step 5 (handoff prompt).
 
@@ -695,7 +743,8 @@ Resolve the handoff target by `ACTIVE_PROJECT_MODE` and `ACTIVE_PROJECT_PR_STATU
 | ----------- | ---------------------------- | ------------------------- |
 | spec-driven | none / closed                | `oat-project-plan`        |
 | quick       | none / closed                | `oat-project-quick-start` |
-| either      | open (`oat_pr_status: open`) | `oat-project-revise`      |
+| lite        | none / closed                | `oat-project-lite`        |
+| any mode    | open (`oat_pr_status: open`) | `oat-project-revise`      |
 
 Print the handoff prompt template, substituting `<skill-name>`, `<artifact>`, `<hash>`, and `<subject>` from the actual branch commit or synced push receipt:
 
@@ -771,6 +820,6 @@ End mode assertion when the split handoff completes or reports its own blocker.
 - ✅ Each handoff branch (9a-9k) reads the correct downstream `SKILL.md` path and enters at the documented step. Project promotion writes `discovery.md` only — never `design.md` — and does not auto-chain into the next phase.
 - ✅ Doc-to-path validation handles all four cases: path-is-directory, parent-missing (with explicit out-of-repo confirmation), file-already-exists (overwrite or rename), unwritable (surface OS error).
 - ✅ Fold-back persistence safety contract honored: preflight `git status --porcelain -- "$ARTIFACT_PATH"` runs before any artifact mutation; clean → append + exact-path branch commit for shared/local or validated `oat project push --json` for synced; dirty → three-option picker (persist-prior-first / mix / abort-to-reference-file); handoff prompt prints only after the scope-appropriate receipt succeeds.
-- ✅ Handoff target for fold-back resolves correctly per `oat_workflow_mode` + `oat_pr_status`: `oat-project-plan` (spec-driven, no/closed PR) / `oat-project-quick-start` (quick, no/closed PR) / `oat-project-revise` (either mode, open PR).
+- ✅ Handoff target for fold-back resolves correctly per `oat_workflow_mode` + `oat_pr_status`: `oat-project-plan` (spec-driven, no/closed PR) / `oat-project-quick-start` (quick, no/closed PR) / `oat-project-lite` (lite, no/closed PR) / `oat-project-revise` (any mode, open PR).
 - ✅ Active-project 3-way router (related / independent / supplementary) fires before the standard pack-filtered picker when both `WORKFLOWS_INSTALLED == "true"` and `ACTIVE_PROJECT_VALID == "true"`.
 - ✅ Skill validates cleanly under `pnpm oat:validate-skills` (frontmatter contract, allowed-tools, mode-assertion structure).

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

@@ -1,6 +1,6 @@
 ---
 name: oat-docs
-version: 1.0.1
+version: 1.0.2
 description: Use when a user asks questions about OAT workflows, CLI commands, skill authoring, configuration, or project lifecycle. Answers questions by reading locally-bundled OAT documentation.
 argument-hint: '[question]'
 disable-model-invocation: false
@@ -145,7 +145,7 @@ Based on the docs, here's how OAT project workflows work: [answer]
 You can read more in `guide/workflow/lifecycle.md`.
 
 Would you like me to:
-- Start a new project? (I'd invoke oat-project-quick-start)
+- Start a new project? (I'd invoke oat-project-lite for single-sitting work, or oat-project-quick-start for a larger quick workflow)
 - Check your current project status? (I'd read your active project's state.md)
 ```
 
@@ -158,22 +158,27 @@ Would you like me to:
 **Response:**
 
 ```
-To create a new OAT project, you have two main approaches:
+To create a new OAT project, you have three main approaches:
 
-1. **Quick mode** (recommended for most tasks):
+1. **Lite mode** (recommended for single-sitting changes):
+   oat-project-lite <project-name> "project description"
+
+2. **Quick mode** (recommended for larger bounded work):
    oat-project-quick-start <project-name> "project description"
 
-2. **Spec-driven mode** (for complex features):
+3. **Spec-driven mode** (for complex features):
    oat-project-new <project-name>
 
-Quick mode goes straight from discovery to plan. Spec-driven mode adds
-formal spec and design phases. If you invoke quick mode with only a
+Lite combines the interview and requirements contract in one plan for a
+single sitting. Quick mode goes straight from discovery to plan. Spec-driven
+mode adds formal spec and design phases. If you invoke quick mode with only a
 project name, it should ask you for the missing project description
 before discovery starts.
 
 Both create a project directory under your projects root
 (default: .oat/projects/shared/<project-name>/) with standard artifacts:
-state.md, discovery.md, plan.md, and implementation.md.
+state.md, plan.md, and implementation.md; quick and spec-driven modes also use
+discovery.md.
 
 See: guide/workflow/lifecycle.md, guide/getting-started.md
 

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

@@ -1,6 +1,6 @@
 ---
 name: oat-doctor
-version: 1.2.0
+version: 1.2.1
 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
@@ -174,7 +174,7 @@ it, and lists every skill that pack ships.
 - oat-project-capture, oat-project-clear-active, oat-project-complete
 - oat-project-design, oat-project-dispatch-subagents, oat-project-discover
 - oat-project-document, oat-project-implement, oat-project-import-plan
-- oat-project-new, oat-project-next, oat-project-open
+- oat-project-lite, oat-project-new, oat-project-next, oat-project-open
 - oat-project-plan, oat-project-plan-writing, oat-project-pr-final
 - oat-project-pr-progress, oat-project-progress, oat-project-promote-spec-driven
 - oat-project-quick-start, oat-project-reconcile, oat-project-retro
@@ -238,7 +238,7 @@ OAT ▸ DOCTOR SUMMARY
 | --------- | ------- | ------ | -------- |
 | core      | user    | 2/2    | current  |
 | docs      | project | 7/7    | current  |
-| workflows | project | 39/39  | current  |
+| workflows | project | 40/40  | current  |
 | ideas     | user    | 4/4    | current  |
 | project-management | project | 4/4 | current |
 | research  | project | 6/6    | current  |

package/assets/skills/oat-pjm-review-backlog/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: oat-pjm-review-backlog
-version: 1.6.0
+version: 1.6.1
 description: Use when prioritizing the file-backed repo backlog or evaluating roadmap alignment. Produces value-effort ratings, dependency mapping, execution recommendations, and an optional external-plan handoff.
 argument-hint: '[backlog-root] [--roadmap=<path>] [--output=<path>]'
 disable-model-invocation: true
@@ -255,7 +255,7 @@ This step mirrors the **Project Kickoff Handoffs** section of the pjm instructio
 **For each item in the agreed kickoff stack**, write or refresh `.oat/repo/pjm/handoffs/<BL-id>.md` with:
 
 - the backlog item reference — its ID **and** human-readable title **and** path (never a bare ID);
-- the recommended project mode (`oat-project-quick-start` vs `oat-project-new`), including which artifacts (spec/design/plan) to pre-populate from existing research when it exists;
+- the recommended project mode (`oat-project-lite` for single-sitting work, `oat-project-quick-start` for quick work, or `oat-project-new` for spec-driven work), including which artifacts (spec/design/plan) to pre-populate from existing research when it exists;
 - authoritative input pointers (research directories, decision records, code paths);
 - repo conventions and verification gates the item file does not restate;
 - a close-out section requiring (a) the **Backlog Lifecycle** — `oat backlog archive <id>` — executed in the same PR that ships the item, and (b) deletion of the handoff file (`git rm`) in that same PR.