oh-my-codex 0.15.2 → 0.16.0

package/skills/ralph/SKILL.md

@@ -36,6 +36,7 @@ Complex tasks often fail silently: partial implementations get declared "done",
 - Read `docs/shared/agent-tiers.md` before first delegation to select correct agent tiers
 - Deliver the full implementation: no scope reduction, no partial completion, no deleting tests to make them pass
 - Apply the shared workflow guidance pattern: outcome-first framing, concise visible updates for multi-step execution, local overrides for the active workflow branch, validation proportional to risk, explicit stop rules, and automatic continuation for safe reversible steps. Ask only for material, destructive, credentialed, external-production, or preference-dependent branches.
+- Integrate with Codex goal mode when goal tools are available: inspect the active thread goal with `get_goal`, preserve it as the top-level stop condition, and only call `update_goal({status: "complete"})` after a Ralph completion audit proves the objective is actually achieved.
 </Execution_Policy>
 
 <Steps>
@@ -60,12 +61,13 @@ Complex tasks often fail silently: partial implementations get declared "done",
    - When Ralph is entered as a ralplan follow-up, start from the approved **available-agent-types roster** and make the delegation plan explicit: implementation lane, evidence/regression lane, and final sign-off lane using only known agent types
 4. **Run long operations in background**: Builds, installs, test suites use `run_in_background: true`
 5. **Visual task gate (when screenshot/reference images are present)**:
-   - Run `$visual-verdict` **before every next edit**.
+   - Run the Visual Ralph verdict step **before every next edit**.
    - Require structured JSON output: `score`, `verdict`, `category_match`, `differences[]`, `suggestions[]`, `reasoning`.
    - Persist verdict to `.omx/state/{scope}/ralph-progress.json` including numeric + qualitative feedback.
    - Default pass threshold: `score >= 90`.
-   - **URL-based visual cloning tasks**: When the task description contains a target URL (e.g., "clone https://example.com"), route the work through `$visual-ralph`. `$web-clone` is hard-deprecated; Visual Ralph owns the migrated live-URL visual implementation use case and uses `$visual-verdict` for measured visual scoring.
+   - **URL-based visual cloning tasks**: When the task description contains a target URL (e.g., "clone https://example.com"), route the work through `$visual-ralph`. `$web-clone` is hard-deprecated; Visual Ralph owns the migrated live-URL visual implementation use case and uses its built-in visual verdict step for measured visual scoring.
 6. **Verify completion with fresh evidence**:
+   - If Codex goal mode is available, call `get_goal` before final verification to restate the active objective and include it in the evidence checklist.
    a. Identify what command proves the task is complete
    b. Run verification (test, build, lint)
    c. Read the output -- confirm it actually passed
@@ -84,7 +86,7 @@ Complex tasks often fail silently: partial implementations get declared "done",
    - After the deslop pass, re-run all tests/build/lint and read the output to confirm they still pass.
    - If post-deslop regression fails, roll back cleaner changes or fix and retry. Then rerun Step 7.5 and Step 7.6 until the regression is green.
    - Do not proceed to completion until post-deslop regression is green (unless `--no-deslop` explicitly skipped the deslop pass).
-8. **On approval**: Run `/cancel` to cleanly exit and clean up all state files
+8. **On approval**: If Codex goal mode is active, call `update_goal({status: "complete"})` before `/cancel`; report final elapsed time and token-budget usage when the tool returns it. Then run `/cancel` to cleanly exit and clean up all state files.
 9. **On rejection**: Fix the issues raised, then re-verify at the same tier
 </Steps>
 
@@ -94,10 +96,26 @@ Complex tasks often fail silently: partial implementations get declared "done",
 - Skip Codex consultation for simple feature additions, well-tested changes, or time-critical verification
 - If ToolSearch finds no MCP tools or Codex is unavailable, proceed with architect agent verification alone -- never block on external tools
 - Use `state_write` / `state_read` for ralph mode state persistence between iterations
