oh-my-codex 0.14.4 → 0.15.1

package/plugins/oh-my-codex/skills/analyze/SKILL.md

@@ -0,0 +1,148 @@
+---
+name: analyze
+description: "Run read-only deep repository analysis and return a ranked synthesis with explicit confidence, concrete file references, and clear evidence-vs-inference boundaries. Use when a user says 'analyze', 'investigate', 'why does', 'what's causing', or needs grounded cross-file explanation before any changes are proposed."
+---
+
+# Analyze — Read-Only Deep Analysis
+
+Use this skill to answer the user’s question through **read-only repository analysis**. The goal is to explain what the codebase most likely says about the question, not to drift into implementation, debugging theater, or generic fix planning.
+
+## Use `$analyze` when
+
+- the user wants a grounded explanation, not code changes
+- the answer requires reading multiple files or tracing behavior across boundaries
+- there are several plausible explanations and they need to be ranked
+- confidence should reflect the strength of the available evidence
+- the user wants to understand architecture, behavior, causality, impact, or tradeoffs before changing anything
+
+Examples:
+- why a workflow behaves a certain way
+- how a feature is wired across modules
+- what likely explains a failure, regression, or mismatch
+- what would be impacted by changing a dependency or contract
+- which interpretation of the current codebase is best supported
+
+## Do not use `$analyze` when
+
+- the user explicitly wants code edits, a fix, or execution — use the appropriate implementation lane instead
+- the user wants a new product plan or acceptance criteria — use `$plan` / `$ralplan`
+- the request is a simple one-file fact lookup — read the file and answer directly
+- the request is purely about running the OMX tmux team runtime — use `$team` only when OMX runtime is active
+
+## Non-negotiable contract
+
+Analyze is **read-only by contract**.
+
+- Do not edit files.
+- Do not turn the answer into an implementation plan.
+- Do not recommend fixes as the primary output.
+- Do not silently switch into execution work.
+- Do not overclaim certainty.
+- Do not invent facts that are not supported by repository evidence.
+- Do not use judgmental, normative, or speculative language that outruns the evidence.
+
+If a next step is helpful, keep it to a **discriminating read-only probe** that would reduce uncertainty.
+
+## Question-aligned synthesis
+
+Answer the user’s actual question first.
+
+- Start from the asked question, not a generic debugger template.
+- Keep the synthesis scoped to what the user needs to know.
+- Scale the depth to the request: for simple or obvious questions, reduce swarm intensity and answer directly after enough reading.
+- For broader questions, expand the search surface but keep the final answer tightly synthesized.
+
+## Evidence rules
+
+Maintain an explicit **evidence-vs-inference distinction**. Every material claim must be labeled as one of:
+
+1. **Evidence** — directly supported by concrete repository artifacts
+2. **Inference** — a reasoned conclusion drawn from evidence
+3. **Unknown** — a question the current repository evidence does not resolve
+
+Never present an inference as if it were direct evidence.
+Never present a guess as if it were an inference.
+Call out uncertainty explicitly when the codebase does not settle the question.
+
+### Acceptable evidence
+
+Prefer stronger evidence over weaker evidence:
+
+1. direct code paths, contracts, tests, generated artifacts, configs, or docs with concrete file references
+2. multiple independent files pointing to the same conclusion
+3. localized behavioral inference from well-supported code structure
+4. weaker contextual clues that remain explicitly marked as tentative
+
+Unsupported speculation is not evidence.
+
+## Parallel exploration policy
+
+Parallel exploration is allowed when it improves quality, but it must stay runtime-safe.
+
+- Default to direct read-only analysis when the answer is simple.
+- When parallelism helps, prefer **native subagents by default** or equivalent in-session parallel exploration when available.
+- Keep parallel lanes bounded: each lane should answer a concrete sub-question or inspect a specific subsystem.
+- Use **`$team` only when OMX runtime is active** and durable tmux-based coordination is actually needed.
+- Do not imply that `$team` is available in plain Codex/App sessions.
+
+A good default split for complex analysis is:
+- one lane for primary code path / contracts
+- one lane for config / orchestration / generated surfaces
+- one lane for tests / docs / secondary corroboration
+
+## Execution policy
+
+- Default to concise, evidence-dense progress and completion reporting unless the user or risk level requires more detail.
+- Treat newer user task updates as local overrides for the active workflow branch while preserving earlier non-conflicting constraints.
+- If the user says `continue`, keep working from the current analysis state instead of restarting discovery.
+
+## Working method
+
+1. Restate the question in one sentence.
+2. Identify the smallest set of files most likely to answer it.
+3. Read for direct evidence first.
+4. If needed, open bounded parallel exploration lanes.
+5. Compare competing explanations.
+6. Rank the explanations by support.
+7. Return a synthesis that clearly separates evidence from inference.
+
+## Output contract
+
+Structure the answer so the user can see what is known, what is inferred, and how confident the synthesis is.
+
+### Question
+[Restate the user’s question briefly]
+
+### Ranked synthesis
+| Rank | Explanation | Confidence | Basis |
+|------|-------------|------------|-------|
+| 1 | ... | High / Medium / Low | strongest supporting evidence |
+| 2 | ... | High / Medium / Low | why it trails |
+| 3 | ... | High / Medium / Low | why it remains possible |
+
+### Evidence
+- `path/to/file:line-line` — what this artifact directly shows
+- `path/to/file:line-line` — corroborating evidence
+
+### Inference
+- What the evidence most strongly implies
+- Why weaker alternatives were down-ranked
+
+### Unknowns / limits
+- What the repository evidence does not establish
+- What would need to be checked next to reduce uncertainty
+
+## Quality bar
+
+A good analyze response is:
+- read-only and question-aligned
+- ranked rather than flat
+- explicit about confidence
+- concrete about file references
+- careful about evidence vs inference
+- free of unsupported speculation
+- free of normative drift or judgmental filler
+- explicit about the evidence-vs-inference distinction
+- concise for simple cases, broader only when the question truly needs it
+
+Task: {{ARGUMENTS}}

package/plugins/oh-my-codex/skills/ask-claude/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: ask-claude
+description: Ask Claude via local CLI and capture a reusable artifact
+---
+
+# Ask Claude (Local CLI)
+
+Use the locally installed Claude CLI as a direct external advisor for focused questions, reviews, or second opinions.
+
+## Usage
+
+```bash
+/ask-claude <question or task>
+```
+
+## Routing
+
+### Preferred: Local CLI execution
+Run Claude through the canonical OMX CLI command path (no MCP routing):
+
+```bash
+omx ask claude "{{ARGUMENTS}}"
+```
+
+Exact non-interactive Claude CLI command from `claude --help`:
+
+```bash
+claude -p "{{ARGUMENTS}}"
+# equivalent: claude --print "{{ARGUMENTS}}"
+```
+
+If needed, adapt to the user's installed Claude CLI variant while keeping local execution as the default path.
+
+Legacy compatibility entrypoints (`./scripts/ask-claude.sh`, `npm run ask:claude -- ...`) are transitional wrappers.
+
+### Missing binary behavior
+If `claude` is not found, do **not** switch to MCP.
+Instead:
+1. Explain that local Claude CLI is required for this skill.
+2. Ask the user to install/configure Claude CLI.
+3. Provide a quick verification command:
+
+```bash
+claude --version
+```
+
+## Artifact requirement
+After local execution, save a markdown artifact to:
+
+```text
+.omx/artifacts/claude-<slug>-<timestamp>.md
+```
+
+Minimum artifact sections:
+1. Original user task
+2. Final prompt sent to Claude CLI
+3. Claude output (raw)
+4. Concise summary
+5. Action items / next steps
+
+Task: {{ARGUMENTS}}

package/plugins/oh-my-codex/skills/ask-gemini/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: ask-gemini
+description: Ask Gemini via local CLI and capture a reusable artifact
+---
+
+# Ask Gemini (Local CLI)
+
+Use the locally installed Gemini CLI as a direct external advisor for brainstorming, design feedback, and second opinions.
+
+## Usage
+
+```bash
+/ask-gemini <question or task>
+```
+
+## Routing
+
+### Preferred: Local CLI execution
+Run Gemini through the canonical OMX CLI command path (no MCP routing):
+
+```bash
+omx ask gemini "{{ARGUMENTS}}"
+```
+
+Exact non-interactive Gemini CLI command from `gemini --help`:
+
+```bash
+gemini -p "{{ARGUMENTS}}"
+# equivalent: gemini --prompt "{{ARGUMENTS}}"
+```
+
+If needed, adapt to the user's installed Gemini CLI variant while keeping local execution as the default path.
+
+Legacy compatibility entrypoints (`./scripts/ask-gemini.sh`, `npm run ask:gemini -- ...`) are transitional wrappers.
+
+### Missing binary behavior
+If `gemini` is not found, do **not** switch to MCP.
+Instead:
+1. Explain that local Gemini CLI is required for this skill.
+2. Ask the user to install/configure Gemini CLI.
+3. Provide a quick verification command:
+
+```bash
+gemini --version
+```
+
+## Artifact requirement
+After local execution, save a markdown artifact to:
+
+```text
+.omx/artifacts/gemini-<slug>-<timestamp>.md
+```
+
+Minimum artifact sections:
+1. Original user task
+2. Final prompt sent to Gemini CLI
+3. Gemini output (raw)
+4. Concise summary
+5. Action items / next steps
+
+Task: {{ARGUMENTS}}

package/plugins/oh-my-codex/skills/autopilot/SKILL.md

