ultra-builder-pro-cli 0.16.0 → 0.17.1

package/skills/ultra-research/SKILL.md

@@ -1,117 +1,103 @@
 ---
 name: ultra-research
-description: Establish or extend an evidence-backed Ultra product and architecture baseline through the complete semantic research workflow, with resumable step state and traceable outputs. Use when initialization routes to research, baseline evidence is incomplete, or the owner explicitly requests bounded research for an active change.
+description: Build or refresh an evidence-backed product and architecture baseline with model-selected semantic coverage and low-load user alignment. Use when initialization, brownfield adoption, or an active change has a real evidence gap.
 ---
 
-# Establish research authority without overwhelming the owner
-
-Use host reasoning to discover facts and synthesize artifacts. Use Ultra MCP for run
-position, decision authority, output digests, blockers, and convergence. Read
-`../ultra-think/references/decision-dialogue.md` before asking any owner question.
-Never ask MCP to generate research content.
-
-## Bind the run
-
-1. Call `baseline.get`. Route absent, migrated, unreadable, or corrupt authority to
-   `ultra-init` or `ultra-doctor` as reported.
-2. Call `workflow.list` for `kind: "research"` and the bound baseline or change. Resume
-   the active, blocked, or ready run; use `workflow.get` before doing more work.
-3. When no run exists:
-   - start `full` for an initial greenfield baseline;
-   - start `adoption` for a brownfield baseline;
-   - use `product`, `feature`, `architecture`, or `custom` only when the owner
-     explicitly selected that bounded scope for an active change.
-
-Never infer an MVP, reduced product posture, skipped step, or release phase. Full and
-adoption modes execute all seventeen semantic steps. A custom run records every
-excluded step and its selection reason in DB.
-
-## Preserve complete semantic coverage
-
-Read only the reference matching `workflow.next_step.step_id`:
-
-| Step | Reference |
-|---|---|
-| `00-problem-validation` | `references/00-problem-validation.md` |
-| `01-opportunity-discovery` | `references/01-opportunity-discovery.md` |
-| `02-market-assessment` | `references/02-market-assessment.md` |
-| `03-competitive-landscape` | `references/03-competitive-landscape.md` |
-| `04-product-strategy` | `references/04-product-strategy.md` |
-| `05-assumptions-validation` | `references/05-assumptions-validation.md` |
-| `10-user-personas` | `references/10-user-personas.md` |
-| `11-user-scenarios` | `references/11-user-scenarios.md` |
-| `20-user-stories` | `references/20-user-stories.md` |
-| `21-features-scope` | `references/21-features-scope.md` |
-| `22-success-metrics` | `references/22-success-metrics.md` |
-| `30-architecture-context` | `references/30-architecture-context.md` |
-| `31-solution-strategy` | `references/31-solution-strategy.md` |
-| `32-building-blocks` | `references/32-building-blocks.md` |
-| `40-deployment` | `references/40-deployment.md` |
-| `41-quality-risks` | `references/41-quality-risks.md` |
-| `99-synthesis` | `references/99-synthesis.md` |
-
-The seventeen steps are an internal completeness contract, not a questionnaire or the
-default user interface. For each selected step:
-
-1. Read only its reference and inspect repository, specification, runtime, tests, and
-   current primary-source evidence. Do not ask the owner to repeat observable facts.
-2. Separate `Observed`, `Verified`, `Decided`, and `Unknown`. Resolve evidence-answerable
-   unknowns autonomously and record evidence-backed `not_applicable` results.
-3. If a load-bearing owner decision remains, start or resume one decision thread bound
-   to this research workflow. Open the earliest dependent decision, present only that
-   question, and STOP. Do not update specifications or complete the workflow step while
-   its checkpoint is unconfirmed.
-4. After a coherent decision cluster, prepare one checkpoint. Present the compact
-   shared understanding and affected specifications, obtain approval, and apply the
-   accepted decisions.
-5. Update only the relevant baseline specification or active-change research artifact.
-   Preserve evidence, decisions, drift, and unknowns without copying conversation text.
-   Write the accepted cluster to the stable
-   `.ultra/docs/decisions/<thread-id>.md` projection and confirm its checkpoint with
-   that digest. Do not bind an intermediate shared specification that later research
-   steps are expected to extend.
-6. Write one immutable step report at
-   `.ultra/docs/research/<workflow-id>/<step-id>.md`. It must have a title and the
-   sections `Evidence`, `Specification updates`, and `Decisions and unknowns`. Link
-   specification anchors and external sources; do not copy transcripts or provider
-   payloads.
-7. Call `workflow.step` with `completed`, bounded evidence references, that step report
-   as `research-step-report`, material decisions, and one or more `semantic_records`.
-   Each record has a stable `id`, the step-specific `kind` and `attributes` named in
-   its reference, a status (`observed`, `verified`, `decided`, `accepted`, `unknown`,
-   or `not_applicable`), a concise summary, evidence refs, optional typed links, and a
-   project-relative `source_ref` using `path#anchor`. Use the immutable step report as
-   the source when later edits could change a shared specification. MCP verifies the
-   anchor and stores its digest; `not_applicable` requires an evidence-backed rationale.
-8. For `99-synthesis` in `full` or `adoption` mode, also bind the current
-   `discovery.md`, `product.md`, `architecture.md`, and `research-distillate.md` as
-   outputs. This freezes the exact researched baseline without making the reports a
-   second specification authority.
-9. If evidence or owner authority is missing, call `workflow.step` with `blocked` and
-   specific blocker codes. Resume that same step after resolution; never skip a
-   required step to obtain a ready state.
-
-## Converge
-
-When all selected steps are ready, call `workflow.complete` and read the completed run
-back. Missing or stale output blocks completion.
-
-For initial or adoption research, call `baseline.record` with discovery, product, and
-architecture specification refs; current repository revision and scope; bounded source,
-docs, runtime, test, deployment, and external evidence; actual verification commands
-and results; unknowns; the complete gap ledger; classification; and external provider
-metadata references. Do not store prompts, transcripts, memory, or graph content.
-
-Present the recorded revision, worktree snapshot, known failures, blockers, and gaps.
-Only after explicit owner approval call `baseline.converge`. Reuse the final research
-checkpoint approval when it names this exact recorded revision, worktree snapshot,
-known failures, blockers, and gaps; do not ask for an equivalent approval again. If
-that snapshot changed, prepare one refreshed checkpoint instead. Accept known-red or a
-dirty worktree only when that exact snapshot was approved. Convergence must verify the
-completed full/adoption research run and current output digests.
-
-Return a compact checkpoint: workflow id, completed/selected semantic coverage,
-current decision or blocker, baseline state, open gaps, approval state, and one route.
-Do not print all seventeen report paths unless requested; they remain discoverable
-through workflow state. A ready initial baseline routes to `ultra-change`; bounded
-change research returns to its breadcrumb and then `ultra-plan` when ready.
+# Research with adaptive coverage
+
+The host model owns investigation, synthesis, and coverage judgment. Ultra MCP owns the
+run, evidence references, semantic records, artifact digests, freshness, and
+convergence. The seventeen areas are a coverage catalog, not a mandatory questionnaire
+or a fixed sequence of user conversations.
+
+Read `../ultra-think/references/decision-dialogue.md` before asking a material question.
+
+## Bind authority
+
+1. Read `system.doctor`, `baseline.get`, active decisions, and existing research runs.
+2. Resume the matching active, blocked, or ready run. Do not create parallel authority.
+3. If none exists, select:
+   - `full` for a greenfield baseline;
+   - `adoption` for a brownfield baseline;
+   - a bounded mode only for a recorded active-change research disposition.
+4. Before `workflow.start`, inspect current code, docs, tests, runtime, and prior
+   artifacts. Provide one disposition for every catalog area in `full` or `adoption`:
+   - `execute`: produce fresh evidence;
+   - `verify_existing`: verify a current artifact against its source;
+   - `reuse`: reuse evidence that is still current;
+   - `not_applicable`: exclude with an evidence reference and rationale;
+   - `deferred`: record the consequence and owner acceptance when deferral changes the
+     accepted scope or leaves material risk.
+
+`99-synthesis` must execute, verify, or reuse. A missing disposition is a coverage
+error; a non-executed area with evidence is not an incomplete workflow.
+
+## Coverage catalog
+
+Load only the reference for a step that must execute, verify, or reuse:
+
+| Area | Reference | Area | Reference |
+|---|---|---|---|
+| `00-problem-validation` | `references/00-problem-validation.md` | `01-opportunity-discovery` | `references/01-opportunity-discovery.md` |
+| `02-market-assessment` | `references/02-market-assessment.md` | `03-competitive-landscape` | `references/03-competitive-landscape.md` |
+| `04-product-strategy` | `references/04-product-strategy.md` | `05-assumptions-validation` | `references/05-assumptions-validation.md` |
+| `10-user-personas` | `references/10-user-personas.md` | `11-user-scenarios` | `references/11-user-scenarios.md` |
+| `20-user-stories` | `references/20-user-stories.md` | `21-features-scope` | `references/21-features-scope.md` |
+| `22-success-metrics` | `references/22-success-metrics.md` | `30-architecture-context` | `references/30-architecture-context.md` |
+| `31-solution-strategy` | `references/31-solution-strategy.md` | `32-building-blocks` | `references/32-building-blocks.md` |
+| `40-deployment` | `references/40-deployment.md` | `41-quality-risks` | `references/41-quality-risks.md` |
+| `99-synthesis` | `references/99-synthesis.md` |  |  |
+
+## Investigate and interact
+
+For each active area:
+
+1. Resolve observable facts from the checkout, runtime, tests, existing specifications,
+   and primary sources. Separate `Observed`, `Verified`, `Decided`, and `Unknown`.
+2. Ask the user only for a material intent, scope, compatibility, risk, or recovery
+   decision that evidence cannot answer. Use the host's native question UI when
+   available. Present the recommendation and effect; avoid a questionnaire or a dump
+   of the hidden research queue.
+3. Process dependent decisions one at a time. A small group of independent,
+   low-cognitive-load facts may be asked together when the host UI supports it.
+4. Normalize explicit user intent without redundant confirmation. Create durable
+   decision state only when a project-bound decision must survive interruption.
+5. Update the smallest relevant baseline specification or active-change research
+   artifact. Do not copy prompts, transcripts, provider payloads, or internal chain of
+   thought.
+
+For every required workflow step, write
+`.ultra/docs/research/<workflow-id>/<step-id>.md` with `Evidence`,
+`Specification updates`, and `Decisions and unknowns`. Call `workflow.step` with
+bounded evidence, the report output, and typed semantic records. Reused or verified
+evidence must still produce a current report and digest. Block the same step when
+required evidence or owner authority is missing.
+
+At synthesis, bind the current `discovery.md`, `product.md`, `architecture.md`, and
+`research-distillate.md` for initial/adoption research.
+
+## Baseline convergence
+
+After `workflow.complete`, initial or adoption research calls `baseline.record` with
+the current repository scope and revision, specification refs, evidence, real
+verification results, unknowns, gap ledger, classification, and external provider
+metadata references.
+
+If Git is initialized but unborn, present the exact local checkpoint paths and purpose
+for user authorization, then create only that local commit. Never create a remote,
+tag, or push through research. If authorization or identity is missing, preserve the
+run as blocked with `BASELINE_GIT_HEAD_REQUIRED`.
+
+Call `baseline.converge` only when the user has accepted the exact baseline snapshot,
+known failures, blocking gaps, and scope. Reuse an unambiguous current approval; do not
+ask twice. MCP must reject stale research, drift, missing evidence, and unaccepted
+failures.
+
+Reuse the final research checkpoint approval during baseline convergence; do not ask
+for an equivalent approval again. After initial or adoption convergence,
+`ultra-change` becomes an available transition. Bounded change research returns to
+its owning Change authority.
+
+Return a compact coverage summary by disposition, current evidence or decision
+blocker, baseline state, gaps, and allowed transitions. The host chooses the semantic
+recommendation; MCP supplies only valid and required transitions.