+- Use Codex goal tools when present: `get_goal` to discover or re-check the active objective, `create_goal` only when the user/system explicitly requested a new goal and no active goal exists, and `update_goal` only after the audited objective is fully achieved.
 - Persist context snapshot path in Ralph mode state so later phases and agents share the same grounding context
 - If an `omx_state` MCP tool call reports that its stdio transport is unavailable/closed, do **not** retry the same MCP call. Retry once through the supported CLI parity surface with the same payload, preserving `workingDirectory` and `session_id`: `omx state write --input '<json>' --json`, `omx state read --input '<json>' --json`, or `omx state clear --input '<json>' --json`. If the CLI path also fails, continue with `.omx/context` / `.omx/plans` file-backed artifacts and report the state persistence blocker.
 </Tool_Usage>
 
+## Goal Mode Integration
+
+Codex goal mode is the thread-level completion contract for long-running Ralph work. Ralph state tracks workflow mechanics; goal mode tracks whether the user objective is truly done. When the goal tools are available:
+
+1. Call `get_goal` during intake or before the first execution loop when the prompt/hook says an active thread goal exists.
+2. If no goal exists, call `create_goal` only when the user or system explicitly asked for goal tracking; otherwise continue with Ralph state alone.
+3. Treat `goal.objective` as binding acceptance scope. Newer user updates can refine the current branch, but do not silently narrow the goal.
+4. Before completion, perform a prompt-to-artifact checklist and completion audit against real evidence:
+   - restate the objective as deliverables/success criteria
+   - map every prompt requirement, named workflow (`$ralplan`, `$ralph`), file, command, test, gate, and deliverable to evidence
+   - inspect the actual files, command output, state, and tests behind each checklist item
+   - identify missing, weakly verified, or uncovered requirements and continue if any remain
+5. Call `update_goal({status: "complete"})` only when the audit shows no required work remains. Do not use passing tests, Ralph state, or architect approval as proxy proof unless they cover the whole goal.
+6. If goal tools are unavailable, keep working through Ralph state and mention the missing goal-mode evidence in the final report.
+
 ## State Management
 
 Use the `omx_state` MCP server tools (`state_write`, `state_read`, `state_clear`) for Ralph lifecycle state.
@@ -177,6 +195,7 @@ Why bad: These are independent tasks that should run in parallel, not sequential
 - [ ] Fresh build output shows success
 - [ ] lsp_diagnostics shows 0 errors on affected files
 - [ ] Architect verification passed (STANDARD tier minimum)
+- [ ] Codex goal-mode completion audit passed, and `update_goal({status: "complete"})` was called when an active goal exists
 - [ ] ai-slop-cleaner pass completed on changed files (or --no-deslop specified)
 - [ ] Post-deslop regression tests pass
 - [ ] `/cancel` run for clean state cleanup

package/skills/ralph-init/SKILL.md

@@ -1,46 +1,10 @@
 ---
 name: ralph-init
-description: Initialize a PRD (Product Requirements Document) for structured ralph-loop execution
+description: Ralph Init deprecated skill
 ---
 
-# Ralph Init
+# Ralph Init deprecated
 
-Initialize a PRD (Product Requirements Document) for structured ralph-loop execution. Creates a structured requirements document that Ralph can use for goal-driven iteration.
+Hard-deprecated. Do not invoke or route this skill. Use `$ralph` directly after PRD/test-spec planning is complete.
 
-## Usage
-
-```
-/ralph-init "project or feature description"
-```
-
-## Behavior
-
-1. **Gather requirements** via interactive interview or from the provided description
-2. **Create PRD** at `.omx/plans/prd-{slug}.md` with:
-   - Problem statement
-   - Goals and non-goals
-   - Acceptance criteria (testable)
-   - Technical constraints
-   - Implementation phases
-3. **Link to Ralph** so that `/ralph` can use the PRD as its completion criteria
-4. **Initialize/ensure canonical progress ledger** at `.omx/state/{scope}/ralph-progress.json` (session scope if active session exists)
-
-### Canonical source contract
-
-- Canonical PRD source of truth is `.omx/plans/prd-{slug}.md`.
-- Ralph progress source of truth is `.omx/state/{scope}/ralph-progress.json` (session scope when available).
-- During the current compatibility window, Ralph `--prd` startup still validates machine-readable story state from `.omx/prd.json`.
-- Legacy `.omx/prd.json` / `.omx/progress.txt` inputs migrate one-way into canonical artifacts, but canonical PRD markdown is not yet the startup validation source for `omx ralph --prd ...`.
-
-## Output
-
-A structured PRD file saved to `.omx/plans/` that serves as the definition of done for Ralph execution.
-
-## Next Steps
-
-After creating the PRD, start execution with:
-```
-/ralph "implement the PRD"
-```
-
-Ralph will iterate until all acceptance criteria in the PRD are met and architect-verified.
+Task: {{ARGUMENTS}}