@@ -0,0 +1,231 @@
+---
+name: autopilot
+description: Full autonomous execution from idea to working code
+---
+
+<Purpose>
+Autopilot takes a brief product idea and autonomously handles the full lifecycle: requirements analysis, technical design, planning, parallel implementation, QA cycling, and multi-perspective validation. It produces working, verified code from a 2-3 line description.
+</Purpose>
+
+<Use_When>
+- User wants end-to-end autonomous execution from an idea to working code
+- User says "autopilot", "auto pilot", "autonomous", "build me", "create me", "make me", "full auto", "handle it all", or "I want a/an..."
+- Task requires multiple phases: planning, coding, testing, and validation
+- User wants hands-off execution and is willing to let the system run to completion
+</Use_When>
+
+<Do_Not_Use_When>
+- User wants to explore options or brainstorm -- use `plan` skill instead
+- User says "just explain", "draft only", or "what would you suggest" -- respond conversationally
+- User wants a single focused code change -- use `ralph` or delegate to an executor agent
+- User wants to review or critique an existing plan -- use `plan --review`
+- Task is a quick fix or small bug -- use direct executor delegation
+</Do_Not_Use_When>
+
+<Why_This_Exists>
+Most non-trivial software tasks require coordinated phases: understanding requirements, designing a solution, implementing in parallel, testing, and validating quality. Autopilot orchestrates all of these phases automatically so the user can describe what they want and receive working code without managing each step.
+</Why_This_Exists>
+
+<Execution_Policy>
+- Each phase must complete before the next begins
+- Parallel execution is used within phases where possible (Phase 2 and Phase 4)
+- QA cycles repeat up to 5 times; if the same error persists 3 times, stop and report the fundamental issue
+- Validation requires approval from all reviewers; rejected items get fixed and re-validated
+- Cancel with `/cancel` at any time; progress is preserved for resume
+- If a deep-interview spec exists, use it as high-clarity phase input instead of re-expanding from scratch
+- If input is too vague for reliable expansion, offer/trigger `$deep-interview` first
+- Do not enter expansion/planning/execution-heavy phases until pre-context grounding exists; if fast execution is forced, proceed only with explicit risk notes
+- Apply the shared workflow guidance pattern: concise, evidence-dense progress and completion reporting, local overrides for the active workflow branch, persistent inspection/verification while the workflow depends on it, and automatic continuation for safe reversible steps. Ask only for material, destructive, or preference-dependent branches.
+</Execution_Policy>
+
+<Steps>
+0. **Pre-context Intake (required before Phase 0 starts)**:
+   - Derive a task slug from the request.
+   - Load the latest relevant snapshot from `.omx/context/{slug}-*.md` when available.
+   - If no snapshot exists, create `.omx/context/{slug}-{timestamp}.md` (UTC `YYYYMMDDTHHMMSSZ`) with:
+     - Task statement
+     - Desired outcome
+     - Known facts/evidence
+     - Constraints
+     - Unknowns/open questions
+     - Likely codebase touchpoints
+   - If ambiguity remains high, run `explore` first for brownfield facts, then run `$deep-interview --quick <task>` before proceeding.
+   - Carry the snapshot path into autopilot artifacts/state so all phases share grounded context.
+
+1. **Phase 0 - Expansion**: Turn the user's idea into a detailed spec
+   - If `.omx/specs/deep-interview-*.md` exists for this task: reuse it and skip redundant expansion work
+   - If prompt is highly vague: route to `$deep-interview` for Socratic ambiguity-gated clarification
+   - Analyst (THOROUGH tier): Extract requirements
+   - Architect (THOROUGH tier): Create technical specification
+   - Output: `.omx/plans/autopilot-spec.md`
+
+2. **Phase 1 - Planning**: Create an implementation plan from the spec
+   - Architect (THOROUGH tier): Create plan (direct mode, no interview)
+   - Critic (THOROUGH tier): Validate plan
+   - Output: `.omx/plans/autopilot-impl.md`
+
+3. **Phase 2 - Execution**: Implement the plan using Ralph + Ultrawork
+   - LOW-tier executor/search roles: Simple tasks
+   - STANDARD-tier executor roles: Standard tasks
+   - THOROUGH-tier executor/architect roles: Complex tasks
+   - Run independent tasks in parallel
+
+4. **Phase 3 - QA**: Cycle until all tests pass (UltraQA mode)
+   - Build, lint, test, fix failures
+   - Repeat up to 5 cycles
+   - Stop early if the same error repeats 3 times (indicates a fundamental issue)
+
+5. **Phase 4 - Validation**: Multi-perspective review in parallel
+   - Architect: Functional completeness
+   - Security-reviewer: Vulnerability check
+   - Code-reviewer: Quality review
+   - All must approve; fix and re-validate on rejection
+
+6. **Phase 5 - Cleanup**: Clear all mode state via OMX MCP tools on successful completion
+   - `state_clear({mode: "autopilot"})`
+   - `state_clear({mode: "ralph"})`
+   - `state_clear({mode: "ultrawork"})`
+   - `state_clear({mode: "ultraqa"})`
+   - Or run `/cancel` for clean exit
+</Steps>
+
+<Tool_Usage>
+- Before first MCP tool use, call `ToolSearch("mcp")` to discover deferred MCP tools
+- Use `ask_codex` with `agent_role: "architect"` for Phase 4 architecture validation
+- Use `ask_codex` with `agent_role: "security-reviewer"` for Phase 4 security review
+- Use `ask_codex` with `agent_role: "code-reviewer"` for Phase 4 quality review
+- Agents form their own analysis first, then consult Codex for cross-validation
+- If ToolSearch finds no MCP tools or Codex is unavailable, proceed without it -- never block on external tools
+</Tool_Usage>
+
+## State Management
+
+Use `omx_state` MCP tools for autopilot lifecycle state.
+
+- **On start**:
+  `state_write({mode: "autopilot", active: true, current_phase: "expansion", started_at: "<now>", state: {context_snapshot_path: "<snapshot-path>"}})`
+- **On phase transitions**:
+  `state_write({mode: "autopilot", current_phase: "planning"})`
+  `state_write({mode: "autopilot", current_phase: "execution"})`
+  `state_write({mode: "autopilot", current_phase: "qa"})`
+  `state_write({mode: "autopilot", current_phase: "validation"})`
+- **On completion**:
+  `state_write({mode: "autopilot", active: false, current_phase: "complete", completed_at: "<now>"})`
+- **On cancellation/cleanup**:
+  run `$cancel` (which should call `state_clear(mode="autopilot")`)
+
+
+## Scenario Examples
+
+**Good:** The user says `continue` after the workflow already has a clear next step. Continue the current branch of work instead of restarting or re-asking the same question.
+
+**Good:** The user changes only the output shape or downstream delivery step (for example `make a PR`). Preserve earlier non-conflicting workflow constraints and apply the update locally.
+
+**Bad:** The user says `continue`, and the workflow restarts discovery or stops before the missing verification/evidence is gathered.
+
+<Examples>
+<Good>
+User: "autopilot A REST API for a bookstore inventory with CRUD operations using TypeScript"
+Why good: Specific domain (bookstore), clear features (CRUD), technology constraint (TypeScript). Autopilot has enough context to expand into a full spec.
+</Good>
+
+<Good>
+User: "build me a CLI tool that tracks daily habits with streak counting"
+Why good: Clear product concept with a specific feature. The "build me" trigger activates autopilot.
+</Good>
+
+<Bad>
+User: "fix the bug in the login page"
+Why bad: This is a single focused fix, not a multi-phase project. Use direct executor delegation or ralph instead.
+</Bad>
+
+<Bad>
+User: "what are some good approaches for adding caching?"
+Why bad: This is an exploration/brainstorming request. Respond conversationally or use the plan skill.
+</Bad>
+</Examples>
+
+<Escalation_And_Stop_Conditions>
+- Stop and report when the same QA error persists across 3 cycles (fundamental issue requiring human input)
+- Stop and report when validation keeps failing after 3 re-validation rounds
+- Stop when the user says "stop", "cancel", or "abort"
+- If requirements were too vague and expansion produces an unclear spec, pause and redirect to `$deep-interview` before proceeding
+</Escalation_And_Stop_Conditions>
+
+<Final_Checklist>
+- [ ] All 5 phases completed (Expansion, Planning, Execution, QA, Validation)
+- [ ] All validators approved in Phase 4
+- [ ] Tests pass (verified with fresh test run output)
+- [ ] Build succeeds (verified with fresh build output)
+- [ ] State files cleaned up
+- [ ] User informed of completion with summary of what was built
+</Final_Checklist>
+
+<Advanced>
+## Configuration
+
+Optional settings in `~/.codex/config.toml`:
+
+```toml
+[omx.autopilot]
+maxIterations = 10
+maxQaCycles = 5
+maxValidationRounds = 3
+pauseAfterExpansion = false
+pauseAfterPlanning = false
+skipQa = false
+skipValidation = false
+```
+
+## Resume
+
+If autopilot was cancelled or failed, run `/autopilot` again to resume from where it stopped.
+
+## Recommended Clarity Pipeline
+
+For ambiguous requests, prefer:
+
+```
+deep-interview -> ralplan -> autopilot
+```
+
+- `deep-interview`: ambiguity-gated Socratic requirements
+- `ralplan`: consensus planning (planner/architect/critic)
+- `autopilot`: execution + QA + validation
+
+## Best Practices for Input
+
+1. Be specific about the domain -- "bookstore" not "store"
+2. Mention key features -- "with CRUD", "with authentication"
+3. Specify constraints -- "using TypeScript", "with PostgreSQL"
+4. Let it run -- avoid interrupting unless truly needed
+
+## Pipeline Orchestrator (v0.8+)
+
+Autopilot can be driven by the configurable pipeline orchestrator (`src/pipeline/`), which
+sequences stages through a uniform `PipelineStage` interface:
+
+```
+RALPLAN (consensus planning) -> team-exec (Codex CLI workers) -> ralph-verify (architect verification)
+```
+
+Pipeline configuration options:
+
+```toml
+[omx.autopilot.pipeline]
+maxRalphIterations = 10    # Ralph verification iteration ceiling
+workerCount = 2            # Number of Codex CLI team workers
+agentType = "executor"     # Agent type for team workers
+```
+
+The pipeline persists state via `pipeline-state.json` and supports resume from the last
+incomplete stage. See `src/pipeline/orchestrator.ts` for the full API.
+
+## Troubleshooting
+
+**Stuck in a phase?** Check TODO list for blocked tasks, run `state_read({mode: "autopilot"})`, or cancel and resume.
+
+**QA cycles exhausted?** The same error 3 times indicates a fundamental issue. Review the error pattern; manual intervention may be needed.
+
+**Validation keeps failing?** Review the specific issues. Requirements may have been too vague -- cancel and provide more detail.
+</Advanced>

