ultra-builder-pro-cli 0.10.0 → 0.12.1

package/skills/ultra-status/SKILL.md

@@ -1,77 +1,62 @@
 ---
 name: ultra-status
-description: "Route the project from its authoritative Ultra breadcrumb, readiness gates, task state, and current verification evidence."
-user-invocable: true
-runtime: all
-mcp_tools_required:
-  - change.breadcrumb
-  - change.list
-  - task.list
-  - task.get
-  - session.list
-  - system.doctor
-cli_fallback: "status --cost --json"
+description: Report authoritative Ultra health, position, readiness, evidence freshness, and one deterministic next action. Use when the user asks where an Ultra project stands or what should happen next.
 ---
 
-# ultra-status — One Router, One Next Action
+# Route from authoritative status
 
-Use this workflow to answer “where are we?” and “what should happen next?” without
-reconstructing project state from prose. `.ultra/state.db` is authoritative; reports
-and Markdown are evidence or projections.
+Answer status questions without reconstructing state from prose. `.ultra/state.db` is
+authoritative; reports and Markdown are evidence or projections.
 
 ## Read order
 
-1. Call `system.doctor { repair: false }`. If authority is unhealthy, route only to
+1. Call `system.doctor` in read-only mode. If authority is unhealthy, route only to
    `ultra-doctor` and include the blocking diagnostic.
-2. Call `change.breadcrumb`. It returns the active change, task, role, gate,
-   readiness, blockers, stale status, and one deterministic next action.
-3. Call `task.list` and `session.list` for counts and active execution detail.
-4. Read `.ultra/test-report.json` and `.ultra/delivery-report.json` only when they
-   exist. Treat a report from a different HEAD as stale.
-5. Read git branch, HEAD, and worktree status. Do not mutate anything.
-
-Never fall back to `.ultra/tasks/tasks.json`, context Markdown frontmatter, or raw
-SQLite when MCP task state is unavailable. Label that panel unavailable.
-
-## Routing rules
-
-The breadcrumb owns the primary route. Do not print a menu of every Ultra command.
-
-| State | Route |
-|---|---|
-| doctor unhealthy | `ultra-doctor` |
-| no Ultra project | `ultra-init` |
-| no baseline specs or tasks | `ultra-research` or `ultra-plan`, matching the missing artifact |
-| readiness blocked or context stale | recompile through `ultra-change`, `ultra-plan`, or `ultra-dev` as named by the breadcrumb |
-| implementation task ready | `ultra-dev <task-id>` |
-| all scoped tasks complete, test report missing/stale | `ultra-test` |
-| review or convergence incomplete | `ultra-review all` or `ultra-deliver`, matching the gate |
-| ready change | `ultra-deliver` |
-| archived change and clean HEAD | report complete; do not invent more work |
-
-When there is no active change, derive a single baseline route from tasks and reports.
-If several changes are active or blocked, report ambiguity and require an explicit
-change id instead of guessing.
+2. Call `baseline.get` for mode, lifecycle status, repository revision, specification
+   digest health, known warnings, and adoption blockers.
+3. Call `change.breadcrumb` for the active change, task, role, gate, readiness,
+   blockers, advisory warnings, staleness, and next action.
+4. Call `task.list` and `session.list` for progress and active execution details.
+5. Read test and delivery reports only when present, and mark a report stale when its
+   HEAD differs from the current checkout.
+6. Read Git branch, HEAD, and worktree status without mutation.
+
+If MCP task or change state is unavailable, label that panel unavailable. Never fall
+back to generated task JSON, context frontmatter, or raw SQLite.
+
+## Routing
+
+Follow the breadcrumb's primary route and return one action, not a menu:
+
+- unhealthy authority: `ultra-doctor`;
+- missing Ultra project: `ultra-init`;
+- missing baseline evidence with no active change: `ultra-init`, then
+  `ultra-research` or `ultra-plan` according to the gap;
+- baseline or context-budget warning during an active change: keep the current route
+  and surface the warning; do not turn it into a refusal;
+- blocked or stale context: the workflow named by the breadcrumb;
+- ready implementation task: `ultra-dev <task-id>`;
+- completed tasks with missing or stale test evidence: `ultra-test`;
+- incomplete review or convergence: `ultra-review` or `ultra-deliver`;
+- ready change: `ultra-deliver`;
+- archived change with fresh evidence: report completion without inventing more work.
+
+Require an explicit change id when several active changes make the route ambiguous.
 
 ## Output
 