package/skills/review/SKILL.md

@@ -1,38 +1,10 @@
 ---
 name: review
-description: Reviewer-only pass for /plan --review and cleanup artifact review
+description: Deprecated standalone review skill
 ---
 
-# Review (Reviewer-Only Pass)
+# Review deprecated
 
-Review is a shorthand alias for `/plan --review`. It triggers Critic evaluation of an existing plan and is intended to preserve writer/reviewer separation.
+Hard-deprecated. Do not invoke or route this skill. Use `$code-review` directly for implementation review, or `$plan --review` only when explicitly reviewing an existing planning artifact.
 
-## Usage
-
-```
-/review
-/review "path/to/plan.md"
-```
-
-## Behavior
-
-This skill invokes the Plan skill in review mode:
-
-```
-/plan --review <arguments>
-```
-
-The review workflow:
-1. Treat review as a reviewer-only pass. The authoring context may write the plan or cleanup proposal, but a separate reviewer context must issue the verdict.
-2. Read plan file from `.omx/plans/` (or specified path)
-3. Evaluate via Critic agent
-4. For cleanup/refactor/anti-slop work, confirm the artifact includes a cleanup plan, regression-test coverage or an explicit test gap, bounded smell-by-smell passes, and quality gates.
-5. Return verdict: APPROVED, REVISE (with specific feedback), or REJECT (replanning required)
-
-## Guardrails
-
-- Never write and approve in the same context.
-- If the current context authored the artifact, hand review to Critic or another reviewer role.
-- Approval must cite concrete evidence, not author claims.
-
-Follow the Plan skill's full documentation for review mode details.
+Task: {{ARGUMENTS}}

package/skills/security-review/SKILL.md

@@ -1,300 +1,10 @@
 ---
 name: security-review
-description: Run a comprehensive security review on code
+description: Deprecated standalone security review skill
 ---
 
-# Security Review Skill
+# Security Review deprecated
 
-Conduct a thorough security audit checking for OWASP Top 10 vulnerabilities, hardcoded secrets, and unsafe patterns.
+Hard-deprecated. Do not invoke or route this skill. Use `$code-review` directly for new review workflows when security concerns are in scope.
 