package/skills/ultra-review/SKILL.md

@@ -1,71 +1,56 @@
 ---
 name: ultra-review
-description: Run independent specification-fidelity and engineering reviews over one current Ultra diff and persist bounded review evidence. Use when a task or change needs a read-only review gate before completion, convergence, or delivery.
+description: Independently review one current Ultra plan, task diff, or aggregate change on specification fidelity and engineering standards. Use when current evidence needs a review gate or focused risk analysis.
 ---
 
-# Review one current diff
+# Review one bounded scope
 
-Keep two verdict axes independent:
+Keep two independent verdict axes:
 
-- `spec_fidelity`: accepted intent, delta, behavior, docs impact, and public seam;
-- `engineering_standards`: correctness, safety, tests, maintainability, observability,
-  integration, and recovery.
+- `spec_fidelity`: accepted intent, behavior, documentation impact, and public seams;
+- `engineering_standards`: correctness, safety, tests, integration, maintainability,
+  observability, and recovery.
 
-One axis cannot compensate for the other.
+Neither axis can compensate for the other.
 
-## Bind durable scope
+## Bind evidence
 
-1. Read `references/review-modes.md`. Select exactly one review mode: `task` for one
-   implementation slice, `change` for aggregate delivery readiness, or `plan` for an
-   approved plan before implementation. Bind only the evidence defined by that mode.
-2. Resolve one explicit diff range, current full HEAD, change, task set, accepted
-   evidence, and decision checkpoint state. Stop on an empty or ambiguous scope or an
-   unconfirmed alignment checkpoint.
-3. Resume or start a `review` workflow. Record `bind-diff` with revision, paths, mode,
-   and task set.
-4. Compile `change.context` for `review` using only accepted intent, delta, task
-   contracts, tests, public seams, and diff paths. Record `compile-context` only when
-   ready, with the immutable context manifest as the step output.
-5. Create `.ultra/reviews/<session-id>/` with mode, change id, exact task ids, full HEAD,
-   worktree digest, diff range, scope metadata, and pending verdicts.
+1. Read `references/review-modes.md` and select `plan`, `task`, or `change` from the
+   actual review request.
+2. Bind one explicit diff or plan artifact, full HEAD, worktree digest, task set,
+   acceptance, and current decision state.
+3. Resume or start the review workflow and record `bind-diff`.
+4. Compile `change.context` for `review` and record the immutable manifest under
+   `compile-context`.
 
-## Execute independent axes
+An empty, ambiguous, or stale scope cannot pass.
 
-Always run the bounded `review-spec` worker for specification fidelity. Select the
-smallest necessary engineering workers using the mode and risk matrix; a change review
-for delivery runs every applicable role. Record every selected and skipped role with a
-scope-specific rationale. Invoke them through the current host's native bounded-worker
-mechanism. Keep workers independent and pass only the current diff plus their role
-context.
+## Select workers by risk
 
-Resolve `references/unified-schema.md` from this Skill directory and pass its absolute
-path as `SCHEMA_PATH`. Validate artifacts with `scripts/review_wait.py`; a missing,
-invalid, stale, or partial required artifact is not a pass.
+Always run `review-spec`. Select the smallest engineering worker set that covers the
+actual diff and risk. Record every selected and excluded worker with a specific
+rationale; do not run every specialist ceremonially.
 
-Record:
+Invoke workers through the current host's native bounded-worker mechanism and pass
+only their role, current scope, and relevant evidence. Workers are read-only and may
+not decide owner choices or edit source.
 
-- `review-specification` with `spec-fidelity.json` as an output;
-- `review-engineering` with every selected engineering artifact as outputs;
-- `coordinate-findings` with the coordinated summary output.
+Resolve `references/unified-schema.md` from this Skill directory and pass its absolute
+path as `SCHEMA_PATH`. Validate specialist artifacts with
+`scripts/review_wait.py`. Record outputs under `review-specification`,
+`review-engineering`, and `coordinate-findings`.
 
