okstra 0.224.0 → 0.225.0

package/runtime/skills/okstra-container-build/SKILL.md

@@ -16,14 +16,18 @@ Single entry point for the okstra user-test container runtime. okstra provisions
 
 ## Step 0: Preflight (shared)
 
+<!-- BEGIN FRAGMENT: host-runtime-selection -->
+Resolve `<host-runtime>` from the launcher's `OKSTRA_RUNTIME_HOST` when present; otherwise use the registered host ID declared by the current harness. Do not infer the host from worker models, installed executables, or `PATH`. If neither source identifies the host, report that it is unknown instead of substituting another host. Keep the same resolved host when retrying against another project directory.
+<!-- END FRAGMENT: host-runtime-selection -->
+
 Before any sub-command:
 
 <!-- BEGIN FRAGMENT: bash-invocation-rule -->
-Run one Bash tool call, starting with the literal token `okstra` (never wrapped in `if`/`eval`/`export`/`$(...)`/`VAR=...`/`||`/`&&`/`npx` — a non-literal leading token defeats the `Bash(okstra:*)` permission match):
+Run one shell-command tool call, starting with the literal token `okstra` (never wrapped in `if`/`eval`/`export`/`$(...)`/`VAR=...`/`||`/`&&`/`npx` — literal command tokens keep execution permissions reviewable):
 <!-- END FRAGMENT: bash-invocation-rule -->
 
 ```bash
-okstra preflight --runtime claude-code
+okstra preflight --runtime <host-runtime>
 ```
 
 On `Okstra preflight: ready`, carry the fixed `Project root` line and pass it as `--project-root <projectRoot>` to every `okstra container` call below. On `Okstra preflight: failed`, show `Reason` and `Recovery`, then stop.

package/runtime/skills/okstra-discussion/SKILL.md

@@ -10,7 +10,7 @@ Start or continue a `discussion` task — the user and several agents research a
 A discussion needs no manager. `okstra manager task sync` reads the discussion of a manager task's child by reference; it never starts or completes one.
 
 <!-- BEGIN FRAGMENT: wizard-bash-invocation-rule -->
-**Bash invocation rule (permission-friendly)**: every Bash command in this skill begins with the literal token `okstra` (or another already-allowed binary) and passes literal argument values. Do not introduce shell variables (`$STATE_FILE`, `$ANSWER`, `$projectRoot`, ...), `$(...)` command substitution, or leading `VAR=...` assignments — any of those make the leading token non-literal, defeat the `Bash(okstra:*)` permission match, and force a confirmation prompt on every wizard call. When a prior tool call emitted a path or value, read it from the tool output and paste the literal string into the next command.
+**Shell invocation rule (permission-friendly)**: every shell command in this skill begins with the literal token `okstra` (or another already-allowed binary) and passes literal argument values. Do not introduce shell variables (`$STATE_FILE`, `$ANSWER`, `$projectRoot`, ...), `$(...)` command substitution, or leading `VAR=...` assignments — any of those make the command harder to audit; apply the selected host adapter's execution-permission guidance. When a prior tool call emitted a path or value, read it from the tool output and paste the literal string into the next command.
 <!-- END FRAGMENT: wizard-bash-invocation-rule -->
 
 ## When to Use
@@ -76,7 +76,7 @@ Record the semantic functions that the live harness can actually perform. Always
 
 The host-native provider runs as the current lead session when its role is supported. Other selected providers run through their registered CLI wrappers. Claude remains only the model-policy default; it is not the process owner.
 
-Run one Bash tool call (Bash invocation rule from the top of this file applies):
+Run one shell-command tool call (Shell invocation rule from the top of this file applies):
 
 ```bash
 okstra preflight --runtime <host-runtime>
@@ -242,9 +242,9 @@ okstra config set pr-template-path "<value>" --scope global
 
 If an action has an unknown `command`, `key`, or `scope`, stop and report the wizard output instead of inventing a command.
 
-Before rendering the next phase's bundle — and between worker rounds within a phase (reverify/critic/gapverify batches), after you have collected that round's results and token usage and before you dispatch the next round — close the panes of the dispatches that finished in the prior round so they do not accumulate: `okstra team reclaim --project-root <projectRoot> --run-manifest <RUN_MANIFEST_PATH>` closes them, records `phase-batch-cleanup panes=<n>` with the number it closed, and prints that `PROGRESS:` line last — emit it as printed and do not call `okstra lead-progress append` for it. The command reads each dispatch's recorded status, so an in-progress worker keeps its pane whichever moment you call it. It closes only the panes okstra opened and recorded — a pane the harness opened for its own teammate carries no recorded id and is not okstra's to close. `shutdown_request` alone only idles the agent and frees no pane, so it stays part of the run-end sequence for roster/token hygiene. A `cli-wrapper` run holds no pane at all and `team reclaim` refuses it, so record the checkpoint there with `okstra lead-progress append … --phase phase-batch-cleanup --field panes=0`.
+Before rendering the next phase's bundle — and between worker rounds within a phase (reverify/critic/gapverify batches), after you have collected that round's results and token usage and before you dispatch the next round — close the panes of the dispatches that finished in the prior round so they do not accumulate: `okstra team reclaim --project-root <projectRoot> --run-manifest <RUN_MANIFEST_PATH>` closes them, records `phase-batch-cleanup panes=<n>` with the number it closed, and prints that `PROGRESS:` line last — emit it as printed and do not call `okstra lead-progress append` for it. The command reads each dispatch's recorded status, so an in-progress worker keeps its pane whichever moment you call it. It closes only the panes okstra opened and recorded — a pane the harness opened for its own teammate carries no recorded id and is not okstra's to close. After collecting results and token usage, apply the selected adapter's `shutdown_workers` operation only to confirmed-complete workers; preserve in-flight workers and the lead. A `cli-wrapper` run holds no pane at all and `team reclaim` refuses it, so record the checkpoint there with `okstra lead-progress append … --phase phase-batch-cleanup --field panes=0`.
 
-Before you ask the user for any approval, clarification, or decision after workers have been dispatched, run `okstra team reclaim … --gate` first: it closes the finished panes and prints `PROGRESS: phase-gate-cleanup panes=<n>` for you to emit, without recording a batch cleanup. Then `TaskStop` each completed worker. A `TaskStop` by itself idles the task but leaves the pane open — the `team reclaim` call is what closes it. This keeps a user gate from being shown while finished worker panes remain; in-progress dispatches keep their panes. Then follow `prompts/lead/okstra-lead-contract.md` "User confirmation before an approval blocker": read cited plan items, worker findings, and files before asking, and ask in the user's language with each option's outcome.
+Before you ask the user for any approval, clarification, or decision after workers have been dispatched, run `okstra team reclaim … --gate` first: it closes the finished panes and prints `PROGRESS: phase-gate-cleanup panes=<n>` for you to emit, without recording a batch cleanup. Then apply the selected adapter's `shutdown_workers` operation to confirmed-complete workers after collecting their results and token usage; preserve in-flight workers and the lead. This keeps a user gate from being shown while finished worker panes remain; in-progress dispatches keep their panes. Then follow `prompts/lead/okstra-lead-contract.md` "User confirmation before an approval blocker": read cited plan items, worker findings, and files before asking, and ask in the user's language with each option's outcome.
 
 Build the `okstra render-bundle` invocation from `outcome.renderArgv`, passing every token verbatim and in order (including empty strings — they are intentional `use phase default` markers).
 
@@ -257,13 +257,13 @@ Step 3's empty-answer and escaping rules apply verbatim: every flag in `renderAr
 `renderArgv` already contains exactly one `--lead-runtime <host-runtime>` pair. Do not add or replace it. Do not enumerate a fixed provider list in this skill because the wizard and role model pool own the ordered tokens.
 
 ```bash
-okstra render-bundle \
+okstra render-bundle --summary-only \
   <outcome.renderArgv token 1> \
   <outcome.renderArgv token 2> \
   <each remaining outcome.renderArgv token in order>
 ```
 
-`render-bundle` auto-supplies `--workspace-root` and forces `--render-only`. Stdout prints `okstra task root:`, `okstra instruction-set:`, `okstra run manifest:`, and the full rendered lead prompt. Parse the labelled lines for `TASK_ROOT`, `INSTRUCTION_SET_PATH`, and `RUN_MANIFEST_PATH`. Also watch for an optional `okstra concurrent-run stages:` label line — present only when a concurrent run is detected (see "Concurrent-run detection branch" below).
+`render-bundle` auto-supplies `--workspace-root` and forces `--render-only`. Stdout prints `okstra task root:`, `okstra instruction-set:`, `okstra run manifest:`, and other preparation status. `--summary-only` omits the lead prompt body from stdout; Step 6 reads the verified saved prompt from the manifest path. Parse the labelled lines for `TASK_ROOT`, `INSTRUCTION_SET_PATH`, and `RUN_MANIFEST_PATH`. Also watch for an optional `okstra concurrent-run stages:` label line — present only when a concurrent run is detected (see "Concurrent-run detection branch" below).
 
 Before acting as the lead, read `resources.leadPromptMetadataPath` from the run
 manifest and execute the host-native specification-link gate:

package/runtime/skills/okstra-inspect/SKILL.md

@@ -28,10 +28,12 @@ Single read-side entry point for okstra runtime inspection plus the one status m
 
 ## Step 0: Preflight (shared)
 
-Resolve `<host-runtime>` from the launcher's `OKSTRA_RUNTIME_HOST` when present; otherwise use the registered host ID declared by the current harness (`codex` in Codex, `claude-code` in Claude Code). This follows `okstra-run`'s host selection rule. Do not infer the host from worker models, installed executables, or `PATH`. If neither source identifies the host, report that it is unknown instead of substituting Claude Code. Keep the same resolved host when retrying against another project directory.
+<!-- BEGIN FRAGMENT: host-runtime-selection -->
+Resolve `<host-runtime>` from the launcher's `OKSTRA_RUNTIME_HOST` when present; otherwise use the registered host ID declared by the current harness. Do not infer the host from worker models, installed executables, or `PATH`. If neither source identifies the host, report that it is unknown instead of substituting another host. Keep the same resolved host when retrying against another project directory.
+<!-- END FRAGMENT: host-runtime-selection -->
 
 <!-- BEGIN FRAGMENT: bash-invocation-rule -->
-Run one Bash tool call, starting with the literal token `okstra` (never wrapped in `if`/`eval`/`export`/`$(...)`/`VAR=...`/`||`/`&&`/`npx` — a non-literal leading token defeats the `Bash(okstra:*)` permission match):
+Run one shell-command tool call, starting with the literal token `okstra` (never wrapped in `if`/`eval`/`export`/`$(...)`/`VAR=...`/`||`/`&&`/`npx` — literal command tokens keep execution permissions reviewable):
 <!-- END FRAGMENT: bash-invocation-rule -->
 
 ```bash
@@ -58,7 +60,7 @@ Every subsequent `okstra <subcmd>` call self-bootstraps its Python path, so this
 
 Classify the user's request into one sub-command using the trigger table above. If ambiguous (e.g. "show me okstra"), ask which facet — do not silently default. After routing, **Read the chosen row's facet file** (path relative to this skill's base directory) and follow it for the rest of the response. Load exactly one facet per sub-command — never preload the others.
 
-When you ask which facet, the option list is **authoritative**: enumerate every sub-command in the dispatch table above as a numbered text list, in table order, each with its one-line description, and let the user pick by number or name. Never present a hand-picked subset — the AskUserQuestion 4-option cap is not a reason to drop facets; render the full menu as text in the question body so no facet (e.g. a newly added one) is ever hidden. The table is the single source of truth for this menu; adding a row there (plus its facet file) is all it takes for the facet to appear here.
+When you ask which facet, the option list is **authoritative**: enumerate every sub-command in the dispatch table above as a numbered text list, in table order, each with its one-line description, and let the user pick by number or name. Never present a hand-picked subset — the current host's native option limit is not a reason to drop facets; render the full menu as text in the question body so no facet (e.g. a newly added one) is ever hidden. The table is the single source of truth for this menu; adding a row there (plus its facet file) is all it takes for the facet to appear here.
 
 When the user chains multiple facets in one message (e.g. "status, and then time for DEV-9047"), execute them sequentially — Step 0 runs once, then load and run each facet in turn.
 

package/runtime/skills/okstra-manager/SKILL.md

@@ -7,9 +7,13 @@ disable-model-invocation: true
 
 # OKSTRA Manager
 
+<!-- BEGIN FRAGMENT: host-question-interface -->
+For authored questions, `prompt_user` means the current host's available question interface, not a literal tool name. Use the selected host relay when one is provided. Preserve every question, option, description, and answer; use native controls only when the live session permits them and the complete interaction fits its limits. Otherwise show complete numbered choices and accept the user's reply; collect free text through normal conversation. If a native control is refused, follow the relay's recovery mapping, or use text when no relay is provided. A delivery acknowledgement or preselected option is not an answer; wait for the user's actual response.
+<!-- END FRAGMENT: host-question-interface -->
+
 Thin conversational wrapper over `okstra manager`. Manager state and child launch decisions belong to the CLI fixed output, not to this skill.
 
-## Bash Invocation Rule
+## Shell Invocation Rule
 
 Every command in this skill must begin with the literal token `okstra`. Do not introduce shell variables, command substitution, leading environment assignments, or alternate wrappers around `okstra manager`.
 
@@ -61,9 +65,9 @@ okstra manager view --manager-id <manager-id>
 Use this when one Linear project, or one parent issue, covers work in several registered projects and each project needs its own brief. A Linear project can point at several projects, and one issue can too; every (issue, project) pair gets its own brief and child task.
 
 1. Run `okstra manager list projects --manager-id <manager-id>`. These are the only valid targets. Register a missing repo with `okstra manager new project ...` first.
-2. Fetch from the Linear MCP: the project (`get_project`) and its issues (`list_issues` filtered by that project), then each issue with `get_issue`, including sub-issues and blocking or related links. If the Linear tools are missing, load them once with `ToolSearch`; if they are still missing, ask the user to paste the bodies. Never invent ticket content.
-3. For each issue, propose target projects from evidence: labels, team, repository names or paths in the body. Confirm with `AskUserQuestion` (multi-select, recommended projects first, reason in each description).
-4. For each (issue, project) pair, draft the scope: the part of the issue this project implements. Confirm it with `AskUserQuestion` offering one or two drafts plus a custom-input option. A pair without scope is rejected by the CLI.
+2. Fetch from the Linear MCP: the project (`get_project`) and its issues (`list_issues` filtered by that project), then each issue with `get_issue`, including sub-issues and blocking or related links. If the Linear tools are missing, load them once with the host's tool-discovery capability (when available); if they are still missing, ask the user to paste the bodies. Never invent ticket content.
+3. For each issue, propose target projects from evidence: labels, team, repository names or paths in the body. Confirm with `prompt_user` (multi-select, recommended projects first, reason in each description).
+4. For each (issue, project) pair, draft the scope: the part of the issue this project implements. Confirm it with `prompt_user` offering one or two drafts plus a custom-input option. A pair without scope is rejected by the CLI.
 5. Author each pair's brief fields under the okstra-brief-gen brief contract: bodies verbatim, `EB-NNN` / `PB-NNN` / `EO-NNN` items as `<id> <observable condition> — verify: <how>`, anything without an observation method under `externalGates`, and `openQuestions` rows prefixed `general:`, `terminology:`, `intent-check:`, `conversion-block:` or `adr-candidate:`.
 6. Write the plan JSON below with the Write tool to a scratch path outside the project roots, then run `okstra manager task split ... --plan <path>`.
    - `split plan rejected` or `rendered briefs failed validate-brief`: fix the named fields and run it again. Nothing was written.

package/runtime/skills/okstra-memory/SKILL.md

@@ -32,7 +32,7 @@ tokens, JWTs) and exits non-zero — redact and retry if you hit it.
 
 ## Step 0: Check CLI availability
 
-Run as a separate Bash tool call with literal leading token:
+Run as a separate shell-command tool call with literal leading token:
 
 ```bash
 okstra memory --help

package/runtime/skills/okstra-pr-gen/SKILL.md

@@ -5,6 +5,10 @@ description: Use when the user wants to register a PR body template or generate
 
 # okstra-pr-gen
 
+<!-- BEGIN FRAGMENT: host-question-interface -->
+For authored questions, `prompt_user` means the current host's available question interface, not a literal tool name. Use the selected host relay when one is provided. Preserve every question, option, description, and answer; use native controls only when the live session permits them and the complete interaction fits its limits. Otherwise show complete numbered choices and accept the user's reply; collect free text through normal conversation. If a native control is refused, follow the relay's recovery mapping, or use text when no relay is provided. A delivery acknowledgement or preselected option is not an answer; wait for the user's actual response.
+<!-- END FRAGMENT: host-question-interface -->
+
 Register PR body templates and generate PR descriptions. Templates live in the
 user home at `~/.okstra/template/pr/`. This skill is **global** — it does not
 require `<PROJECT_ROOT>/.okstra/project.json`. PR generation additionally
@@ -12,7 +16,7 @@ requires the current directory to be a git repository.
 
 ## Step 0: Check CLI availability
 
-Run as a separate Bash tool call with a literal leading token:
+Run as a separate shell-command tool call with a literal leading token:
 
 ```bash
 okstra pr --help
@@ -22,14 +26,14 @@ If `okstra` is not on PATH, tell the user:
 
 `okstra not installed — run npx okstra@latest install once, then retry this skill.`
 
-**Bash invocation rule:** every Bash command begins with the literal token
+**Shell invocation rule:** every shell command begins with the literal token
 `okstra` and passes literal argument values. Do not introduce shell variables,
-`$(...)`, leading `VAR=`, or wrap in `if`/`eval`/`||`/`&&` — that defeats the
-`Bash(okstra:*)` permission match. Paste literal values emitted by a prior call.
+`$(...)`, leading `VAR=`, or wrap in `if`/`eval`/`||`/`&&` — keep arguments literal and follow the current host's
+execution-permission guidance. Paste literal values emitted by a prior call.
 
 ## Step 1: Pick the mode (always first)
 
-Present a 3-option picker (`AskUserQuestion`):
+Present a 3-option picker (`prompt_user`):
 
 1. `Generate PR` — generate a PR body from a branch diff.
 2. `Register template` — save a new PR body template.
@@ -118,7 +122,7 @@ user's explicit confirmation.
 
 ## Mode B — Register template
 
-1. Ask for a template name (`AskUserQuestion`, free text). It must match
+1. Ask for a template name (`prompt_user`, free text). It must match
    `^[A-Za-z0-9._-]+$`; re-ask on invalid input.
 2. Ask for the template body — either pasted text or an absolute file path.
 3. Save it:

package/runtime/skills/okstra-rollup/SKILL.md

@@ -12,12 +12,16 @@ The skill itself writes nothing. `okstra rollup` resolves every catalog task by
 
 ## Step 0: Preflight
 
+<!-- BEGIN FRAGMENT: host-runtime-selection -->
+Resolve `<host-runtime>` from the launcher's `OKSTRA_RUNTIME_HOST` when present; otherwise use the registered host ID declared by the current harness. Do not infer the host from worker models, installed executables, or `PATH`. If neither source identifies the host, report that it is unknown instead of substituting another host. Keep the same resolved host when retrying against another project directory.
+<!-- END FRAGMENT: host-runtime-selection -->
+
 <!-- BEGIN FRAGMENT: bash-invocation-rule -->
-Run one Bash tool call, starting with the literal token `okstra` (never wrapped in `if`/`eval`/`export`/`$(...)`/`VAR=...`/`||`/`&&`/`npx` — a non-literal leading token defeats the `Bash(okstra:*)` permission match):
+Run one shell-command tool call, starting with the literal token `okstra` (never wrapped in `if`/`eval`/`export`/`$(...)`/`VAR=...`/`||`/`&&`/`npx` — literal command tokens keep execution permissions reviewable):
 <!-- END FRAGMENT: bash-invocation-rule -->
 
 ```bash
-okstra preflight --runtime claude-code
+okstra preflight --runtime <host-runtime>
 ```
 
 On `Okstra preflight: ready`, carry the fixed `Project root` line. On `Okstra preflight: failed`, show `Reason` and `Recovery`, then stop.

package/runtime/skills/okstra-run/SKILL.md

@@ -10,7 +10,7 @@ Launch an okstra task — gather inputs interactively via the **wizard state mac
 **Single authority**: this skill drives `okstra wizard`, which owns every step (ordering, branching, validation). The skill is just a thin prompt-relay loop — it never decides "what to ask next" itself. If the flow needs to change, edit `scripts/okstra_ctl/wizard/registry.py` (the `STEPS` order) or the owning `scripts/okstra_ctl/wizard/steps_*.py`, not this file.
 
 <!-- BEGIN FRAGMENT: wizard-bash-invocation-rule -->
-**Bash invocation rule (permission-friendly)**: every Bash command in this skill begins with the literal token `okstra` (or another already-allowed binary) and passes literal argument values. Do not introduce shell variables (`$STATE_FILE`, `$ANSWER`, `$projectRoot`, ...), `$(...)` command substitution, or leading `VAR=...` assignments — any of those make the leading token non-literal, defeat the `Bash(okstra:*)` permission match, and force a confirmation prompt on every wizard call. When a prior tool call emitted a path or value, read it from the tool output and paste the literal string into the next command.
+**Shell invocation rule (permission-friendly)**: every shell command in this skill begins with the literal token `okstra` (or another already-allowed binary) and passes literal argument values. Do not introduce shell variables (`$STATE_FILE`, `$ANSWER`, `$projectRoot`, ...), `$(...)` command substitution, or leading `VAR=...` assignments — any of those make the command harder to audit; apply the selected host adapter's execution-permission guidance. When a prior tool call emitted a path or value, read it from the tool output and paste the literal string into the next command.
 <!-- END FRAGMENT: wizard-bash-invocation-rule -->
 
 ## When to Use
@@ -76,7 +76,7 @@ Record the semantic functions that the live harness can actually perform. Always
 
 The host-native provider runs as the current lead session when its role is supported. Other selected providers run through their registered CLI wrappers. Claude remains only the model-policy default; it is not the process owner.
 
-Run one Bash tool call (Bash invocation rule from the top of this file applies):
+Run one shell-command tool call (Shell invocation rule from the top of this file applies):
 
 ```bash
 okstra preflight --runtime <host-runtime>
@@ -147,7 +147,7 @@ For numbered interactions, render every option as a 1-based Markdown item contai
 
 ## Step 2: Initialize the wizard
 
-First, generate a state-file path (Bash invocation rule from the top of this file applies to every command below):
+First, generate a state-file path (Shell invocation rule from the top of this file applies to every command below):
 
 ```bash
 okstra wizard new-state-file
@@ -217,6 +217,7 @@ That is the entire interactive flow. The wizard handles:
 - `implementation`-only sub-flow: approved-plan path (frontmatter `approved: true` check) + stage pick (`auto` = the earliest incomplete stage whose dependencies are satisfied, or a specific stage number). Implementer slots use role-count / role-model like every other role (`executor` is only a compatibility alias for `implementer`). When an approved plan is selected and a `## PLAN DECISION` sidecar carrying `Status: approved`, exported from the report — matching the plan on source-report·seq — is detected in that run's sibling `user-responses/`, the approve-confirm step expands to 3 options (`yes_apply` recommended: approve + apply the option as exported / `yes` approve only / `no` abort) — `yes_apply` validates the option against the plan's `optionCandidates` before applying it via the existing approval·option path,
 - `release-handoff`-only sub-flow: after the approved plan auto-resolves, a `handoff_stage_pick` multi-select — choose the eligible stages to open a PR for, one PR per stage; the result goes out as render-args' `stages` key (csv; empty takes every eligible stage),
 - launch selection after identity/worktree steps: one screen per static role, in profile order. A role that can run several instances (`max > 1`) is a checkbox step `role-models:<role>` (`multi: true`) — the number of models checked is the number of instances, there is no separate count question; the label states the profile range and recommended count, every executable candidate is listed on that one screen (defaults first, the recommended set flagged), and when the list exceeds the host's native checkbox limit the runtime either splits it into several checkbox questions on one `pick_group` screen (interaction plan `native-group`; the question steps are `role-models:<role>#1`, `#2`, … and the answer is one JSON object keyed by them, each value a CSV) when the host's native question group holds every option, or returns the interaction plan `numbered-multi` — render the whole list, never a shortlist or pages. An optional role (`min = 0`, e.g. critic) carries a `추가 안 함` row. A fixed single role (`min = max = 1`, e.g. report-writer) is a single pick `role-model:<role>:1`, and a role capped at one model (`max = 1`, e.g. critic) is a single pick on its `role-models:<role>` step; both split the same way when they exceed the native option limit — the tabs are checkbox questions, the answer is the same keyed JSON object, and the wizard rejects a screen whose tabs together name more than one value. current-session lead is this session and is listed on the confirmation summary, not as a wizard step. The wizard does not fork on defaults-vs-customize, does not show a provider roster multi-pick, and does not offer a separate implementer-provider pick. Dynamic verifiers are not chosen at launch. Repeated `--role-count` / `--role-model` tokens on `renderArgv` are intentional,
+- reasoning effort (`reasoning_effort`) after the role screens and the directive, for every task type whose profile starts workers (not `release-handoff`): `high` (recommended) / `low` / `medium` / `xhigh`. The answer goes out as `--reasoning-effort`, is stored as the run manifest's `reasoningEffort`, and every claude, codex and grok worker CLI of the run starts with it; antigravity, kimi and zai keep their own configuration.
 - **resume-clarification (in-session equivalent)** — there is no separate mode or flag matching the shell's `okstra.sh --resume-clarification`; two steps of the standard flow carry out its substance. (1) `reuse_previous` (yes/no to reuse the previous run's settings — in `requirements-discovery` / `error-analysis` / `implementation-planning` / `project-analysis` / `feature-analysis` / `change-impact-analysis`, only when prior run-inputs exist): YES prefills role-count·role-model·directive·related-tasks at once (and, for the analysis types, the target and evidence inputs). (2) `clarification_pick`: a `revision-requested` analysis report for the selected analysis type is recommended first; otherwise the **task-type's own** previous `final-report` is auto-recommended as the carry-in input (for `technical-verification`, the `implementation-option-selection` report), falling back to the newest by mtime across all phases when absent — except for `implementation-planning` and `technical-verification`, which get no cross-phase fallback. The approved plan is never recommended here. The same run's `user-responses/` sidecar (answers the user filled in) is attached alongside. The chosen path is passed to prepare as `--clarification-response` — the user makes the sidecar via the report's `Export user response`, places it in `runs/<task-type>/user-responses/`, and re-runs the same phase,
 - **re-verification scope (`reverify_scope_pick`, `implementation-planning` clarification re-runs only)** — asked right before `confirm` when the re-run is narrowable **or** an answered `C-NNN` traces to no stage. When every answered id traces to a stage: 3 options — `auto` (recommended — leave it to the lead's `okstra incremental-scope` decision) / `full` (re-verify every stage) / Enter directly (a stage-number CSV, validated against the prior report's Stage Map). When an id is unlinked, `auto` is omitted and the user names stages or picks `full`; that unlinked id does not freeze the run at full. The answer goes out as `--reverify-scope` and reaches the lead prompt as the `REVERIFY_SCOPE_MODE` / `REVERIFY_SCOPE_STAGES` tokens; it shapes that CLI's inputs rather than replacing the decision. The confirmation block's `reverify-scope` line names unlinked ids as needing stage numbers, not as a forced full re-run,
 - `release-handoff` PR template override + persist scope,
@@ -275,9 +276,9 @@ okstra config set pr-template-path "<value>" --scope global
 
 If an action has an unknown `command`, `key`, or `scope`, stop and report the wizard output instead of inventing a command.
 
-Before rendering the next phase's bundle — and between worker rounds within a phase (reverify/critic/gapverify batches), after you have collected that round's results and token usage and before you dispatch the next round — close the panes of the dispatches that finished in the prior round so they do not accumulate: `okstra team reclaim --project-root <projectRoot> --run-manifest <RUN_MANIFEST_PATH>` closes them, records `phase-batch-cleanup panes=<n>` with the number it closed, and prints that `PROGRESS:` line last — emit it as printed and do not call `okstra lead-progress append` for it. The command reads each dispatch's recorded status, so an in-progress worker keeps its pane whichever moment you call it. It closes only the panes okstra opened and recorded — a pane the harness opened for its own teammate carries no recorded id and is not okstra's to close. `shutdown_request` alone only idles the agent and frees no pane, so it stays part of the run-end sequence for roster/token hygiene. A `cli-wrapper` run holds no pane at all and `team reclaim` refuses it, so record the checkpoint there with `okstra lead-progress append … --phase phase-batch-cleanup --field panes=0`.
+Before rendering the next phase's bundle — and between worker rounds within a phase (reverify/critic/gapverify batches), after you have collected that round's results and token usage and before you dispatch the next round — close the panes of the dispatches that finished in the prior round so they do not accumulate: `okstra team reclaim --project-root <projectRoot> --run-manifest <RUN_MANIFEST_PATH>` closes them, records `phase-batch-cleanup panes=<n>` with the number it closed, and prints that `PROGRESS:` line last — emit it as printed and do not call `okstra lead-progress append` for it. The command reads each dispatch's recorded status, so an in-progress worker keeps its pane whichever moment you call it. It closes only the panes okstra opened and recorded — a pane the harness opened for its own teammate carries no recorded id and is not okstra's to close. After collecting results and token usage, apply the selected adapter's `shutdown_workers` operation only to confirmed-complete workers; preserve in-flight workers and the lead. A `cli-wrapper` run holds no pane at all and `team reclaim` refuses it, so record the checkpoint there with `okstra lead-progress append … --phase phase-batch-cleanup --field panes=0`.
 
-Before you ask the user for any approval, clarification, or decision after workers have been dispatched, run `okstra team reclaim … --gate` first: it closes the finished panes and prints `PROGRESS: phase-gate-cleanup panes=<n>` for you to emit, without recording a batch cleanup. Then `TaskStop` each completed worker. A `TaskStop` by itself idles the task but leaves the pane open — the `team reclaim` call is what closes it. This keeps a user gate from being shown while finished worker panes remain; in-progress dispatches keep their panes. Then follow `prompts/lead/okstra-lead-contract.md` "User confirmation before an approval blocker": read cited plan items, worker findings, and files before asking, and ask in the user's language with each option's outcome.
+Before you ask the user for any approval, clarification, or decision after workers have been dispatched, run `okstra team reclaim … --gate` first: it closes the finished panes and prints `PROGRESS: phase-gate-cleanup panes=<n>` for you to emit, without recording a batch cleanup. Then apply the selected adapter's `shutdown_workers` operation to confirmed-complete workers after collecting their results and token usage; preserve in-flight workers and the lead. This keeps a user gate from being shown while finished worker panes remain; in-progress dispatches keep their panes. Then follow `prompts/lead/okstra-lead-contract.md` "User confirmation before an approval blocker": read cited plan items, worker findings, and files before asking, and ask in the user's language with each option's outcome.
 
 Build the `okstra render-bundle` invocation from `outcome.renderArgv`, passing every token verbatim and in order (including empty strings — they are intentional `use phase default` markers).
 
@@ -290,13 +291,13 @@ Step 3's empty-answer and escaping rules apply verbatim: every flag in `renderAr
 `renderArgv` already contains exactly one `--lead-runtime <host-runtime>` pair. Do not add or replace it. Do not enumerate a fixed provider list in this skill because the wizard and role model pool own the ordered tokens.
 
 ```bash
-okstra render-bundle \
+okstra render-bundle --summary-only \
   <outcome.renderArgv token 1> \
   <outcome.renderArgv token 2> \
   <each remaining outcome.renderArgv token in order>
 ```
 
-`render-bundle` auto-supplies `--workspace-root` and forces `--render-only`. Stdout prints `okstra task root:`, `okstra instruction-set:`, `okstra run manifest:`, and the full rendered lead prompt. Parse the labelled lines for `TASK_ROOT`, `INSTRUCTION_SET_PATH`, and `RUN_MANIFEST_PATH`. Also watch for an optional `okstra concurrent-run stages:` label line — present only when a concurrent run is detected (see "Concurrent-run detection branch" below).
+`render-bundle` auto-supplies `--workspace-root` and forces `--render-only`. Stdout prints `okstra task root:`, `okstra instruction-set:`, `okstra run manifest:`, and other preparation status. `--summary-only` omits the lead prompt body from stdout; Step 6 reads the verified saved prompt from the manifest path. Parse the labelled lines for `TASK_ROOT`, `INSTRUCTION_SET_PATH`, and `RUN_MANIFEST_PATH`. Also watch for an optional `okstra concurrent-run stages:` label line — present only when a concurrent run is detected (see "Concurrent-run detection branch" below).
 
 Before acting as the lead, read `resources.leadPromptMetadataPath` from the run
 manifest and execute the host-native specification-link gate:

package/runtime/skills/okstra-schedule-gen/SKILL.md

@@ -1,12 +1,15 @@
 ---
 name: okstra-schedule-gen
 description: Use when the user asks for a task-group work schedule, a consolidated implementation plan across multiple tasks in a task-group, or wants to generate a schedule or work plan for non-done tasks.
-model: opus
 ---
 
 # OKSTRA Schedule Gen
 
-Generate a consolidated work schedule for the selected `implementation-planning` stages of every non-done task in a given `task-group` (or a single `task-id`). For each task the skill reads the source-aware **Stage Map**, records the user's stage choices in a temporary selection contract, and gates the same draft through deterministic validation followed by an independent narrative review. It runs as a **lead + verifier** flow; the frontmatter `model: opus` switches supporting harnesses to Opus-class for the turn — stage-level cross-task synthesis needs that reasoning depth.
+<!-- BEGIN FRAGMENT: host-question-interface -->
+For authored questions, `prompt_user` means the current host's available question interface, not a literal tool name. Use the selected host relay when one is provided. Preserve every question, option, description, and answer; use native controls only when the live session permits them and the complete interaction fits its limits. Otherwise show complete numbered choices and accept the user's reply; collect free text through normal conversation. If a native control is refused, follow the relay's recovery mapping, or use text when no relay is provided. A delivery acknowledgement or preselected option is not an answer; wait for the user's actual response.
+<!-- END FRAGMENT: host-question-interface -->
+
+Generate a consolidated work schedule for the selected `implementation-planning` stages of every non-done task in a given `task-group` (or a single `task-id`). For each task the skill reads the source-aware **Stage Map**, records the user's stage choices in a temporary selection contract, and gates the same draft through deterministic validation followed by an independent narrative review. It runs as a **lead + verifier** flow in the current authoring session; the registered operation contract selects the independent verifier.
 
 ## When to Use
 
@@ -19,12 +22,16 @@ Public invocation: `/okstra-schedule-gen [task-group]`. A title or directive may
 
 ## Step 0: Preflight
 
+<!-- BEGIN FRAGMENT: host-runtime-selection -->
+Resolve `<host-runtime>` from the launcher's `OKSTRA_RUNTIME_HOST` when present; otherwise use the registered host ID declared by the current harness. Do not infer the host from worker models, installed executables, or `PATH`. If neither source identifies the host, report that it is unknown instead of substituting another host. Keep the same resolved host when retrying against another project directory.
+<!-- END FRAGMENT: host-runtime-selection -->
+
 <!-- BEGIN FRAGMENT: bash-invocation-rule -->
-Run one Bash tool call, starting with the literal token `okstra` (never wrapped in `if`/`eval`/`export`/`$(...)`/`VAR=...`/`||`/`&&`/`npx` — a non-literal leading token defeats the `Bash(okstra:*)` permission match):
+Run one shell-command tool call, starting with the literal token `okstra` (never wrapped in `if`/`eval`/`export`/`$(...)`/`VAR=...`/`||`/`&&`/`npx` — literal command tokens keep execution permissions reviewable):
 <!-- END FRAGMENT: bash-invocation-rule -->
 
 ```bash
-okstra preflight --runtime claude-code
+okstra preflight --runtime <host-runtime>
 ```
 
 On `Okstra preflight: ready`, carry the fixed `Project root` line for the later `model-io` calls. On `Okstra preflight: failed`, show `Reason` and `Recovery`, then stop.
@@ -130,8 +137,8 @@ Run this **once per in-scope task that has a non-empty `remainingStages`**, sequ
 2. Pick natural cut points to form up to **3 cumulative bundles**: `B1` = through the first milestone, `B2` = through the core, `B3` = all remaining. Each bundle is a **dependency-closed prefix** — selecting it never omits a prerequisite stage. Label each bundle with its stage list and summed `step_count` (e.g. `B2: stage 1–4 (steps 12)`).
 3. If `remainingStages` has ≤2 stages, emit only the bundles that are distinct (1–2), never pad to 3.
 
-**Render the picker** with `AskUserQuestion` (one question for this task):
-- Options = the distinct bundles + a final `"All remaining stages"` option. `AskUserQuestion`'s built-in Other slot serves the `Enter directly` (arbitrary stage subset) case; when the user supplies a custom subset, close it under `depends_on` before accepting.
+**Render the picker** with `prompt_user` (one question for this task):
+- Options = the distinct bundles + a final `"All remaining stages"` option. Use the host's free-input mechanism for `Enter directly` (an arbitrary stage subset), or collect that value as a separate text answer; when the user supplies a custom subset, close it under `depends_on` before accepting.
 - **Degenerate skip:** if only one distinct bundle exists AND it already equals all remaining stages, skip the picker for this task and set `selectedStages = remainingStages` (log `> _Stage picker skipped: remaining stages form a single dependency chain._`).
 
 Record the chosen `selectedStages` for this task. Reject and re-prompt any custom selection whose transitive `depends_on` closure is not covered by `selectedStages ∪ doneStages`.

package/runtime/skills/okstra-setup/SKILL.md

@@ -5,6 +5,10 @@ description: One-time bootstrap for okstra in a new project or on a new machine
 
 # okstra-setup
 
+<!-- BEGIN FRAGMENT: host-question-interface -->
+For authored questions, `prompt_user` means the current host's available question interface, not a literal tool name. Use the selected host relay when one is provided. Preserve every question, option, description, and answer; use native controls only when the live session permits them and the complete interaction fits its limits. Otherwise show complete numbered choices and accept the user's reply; collect free text through normal conversation. If a native control is refused, follow the relay's recovery mapping, or use text when no relay is provided. A delivery acknowledgement or preselected option is not an answer; wait for the user's actual response.
+<!-- END FRAGMENT: host-question-interface -->
+
 One-time bootstrap. Run when okstra is being used for the first time on this
 machine, or when adopting okstra in a new project.
 
@@ -28,7 +32,7 @@ Inform the user up-front and confirm before continuing:
   or `nvm`.
 - **Python 3.10+** required (runs the okstra core).
 - The current working directory must be inside the project that will host the
-  okstra metadata. If unsure, ask with `AskUserQuestion` for an absolute project
+  okstra metadata. If unsure, ask with `prompt_user` for an absolute project
   root before proceeding.
 
 ## Step 1: Install okstra
@@ -88,7 +92,7 @@ Do not run recursive `sudo chown` based only on npm's generic message. A cache
 override does not grant network access or permission to write the installation
 targets; follow the host's permission mechanism if either remains blocked.
 
-**Bash invocation rule (permission-friendly)**: after Step 1, every Bash command in this skill MUST begin with the literal token `okstra` and pass literal argument values. Do not introduce shell variables (`$PROJECT_ROOT`, `$PROJECT_ID`, ...), `$(...)` command substitution, leading `VAR=...` assignments, or wrap commands in `if`/`eval`/`||`/`&&` — any of those make the leading token non-literal, defeat the `Bash(okstra:*)` permission match, and force a confirmation prompt on every call. When a prior tool call emitted a path or value, paste the literal string into the next command. Every `okstra <subcmd>` call self-bootstraps its Python path — never run `okstra paths --shell` / `export PYTHONPATH=...`.
+**Shell invocation rule (permission-friendly)**: after Step 1, every shell command in this skill MUST begin with the literal token `okstra` and pass literal argument values. Do not introduce shell variables (`$PROJECT_ROOT`, `$PROJECT_ID`, ...), `$(...)` command substitution, leading `VAR=...` assignments, or wrap commands in `if`/`eval`/`||`/`&&` — any of those make the command harder to audit; apply the current host's execution-permission guidance. When a prior tool call emitted a path or value, paste the literal string into the next command. Every `okstra <subcmd>` call self-bootstraps its Python path — never run `okstra paths --shell` / `export PYTHONPATH=...`.
 
 ## Step 2: Resolve PROJECT_ROOT
 
@@ -101,7 +105,7 @@ carries `Project ID` and `Project root`; on `Okstra preflight: failed` it carrie
 `Stage`, `Reason`, and `Recovery`, and no `Project root` line.
 
 - `Okstra preflight: ready` → carry `Project root` as a literal absolute string and paste it into every subsequent command in this skill.
-- `Okstra preflight: failed`, `Stage: resolve` → ask the user (`AskUserQuestion`, free text) for an absolute project root and rerun as a separate Bash tool call with the literal absolute path:
+- `Okstra preflight: failed`, `Stage: resolve` → ask the user (`prompt_user`, free text) for an absolute project root and rerun as a separate shell-command tool call with the literal absolute path:
 
   ```bash
   okstra preflight --runtime <host-runtime> --cwd /abs/path/from/user
@@ -126,7 +130,7 @@ okstra refuses to change `projectId` on an existing project (see
 `okstra_project.resolver.upsert_project_json`), so overwriting requires
 manually deleting the file first.
 
-If the file does NOT exist, ask via `AskUserQuestion`:
+If the file does NOT exist, ask via `prompt_user`:
 
 - **Question**: `"Project id for okstra (e.g. INV-1234, my-app, okstra)"`
 - **Validate**: the answer must be non-empty AND contain at least one

package/runtime/skills/okstra-setup/references/project-config.md

@@ -4,7 +4,7 @@ Use this reference only when the user asks to customise one of the areas below a
 `project.json` exists. The built-in defaults work for most projects — none of
 these sections is required for a working setup.
 
-The Bash invocation rule from SKILL.md applies to every command here.
+The Shell invocation rule from SKILL.md applies to every command here.
 
 ## A. Worktree sync dirs (`worktreeSyncDirs`)
 
@@ -172,7 +172,7 @@ the next `okstra setup` or run prepare.
 opt-in; the same prompt is offered again on the first `release-handoff` run,
 so deferring (`Later`) is safe.
 
-Ask with `AskUserQuestion` (fixed options — file path entry happens in the
+Ask with `prompt_user` (fixed options — file path entry happens in the
 follow-up plain text prompt):
 
 - **Question**: `"Register the PR body template that release-handoff will use for this project?"`
@@ -200,7 +200,7 @@ The value is a language tag (`en`, `ko`, `fr`, `pt-BR`, …). The report writer
 writes the report prose directly in that language; no translation step runs.
 If you skip, no `reportLanguage` field is written and the runtime uses `en`.
 
-AskUserQuestion (fixed options):
+prompt_user (fixed options):
 - Question: `"Which language should the final report be written in?"`
 - Options:
   1. `English (recommended)` → `en`

package/runtime/skills/okstra-usage/SKILL.md

@@ -14,10 +14,14 @@ Project usage snapshot. The skill itself writes nothing. `okstra usage-report` r
 
 ## Step 0: Preflight
 
+<!-- BEGIN FRAGMENT: host-runtime-selection -->
+Resolve `<host-runtime>` from the launcher's `OKSTRA_RUNTIME_HOST` when present; otherwise use the registered host ID declared by the current harness. Do not infer the host from worker models, installed executables, or `PATH`. If neither source identifies the host, report that it is unknown instead of substituting another host. Keep the same resolved host when retrying against another project directory.
+<!-- END FRAGMENT: host-runtime-selection -->
+
 Run one literal Bash call:
 
 ```bash
-okstra preflight --runtime claude-code
+okstra preflight --runtime <host-runtime>
 ```
 
 On `Okstra preflight: ready`, carry the fixed `Project root` line. On

package/runtime/skills/okstra-user-response/SKILL.md

@@ -6,6 +6,10 @@ description: >-
 
 # OKSTRA User Response
 
+<!-- BEGIN FRAGMENT: host-question-interface -->
+For authored questions, `prompt_user` means the current host's available question interface, not a literal tool name. Use the selected host relay when one is provided. Preserve every question, option, description, and answer; use native controls only when the live session permits them and the complete interaction fits its limits. Otherwise show complete numbered choices and accept the user's reply; collect free text through normal conversation. If a native control is refused, follow the relay's recovery mapping, or use text when no relay is provided. A delivery acknowledgement or preselected option is not an answer; wait for the user's actual response.
+<!-- END FRAGMENT: host-question-interface -->
+
 Use this skill for open `C-*` clarification items, explicit plan decisions, and the implementation direction a finished `implementation-option-selection` comparison awaits. The user alone selects or writes every answer. Never infer an answer or approval.
 
 The model-facing commands are fixed text reads and typed transaction writes:
@@ -28,7 +32,7 @@ Do not use the automation-oriented `list` or `show` commands. Do not open a repo
 Use the registered host ID that the current harness declares for this session. Do not infer it from an executable or `PATH`. Do not substitute `claude-code`.
 
 <!-- BEGIN FRAGMENT: bash-invocation-rule -->
-Run one Bash tool call, starting with the literal token `okstra` (never wrapped in `if`/`eval`/`export`/`$(...)`/`VAR=...`/`||`/`&&`/`npx` — a non-literal leading token defeats the `Bash(okstra:*)` permission match):
+Run one shell-command tool call, starting with the literal token `okstra` (never wrapped in `if`/`eval`/`export`/`$(...)`/`VAR=...`/`||`/`&&`/`npx` — literal command tokens keep execution permissions reviewable):
 <!-- END FRAGMENT: bash-invocation-rule -->
 
 ```bash
@@ -57,12 +61,12 @@ Every choice this skill asks — the task pick, each clarification, an explicit
 
 Read the absolute path in the fixed `Relay contract` line. In that file, take the `Wizard interaction relay` JSON. Intersect its `semanticFunctions` with the functions this session can actually call, using each `interactions` kind's `function` field. The live harness does not expose tools named `native_single_select`. Keep `native-single` only when `native_single_select` is in that intersection. Keep `nativeLimits`. If `Relay contract` is `-`, native-single is unavailable.
 
-- When `native-single` is available and the option count fits `nativeLimits` (unique labels, within min/max): call `interactions.native-single.function` once with one question and every option as `{label, description}` in original order. Do not print a numbered list in chat while the native tool is available. Emit the question as the last thing in that turn; text emitted after the call renders below the question. Claude Code's function is `AskUserQuestion`, Grok's is `ask_user_question`, Codex's is `request_user_input` — copy the relay field; do not substitute one name for another.
+- When `native-single` is available and the option count fits `nativeLimits` (unique labels, within min/max): call `interactions.native-single.function` once with one question and every option as `{label, description}` in original order. Do not print a numbered list in chat while the native tool is available. Emit the question as the last thing in that turn; text emitted after the call renders below the question. Copy the function name from the selected relay field; do not substitute another host's function.
 - Otherwise render a 1-based numbered Markdown list and wait for the next message. Do not drop options to force the native tool.
 
 Copy the view's `Picker:` `- Label:` / `Description:` pairs into that function in that order. Do not rebuild labels from the `Options:` dump. `--option-number` is the 1-based `Option N:` index, which is the same order as `Picker:`. The HTML report's `<select>` uses the same `option.answer` values.
 
-Pass only the choices this step already owns — the `list-view` `Picker:` rows, the report `Picker:` rows, or the two confirmation labels. Do not append `Enter directly`. Claude Other, Grok `z`, and Codex's free-form row already collect a custom answer; that row is `Enters an answer`. When native-single is unavailable, a next message that is not a listed label or its 1-based number is the same `Enters an answer`. Do not ask a second question for the custom value.
+Pass only the choices this step already owns — the `list-view` `Picker:` rows, the report `Picker:` rows, or the two confirmation labels. Do not append `Enter directly`. The selected host's free-input mechanism already collects a custom answer; that row is `Enters an answer`. When native-single is unavailable, a next message that is not a listed label or its 1-based number is the same `Enters an answer`. Do not ask a second question for the custom value.
 
 Never invent a picker function. Never ask the user to type a number when the native tool is available.