-## When to Use
-
-This skill activates when:
-- User requests "security review", "security audit"
-- After writing code that handles user input
-- After adding new API endpoints
-- After modifying authentication/authorization logic
-- Before deploying to production
-- After adding external dependencies
-
-## What It Does
-
-## GPT-5.5 Guidance Alignment
-
-- Default to outcome-first progress and completion reporting: state the target result, evidence, validation status, and stop condition before adding process detail.
-- Treat newer user task updates as local overrides for the active workflow branch while preserving earlier non-conflicting constraints.
-- If correctness depends on additional inspection, retrieval, execution, or verification, keep using the relevant tools until the security review is grounded; stop once enough evidence exists.
-- Continue through clear, low-risk, reversible next steps automatically; ask only when the next step is materially branching, destructive, credentialed, external-production, or preference-dependent.
-
-Delegates to the `security-reviewer` agent (THOROUGH tier) for deep security analysis:
-
-1. **OWASP Top 10 Scan**
-   - A01: Broken Access Control
-   - A02: Cryptographic Failures
-   - A03: Injection (SQL, NoSQL, Command, XSS)
-   - A04: Insecure Design
-   - A05: Security Misconfiguration
-   - A06: Vulnerable and Outdated Components
-   - A07: Identification and Authentication Failures
-   - A08: Software and Data Integrity Failures
-   - A09: Security Logging and Monitoring Failures
-   - A10: Server-Side Request Forgery (SSRF)
-
-2. **Secrets Detection**
-   - Hardcoded API keys
-   - Passwords in source code
-   - Private keys in repo
-   - Tokens and credentials
-   - Connection strings with secrets
-
-3. **Input Validation**
-   - All user inputs sanitized
-   - SQL/NoSQL injection prevention
-   - Command injection prevention
-   - XSS prevention (output escaping)
-   - Path traversal prevention
-
-4. **Authentication/Authorization**
-   - Proper password hashing (bcrypt, argon2)
-   - Session management security
-   - Access control enforcement
-   - JWT implementation security
-
-5. **Dependency Security**
-   - Run `npm audit` for known vulnerabilities
-   - Check for outdated dependencies
-   - Identify high-severity CVEs
-
-## Agent Delegation
-
-```
-delegate(
-  role="security-reviewer",
-  tier="THOROUGH",
-  prompt="SECURITY REVIEW TASK
-
-Conduct comprehensive security audit of codebase.
-
-Scope: [specific files or entire codebase]
-
-Security Checklist:
-1. OWASP Top 10 scan
-2. Hardcoded secrets detection
-3. Input validation review
-4. Authentication/authorization review
-5. Dependency vulnerability scan (npm audit)
-
-Output: Security review report with:
-- Summary of findings by severity (CRITICAL, HIGH, MEDIUM, LOW)
-- Specific file:line locations
-- CVE references where applicable
-- Remediation guidance for each issue
-- Overall security posture assessment"
-)
-```
-
-## External Model Consultation (Preferred)
-
-The security-reviewer agent SHOULD consult Codex for cross-validation.
-
-### Protocol
-1. **Form your OWN security analysis FIRST** - Complete the review independently
-2. **Consult for validation** - Cross-check findings with Codex
-3. **Critically evaluate** - Never blindly adopt external findings
-4. **Graceful fallback** - Never block if tools unavailable
-
-### When to Consult
-- Authentication/authorization code
-- Cryptographic implementations
-- Input validation for untrusted data
-- High-risk vulnerability patterns
-- Production deployment code
-
-### When to Skip
-- Low-risk utility code
-- Well-audited patterns
-- Time-critical security assessments
-- Code with existing security tests
-
-### Tool Usage
-Before first MCP tool use, call `ToolSearch("mcp")` to discover deferred MCP tools.
-Use `mcp__x__ask_codex` with `agent_role: "security-reviewer"`.
-If ToolSearch finds no MCP tools, fall back to the `security-reviewer` agent.
-
-**Note:** Security second opinions are high-value. Consider consulting for CRITICAL/HIGH findings.
-
-## Output Format
-
-```
-SECURITY REVIEW REPORT
-======================
-
-Scope: Entire codebase (42 files scanned)
-Scan Date: 2026-01-24T14:30:00Z
-
-CRITICAL (2)
-------------
-1. src/api/auth.ts:89 - Hardcoded API Key
-   Finding: AWS API key hardcoded in source code
-   Impact: Credential exposure if code is public or leaked
-   Remediation: Move to environment variables, rotate key immediately
-   Reference: OWASP A02:2021 – Cryptographic Failures
-
-2. src/db/query.ts:45 - SQL Injection Vulnerability
-   Finding: User input concatenated directly into SQL query
-   Impact: Attacker can execute arbitrary SQL commands
-   Remediation: Use parameterized queries or ORM
-   Reference: OWASP A03:2021 – Injection
-
-HIGH (5)
---------
-3. src/auth/password.ts:22 - Weak Password Hashing
-   Finding: Passwords hashed with MD5 (cryptographically broken)
-   Impact: Passwords can be reversed via rainbow tables
-   Remediation: Use bcrypt or argon2 with appropriate work factor
-   Reference: OWASP A02:2021 – Cryptographic Failures
-
-4. src/components/UserInput.tsx:67 - XSS Vulnerability
-   Finding: User input rendered with dangerouslySetInnerHTML
-   Impact: Cross-site scripting attack vector
-   Remediation: Sanitize HTML or use safe rendering
-   Reference: OWASP A03:2021 – Injection (XSS)
-
-5. src/api/upload.ts:34 - Path Traversal Vulnerability
-   Finding: User-controlled filename used without validation
-   Impact: Attacker can read/write arbitrary files
-   Remediation: Validate and sanitize filenames, use allowlist
-   Reference: OWASP A01:2021 – Broken Access Control
-
-...
-
-MEDIUM (8)
-----------
-...
-
-LOW (12)
---------
-...
-
-DEPENDENCY VULNERABILITIES
---------------------------
-Found 3 vulnerabilities via npm audit:
-
-CRITICAL: axios@0.21.0 - Server-Side Request Forgery (CVE-2021-3749)
-  Installed: axios@0.21.0
-  Fix: npm install axios@0.21.2
-
-HIGH: lodash@4.17.19 - Prototype Pollution (CVE-2020-8203)
-  Installed: lodash@4.17.19
-  Fix: npm install lodash@4.17.21
-
-...
-
-OVERALL ASSESSMENT
-------------------
-Security Posture: POOR (2 CRITICAL, 5 HIGH issues)
-
-Immediate Actions Required:
-1. Rotate exposed AWS API key
-2. Fix SQL injection in db/query.ts
-3. Upgrade password hashing to bcrypt
-4. Update vulnerable dependencies
-
-Recommendation: DO NOT DEPLOY until CRITICAL and HIGH issues resolved.
-```
-
-## Security Checklist
-
-The security-reviewer agent verifies:
-
-### Authentication & Authorization
-- [ ] Passwords hashed with strong algorithm (bcrypt/argon2)
-- [ ] Session tokens cryptographically random
-- [ ] JWT tokens properly signed and validated
-- [ ] Access control enforced on all protected resources
-- [ ] No authentication bypass vulnerabilities
-
-### Input Validation
-- [ ] All user inputs validated and sanitized
-- [ ] SQL queries use parameterization (no string concatenation)
-- [ ] NoSQL queries prevent injection
-- [ ] File uploads validated (type, size, content)
-- [ ] URLs validated to prevent SSRF
-
-### Output Encoding
-- [ ] HTML output escaped to prevent XSS
-- [ ] JSON responses properly encoded
-- [ ] No user data in error messages
-- [ ] Content-Security-Policy headers set
-
-### Secrets Management
-- [ ] No hardcoded API keys
-- [ ] No passwords in source code
-- [ ] No private keys in repo
-- [ ] Environment variables used for secrets
-- [ ] Secrets not logged or exposed in errors
-
-### Cryptography
-- [ ] Strong algorithms used (AES-256, RSA-2048+)
-- [ ] Proper key management
-- [ ] Random number generation cryptographically secure
-- [ ] TLS/HTTPS enforced for sensitive data
-
-### Dependencies
-- [ ] No known vulnerabilities in dependencies
-- [ ] Dependencies up to date
-- [ ] No CRITICAL or HIGH CVEs
-- [ ] Dependency sources verified
-
-## Severity Definitions
-
-**CRITICAL** - Exploitable vulnerability with severe impact (data breach, RCE, credential theft)
-**HIGH** - Vulnerability requiring specific conditions but serious impact
-**MEDIUM** - Security weakness with limited impact or difficult exploitation
-**LOW** - Best practice violation or minor security concern
-
-## Remediation Priority
-
-1. **Rotate exposed secrets** - Immediate (within 1 hour)
-2. **Fix CRITICAL** - Urgent (within 24 hours)
-3. **Fix HIGH** - Important (within 1 week)
-4. **Fix MEDIUM** - Planned (within 1 month)
-5. **Fix LOW** - Backlog (when convenient)
-
-
-## 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.
-
-## Use with Other Skills
-
-**With Team:**
-```
-/team "run security review on authentication module"
-```
-Uses: explore → security-reviewer → executor → security-reviewer (re-verify)
-
-**With Swarm:**
-```
-/swarm 4:security-reviewer "audit all API endpoints"
-```
-Parallel security review across multiple endpoints.
-
-**With Ralph:**
-```
-/ralph security-review then fix all issues
-```
-Review, fix, re-review until all issues resolved.
-
-## Best Practices
-
-- **Review early** - Security by design, not afterthought
-- **Review often** - Every major feature or API change
-- **Automate** - Run security scans in CI/CD pipeline
-- **Fix immediately** - Don't accumulate security debt
-- **Educate** - Learn from findings to prevent future issues
-- **Verify fixes** - Re-run security review after remediation
+Task: {{ARGUMENTS}}