-The coordinator preserves every specialist finding unchanged in `SUMMARY.json`.
-Duplicate root causes may be grouped only in the human-readable summary. Review is
-read-only except for review artifacts; implementation fixes are a separate dev action.
-If a finding exposes a new owner choice, preserve it as a finding and route the primary
-agent to `ultra-think`; a review worker must not open, answer, or hide that decision.
+The coordinator preserves every finding unchanged in `SUMMARY.json`; it may group
+duplicate root causes only in the human summary. A new material owner choice remains a
+finding and routes to the interaction protocol.
 
-## Verify and complete
+## Complete
 
-Recheck reviewed HEAD, worktree digest, review-context digest, diff, acceptance, task
-set, artifact schemas, and both verdicts. Record `verify-review-gate`, then call
-`workflow.complete`. MCP
-derives each axis and the durable verdict from the specialist outputs, then requires
-`SUMMARY.json` to match their complete finding set. Prompt claims and a lossy
-coordinator summary cannot replace either axis. Any code, test, spec, or contract edit
-invalidates affected review evidence and requires a new or resumed run.
+Recheck HEAD, worktree, context digest, diff, task set, acceptance, artifact schemas,
+and both axes. Record `verify-review-gate`, then call `workflow.complete`. MCP derives
+the durable verdict and rejects missing specialists, lossy coordination, stale
+artifacts, or prompt-supplied conclusions.
 
-Return both axis verdicts first, blocking findings, reviewed revision and paths,
-artifact digests, workflow id, skipped-role rationale, and one exact next route. A
-blocking implementation finding returns to `ultra-dev`; stale verification returns to
-`ultra-test`; a new owner choice returns to `ultra-think`; an approved current change
-review routes to `ultra-deliver`.
+Any relevant code, test, specification, or contract edit invalidates the affected
+review evidence. Return both verdict axes, blocking findings, reviewed scope, worker
+selection rationale, artifact digests, and allowed transitions.

package/skills/ultra-review/references/review-modes.md

@@ -22,6 +22,8 @@ may be skipped with a concrete rationale.
 
 ## Selection record
 
-For every available worker, record `selected` or `skipped` and a rationale tied to the
-mode, changed paths, public seam, and risk flags. A role is applicable when its evidence
-could change either verdict axis. Tool availability alone is not a selection reason.
+Disposition the complete specialist roster: `review-spec`, `review-code`,
+`review-tests`, `review-errors`, `review-design`, and `review-comments`. Record each as
+`selected` or `skipped` with a rationale tied to the mode, changed paths, public seam,
+and risk flags. A role is applicable when its evidence could change either verdict
+axis. Tool availability alone is not a selection reason.

package/skills/ultra-review/references/unified-schema.md

