@open-agent-toolkit/cli 0.2.57 → 0.2.59

package/assets/skills/oat-project-progress/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: oat-project-progress
-version: 1.3.0
+version: 1.3.1
 description: Use when the user explicitly asks to check OAT project progress — e.g. "check progress", "what's next", "where are we", or confirms a previously offered progress check. Do NOT auto-invoke just because a workflow step completed. Reads project status and offers the next route.
 disable-model-invocation: false
 user-invocable: true
@@ -175,6 +175,8 @@ Read `{project}/state.md` frontmatter:
 - `oat_blockers` - Any blockers
 - `oat_hill_checkpoints` - Configured gates (e.g., `["discovery", "spec", "design"]`)
 - `oat_hill_completed` - Completed HiLL checkpoints
+- `oat_skill_gate_overrides` - Configured lifecycle gates this project
+  deliberately disabled, keyed by gate-aware skill name
 
 **Display format:**
 
@@ -186,10 +188,19 @@ Read `{project}/state.md` frontmatter:
    HiLL Gates: {oat_hill_checkpoints}
    Completed: {oat_hill_completed as checkmarks}
    HiLL Pending: {yes/no for current phase}
+   Gate Overrides: {gate-aware skill keys from oat_skill_gate_overrides, or "None"}
    Blockers: {oat_blockers or "None"}
    Next: {recommended_skill}
 ```
 
+Report every active override by its gate-aware skill key, so a deliberately
+disabled lifecycle gate is visible to reviewers rather than silently absent.
+An override is project posture recorded in `state.md`; it never changes shared,
+local, or user configuration, and it is not a gate outcome. Show an override
+even when no gate is currently configured for that skill, and never infer a
+configured gate from an override alone. This is read-only reporting: never add,
+remove, or repair the map here.
+
 ### Step 5: Determine Next Skill
 
 Based on project state, recommend next action.

package/assets/skills/oat-project-quick-start/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: oat-project-quick-start
-version: 2.3.8
+version: 2.3.9
 description: Use when a task is small enough for quick mode or rapid iteration is preferred. Scaffolds a lightweight OAT project from discovery directly to a runnable plan, with optional brainstorming and lightweight design.
 argument-hint: '<project-name> ["project description"]'
 oat_gateable: true
@@ -651,6 +651,25 @@ This Phase gate review setup is independent from HiLL checkpoints. Do not read o
 change HiLL fields here, and do not add a provider/model `--target` to any
 lifecycle command.
 
+### Step 3.57: Configure Lifecycle Gate Posture
+
+After the generated quick plan has stable phase IDs and before Step 3.6
+starts the plan artifact review, invoke the `Shared Lifecycle Gate Posture Setup Contract` from
+`oat-project-plan-writing`: load the current
+`oat-project-plan-writing/SKILL.md` and follow that contract as written. This
+runs adjacent to, but independently from, the phase gate review setup above.
+
+If `"$PROJECT_PATH/state.md"` already contains an explicit
+`oat_skill_gate_overrides` map, preserve it through the shared contract without
+probing, prompting, or mutation. Otherwise let the contract probe the configured
+gate-aware skills and offer a keep-or-disable choice for each configured gate
+independently.
+
+Persist only disabled choices, and only in `"$PROJECT_PATH/state.md"`. Keeping
+every gate leaves the map absent. Never modify the shared, local, or user
+configuration layers, and never prompt or write a new map in non-interactive
+mode.
+
 ### Step 3.6: Run Plan Artifact Review Loop
 
 Before dispatching the artifact reviewer, invoke the `Managed Dispatch
@@ -726,13 +745,19 @@ artifact above that exists.
 After artifact finalization and plan artifact review, run the configured gate
 as the last check before plan and project completion:
 
-1. Resolve the gate for this skill:
+1. Resolve the gate for this skill with project context:
 
    ```bash
-   oat gate resolve <this-skill> --json
+   oat gate resolve <this-skill> --project "$PROJECT_PATH" --json
    ```
 
-   If the command returns JSON `null`, no gate is configured; proceed directly to the completion steps in Step 3.7 below.
+   Handle all three `resolution` values explicitly:
+   - `not_configured`: no gate is configured; proceed directly to the completion steps in Step 3.7 below.
+   - `configured_disabled_by_project`: the operator disabled this configured gate for this project. Do not launch any process. Emit `configured but disabled by project override`, including the project path and the `projectOverride` source from the envelope, then proceed directly to the completion steps in Step 3.7 below. A project-disabled gate never enters the passed, missing, or failed branches, and its `configuredGate` is evidence only, never executed.
+   - `configured`: continue with the steps below, executing `effectiveGate` exactly as configured.
+
+   A null, missing, malformed, or unrecognized result is an operational failure
+   that fails closed as unresolved. Never treat it as "no gate configured."
 
 2. Export the resolved project path into the command shell: