ultra-builder-pro-cli 0.9.0 → 0.11.0

package/skills/ultra-status/SKILL.md

@@ -1,190 +1,55 @@
 ---
 name: ultra-status
-description: "Real-time project status — progress, risk analysis, workflow routing. Reads task.list + session.list from state.db; reads test/delivery reports from files."
-runtime: all
-mcp_tools_required:
-  - task.list
-  - task.get
-  - session.list
-  - session.subscribe_events
-  - change.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 — Phase 3.6
+# Route from authoritative status
 
-Single-call dashboard. Pulls task state from state.db (authoritative), layers
-in `.ultra/test-report.json` + `.ultra/delivery-report.json` (file artifacts),
-reports progress + risks + workflow routing.
-It never treats a completed initial delivery as a terminal state: a healthy
-baseline routes the next daily request through `/ultra-change`.
+Answer status questions without reconstructing state from prose. `.ultra/state.db` is
+authoritative; reports and Markdown are evidence or projections.
 
-## Authority failure boundary
+## Read order
 
-`task.list` and `task.get` are the only task-state inputs. If either is
-unavailable or returns an authority error, surface it and stop. Never fall back to `.ultra/tasks/tasks.json`.
-On `LEGACY_STATE_MIGRATION_REQUIRED`, instruct the
-user to run `ultra-tools migrate --from=4.4 --to=4.5 --source-dir <project-root>`.
+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` for the active change, task, role, gate, readiness,
+   blockers, staleness, and next action.
+3. Call `task.list` and `session.list` for progress and active execution details.
+4. Read test and delivery reports only when present, and mark a report stale when its
+   HEAD differs from the current checkout.
+5. Read Git branch, HEAD, and worktree status without mutation.
 
-## Workflow
+If MCP task or change state is unavailable, label that panel unavailable. Never fall
+back to generated task JSON, context frontmatter, or raw SQLite.
 
-### Phase 0 — Environment validation
+## Routing
 
-| Check | If missing |
-|-------|-----------|
-| state.db reachable through `task.list` | suggest `/ultra-init` only when `.ultra/` is absent; otherwise surface the MCP error |
-| At least one task visible via `task.list` | suggest `/ultra-plan` |
-| `task.list` returns valid rows | surface error |
+Follow the breadcrumb's primary route and return one action, not a menu:
 
-### Phase 1 — Load data
+- unhealthy authority: `ultra-doctor`;
+- missing Ultra project: `ultra-init`;
+- missing baseline evidence: `ultra-research` or `ultra-plan`, matching the gap;
+- 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.
 
-```jsonc
-// MCP: task.list (no filter — get all tasks)
-{}
-// → { tasks: [...], count: N }
+Require an explicit change id when several active changes make the route ambiguous.
 
-// MCP: session.list (active sessions; Phase 4.5.4)
-{ "status": "running" }
-// → { sessions: [...], count: N }
+## Output
 
-// MCP: session.subscribe_events (recent events for the "last event" panel)
-{ "since_id": 0, "limit": 20 }
-// → { events: [...], next_since_id: M }
+Use a compact shape:
 
-// MCP: change.list (continuous-change lane)
-{ "limit": 20 }
-
-// MCP: system.doctor (read-only runtime health)
-{ "repair": false }
+```text
+Ultra: <healthy|degraded> · <branch>@<head> · worktree <clean|dirty>
+Position: change=<id|none> task=<id|none> role=<role> gate=<gate>
+Readiness: <ready|blocked|stale> — <blockers or none>
+Progress: <completed>/<total>; sessions=<active count>
+Evidence: tests=<fresh|stale|missing>; delivery=<fresh|stale|missing>
+Next: <one exact action>
 ```
 
-Also read:
-- `.ultra/test-report.json` — if present
-- `.ultra/delivery-report.json` — if present
-
-Extract:
-- Task stats: by status (`pending`/`in_progress`/`completed`/`blocked`), by priority (P0-P3)
-- Current `in_progress` task, next `pending` task (topological order)
-- Active sessions: count, per-runtime breakdown, orphan warnings
-- Most recent 20 events (by `events.id` DESC) — "last event" panel
-- Test passed / failed / stale (compare `git_commit` to HEAD)
-- Delivery readiness (tag + pushed)
-- Active/blocked/ready change, linked task counts, docs impact, and context freshness
-- Runtime health: open incidents, projection lag/failure, orphan sessions, missing change artifacts
-
-### Phase 2 — Progress report
-
-Compact multi-section output:
-- **Overview**: progress bar `[████░░░░] 50%`, completion %, velocity (completed tasks / elapsed days)
-- **Tasks**: counts per status + per priority
-- **Test**: pass/fail, `run_count`, `blocking_issues` if any
-- **Delivery**: `version` + `pushed` + last tag
-- **Change**: active id/kind/status, docs impact, task completion, context/provider freshness
-- **Runtime**: healthy/degraded with failing doctor checks only
-- **Risks**: auto-detected list (see Phase 3)
-- **Next**: recommended next task (see Phase 4)
-
-### Phase 3 — Risk detection
-
-Auto-detect:
-- **Blockers**: tasks with unsatisfied dependencies
-- **Stalled**: `in_progress` for >3 days (check `updated_at`)
-- **Overdue**: past `estimated_days` from when moved to `in_progress`
-- **Complexity spike**: 3+ consecutive `pending` tasks with complexity ≥7
-- **Test stale**: `test-report.json.git_commit ≠ HEAD`
-- **Orphan sessions**: any session with `lease_expires_at < now()` still status=running
-  (uninitialized by orphan-reaper; escalate)
-- **Projection/incident failure**: read-only doctor is degraded → route to
-  `/ultra-doctor`; never infer recovery from a generated JSON file
-- **Context stale**: active change manifest head or task set differs from current state
-- **Docs drift**: change has `docs_impact.status=unknown` or declared required file is missing
-
-| Icon | Meaning | Action |
-|------|---------|--------|
-| 🟢 | on track | continue |
-| 🟡 | minor issues | review stalled |
-| 🟠 | significant risks | address blockers |
-| 🔴 | critical | stop and resolve |
-
-### Phase 4 — Next-task recommendation
-
-Select next optimal task by:
-1. Priority (P0 > P1 > P2 > P3)
-2. Dependencies resolved (only `pending` with all deps `completed`)
-3. Complexity sweet spot (prefer 3-5, avoid clustering 7+)
-4. Context continuity (favor same component as recent completed task)
-
-### Phase 5 — Workflow routing (▶ Next Up)
-
-Detect position from artifacts:
-
-| Condition | Route |
-|-----------|-------|
-| No `.ultra/` | `/ultra-init` |
-| Specs have `[NEEDS CLARIFICATION]` or missing | `/ultra-research` |
-| No tasks and no delivered baseline | `/ultra-plan` |
-| Doctor degraded because of Ultra runtime state | `/ultra-doctor` |
-| No active/blocked/ready change and fresh delivery exists | `/ultra-change` for the next daily change |
-| Active change has any `pending` linked task | `/ultra-dev` (show which) |
-| Active change linked tasks all `completed` | `/ultra-test` |
-| Matching fresh `test-report.json.passed === true` | `/ultra-deliver` |
-| `test-report.json.passed === false` | `/ultra-dev` (show blocking issues) |
-| Change is `ready` | `/ultra-deliver` to reconcile/archive before release completion |
-| Latest change archived and delivery fresh | Baseline healthy; next work starts with `/ultra-change` |
-
-**Safety checks before routing**:
-- Routing to deliver but `test-report.git_commit ≠ HEAD` → warn "Tests stale"
-- `git status --porcelain` non-empty → warn "Uncommitted changes"
-
-**Output block**:
-```markdown
----
-## ▶ Next Up
-**{command}** — {description}
-`/clear` then `/{command}`
----
-**Also available**: `/{alt}` — {description}
----
-```
-
-## Single-task mode (`$1` supplied)
-
-When `task-id` provided:
-```jsonc
-// MCP: task.get
-{ "id": "<id>" }
-```
-Display: title, status, priority, complexity, deps, files_modified (if set),
-session_id (if active), `context_file`, `trace_to`, stale flag, update history.
-
-## MCP and CLI matrix
-
-| Purpose | MCP tool | CLI fallback |
-|---------|----------|--------------|
-| List tasks | `task.list` | none; fail closed |
-| Single task detail | `task.get` | none; fail closed |
-| Change lane | `change.list` | none; fail closed |
-| Runtime health | `system.doctor { repair:false }` | `ultra-tools system doctor` |
-| Cost panel (Phase 6.3) | — | `ultra-tools status --cost --json --since 7d` |
-
-## Cost panel (Phase 6.3)
-
-`ultra-tools status --cost --json` returns `{period, by_runtime, top_tasks,
-total_cost_usd}`. Render under the progress section when the user asks
-"how much did we spend?" or `/ultra-status --cost` is invoked. `--since 7d`
-is the conventional weekly window; override with ISO-8601 for custom ranges.
-
-## What this skill DOES NOT do
-
-- Does NOT modify or repair state
-- Does NOT run tests / build / deploy
-- Does NOT require all artifacts (partial reports are tolerated)
-
-## Integration
-
-| | |
-|---|---|
-| **Input** | state.db via task/change/session/system reads, test/delivery reports, git HEAD |
-| **Output** | console report (Chinese per project rule) |
-| **When** | anytime — idempotent read-only |
+This workflow is read-only. It does not repair state, compile context, update tasks, or
+release software.

package/skills/ultra-test/SKILL.md

@@ -1,213 +1,59 @@
 ---
 name: ultra-test
-description: "Pre-delivery quality audit — Anti-Pattern + Coverage Gap + Wiring + E2E + Performance + Security. Writes .ultra/test-report.json; no state.db writes."
-runtime: all
-mcp_tools_required:
-  - task.list
-  - change.list
+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 — Phase 3.5
+# Verify delivery readiness
 
-Project-level quality audit before `/ultra-deliver`. Auditors are orthogonal;
-each writes a JSON gate result; the skill aggregates into `.ultra/test-report.json`.
-This is **not** for running unit tests (that is `/ultra-dev`). This is the
-pre-ship gate.
+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.
 
-## Authority failure boundary
+## Entry gate
 
-The completed-task precheck requires MCP `task.list`. If it is unavailable or
-returns an authority error, stop the audit. Never fall back to
-`.ultra/tasks/tasks.json`. For `LEGACY_STATE_MIGRATION_REQUIRED`, instruct
-`ultra-tools migrate --from=4.4 --to=4.5 --source-dir <project-root>`.
+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.
 
-## Prerequisites
+Never use generated task JSON as authority or reuse the implementer's full
+conversation as test context.
 
-- `task.list` returns ≥1 task with `status=completed`
-- Repo has test files (Step 0 pre-check)
+## Evidence matrix
 
-## Workflow
+Map each acceptance claim to observable evidence:
 
-### Step 0 — Pre-Execution
+| Check | Evidence | Blocking result |
+|---|---|---|
+| 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 |
 
-1. Detect project type from config (`package.json` / `Cargo.toml` / `go.mod` / `pyproject.toml` / …)
-2. `task.list { status: "completed" }` → confirm ≥1 task delivered
-3. `change.list` → identify the active/blocked change, if any; filter linked
-   tasks locally by `change_id`
-4. Find test files (suffix `.test.*`, `.spec.*`, `test_*.py`, `*_test.go`)
+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.
 
-Block with instructive error if any precheck fails.
+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.
 
-### Step 1 — Anti-Pattern Detection
+## Report contract
 
-Detect fake / meaningless tests that waste CI time.
+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.
 
-| Pattern | Example | Severity |
-|---------|---------|----------|
-| Tautology | `assert True`, `expect(true).toBe(true)` | CRITICAL |
-| Empty test | function body is just `pass` / `{}` | CRITICAL |
-| Core-logic mock | `jest.mock()` on domain/service/state files | CRITICAL |
+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.
 
-Use Grep with language-appropriate regex; count matches per file.
+## Exit
 
-**Gate**: any CRITICAL match → fail.
-
-### Step 2 — Coverage Gap Analysis
-
-Find exported functions / classes with **zero** test references.
-
-1. Enumerate exports in `src/` (or language equivalent)
-2. For each symbol, grep test files for its name
-3. Bucket:
-   - HIGH: core business logic untested
-   - MEDIUM: utility untested
-   - LOW: config/constant untested
-
-**Output**: `.ultra/docs/test-coverage-gaps.md`
-**Gate**: any HIGH → fail.
-
-### Step 2.5 — Wiring Verification
-
-Detect orphan code — files that exist and pass tests but are not reachable.
-
-1. Enumerate exported symbols in source files
-2. For each export, grep **non-test** source for imports
-3. Report exports with 0 non-test imports as orphaned
-
-Also check boundary wiring:
-- Component → API (fetch/axios targets a real route)
-- API → DB (handler imports a real client)
-- Form → handler (onSubmit is not `() => {}`)
-- State → render (state appears in JSX/template)
-
-Stub detection (Level-2 substantive):
-- Functions returning empty `[]` / `{}` without real work
-- `console.log`-only bodies
-- Handlers calling only `e.preventDefault()`
-- Components returning only `<div>Placeholder</div>`
-
-**Output**: append to `test-coverage-gaps.md` under `## Wiring Gaps`.
-**Gate**: any HIGH orphan or stub → fail.
-
-### Step 3 — E2E Testing (conditional)
-
-**Trigger**: project has web UI or API endpoints.
-
-1. Start dev server (detect `scripts.dev` / `scripts.start`)
-2. Navigate key pages/endpoints
-3. Verify elements render; check console errors
-4. Exercise primary user flows
-
-**Method per runtime**:
-- Claude: `mcp__claude-in-chrome__*` or Playwright via Bash
-- Others: Playwright via `npx playwright` (CLI portable)
-
-**Gate**: critical pages fail / major errors → fail.
-
-### Step 4 — Performance (conditional, frontend only)
-
-Lighthouse on dev server. Core Web Vitals gates:
-- LCP < 2.5s
-- INP < 200ms
-- CLS < 0.1
-
-**Gate**: any metric above threshold → fail.
-
-### Step 5 — Security Audit
-
-Dependency vulnerability scan via project's native tool:
-- `npm audit --json` / `pnpm audit --json` / `yarn audit --json`
-- `cargo audit --json`
-- `pip-audit --format=json`
-- `govulncheck ./...`
-
-**Severity**:
-- Critical/High → fail
-- Medium → warn
-- Low → info
-
-### Step 6 — Auto-Fix Loop
-
-If any gate failed, loop (max 5 attempts):
-
-1. Read `blocking_issues`
-2. Fix what is fixable without user input:
-   - Coverage Gap → write missing tests
-   - Anti-Pattern → rewrite fake tests
-   - E2E error → fix the code
-   - Performance → code-level optimizations (lazy, splitting, memoization)
-3. External blockers (upstream CVE, breaking dep bump) → break, report, ask user
-4. If all gates pass → exit loop
-
-If max reached → surface remaining issues; `passed=false`.
-
-### Step 7 — Persist `.ultra/test-report.json`
-
-```jsonc
-{
-  "timestamp": "<ISO8601>",
-  "git_commit": "<HEAD>",
-  "change_id": "<active-change-id-or-null>",
-  "passed": true,
-  "run_count": 1,
-  "commands": [
-    { "command": "<exact command>", "exit_code": 0, "scope": "unit/integration/e2e/build" }
-  ],
-  "gates": {
-    "anti_pattern":  { "passed": true, "critical": 0, "warning": 1 },
-    "coverage_gaps": { "passed": true, "high": 0, "medium": 3, "low": 5 },
-    "wiring":        { "passed": true, "orphans": 0, "stubs": 0 },
-    "e2e":           { "passed": true, "skipped": false },
-    "performance":   { "passed": true, "lcp": 1.8, "inp": 150, "cls": 0.05 },
-    "security":      { "passed": true, "critical": 0, "high": 0, "medium": 2 }
-  },
-  "blocking_issues": []
-}
-```
-
-Rules:
-- File exists → increment `run_count`
-- `passed = true` iff all gates `.passed === true`
-- `blocking_issues` lists human-readable strings for any fail
-- `commands` records exact executable evidence; prose such as “tests look good”
-  is not convergence evidence
-- when a continuous change is active, `change_id` must match it; never reuse a
-  report from another change
-
-### Step 8 — Report
-
-Print a compact summary (emoji-free, ≤20 lines). Suggest `/ultra-deliver` only
-when `passed=true`.
-
-## Quality Gates — summary
-
-| Gate | Requirement |
-|------|-------------|
-| Anti-Pattern | 0 critical |
-| Coverage Gaps | 0 HIGH |
-| Wiring | 0 HIGH orphan, 0 HIGH stub |
-| E2E | all flows pass (if applicable) |
-| Performance | all Core Web Vitals (if frontend) |
-| Security | 0 critical/high |
-
-## MCP failure matrix
-
-| Purpose | MCP tool | CLI fallback |
-|---------|----------|--------------|
-| Confirm ≥1 completed task | `task.list { status: "completed" }` | none; fail closed |
-| Identify active change | `change.list` | none; omit only for initial baseline delivery |
-| Confirm risky auto-fix | none | current Host's native user-interaction surface |
-
-## What this skill DOES NOT do
-
-- Does NOT run unit tests (that is `/ultra-dev`)
-- Does NOT mutate state.db (auditing is read-only against state)
-- Does NOT release or tag (that is `/ultra-deliver`)
-
-## Integration
-
-| | |
-|---|---|
-| **Input** | Source + test files, state.db (read-only) |
-| **Output** | `.ultra/test-report.json` with exact commands/change id, `.ultra/docs/test-coverage-gaps.md` |
-| **Next** | `/ultra-deliver` (only when `passed=true`) |
+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,109 +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."
-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.