-Keep the answer compact:
+Use a compact shape:
 
 ```text
 Ultra: <healthy|degraded> · <branch>@<head> · worktree <clean|dirty>
 Position: change=<id|none> task=<id|none> role=<role> gate=<gate>
+Baseline: <greenfield|brownfield|migrated>/<status> revision=<revision|none>
 Readiness: <ready|blocked|stale> — <blockers or none>
+Warnings: <advisory conditions or none>
 Progress: <completed>/<total>; sessions=<active count>
 Evidence: tests=<fresh|stale|missing>; delivery=<fresh|stale|missing>
-Next: <exactly one action, including the task/change id when known>
+Next: <one exact action>
 ```
 
-Separate verified facts from unavailable panels. Do not hide a stale context or stale
-test report behind an overall “healthy” label.
-
-## Boundaries
-
-- Read-only: this workflow does not repair, compile context, update tasks, or release.
-- Cost data may use the declared CLI fallback, but task/change authority may not.
-- External memory and code graph providers are optional metadata references; their
-  absence does not change Ultra authority.
+This workflow is read-only. It does not repair state, compile context, update tasks, or
+release software.

package/skills/ultra-test/SKILL.md

@@ -1,94 +1,59 @@
 ---
 name: ultra-test
-description: "Run the pre-delivery check gate from a fresh role context and record exact feedback-loop, wiring, recovery, and acceptance evidence."
-user-invocable: true
-runtime: all
-mcp_tools_required:
-  - task.list
-  - change.list
-  - change.context
-  - change.breadcrumb
+description: Run an independent pre-delivery verification gate and record exact feedback-loop, reachability, recovery, and acceptance evidence. Use when scoped implementation tasks are complete and delivery readiness must be established.
 ---
 
-# ultra-test — Independent Check Context
+# Verify delivery readiness
 
-This is the project/change pre-delivery gate, not a replacement for the task-level TDD
-loop. It produces `.ultra/test-report.json`; task and change authority remain in
-`.ultra/state.db`.
+Run this gate from a fresh checking context. It complements task-level development
+tests and writes `.ultra/test-report.json`; it does not replace authoritative task or
+change state.
 
 ## Entry gate
 
-1. Call `task.list`; require at least one completed task in scope.
-2. Call `change.list` and bind to exactly one relevant active/blocked/ready change, or
-   explicitly record `change_id: null` for an initial baseline.
-3. For a change, compile `change.context` with `role=check`, `gate=verification`, only
-   the tests/specs/source seams needed to verify it, and the same execution contract.
+1. Call `task.list` and require at least one completed task in scope.
+2. Call `change.list` and bind exactly one relevant change, or record a null change id
+   for an initial baseline.
+3. For a change, compile `change.context` for the checking role and verification gate
+   with only the specifications, tests, and source seams needed for acceptance.
 4. Call `change.breadcrumb`; stop when context is stale or readiness is blocked.
 
-Never fall back to `.ultra/tasks/tasks.json`. Do not reuse the implementer's full
+Never use generated task JSON as authority or reuse the implementer's full
 conversation as test context.
 
-## Verification matrix
+## Evidence matrix
 
-Build a matrix from acceptance claims to observable evidence:
+Map each acceptance claim to observable evidence:
 
