oh-my-codex 0.14.0 → 0.14.2

package/skills/code-review/SKILL.md

@@ -15,8 +15,6 @@ This skill activates when:
 - After implementing a major feature
 - User wants quality assessment
 
-## What It Does
-
 ## GPT-5.4 Guidance Alignment
 
 - Default to concise, evidence-dense progress and completion reporting unless the user or risk level requires more detail.
@@ -24,30 +22,49 @@ This skill activates when:
 - If correctness depends on additional inspection, retrieval, execution, or verification, keep using the relevant tools until the review is grounded.
 - Continue through clear, low-risk, reversible next steps automatically; ask only when the next step is materially branching, destructive, or preference-dependent.
 
-Delegates to the `code-reviewer` agent (THOROUGH tier) for deep analysis:
+Delegates to the `code-reviewer` and `architect` agents in parallel for a two-lane review:
 
 1. **Identify Changes**
    - Run `git diff` to find changed files
    - Determine scope of review (specific files or entire PR)
 
-2. **Review Categories**
+2. **Launch Parallel Review Lanes**
+   - **`code-reviewer` lane** - owns spec compliance, security, code quality, performance, and maintainability findings
+   - **`architect` lane** - owns the devil's-advocate / design-tradeoff perspective
+   - Both lanes run in parallel and produce distinct outputs before final synthesis
+
+3. **Review Categories**
    - **Security** - Hardcoded secrets, injection risks, XSS, CSRF
    - **Code Quality** - Function size, complexity, nesting depth
    - **Performance** - Algorithm efficiency, N+1 queries, caching
    - **Best Practices** - Naming, documentation, error handling
    - **Maintainability** - Duplication, coupling, testability
 
-3. **Severity Rating**
+4. **Severity Rating**
    - **CRITICAL** - Security vulnerability (must fix before merge)
    - **HIGH** - Bug or major code smell (should fix before merge)
    - **MEDIUM** - Minor issue (fix when possible)
    - **LOW** - Style/suggestion (consider fixing)
 
-4. **Specific Recommendations**
+5. **Architectural Status Contract**
+   - **CLEAR** - No unresolved architectural blocker was found
+   - **WATCH** - Non-blocking design/tradeoff concern that must appear in the final synthesis
+   - **BLOCK** - Unresolved design concern that prevents a merge-ready verdict
+
+6. **Specific Recommendations**
    - File:line locations for each issue
    - Concrete fix suggestions
    - Code examples where applicable
 
+7. **Final Synthesis**
+   - Combine the `code-reviewer` recommendation and the architect status into one final verdict
+   - Deterministic merge gating rules:
+     - If architect status is **BLOCK**, final recommendation is **REQUEST CHANGES**
+     - Else if `code-reviewer` recommendation is **REQUEST CHANGES**, final recommendation is **REQUEST CHANGES**
+     - Else if architect status is **WATCH**, final recommendation is **COMMENT**
+     - Else final recommendation follows the `code-reviewer` lane
+   - The final report must make architect blockers impossible to miss
+
 ## Agent Delegation
 
 ```
@@ -58,6 +75,8 @@ delegate(
 
 Review code changes for quality, security, and maintainability.
 
+This is the code/spec/security lane. Do not absorb architectural ownership.
+
 Scope: [git diff or specific files]
 
 Review Checklist:
@@ -74,6 +93,29 @@ Output: Code review report with:
 - Fix recommendations
 - Approval recommendation (APPROVE / REQUEST CHANGES / COMMENT)"
 )
+
+delegate(
+  role="architect",
+  tier="THOROUGH",
+  prompt="ARCHITECTURE / DEVIL'S-ADVOCATE REVIEW TASK
+
+Review the same code changes from the architecture/tradeoff perspective.
+
+Scope: [git diff or specific files]
+
+Focus:
+- System boundaries and interfaces
+- Hidden coupling or long-term maintainability risks
+- Tradeoff tension the main reviewer might miss
+- Strongest counterargument against approving as-is
+
+Output:
+- Architectural Status: CLEAR / WATCH / BLOCK
+- File:line evidence for each concern
+- Concrete tradeoff or design recommendation"
+)
+
+Run both lanes in parallel, then synthesize them with the deterministic rules above.
 ```
 
 ## External Model Consultation (Preferred)