@@ -87,9 +87,9 @@ preference as a defect. Preserve the source specialist's severity during coordin
     }
   },
   "workers": {
-    "completed": ["review-code", "review-tests"],
+    "completed": ["review-spec", "review-code", "review-tests"],
     "failed": [],
-    "skipped": []
+    "skipped": ["review-errors", "review-design", "review-comments"]
   },
   "worker_selection": [
     {
@@ -97,6 +97,26 @@ preference as a defect. Preserve the source specialist's severity during coordin
       "status": "selected",
       "rationale": "The specification axis is required for every review mode."
     },
+    {
+      "worker": "review-code",
+      "status": "selected",
+      "rationale": "The runtime diff changes executable behavior."
+    },
+    {
+      "worker": "review-tests",
+      "status": "selected",
+      "rationale": "The accepted behavior depends on changed test evidence."
+    },
+    {
+      "worker": "review-errors",
+      "status": "skipped",
+      "rationale": "The diff does not change an error, fallback, or recovery path."
+    },
+    {
+      "worker": "review-design",
+      "status": "skipped",
+      "rationale": "The bounded change does not alter module or data-flow boundaries."
+    },
     {
       "worker": "review-comments",
       "status": "skipped",
@@ -112,10 +132,10 @@ preference as a defect. Preserve the source specialist's severity during coordin
 `findings` must contain every specialist finding unchanged. Group duplicates only in
 the human-readable summary; never delete or merge machine-readable records.
 
-`mode` is `task`, `change`, or `plan`. `worker_selection` contains every selected or
-skipped worker exactly once with a scope-specific rationale. Its selected set equals
-`workers.completed` plus `workers.failed`; its skipped set equals `workers.skipped`.
-`review-spec` is always selected and completed.
+`mode` is `task`, `change`, or `plan`. `worker_selection` contains each member of the
+six-worker roster exactly once with a scope-specific selected or skipped rationale.
+Its selected set equals `workers.completed` plus `workers.failed`; its skipped set
+equals `workers.skipped`. `review-spec` is always selected and completed.
 
 The overall verdict is `APPROVE` only when both axes pass, artifacts are complete and
 current, and no P0 or P1 finding remains. Use `REQUEST_CHANGES` for a failed axis or

package/skills/ultra-review/scripts/review_wait.py

@@ -25,6 +25,14 @@ AXIS_VERDICTS = {"PASS", "FAIL", "INCOMPLETE"}
 OVERALL_VERDICTS = {"APPROVE", "REQUEST_CHANGES", "INCOMPLETE"}
 REVIEW_MODES = {"task", "change", "plan"}
 SELECTION_STATUSES = {"selected", "skipped"}
+REVIEW_WORKERS = {
+    "review-spec",
+    "review-code",
+    "review-tests",
+    "review-errors",
+    "review-design",
+    "review-comments",
+}
 ARTIFACT_STEM = re.compile(r"^[a-z][a-z0-9-]*$")
 FINDING_FIELDS = {
     "id", "axis", "severity", "category", "title", "file", "line", "trigger",
@@ -240,6 +248,10 @@ def validate_summary(data):
         return "selected workers must equal completed and failed workers"
     if skipped != set(workers["skipped"]):
         return "skipped worker selection must match workers.skipped"
+    if seen_workers != REVIEW_WORKERS:
+        missing = sorted(REVIEW_WORKERS - seen_workers)
+        extra = sorted(seen_workers - REVIEW_WORKERS)
+        return f"worker_selection must disposition the complete roster; missing={missing}, extra={extra}"
     if "review-spec" not in selected or "review-spec" not in set(workers["completed"]):
         return "review-spec must be selected and completed"
     findings = data.get("findings")

package/skills/ultra-status/SKILL.md

@@ -1,64 +1,54 @@
 ---
 name: ultra-status
-description: Report authoritative Ultra project health, baseline, workflow position, task/session progress, evidence freshness, blockers, and one deterministic next action. Use when the user asks what is complete, blocked, stale, or next in an Ultra project.
+description: Read authoritative Ultra health, workflows, decisions, changes, tasks, evidence freshness, and valid transitions. Use when the user asks what is complete, blocked, stale, or currently possible.
 ---
 
-# Route from authoritative state
+# Report authoritative state
 
-This workflow is read-only. Never reconstruct status from prose or generated task
-projections.
+This Skill is read-only. Never fall back to generated task JSON, prose, or context
+frontmatter when DB authority is missing or degraded.
 
-## Read order
+## Read
 
-1. Call `system.doctor` with repair disabled.
-2. Call `baseline.get` for classification, readiness, revision, worktree, spec digests,
-   research provenance, gaps, and blockers.
-3. Call `decision.list`, then `decision.get` for the current active or checkpoint-ready
-   thread. Expose only its current question or checkpoint, not the hidden history.
-4. Call `workflow.list`, then `workflow.get` for every active, blocked, or ready run.
-5. Call `change.breadcrumb`, `change.list`, `task.list`, and `session.list`.
-6. Inspect current Git branch, full HEAD, and worktree without mutation.
-7. Read test, review, and delivery artifacts only when referenced by DB workflow state;
-   compare their recorded digest and revision with current authority.
+1. Run `system.doctor` without repair.
+2. Read baseline classification, revision, worktree, research provenance, gaps, and
+   health.
+3. Read current decision state without exposing hidden future questions.
+4. Read active, blocked, and ready workflows and their current steps.
+5. Read breadcrumb, changes, tasks, sessions, and current Git state.
+6. Read test, review, and delivery artifacts only through DB references and verify
+   their digests and revisions.
 
-If state is unreadable, report that panel unavailable and route to `ultra-doctor`.
-Never fall back to generated task JSON, raw SQLite queries, or context frontmatter.
+If authority is unreadable, report the unavailable panel and the required doctor or
+init transition. Do not mutate, compile context, repair, or release.
 
-## Choose one route
+## Interpret transitions
 
-Prefer the breadcrumb and durable workflow position:
+MCP reports:
 
-- state integrity, schema, projection, or installed-asset failure: `ultra-doctor`;
-- open decision or checkpoint: `ultra-think` with its exact decision id;
-- missing project or migrated compatibility authority: `ultra-init`;
-- active/blocked research: `ultra-research` at its exact `current_step`;
-- ready research with unconverged baseline: finalize research, record, approve, and
-  converge through `ultra-research`;
-- active plan/change/dev/test/review/deliver run: its matching workflow at the exact
-  step or blocker;
-- ready baseline with no change: `ultra-change` to persist the requested outcome before
-  any planning;
-- archived change with fresh evidence: report completion without inventing more work.
+- `allowed_transitions`: mechanically valid capabilities;
+- `required_transition`: the sole recovery route only when a hard invariant permits no
+  safe alternative.
 
-Context-size warnings are advisory. Missing authority, stale required refs or outputs,
-incomplete task contracts, failed evidence, unresolved learning, and missing approval
-are blockers.
-
-## Output
+The host model recommends among allowed transitions using the user's current goal,
+workflow evidence, and cost of interruption. Do not present the recommendation as DB
+authority. A healthy project may validly allow research, change, thinking, or status at
+the same time.
 
 Report:
 
 ```text
-Ultra: <healthy|degraded> · <branch>@<head> · worktree <clean|dirty>
+Ultra: <healthy|degraded> · <branch>@<head|unborn|non-git> · worktree <state>
 Baseline: <mode>/<status> · research=<run/status> · gaps=<open>/<blocking>
-Workflow: <kind/id/status> · step=<current|finalize> · outputs=<fresh|stale>
-Decision: <id/phase|checkpoint|none> · thread=<id/status>
+Workflow: <kind/id/status> · step=<current|complete> · outputs=<fresh|stale>
+Decision: <current|checkpoint|none>
 Change: <id/status|none> · Task: <id/status|none> · Sessions: <active>
-Evidence: test=<state> · review=<two axes> · delivery=<state>
-Blockers: <specific codes or none>
-Warnings: <advisory codes or none>
-Next: <one exact action>
+Evidence: test=<state> · review=<axes> · delivery=<state>
+Blockers: <codes or none>
+Warnings: <codes or none>
+Allowed transitions: <capabilities>
+Required transition: <capability or none>
+Host recommendation: <capability and concise rationale>
 ```
 
-Separate verified facts, inferences, and unavailable evidence. Do not modify state,
-compile context, repair, or release from this Skill.
+Separate verified facts, host inference, and unavailable evidence.