oh-my-codex 0.15.3 → 0.16.0

package/skills/performance-goal/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: performance-goal
+description: "Run an evaluator-gated performance optimization workflow over Codex goal mode with durable OMX artifacts and safe goal handoffs."
+---
+
+# Performance Goal Workflow
+
+Use this skill when a user asks OMX to optimize performance and wants a goal-oriented loop rather than a one-off review.
+
+## Contract
+
+- OMX owns durable workflow state under `.omx/goals/performance/<slug>/`.
+- Codex goal mode owns only the active-thread focus/accounting primitive.
+- Shell commands do **not** mutate hidden Codex goal state. They write artifacts and emit model-facing handoff text.
+- No optimization work may start until an evaluator command and pass/fail contract exist.
+- Do not call `update_goal({status: "complete"})` until the evaluator has a passing checkpoint and a completion audit proves the objective is done; then call `get_goal` again and pass that fresh snapshot to `omx performance-goal complete --codex-goal-json`.
+
+## CLI
+
+Create the workflow and evaluator contract:
+
+```sh
+omx performance-goal create \
+  --objective "Reduce CLI startup latency by 20%" \
+  --evaluator-command "npm run perf:startup" \
+  --evaluator-contract "PASS when p95 latency improves by 20% and regression tests pass" \
+  --slug startup-latency
+```
+
+Emit the Codex goal handoff:
+
+```sh
+omx performance-goal start --slug startup-latency
+```
+
+Record evaluator evidence:
+
+```sh
+omx performance-goal checkpoint --slug startup-latency --status pass --evidence "benchmark + tests passed"
+omx performance-goal checkpoint --slug startup-latency --status fail --evidence "benchmark regressed"
+omx performance-goal checkpoint --slug startup-latency --status blocked --evidence "missing fixture"
+```
+
+Complete only after a passing checkpoint:
+
+```sh
+omx performance-goal complete --slug startup-latency --evidence "final evaluator evidence" --codex-goal-json <get_goal-json-or-path>
+```
+
+## Agent Loop
+
+1. Run `omx performance-goal create` if no workflow exists.
+2. Run `omx performance-goal start` and follow the handoff:
+   - call `get_goal`;
+   - call `create_goal` only when no active goal exists and the objective is explicit;
+   - work only against the evaluator contract;
+   - after evaluator pass and completion audit, call `update_goal({status: "complete"})`, call `get_goal` again, and pass that snapshot to `omx performance-goal complete --codex-goal-json`;
+3. Optimize in small reversible patches.
+4. Run the evaluator and related regression tests.
+5. Record each pass/fail/blocker with `checkpoint`.
+6. Complete only when the pass artifact exists and no required work remains.
+
+## Completion Gate
+
+A performance goal is incomplete unless `.omx/goals/performance/<slug>/state.json` contains a `lastValidation.status` of `pass` and `omx performance-goal complete` receives a matching complete Codex `get_goal` snapshot via `--codex-goal-json`. Passing ordinary tests alone is not sufficient unless they are the declared evaluator contract.

package/skills/plan/SKILL.md

@@ -114,7 +114,7 @@ Jumping into code without understanding requirements leads to rework, scope cree
 2. Evaluate via Critic using `ask_codex` with `agent_role: "critic"`
 3. For cleanup/refactor/anti-slop work, verify that the artifact includes a cleanup plan, regression tests or an explicit test gap, smell-by-smell passes, and quality gates.
 4. Return verdict: APPROVED, REVISE (with specific feedback), or REJECT (replanning required)
-5. If the current context authored the artifact, hand the review to `/review`, `critic`, `quality-reviewer`, `security-reviewer`, or `verifier` as appropriate.
+5. If the current context authored the artifact, hand the review to `$code-review`, `critic`, `quality-reviewer`, or `verifier` as appropriate.
 
 ### Plan Output Format
 

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}}