package/skills/swarm/SKILL.md

@@ -1,25 +1,10 @@
 ---
 name: swarm
-description: N coordinated agents on shared task list (compatibility facade over team)
+description: Swarm deprecated shim
 ---
 
-# Swarm (Compatibility Facade)
+# Swarm deprecated
 
-Swarm is a compatibility alias for the `/team` skill. All swarm invocations are routed to the Team skill's staged pipeline.
+Hard-deprecated. Do not invoke or route this skill. Use `$team` directly for coordinated multi-agent execution.
 
-## Usage
-
-```
-/swarm N:agent-type "task description"
-/swarm "task description"
-```
-
-## Behavior
-
-This skill is identical to `/team`. Invoke the Team skill with the same arguments:
-
-```
-/team <arguments>
-```
-
-Follow the Team skill's full documentation for staged pipeline, agent routing, and coordination semantics.
+Task: {{ARGUMENTS}}

package/skills/tdd/SKILL.md

@@ -1,106 +1,10 @@
 ---
 name: tdd
-description: Test-Driven Development enforcement skill - write tests first, always
+description: TDD deprecated shim
 ---
 
-# TDD Mode
+# TDD deprecated
 
-[TDD MODE ACTIVATED]
+Hard-deprecated. Do not invoke or route this skill. Keep test-first discipline inside the active implementation workflow and verify with the project test suite.
 