package/plugins/oh-my-codex/skills/autoresearch/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: autoresearch
+description: Stateful validator-gated research loop with native-hook persistence
+---
+
+# Autoresearch
+
+Autoresearch is the skill-first replacement for the deprecated `omx autoresearch` command.
+It keeps the useful measured-research loop, but it now runs as a native-hook stateful workflow instead of a direct CLI or tmux launch surface.
+
+## Use when
+- You want a Ralph-ish persistent research loop
+- The task should keep nudging until explicit validation evidence exists
+- You want init-time choice between script validation and prompt+architect validation
+
+## Do not use when
+- You want the old `omx autoresearch` command surface (hard-deprecated)
+- You want detached tmux or split-pane launch parity
+- You have not decided the validation regime yet
+
+## Core contract
+1. **Init chooses validation mode.** Pick exactly one:
+   - `mission-validator-script`
+   - `prompt-architect-artifact`
+2. **Persist mode state** in `.omx/state/.../autoresearch-state.json` including:
+   - `validation_mode`
+   - `completion_artifact_path`
+   - `mission_validator_command` **or** `validator_prompt`
+   - optional `output_artifact_path`
+3. **Completion is artifact-gated.** The loop does not stop because the model says “done”, because a stop hook fired once, or because several turns were no-ops.
+4. **Direct CLI launch is gone.** Use `$deep-interview --autoresearch` for intake and `$autoresearch` for execution.
+
+## Completion artifact contract
+
+### `mission-validator-script`
+The completion artifact must exist and record a passing validator result, for example:
+
+```json
+{
+  "status": "passed",
+  "passed": true,
+  "summary": "metric improved beyond baseline"
+}
+```
+
+### `prompt-architect-artifact`
+The completion artifact must include both an architect approval verdict and an output artifact path, for example:
+
+```json
+{
+  "validator_prompt": "Review the research output against the mission.",
+  "architect_review": { "verdict": "approved" },
+  "output_artifact_path": ".omx/specs/autoresearch-demo/report.md"
+}
+```
+
+## Recommended flow
+1. Run `$deep-interview --autoresearch` to clarify mission + evaluator.
+2. Materialize `.omx/specs/autoresearch-{slug}/mission.md`, `sandbox.md`, and `result.json`.
+3. Start `$autoresearch` with the chosen validation mode stored in mode state.
+4. Let stop-hook / auto-nudge continue until the completion artifact satisfies the chosen validation mode.
+5. Finish only after the validator artifact is complete.
+
+## Migration note
+- `omx autoresearch` is hard-deprecated.
+- No direct CLI launch.
+- No tmux split-pane launch.
+- No noop-count completion gate.