-| Check | Required evidence | Blocking condition |
+| Check | Evidence | Blocking result |
 |---|---|---|
-| Feedback loop | exact command and observed green | command fails or no prior red for fix/incident |
-| Public seam | reachable entry-to-consumer path | orphan/stub/unwired behavior |
-| Regression | focused and adjacent suites | failure or meaningful skipped assertion |
-| Build/static | typecheck/lint/build as applicable | non-zero result |
-| Error/recovery | failure mode and recovery path | silent/swallowed/unrecoverable critical path |
-| Security | input/auth/secrets/dependency checks in scope | high-severity issue |
-| Docs/spec | delivered behavior matches declared delta | drift or unknown impact |
-
-Use repository-native commands and real boundaries where practical. Test doubles are
-acceptable only at costly or nondeterministic external boundaries and must be named.
-
-## Quality checks
-
-- Detect tautologies, empty tests, weakened assertions, and core-domain over-mocking.
-- Find changed exports without meaningful test coverage.
-- Trace changed source into non-test consumers; flag orphan modules and placeholder
-  handlers/components.
-- Exercise key API/UI/CLI flows when the project exposes them.
-- Inspect error handling, authorization, migrations, idempotency, and rollback in the
-  affected risk surface.
-- Compare current HEAD and context digests with the implementation evidence.
-
-Do not mechanically require every possible test category. Mark a check
-`not_applicable` only with a concrete scope reason.
+| Feedback loop | exact command and observed result | failure or missing baseline signal for a fix |
+| Public seam | reachable entry-to-consumer path | orphan, stub, or unwired behavior |
+| Regression | focused and adjacent suites | failure or weakened assertion |
+| Static/build | applicable type, lint, and build commands | non-zero result |
+| Error/recovery | exercised failure and recovery path | silent or unrecoverable critical path |
+| Security | relevant input, authorization, secret, and dependency checks | high-impact exploitable issue |
+| Docs/spec | delivered behavior matches the declared baseline or delta | drift or unknown impact |
+
+Use repository-native commands and real boundaries when practical. Use test doubles
+only at costly or nondeterministic external boundaries, and state why they preserve
+the contract being tested.
+
+Inspect tests for tautologies, empty assertions, hidden skips, excessive boundary
+mocking, changed exports without behavioral coverage, and code with no non-test
+consumer. Apply checks by risk and scope rather than forcing every category.
 
 ## Report contract
 
-Write `.ultra/test-report.json` atomically with at least:
-
-```json
-{
-  "schema_version": "2.0",
-  "change_id": "<id-or-null>",
-  "git_commit": "<full-head>",
-  "context_manifest_hash": "<hash-or-null>",
-  "passed": true,
-  "feedback_loop": {
-    "command": "<exact command>",
-    "expected_red": "<failure contract or not-applicable reason>",
-    "observed_red": true,
-    "observed_green": true,
-    "deterministic": true
-  },
-  "public_seams": ["<verified seam>"],
-  "checks": [],
-  "blocking_issues": [],
-  "commands": []
-}
-```
+Write the report atomically with the current full HEAD, change id, context manifest
+hash, exact commands, baseline and final signals, verified public seams, checks, and
+blocking issues. Preserve concise failure excerpts instead of full logs.
 
-Set `passed=true` only when every required check passes, the report HEAD is current,
-and at least one public seam is verified. Preserve exact commands, exit results, and
-concise failure excerpts; do not paste full logs.
+Set `passed: true` only when every required check passes, the report HEAD is current,
+and at least one declared public seam is verified. A not-applicable check needs a
+specific scope reason.
 
 ## Exit
 
-Call `change.breadcrumb` and route one next action: fix a named blocker, run
-`/ultra-review all`, or run `/ultra-deliver`. A stale report never routes to delivery.
+Call `change.breadcrumb` and return one next action: fix a named blocker, run
+`ultra-review`, or run `ultra-deliver`. A stale report never routes to delivery.