-## The Iron Law
-
-**NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST**
-
-Write code before test? DELETE IT. Start over. No exceptions.
-
-## Red-Green-Refactor Cycle
-
-### 1. RED: Write Failing Test
-- Write test for the NEXT piece of functionality
-- Run test - MUST FAIL
-- If it passes, your test is wrong
-
-### 2. GREEN: Minimal Implementation
-- Write ONLY enough code to pass the test
-- No extras. No "while I'm here."
-- Run test - MUST PASS
-
-### 3. REFACTOR: Clean Up
-- Improve code quality
-- Run tests after EVERY change
-- Must stay green
-
-### 4. REPEAT
-- Next failing test
-- Continue cycle
-
-## Enforcement Rules
-
-| If You See | Action |
-|------------|--------|
-| Code written before test | STOP. Delete code. Write test first. |
-| Test passes on first run | Test is wrong. Fix it to fail first. |
-| Multiple features in one cycle | STOP. One test, one feature. |
-| Skipping refactor | Go back. Clean up before next feature. |
-
-## Commands
-
-Before each implementation:
-```bash
-# Run the project's test command - should have ONE new failure
-```
-
-After implementation:
-```bash
-# Run the project's test command - new test should pass, all others still pass
-```
-
-## Output Format
-
-When guiding TDD:
-
-```
-## TDD Cycle: [Feature Name]
-
-### RED Phase
-Test: [test code]
-Expected failure: [what error you expect]
-Actual: [run result showing failure]
-
-### GREEN Phase
-Implementation: [minimal code]
-Result: [run result showing pass]
-
-### REFACTOR Phase
-Changes: [what was cleaned up]
-Result: [tests still pass]
-```
-
-## External Model Consultation (Preferred)
-
-The tdd-guide agent SHOULD consult Codex for test strategy validation.
-
-### Protocol
-1. **Form your OWN test strategy FIRST** - Design tests independently
-2. **Consult for validation** - Cross-check test coverage strategy
-3. **Critically evaluate** - Never blindly adopt external suggestions
-4. **Graceful fallback** - Never block if tools unavailable
-
-### When to Consult
-- Complex domain logic requiring comprehensive test coverage
-- Edge case identification for critical paths
-- Test architecture for large features
-- Unfamiliar testing patterns
-
-### When to Skip
-- Simple unit tests
-- Well-understood testing patterns
-- Time-critical TDD cycles
-- Small, isolated functionality
-
-### Tool Usage
-Before first MCP tool use, call `ToolSearch("mcp")` to discover deferred MCP tools.
-Use `mcp__x__ask_codex` with `agent_role: "tdd-guide"`.
-If ToolSearch finds no MCP tools, fall back to the `test-engineer` agent.
-
-**Remember:** The discipline IS the value. Shortcuts destroy the benefit.
+Task: {{ARGUMENTS}}