@@ -112,45 +154,59 @@ CODE REVIEW REPORT
 ==================
 
 Files Reviewed: 8
-Total Issues: 15
+Total Issues: 12
+Architectural Status: WATCH
 
 CRITICAL (0)
 -----------
 (none)
 
-HIGH (3)
+HIGH (0)
 --------
+(none)
+
+MEDIUM (7)
+----------
 1. src/api/auth.ts:42
-   Issue: User input not sanitized before SQL query
-   Risk: SQL injection vulnerability
-   Fix: Use parameterized queries or ORM
+   Issue: Email normalization logic is duplicated instead of reusing the shared helper
+   Risk: Validation rules can drift between authentication paths
+   Fix: Route both paths through the shared normalization helper
 
 2. src/components/UserProfile.tsx:89
-   Issue: Password displayed in plain text in logs
-   Risk: Credential exposure
-   Fix: Remove password from log statements
+   Issue: Derived permissions are recalculated on every render
+   Risk: Avoidable work during profile refreshes
+   Fix: Memoize the derived permissions list or compute it upstream
 
 3. src/utils/validation.ts:15
-   Issue: Email regex allows invalid formats
-   Risk: Accepts malformed emails
-   Fix: Use proven email validation library
-
-MEDIUM (7)
-----------
-...
+   Issue: Form-layer and server-layer validation messages are defined separately
+   Risk: User-facing validation guidance can become inconsistent
+   Fix: Share one validation message helper across both call sites
 
 LOW (5)
 -------
 ...
 
-RECOMMENDATION: REQUEST CHANGES
+ARCHITECTURE WATCHLIST
+----------------------
+- src/review/orchestrator.ts:88
+  Concern: Review result synthesis relies on implicit ordering rather than an explicit blocker contract
+  Status: WATCH
+  Recommendation: Define deterministic merge gating before expanding reviewers
+
+SYNTHESIS
+---------
+- code-reviewer recommendation: COMMENT
+- architect status: WATCH
+- final recommendation: COMMENT
+
+RECOMMENDATION: COMMENT
 
-Critical security issues must be addressed before merge.
+Address any WATCH concerns before treating the change as merge-ready.
 ```
 
 ## Review Checklist
 
-The code-reviewer agent checks:
+The `code-reviewer` lane checks:
 
 ### Security
 - [ ] No hardcoded secrets (API keys, passwords, tokens)
@@ -180,11 +236,21 @@ The code-reviewer agent checks:
 - [ ] Tests for critical paths
 - [ ] No commented-out code
 
+## Architect Lane Checklist
+
+The `architect` lane checks:
+
+- [ ] Boundary or interface changes are explicit
+- [ ] New coupling/tradeoff risks are surfaced
+- [ ] Long-horizon maintainability concerns are evidence-backed
+- [ ] Architectural status is one of `CLEAR`, `WATCH`, or `BLOCK`
+- [ ] Any `BLOCK` concern cites the reason merge-ready status should be withheld
+
 ## Approval Criteria
 
-**APPROVE** - No CRITICAL or HIGH issues, minor improvements only
-**REQUEST CHANGES** - CRITICAL or HIGH issues present
-**COMMENT** - Only LOW/MEDIUM issues, no blocking concerns
+**APPROVE** - `code-reviewer` returns APPROVE and architect status is `CLEAR`
+**REQUEST CHANGES** - `code-reviewer` returns REQUEST CHANGES or architect status is `BLOCK`
+**COMMENT** - `code-reviewer` returns COMMENT with architect status `CLEAR`, architect status is `WATCH`, or only LOW/MEDIUM improvements remain
 
 
 ## Scenario Examples
@@ -207,7 +273,7 @@ Includes coordinated review execution across specialized agents.
 ```
 /ralph code-review then fix all issues
 ```
-Review code, get feedback, fix until approved.
+On the explicit Ralph path, review findings should flow into automatic fix follow-up without another permission prompt. Plain `code-review` itself remains read-only and does **not** promise auto-fix.
 
 **With Ultrawork:**
 ```

package/skills/deep-interview/SKILL.md

@@ -52,6 +52,7 @@ If no flag is provided, use **Standard**.
 - Reduce user effort: ask only the highest-leverage unresolved question, and never ask the user for codebase facts that can be discovered directly
 - For brownfield work, prefer evidence-backed confirmation questions such as "I found X in Y. Should this change follow that pattern?"
 - In Codex CLI, deep-interview uses `omx question` as the required OMX-owned structured questioning path for every interview round
+- If you launch `omx question` in a background terminal, immediately wait for that background terminal to finish and read its JSON answer before scoring ambiguity, asking another round, or handing off
 - If `omx question` is unavailable in the current runtime, treat that as a blocker/error for deep-interview rather than falling back to `request_user_input` or plain-text questioning
 - Re-score ambiguity after each answer and show progress transparently
 - Do not hand off to execution while ambiguity remains above threshold unless user explicitly opts to proceed with warning
@@ -154,6 +155,96 @@ Round {n} | Target: {weakest_dimension} | Ambiguity: {score}%
 {question}
 ```
 
+`omx question` payload guidance for interview rounds:
+- Use canonical `type` values instead of authoring raw `multi_select` flags by hand. `type: "single-answerable"` is the default for one-path decisions; `type: "multi-answerable"` is the canonical shape for bounded multi-select rounds. The runtime will keep `multi_select` aligned with `type`.
+- Use `single-answerable` when exactly one answer should drive the next branch, the options are mutually exclusive, or selecting more than one answer would blur the decision boundary. Typical cases: handoff lane selection, choosing the primary failure mode, or confirming which of several competing interpretations is correct.
+- Use `multi-answerable` when multiple options may all be true at once and you need to capture a bounded set of coexisting constraints, non-goals, risks, or acceptance checks in one round. Typical cases: selecting all out-of-scope items, all success metrics that must hold, or all deployment constraints that apply together.
+- If one selected option would immediately require a follow-up question to disambiguate the others, prefer a `single-answerable` round now and ask the follow-up next. Do not hide a branching interview tree inside one overloaded multi-select prompt.
+- Keep interview options bounded and concrete. If the valid answers are already known, set `allow_other: false`; only leave `allow_other: true` when the interview genuinely needs one user-supplied option that cannot be enumerated in advance.
+- Read answers structurally. For `single-answerable`, expect one decisive selection in `answer.value` plus `answer.selected_values`. For `multi-answerable`, treat `answer.selected_values` as the source of truth for all chosen constraints/non-goals and preserve the full set in the transcript/spec.
+
+Canonical bounded single-choice payload:
+
+```json
+{
+  "question": "Which execution lane should own this once the interview is complete?",
+  "type": "single-answerable",
+  "options": [
+    {
+      "label": "Plan first",
+      "value": "ralplan",
+      "description": "Need architecture and test-shape review before execution"
+    },
+    {
+      "label": "Execute directly",
+      "value": "autopilot",
+      "description": "Requirements are already explicit enough for planning plus execution"
+    },
+    {
+      "label": "Refine further",
+      "value": "refine",
+      "description": "Clarification is still needed before any handoff"
+    }
+  ],
+  "allow_other": false,
+  "other_label": "Other",
+  "source": "deep-interview"
+}
+```
+
+Canonical bounded multi-select payload:
+
+```json
+{
+  "question": "Which non-goals must stay out of scope for the first pass?",
+  "type": "multi-answerable",
+  "options": [
+    {
+      "label": "No UI redesign",
+      "value": "no-ui-redesign",
+      "description": "Keep layout and styling unchanged"
+    },
+    {
+      "label": "No new dependencies",
+      "value": "no-new-dependencies",
+      "description": "Work within the existing toolchain"
+    },
+    {
+      "label": "No API contract changes",
+      "value": "no-api-contract-changes",
+      "description": "Preserve external request and response shapes"
+    }
+  ],
+  "allow_other": false,
+  "other_label": "Other",
+  "source": "deep-interview"
+}
+```
+
+Canonical answer-shape reminders:
+
+```json
+{
+  "answer": {
+    "kind": "option",
+    "value": "ralplan",
+    "selected_labels": ["Plan first"],
+    "selected_values": ["ralplan"]
+  }
+}
+```
+
+```json
+{
+  "answer": {
+    "kind": "multi",
+    "value": ["no-new-dependencies", "no-api-contract-changes"],
+    "selected_labels": ["No new dependencies", "No API contract changes"],
+    "selected_values": ["no-new-dependencies", "no-api-contract-changes"]
+  }
+}
+```
+
 ### 2c) Score ambiguity
 Score each weighted dimension in `[0.0, 1.0]` with justification + gap.