ultra-builder-pro-cli 0.9.0 → 0.11.0

package/skills/cc-collab/SKILL.md

@@ -1,26 +1,23 @@
 ---
 name: cc-collab
-description: "Use Claude Code as an explicitly requested, read-only advisor for bounded architecture, diagnosis, or review questions. The current host remains primary and verifies all claims."
-argument-hint: "review|understand|opinion|compare|free [target]"
-user-invocable: true
+description: Ask Claude Code for an independent read-only analysis of a bounded architecture, diagnosis, or review question. Use only when the user explicitly requests Claude Code or CC collaboration and the current host remains primary.
 ---
 
-# Claude Code Collaboration
+# Consult Claude Code read-only
 
-Use Claude Code only when the user explicitly requests a Claude/CC perspective. The current host
-owns scope, evidence, decisions, edits, and final verification. Claude Code is an untrusted,
-read-only advisor.
+Treat Claude Code as an untrusted advisor. The current host owns scope, evidence,
+decisions, edits, and final verification.
 
 ## Preconditions
 
-1. Confirm `claude --version` and authentication.
-2. Bound the workspace, files or diff, question, and expected response shape.
-3. Write the primary host's independent analysis first when independence matters.
-4. Do not pass credentials, unrelated files, or an unbounded home directory.
+1. Confirm the `claude` CLI and authentication.
+2. Bound the workspace, files or diff, question, evidence standard, and response shape.
+3. Write the primary host's analysis first when independence matters.
+4. Exclude credentials, unrelated files, and unbounded home-directory access.
 
 ## Invocation
 
-Run Claude Code without mutation or session persistence:
+Run without mutation or session persistence:
 
 ```bash
 claude --safe-mode -p "<bounded prompt>" \
@@ -30,12 +27,13 @@ claude --safe-mode -p "<bounded prompt>" \
   --no-session-persistence
 ```
 
-Store large output under `.ultra/collab/<session-id>/claude-output.md`. A missing CLI, failed auth,
-timeout, or empty response degrades to host-only analysis; it never blocks the task.
+Store large output under `.ultra/collab/<session-id>/claude-output.md`. A missing CLI,
+failed authentication, timeout, or empty response degrades to host-only analysis and
+never blocks the underlying task.
 
 ## Synthesis
 
-- Verify consequential claims against the current checkout, runtime, tests, or primary docs.
-- Separate agreement, useful dissent, and unsupported assertions.
-- Explain scope or version mismatches before comparing conclusions.
-- Return one host-owned conclusion, not a transcript or a model vote.
+Verify consequential claims against the current checkout, runtime, tests, or primary
+documentation. Separate verified agreement, useful dissent, and unsupported claims.
+Explain scope or version differences and return one host-owned conclusion rather than
+a transcript or model vote.

package/skills/code-review-expert/SKILL.md

@@ -1,118 +1,43 @@
 ---
 name: code-review-expert
-description: "Structured code review checklists: SOLID, security, performance, boundary conditions, removal planning. Injected into code-reviewer agent."
-user-invocable: false
+description: Review a bounded diff for consequential correctness, security, integration, and maintainability defects with evidence and precise locations. Use only when assigned to an Ultra review worker or an explicitly requested read-only code review.
 ---
 
-# Code Review Expert Checklists
-
-Provides structured review workflow and reference checklists for the code-reviewer agent.
-
-## Severity Levels
-
-| Level | Name | Description | Action |
-|-------|------|-------------|--------|
-| **P0** | Critical | Security vulnerability, data loss risk, correctness bug | Must block merge |
-| **P1** | High | Logic error, significant SOLID violation, performance regression | Should fix before merge |
-| **P2** | Medium | Code smell, maintainability concern, minor SOLID violation | Fix in this PR or create follow-up |
-| **P3** | Low | Style, naming, minor suggestion | Optional improvement |
-
-## Review Workflow
-
-### Step 1: Preflight Context
-
-- Run `git status -sb`, `git diff --stat`, and `git diff` to scope changes
-- Use `git diff --cached` to include staged changes
-- If needed, use Grep to find related modules, usages, and contracts
-
-**Edge cases:**
-- **No changes**: Inform user, ask if they want to review staged changes or a specific commit range
-- **Large diff (>500 lines)**: Summarize by file first, then review in batches by module/feature area
-- **Mixed concerns**: Group findings by logical feature, not just file order
-
-### Step 2: SOLID + Architecture Smells
-
-Load `references/solid-checklist.md` for detailed prompts.
-
-Look for SRP/OCP/LSP/ISP/DIP violations and common code smells. When proposing refactor, explain *why* it improves cohesion/coupling. Non-trivial refactors get incremental plans, not large rewrites.
-
-### Step 3: Removal Candidates
-
-Load `references/removal-plan.md` for template.
-
-Identify unused, redundant, or feature-flagged-off code. Distinguish **safe delete now** vs **defer with plan**. Provide follow-up steps with concrete checkpoints.
-
-### Step 4: Security and Reliability
-
-Load `references/security-checklist.md` for coverage.
-
-Check injection, auth gaps, secrets, race conditions, crypto, supply chain. Call out both **exploitability** and **impact**.
-
-### Step 5: Code Quality
-
-Load `references/code-quality-checklist.md` for coverage.
-
-Check error handling, performance/caching, boundary conditions. Flag issues that may cause silent failures or production incidents.
-
-### Step 5.5: Integration & Connectivity
-
-Load `references/integration-checklist.md` for detailed prompts.
-
-Check entry point tracing, contract validation, vertical slice assessment, integration test coverage, and data flow continuity. Flag orphan code, missing contracts, and horizontal-only changes.
-
-### Step 6: Output Format
-
-```markdown
-## Code Review Summary
-
-**Files reviewed**: X files, Y lines changed
-**Overall assessment**: [APPROVE / REQUEST_CHANGES / COMMENT]
-
----
-
-## Findings
-
-### P0 - Critical
-(none or list)
-
-### P1 - High
-- **[file:line]** Brief title
-  - Description of issue
-  - Suggested fix
-
-### P2 - Medium
-...
-
-### P3 - Low
-...
-
----
-
-## Removal/Iteration Plan
-(if applicable)
-
-## Additional Suggestions
-(optional improvements, not blocking)
-```
-
-### Step 7: Next Steps Confirmation
-
-After presenting findings, ask how to proceed:
-
-1. **Fix all** - Implement all suggested fixes
-2. **Fix P0/P1 only** - Address critical and high priority issues
-3. **Fix specific items** - User specifies which issues to fix
-4. **No changes** - Review complete, no implementation needed
-
-**Important**: Do NOT implement any changes until user explicitly confirms.
-
-## Additional Resources
-
-### Reference Files
-
-For detailed patterns and checklists, consult:
-- **`references/solid-checklist.md`** - SOLID violation detection and refactor heuristics
-- **`references/security-checklist.md`** - Security, reliability, and race condition checks
-- **`references/code-quality-checklist.md`** - Error handling, performance, boundary conditions
-- **`references/removal-plan.md`** - Deletion candidates and iteration planning template
-- **`references/integration-checklist.md`** - Entry point tracing, contract validation, data flow continuity
+# Review a bounded code change
+
+Prioritize defects that can change behavior, safety, operability, or delivery. Do not
+fill the report with style preferences or generic best-practice commentary.
+
+## Workflow
+
+1. Establish the exact diff, stated intent, acceptance evidence, current checkout, and
+   relevant repository guidance. If the scope is empty or ambiguous, report that
+   boundary instead of reviewing unrelated history.
+2. Trace changed behavior from a live entry point through state and side effects to a
+   consumer. Read callers, contracts, tests, and error paths needed to prove or refute
+   a finding.
+3. Load focused references only when their scope is present:
+   - `security-rules` for trust or authorization boundaries;
+   - `integration-rules` for cross-component behavior;
+   - `references/correctness-reliability.md` for a concrete behavioral risk;
+   - `references/design-boundaries.md` for a concrete ownership or coupling problem;
+   - `references/removal-plan.md` for code proposed for deletion.
+4. For every candidate finding, state the violated contract, triggering condition,
+   user or system impact, and evidence in the current source. Discard speculative
+   concerns that lack a plausible execution path.
+5. Assign severity from impact and likelihood:
+   - P0: exploitable security issue, data loss, or deterministic critical failure;
+   - P1: material correctness, authorization, reliability, or delivery failure;
+   - P2: bounded maintainability or edge-case defect with concrete future cost;
+   - P3: optional improvement that does not block the accepted outcome.
+6. Deduplicate findings by root cause and order them by severity, path, and line.
+
+## Finding contract
+
+Each finding includes a concise title, severity, tight file and line range,
+trigger, impact, evidence, and smallest complete remediation. Do not request a broad
+rewrite when a local fix satisfies the contract.
+
+If no actionable defect is supported, say so and name the remaining verification or
+coverage gap. Review is read-only unless a separate implementation request explicitly
+authorizes changes.

package/skills/code-review-expert/references/correctness-reliability.md

@@ -0,0 +1,30 @@
+# Correctness and reliability evidence
+
+Read this reference only when the diff changes behavior, state transitions, resource
+use, concurrency, caching, parsing, or failure handling.
+
+## Establish the contract
+
+Identify the input domain, preconditions, observable result, authoritative state, and
+caller-visible failure behavior. Repository code, tests, schemas, runtime configuration,
+and accepted specifications outrank generic conventions.
+
+## Trace material risks
+
+Inspect only risks supported by the changed path:
+
+- boundary values, empty or optional inputs, numeric range, encoding, and ordering;
+- partial writes, lost updates, duplicate execution, retry, idempotency, and rollback;
+- stale caches, key scope, invalidation, and cross-user or cross-tenant isolation;
+- unbounded work, repeated I/O, resource lifetime, timeout, and cancellation;
+- swallowed failures, false success, ambiguous fallback, and missing recovery signals;
+- deployment-time compatibility between readers, writers, clients, and stored data.
+
+A surface pattern is not a finding. Confirm the triggering condition, follow it to an
+observable impact, and check whether a guard or recovery path exists elsewhere.
+
+## Report
+
+State the violated contract, trigger, impact, current source evidence, and smallest
+complete remediation. If scale or concurrency is required to trigger the issue, name
+the evidence-backed operating condition instead of inventing a multiplier.

package/skills/code-review-expert/references/design-boundaries.md

@@ -0,0 +1,26 @@
+# Design boundary evidence
+
+Read this reference only when the diff changes ownership, invariants, public contracts,
+module boundaries, or a recurring variation point.
+
+## Questions grounded in the live path
+
+- Which module owns the invariant and can callers bypass it?
+- Does one authoritative representation exist, or can state diverge across layers?
+- Is the dependency direction compatible with the repository's established boundary?
+- Does a public contract expose implementation details that block a required consumer?
+- Does the change duplicate a domain rule or scatter one accepted change across
+  unrelated owners?
+- Is an abstraction justified by current callers and variants, or only hypothetical
+  future work?
+- Can the behavior be tested and recovered at its public seam?
+
+File size, method length, inheritance, primitive values, data-only types, and branch
+counts are investigation signals. Report them only when they produce a concrete
+correctness, compatibility, testing, recovery, or maintenance cost in this change.
+
+## Remediation
+
+Prefer the smallest boundary correction that restores ownership and the accepted
+contract. Do not prescribe a design pattern, framework, or broad rewrite without
+showing why the existing repository structure cannot satisfy the requirement.

package/skills/code-review-expert/references/removal-plan.md

@@ -1,52 +1,24 @@
-# Removal and Iteration Plan Template
+# Removal evidence
 
-## Priority Levels
+Read this reference only when the proposed change deletes or retires code, a contract,
+configuration, data, or a dependency.
 
-- **P0**: Immediate removal needed (security risk, significant cost, blocking other work)
-- **P1**: Remove in current sprint
-- **P2**: Backlog / next iteration
+## Prove reachability and ownership
 
----
+Search static references, registrations, dynamic loading, reflection, generated code,
+configuration, feature flags, scripts, documentation, and external interfaces that may
+consume the item. Distinguish no evidence of use from evidence of no use.
 
-## Safe to Remove Now
+## Determine the safe action
 
-### Item: [Name/Description]
+Record:
 
-| Field | Details |
-|-------|---------|
-| **Location** | `path/to/file.ts:line` |
-| **Rationale** | Why this should be removed |
-| **Evidence** | Unused (no references), dead feature flag, deprecated API |
-| **Impact** | None / Low - no active consumers |
-| **Deletion steps** | 1. Remove code 2. Remove tests 3. Remove config |
-| **Verification** | Run tests, check no runtime errors, monitor logs |
+- exact item and owner;
+- current consumers and supporting evidence;
+- compatibility, data, deployment, and operator impact;
+- prerequisites for removal when a consumer or migration remains;
+- focused deletion steps, verification, monitoring, and rollback.
 
----
-
-## Defer Removal (Plan Required)
-
-### Item: [Name/Description]
-
-| Field | Details |
-|-------|---------|
-| **Location** | `path/to/file.ts:line` |
-| **Why defer** | Active consumers, needs migration, stakeholder sign-off |
-| **Preconditions** | Feature flag off for 2 weeks, telemetry shows 0 usage |
-| **Breaking changes** | List any API/contract changes |
-| **Migration plan** | Steps for consumers to migrate |
-| **Timeline** | Target date or sprint |
-| **Owner** | Person/team responsible |
-| **Validation** | Metrics to confirm safe removal (error rates, usage counts) |
-| **Rollback plan** | How to restore if issues found |
-
----
-
-## Checklist Before Removal
-
-- [ ] Searched codebase for all references (Grep)
-- [ ] Checked for dynamic/reflection-based usage
-- [ ] Verified no external consumers (APIs, SDKs, docs)
-- [ ] Feature flag telemetry reviewed (if applicable)
-- [ ] Tests updated/removed
-- [ ] Documentation updated
-- [ ] Team notified (if shared code)
+Do not assign urgency from age, naming, or deprecation text alone. Severity follows the
+cost of retaining an actual hazard or deleting a reachable contract. When evidence is
+incomplete, report the missing proof instead of declaring the item safe to remove.

package/skills/codex-collab/SKILL.md

@@ -1,52 +1,47 @@
 ---
 name: codex-collab
-description: Ask Codex CLI for an explicitly requested, read-only second opinion on a bounded review, diagnosis, architecture, or comparison question.
+description: Ask Codex CLI for an independent read-only analysis of a bounded architecture, diagnosis, or review question. Use only when the user explicitly requests Codex collaboration and the current host remains primary.
 ---
 
-# Codex Collaboration
+# Consult Codex read-only
 
-Claude Code remains primary and owns scope, evidence, edits, verification, and the final answer.
-Codex is an untrusted read-only advisor. Use this skill only when the user explicitly requests a
-Codex perspective; do not invoke it as a routine substitute for native review or subagents.
+Treat Codex as an untrusted advisor. The current host owns scope, evidence, edits,
+verification, and the final answer.
 
 ## Preconditions
 
-1. Confirm `codex --version` and authentication.
-2. Fix the workspace, files or diff range, question, evidence standard, and expected response shape.
+1. Confirm the `codex` CLI and authentication.
+2. Bound the workspace, files or diff, question, evidence standard, and response shape.
 3. Write the primary analysis first when independence matters.
-4. Never send secrets, unrelated files, or an unbounded home directory.
+4. Exclude secrets, unrelated files, and unbounded home-directory access.
 
-## Modes
+## Invocation
 
-- `review`: findings against an exact diff or file set.
-- `understand`: a bounded architecture or flow question.
-- `opinion`: one decision with named constraints and alternatives.
-- `compare`: independent answers to the same question.
-- `free`: another tightly scoped read-only prompt.
-
-## Safe invocation
-
-Create a session directory under `.ultra/collab/`, then run Codex without workspace-write or
-danger-full-access:
+Create a session directory under `.ultra/collab/`, then run in a read-only sandbox:
 
 ```bash
-SESSION_PATH=".ultra/collab/$(date +%Y%m%d-%H%M%S)-codex-<mode>"
+SESSION_PATH=".ultra/collab/$(date +%Y%m%d-%H%M%S)-codex"
 mkdir -p "${SESSION_PATH}"
 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"
 ```
 
-Do not enable write-capable automation or permission bypass. This skill has no dependency on
-another Codex plugin or slash command.
+Do not enable write-capable automation or permission bypass. The isolation flags keep
+the advisory run independent from the user's Codex runtime configuration and rules;
+the normal Codex authentication store remains available.
 
 ## Synthesis
 
-1. Read the output only after the process exits and the file is non-empty.
-2. Verify consequential claims against the current checkout, tests, runtime, or primary docs.
-3. Separate agreement, useful dissent, and unsupported assertions.
-4. Return one Claude Code-owned conclusion; do not paste an unreviewed advisor transcript.
+Read output only after the process exits and the file is non-empty. Verify
+consequential claims against the current checkout, runtime, tests, or primary
+documentation. Separate verified agreement, useful dissent, and unsupported claims,
+then return one host-owned conclusion.
 
-If Codex is missing, unauthenticated, times out, or returns empty output, report the degraded path
-and continue with primary evidence. Never block the user's task solely on advisor failure.
+If Codex is unavailable, unauthenticated, times out, or returns empty output, report
+the degraded path and continue with primary evidence.

package/skills/codex-collab/evals/evals.json

@@ -2,38 +2,33 @@
   "skill_name": "codex-collab",
   "evals": [
     {
-      "id": 1,
-      "prompt": "/codex-collab review",
-      "expected_output": "Claude delegates to /codex:review (official plugin), then adds its own perspective and presents a dual-AI synthesis report",
+      "id": "explicit-review",
+      "prompt": "Ask Codex for an independent read-only review of the current diff, then verify its findings yourself.",
+      "should_trigger": true,
       "assertions": [
-        "Delegates to /codex:review instead of invoking codex CLI directly",
-        "Does NOT run 'codex review --uncommitted' directly",
-        "After receiving Codex output, Claude adds its own review perspective",
-        "Presents a synthesis with Consensus and Divergent Views sections"
+        "Bounds the repository and exact diff before launch",
+        "Runs codex exec with a read-only sandbox and file output",
+        "Treats Codex output as untrusted advisory evidence",
+        "Returns one primary-host conclusion after source verification"
       ]
     },
     {
-      "id": 2,
-      "prompt": "/codex-collab opinion 'Should we use a monorepo or polyrepo?'",
-      "expected_output": "Claude sends the question to Codex via exec mode with sandbox, reads output, and presents both opinions",
+      "id": "explicit-decision",
+      "prompt": "Have Codex independently assess whether this service should stay in the monorepo. Do not tell it our current preference.",
+      "should_trigger": true,
       "assertions": [
-        "Uses 'codex exec' (not codex review) for opinion mode",
-        "Uses --sandbox read-only for analysis-only task",
-        "Uses -o (--output-last-message) to capture clean output",
-        "Does NOT reveal Claude's position in the prompt",
-        "Creates session directory under .ultra/collab/",
-        "Presents both opinions with trade-off analysis"
+        "Writes the primary analysis first when independence matters",
+        "Does not prime Codex with the primary conclusion",
+        "Explains evidence or assumption differences before synthesis"
       ]
     },
     {
-      "id": 3,
-      "prompt": "/codex-collab review --base main with a focus on security",
-      "expected_output": "Claude delegates to /codex:adversarial-review for security-focused review, then synthesizes",
+      "id": "ordinary-review-negative",
+      "prompt": "Review the current diff for correctness and security issues.",
+      "should_trigger": false,
       "assertions": [
-        "Delegates to /codex:review or /codex:adversarial-review (official plugin)",
-        "Does NOT invoke codex CLI directly for review tasks",
-        "After receiving output, presents dual-AI synthesis",
-        "Reads output with Read tool, not Bash stdout"
+        "Uses the host's ordinary review workflow",
+        "Does not launch Codex without an explicit user request"
       ]
     }
   ]

package/skills/integration-rules/SKILL.md

@@ -1,71 +1,32 @@
 ---
 name: integration-rules
-description: Ultra Builder Pro system integration rules
-user-invocable: false
+description: Verify that changed components are reachable, contract-compatible, and tested across the boundaries required by the accepted behavior. Use only when an assigned review or implementation slice crosses modules, services, persistence, protocols, or UI seams.
 ---
 
-# Integration Rules
-
-These rules are mandatory for all code review and development work involving multi-component systems.
-
-## Vertical Slice Principle
-
-Every task MUST deliver a thin, working end-to-end path:
-
-| Good (Vertical Slice) | Bad (Horizontal Layer) |
-|------------------------|------------------------|
-| "User can send message" (UI + API + LLM + response display) | "Create all database tables" |
-| "Display product list" (API call + domain filter + UI render) | "Build all API endpoints" |
-| "Process payment" (UI form + gateway + order update) | "Create all UI components" |
-
-## Walking Skeleton
-
-The FIRST deliverable of any multi-component feature must be a walking skeleton:
-- One request flows through ALL layers
-- Returns real data (not hardcoded/mocked)
-- Proves the architecture connects end-to-end
-- Does NOT need to be feature-complete — just connected
-
-## Contract-First Development
-
-When two components will communicate:
-
-| Step | Action | Artifact |
-|------|--------|----------|
-| 1 | Define interface before implementation | TypeScript interface, OpenAPI schema, or protobuf |
-| 2 | Both sides code against the contract | Import shared types or generated clients |
-| 3 | Contract test validates both sides | Test that producer output matches consumer expectation |
-
-## Integration Test Requirements
-
-| Boundary | Required Test |
-|----------|---------------|
-| HTTP API endpoint | Request with real HTTP client, validate response shape + status |
-| Database operation | Testcontainers with real queries, validate data persisted |
-| Message queue | Real producer + consumer, validate message delivered |
-| External service | Test Double with `// Test Double rationale:` (only exception) |
-| In-process module boundary | Real function call, validate input/output contract |
-
-## Orphan Detection
-
-Code without a live entry point is dead-on-arrival.
-
-**Valid entry points** (at least one required per new module):
-- HTTP/WebSocket handler
-- CLI command handler
-- Event/message listener
-- Scheduled job/cron handler
-- Exported function called by a module that has an entry point
-
-**Detection**: Trace from new code upward — if no path reaches an entry point, the code is an orphan.
-
-## Detection Checklist
-
-When reviewing code, flag:
-1. New module/service without any caller (orphan code)
-2. Task structured as horizontal layer instead of vertical slice
-3. Two components communicating without shared interface/contract
-4. New boundary crossing without integration test
-5. Use case with DB/API dependency but only unit tests
-6. Component "works in isolation" but not wired to any entry point
-7. Interface defined but no contract test validating compatibility
+# Verify integration and reachability
+
+Prove that new behavior is connected to a real consumer and that data and failures
+cross each boundary according to one contract.
+
+## Procedure
+
+1. Start at the declared public seam or entry point and trace the changed path through
+   domain behavior, state, side effects, and the final consumer.
+2. At each boundary, identify the producer, consumer, data shape, ownership, error
+   semantics, compatibility expectation, and recovery behavior.
+3. Confirm both sides use the same contract or a deliberate adapter. Inspect runtime
+   configuration and registration, not only exported types.
+4. Verify the implementation is reachable in the production path. A module, handler,
+   schema, or component with no caller or registration is incomplete.
+5. Check that tests cross the boundary whose semantics matter and would fail on a
+   producer-consumer mismatch.
+6. For a larger feature, confirm an executable vertical slice exists before broad
+   expansion. The slice may be narrow, but it must use real wiring and observable data.
+7. Inspect partial failure, retry, idempotency, ordering, rollback, and observability
+   when the boundary can leave inconsistent state.
+
+## Finding contract
+
+Report the broken path, mismatched contract, missing consumer, or unverified failure
+mode with exact source evidence and observable impact. Do not flag a horizontal task
+solely by its name when another completed slice already proves the integration.