package/skills/team/SKILL.md

@@ -156,7 +156,7 @@ Important:
 - Worker panes are independent full Codex/Claude CLI sessions
 - Workers may run in separate git worktrees (`omx team --worktree[=<name>]`) while sharing one team state root
 - Worker ACKs go to `mailbox/leader-fixed.json`
-- Notify hook updates worker heartbeat and nudges leader during active team mode
+- Notify hook updates worker heartbeat and sends lifecycle-driven leader nudges (for example resolved native worker Stop/all-idle or stale-leader evidence) during active team mode; deprecated worker stall/progress heuristics are not operator-facing guidance.
 - Submit routing uses this CLI resolution order per worker trigger:
   1) explicit worker CLI provided by runtime state (persisted on worker identity/config),
   2) `OMX_TEAM_WORKER_CLI_MAP` entry for that worker index,
@@ -221,7 +221,11 @@ sleep 30 && omx team status <team-name>
 
 Repeat that check while the team stays active, or use `omx team await <team-name> --timeout-ms 30000 --json` when event-driven waiting is a better fit.
 
-If the leader gets a stale/team-stalled nudge, immediately run `omx team status <team-name>` before taking any manual intervention.
+If the leader gets a stale, lifecycle, or all-idle nudge, immediately run `omx team status <team-name>` before taking any manual intervention. Deprecated worker stall/progress nudges should not be treated as an active runtime contract.
+
+### Deprecated worker stall/progress knobs
+
+`OMX_TEAM_PROGRESS_STALL_MS` and `OMX_TEAM_WORKER_TURN_STALL_MS` are legacy compatibility/test-only names for the retired worker stall/progress nudge path. Do not recommend them as operator tuning knobs for active team runs; resolved native worker Stop, all-idle, mailbox, and stale-leader evidence are the supported leader wakeup signals.
 
 ## Message Dispatch Policy (CLI-first, state-first)
 

package/skills/trace/SKILL.md

@@ -1,33 +1,10 @@
 ---
 name: trace
-description: Show agent flow trace timeline and summary
+description: Trace deprecated shim
 ---
 
-# Agent Flow Trace
+# Trace deprecated
 
-[TRACE MODE ACTIVATED]
+Hard-deprecated. Do not invoke or route this skill. Use maintained OMX trace/runtime inspection surfaces directly when trace evidence is needed.
 
-## Objective
-
-Display the flow trace showing how hooks, keywords, skills, agents, and tools interacted during this session.
-
-## Instructions
-
-1. **Use `trace_timeline` MCP tool** to show the chronological event timeline
-   - Call with no arguments to show the latest session
-   - Use `filter` parameter to focus on specific event types (hooks, skills, agents, keywords, tools, modes)
-   - Use `last` parameter to limit output
-
-2. **Use `trace_summary` MCP tool** to show aggregate statistics
-   - Hook fire counts
-   - Keywords detected
-   - Skills activated
-   - Mode transitions
-   - Tool performance and bottlenecks
-
-## Output Format
-
-Present the timeline first, then the summary. Highlight:
-- **Mode transitions** (how execution modes changed)
-- **Bottlenecks** (slow tools or agents)
-- **Flow patterns** (keyword -> skill -> agent chains)
+Task: {{ARGUMENTS}}