package/skills/ultra-think/SKILL.md

@@ -1,110 +1,51 @@
 ---
 name: ultra-think
-description: "Deep analysis with adversarial reasoning — Evidence-First + Multi-Perspective + Steel-Man + Pre-Mortem + Sensitivity. Produces a recommendation with confidence bounds."
-user-invocable: true
-runtime: all
-cli_fallback: "direct user interaction"
+description: Produce an evidence-bounded recommendation or diagnosis for a consequential technical or product question. Use when the decision has material tradeoffs, uncertainty, or failure risk that benefits from explicit stress testing.
 ---
 
-# ultra-think — Phase 3.6
+# Analyze a consequential question
 
-Reasoning harness for complex decisions / diagnostics / architecture calls.
-Enforces Evidence-First labelling and adversarial stress-tests before issuing
-a recommendation with explicit confidence.
+Use the smallest reasoning structure that resolves the user's actual decision. Answer
+simple questions directly; do not turn every request into a framework exercise.
 
 ## Workflow
 
-### Step 1 — Scope Check
-
-If the problem is ambiguous / underspecified, ask up to **3** clarifying
-questions through the current Host's native user-interaction surface.
-If the problem is simple, **skip the framework**, answer concisely, and mark
-downstream steps `completed` with note `"skipped: simple answer path"`.
-
-### Step 2 — Evidence Gathering
-
-Every factual claim about tech/API/best-practices must be verified via:
-- Repo source (Read/Grep)
-- Official docs (Context7 MCP: `mcp__context7__query-docs`)
-- Community (Exa MCP: `mcp__exa__web_search_exa`)
-- Web search (fallback)
-
-Label each assertion:
-- **Fact** — verified, cite source (URL / file path)
-- **Inference** — deduced from facts (show the derivation chain)
-- **Speculation** — unverified; list verification steps the user can run
-
-**Iron law**: never trade accuracy for speed. Wrong-with-confidence > "I don't know + here's how to check".
-
-### Step 3 — Multi-Perspective Analysis
-
-Generate **≥3 distinct approaches**. For each, apply whichever lenses are relevant:
-- **Technical** — feasibility, scalability, security, maintainability
-- **Business** — value, cost, time-to-market, competitive advantage
-- **User** — needs, experience, edge cases, accessibility
-- **System** — integration, dependencies, emergent behaviors
-
-### Step 4 — Adversarial Stress-Testing
-
-Apply all four techniques:
-
-| Technique | Question |
-|-----------|----------|
-| **Steel Man** | For the option you're inclined to REJECT, build its strongest possible case. What do you discover? |
-| **Pre-Mortem** | Assume the recommended option has failed in 6 months. List the 3 most likely causes. |
-| **Sensitivity** | Which single assumption, if wrong, would reverse your recommendation? |
-| **Second-Order** | What new problems does the recommendation create 6-12 months out? |
-
-### Step 5 — Synthesis
-
-Recommendation with quantified confidence (0-100%) and explicit uncertainty bounds.
-
-## Output Structure (adapt to problem type)
-
-### Problem Statement
-1-2 sentences: core decision + key constraints.
-
-### Analysis
-Deep analysis using relevant lenses from Step 3.
-
-### Options Comparison (skip for diagnostic/investigative problems)
-| Criterion | Weight | Option A | Option B | Option C |
-|-----------|-------:|----------|----------|----------|
-Quantified where possible.
-
-### Adversarial Findings
-- **Strongest counter-argument** (steel man for rejected option)
-- **Pre-mortem top risk** (most likely failure + mitigation)
-- **Assumption sensitivity** (load-bearing assumption)
-
-### Recommendation
-- **Choice**: <option>
-- **Confidence**: <X>% because <rationale>
-- **Key Assumptions**: what must be true
-- **What would change my mind**: specific evidence / outcome
-
-### Verification Plan
-Concrete steps to validate the decision — metrics, tests, time-boxed experiments.
-
-### Next Steps
-Ordered, actionable items.
-
-## MCP → CLI fallback matrix
-
-| Purpose | MCP tool | CLI fallback |
-|---------|----------|--------------|
-| Clarifying questions | none | current Host's native user-interaction surface |
-
-## What this skill DOES NOT do
-
-- Does NOT modify state.db or project files
-- Does NOT implement the recommendation (that's `/ultra-dev` after `/ultra-plan`)
-- Does NOT replace independent review — output is one model's analysis
-
-## Integration
-
-| | |
-|---|---|
-| **Input** | the problem statement in `$ARGUMENTS`, optional repo context via Read/Grep, docs via Context7/Exa |
-| **Output** | structured Markdown report (Chinese per project rule) |
-| **Feeds** | decisions captured in `.ultra/specs/architecture.md` via Dual-Write Mode of `/ultra-dev` |
+1. State the decision, observed symptom, or disputed claim and the constraints that
+   could change the answer. Ask only for missing information that materially affects
+   the result.
+2. Gather evidence from the most authoritative available source:
+   - current checkout and runtime for repository claims;
+   - official primary documentation for product or API behavior;
+   - current web sources for unstable external facts.
+3. Separate verified facts, evidence-backed inferences, and unresolved assumptions.
+   Cite the supporting file, command, runtime result, or source near each consequential
+   claim.
+4. For a decision, compare only credible alternatives. Do not invent a fixed number of
+   options or assign arbitrary numeric scores. Name the criteria that actually drive
+   the choice and explain the tradeoffs.
+5. For a diagnosis, form falsifiable hypotheses and identify the smallest observation
+   that distinguishes them. Do not recommend implementation before the earliest
+   incorrect state is supported by evidence.
+6. Stress-test the leading conclusion with the techniques that fit the problem:
+   - strongest counterargument;
+   - likely failure scenario and recovery;
+   - load-bearing assumption;
+   - meaningful second-order effect.
+7. Return the recommendation or diagnosis, evidence, uncertainty, what would change
+   the conclusion, and the smallest verification step.
+
+## Output
+
+Adapt the response to the question. Include:
+
+- the conclusion first;
+- the decisive evidence and tradeoffs;
+- unresolved uncertainty without false precision;
+- one concrete verification or follow-up action.
+
+Use a comparison table only when several alternatives share the same decision
+criteria. Comparisons are an analysis tool, not a required output section.
+
+This skill is read-only unless the user separately authorizes writing an analysis
+artifact. It does not update Ultra state, implement the recommendation, or replace an
+independent review.

package/skills/ultra-verify/SKILL.md

@@ -1,92 +1,52 @@
 ---
 name: ultra-verify
-description: Run independent two-model verification with the current host as primary and a read-only Codex advisor, then verify and synthesize the evidence.
+description: Run independent two-model verification with the current host as primary and a read-only external advisor, then verify and synthesize both evidence sets. Use only when the user explicitly requests cross-model verification.
 ---
 
-# Ultra Verify — Independent Two-Model Verification
+# Run independent cross-model verification
 
-Claude Code remains primary. It writes the first independent analysis, verifies consequential
-claims, and owns the final answer. Codex is an untrusted read-only advisor. Use this workflow only
-when the user explicitly asks for cross-model verification.
+Claude Code writes the first analysis, verifies consequential claims, and owns the
+final answer. Codex is an untrusted read-only advisor.
 
 ## Modes
 
-- `decision <question>`: architecture or product decision.
-- `diagnose <symptoms>`: independent root-cause hypotheses.
-- `audit <scope>`: evidence-backed findings.
-- `estimate <task>`: estimates with explicit assumptions.
-
-## Preconditions
-
-1. Confirm `codex --version` plus authentication.
-2. Define the exact workspace, question, evidence standard, and response shape.
-3. Do not send secrets, unrelated files, or an unbounded home directory.
-4. Track four steps in the current host plan: primary analysis, advisor launch, completion wait,
-   and verified synthesis.
-
-## 1. Create the session and write the primary view
-
-```bash
-SESSION_ID="$(date +%Y%m%d-%H%M%S)-verify-<mode>"
-SESSION_PATH=".ultra/collab/${SESSION_ID}"
-mkdir -p "${SESSION_PATH}"
-```
-
-Write Claude Code's evidence-backed analysis to `${SESSION_PATH}/claude-analysis.md` before
-reading the advisor output. Record the mode, checkout, scope, and evidence boundary.
-
-## 2. Launch the advisor read-only
-
-Give the advisor the bounded raw question and evidence without the primary conclusion.
-
-```bash
-codex exec -s read-only \
-  -o "${SESSION_PATH}/codex-output.md" \
-  "<bounded prompt>" \
-  2> "${SESSION_PATH}/codex-error.log"
-```
-
-Never enable write-capable automation, danger-full-access, or permission bypass for the advisor.
-
-## 3. Wait for completed output
-
-Run the bundled waiter in an asynchronous or yielded shell session and poll it at bounded
-intervals; never hold one blocking tool call longer than 60 seconds.
-
-```bash
-python3 "$CLAUDE_PLUGIN_ROOT/skills/ultra-verify/scripts/verify_wait.py" \
-  "${SESSION_PATH}" --timeout 1200
-```
-
-The waiter reports the advisor as `complete`, `failed`, `empty`, or `pending`. Read the output only
-after its status is `complete` and the file is non-empty. Preserve the error log when it fails.
-
-## 4. Verify and synthesize
-
-Compare `claude-analysis.md` with `codex-output.md`:
-
-1. Verify claims against the current checkout, tests, runtime, or primary documentation.
-2. Separate verified agreement, useful dissent, and unsupported assertions.
-3. Explain scope, version, and assumption differences before judging the result.
-4. Write `synthesis.md` and `metadata.json`, then return one Claude Code-owned conclusion.
-
-Use `references/confidence-system.md` for evidence-based confidence and
-`references/cross-verify-modes.md` for mode-specific expectations. Model agreement never overrides
-failing tests or authoritative runtime evidence.
-
-## Degraded operation
-
-- Advisor failure: return the primary analysis with an explicit single-source warning.
-- Never block the underlying user task solely because the advisor is absent, unauthenticated, or
-  slow.
-
-## Session files
-
-```text
-.ultra/collab/<SESSION_ID>/
-  claude-analysis.md
-  codex-output.md
-  codex-error.log
-  metadata.json
-  synthesis.md
-```
+- `decision`: one consequential architecture or product choice;
+- `diagnose`: independent root-cause hypotheses;
+- `audit`: evidence-backed findings over a bounded scope;
+- `estimate`: an estimate with explicit assumptions and uncertainty.
+
+## Workflow
+
+1. Confirm the advisor CLI and authentication. Define the exact workspace, question,
+   evidence standard, and response shape. Exclude secrets and unrelated files.
+2. Create `.ultra/collab/<session-id>/` and write the primary host's evidence-backed
+   analysis to `claude-analysis.md` before reading advisor output.
+3. Launch Codex with the raw bounded question and evidence in a read-only sandbox. Do
+   not include the primary conclusion when independence matters:
+
+   ```bash
+   codex exec -s read-only \
+     -a never \
+     --ephemeral \
+     --ignore-user-config \
+     --ignore-rules \
+     -o "${SESSION_PATH}/codex-output.md" \
+     "<bounded prompt>" \
+     2> "${SESSION_PATH}/codex-error.log"
+   ```
+4. Run `scripts/verify_wait.py` resolved relative to this skill directory. Use a
+   yielded or asynchronous shell session and poll at bounded intervals; do not hold a
+   blocking tool call longer than one minute.
+5. Read advisor output only after the waiter reports a complete, non-empty file.
+6. Verify both analyses against the current checkout, tests, runtime, or primary
+   documentation. Explain scope, version, evidence, and assumption differences before
+   judging disagreement.
+7. Write session metadata and a synthesis artifact, then return one host-owned
+   conclusion.
+
+Read `references/cross-verify-modes.md` for mode-specific evidence and
+`references/confidence-system.md` when confidence language is useful. Model agreement
+never overrides failing tests or authoritative runtime evidence.
+
+Advisor failure degrades to the primary analysis with a single-source warning. It does
+not block the user's underlying task.

package/skills/ultra-verify/evals/evals.json

@@ -2,47 +2,44 @@
   "skill_name": "ultra-verify",
   "evals": [
     {
-      "id": 1,
-      "prompt": "/ultra-verify decision 'Should we use PostgreSQL or MongoDB for our new microservice?'",
-      "expected_output": "Claude writes its analysis first, launches Codex read-only, verifies both analyses, and returns one evidence-backed synthesis",
+      "id": "explicit-decision",
+      "prompt": "Run independent cross-model verification on the database choice, with the current host writing its view before the advisor.",
+      "should_trigger": true,
       "assertions": [
-        "Claude writes its own analysis before reading advisor output",
-        "Launches Codex with a read-only sandbox",
-        "Creates a session directory under .ultra/collab/",
+        "Writes the primary analysis before reading advisor output",
+        "Launches the advisor in a read-only sandbox",
+        "Uses a bounded session directory and completion waiter",
         "Verifies consequential claims against authoritative evidence",
-        "Separates verified agreement, useful dissent, and unsupported assertions"
+        "Returns one host-owned synthesis"
       ]
     },
     {
-      "id": 2,
-      "prompt": "/ultra-verify diagnose 'API returns 500 intermittently under load'",
-      "expected_output": "Independent hypotheses are reconciled through discriminating checks and evidence strength",
+      "id": "explicit-diagnosis",
+      "prompt": "Use two independent models to diagnose the intermittent 500 response and reconcile their hypotheses with discriminating checks.",
+      "should_trigger": true,
       "assertions": [
-        "Both analyses provide ranked hypotheses",
-        "Duplicate hypotheses are merged by root cause",
-        "Each retained hypothesis includes a verification step",
-        "Investigation order follows evidence strength and verification cost"
+        "Keeps both initial hypotheses independent",
+        "Deduplicates by root cause after both outputs complete",
+        "Orders verification by evidence and diagnostic value",
+        "Does not decide by model vote"
       ]
     },
     {
-      "id": 3,
-      "prompt": "/ultra-verify audit",
-      "expected_output": "Findings are deduplicated and verified against the current checkout without vote-based severity",
+      "id": "ordinary-analysis-negative",
+      "prompt": "Should this service use PostgreSQL or MongoDB?",
+      "should_trigger": false,
       "assertions": [
-        "Uses the same scope and severity model for both analyses",
-        "Verifies every reported location",
-        "Retains uniquely reported findings when source evidence confirms them",
-        "Severity does not depend on model agreement"
+        "Answers with the ordinary analysis workflow",
+        "Does not launch an external advisor without explicit cross-model intent"
       ]
     },
     {
-      "id": 4,
-      "prompt": "/ultra-verify estimate 'Implement OAuth2 login with two providers'",
-      "expected_output": "Two estimates are reconciled by scope, assumptions, dependencies, and risk",
+      "id": "ordinary-review-negative",
+      "prompt": "Review these changes before I commit.",
+      "should_trigger": false,
       "assertions": [
-        "Both analyses include work breakdowns and assumptions",
-        "Large differences are explained rather than averaged mechanically",
-        "Final range is supported by the reconciled work breakdown"
+        "Uses the standard review workflow",
+        "Does not substitute cross-model verification for native review"
       ]
     }
   ]