1
0
Source

Cancel any active OMC mode (autopilot, ralph, ultrawork, ecomode, ultraqa, swarm, ultrapilot, pipeline, team)

Install

mkdir -p .claude/skills/cancel && curl -L -o skill.zip "https://mcp.directory/api/skills/download/3746" && unzip -o skill.zip -d .claude/skills/cancel && rm skill.zip

Installs to .claude/skills/cancel

About this skill

Cancel Skill

Intelligent cancellation that detects and cancels the active OMC mode.

The cancel skill is the standard way to complete and exit any OMC mode. When the stop hook detects work is complete, it instructs the LLM to invoke this skill for proper state cleanup. If cancel fails or is interrupted, retry with --force flag, or wait for the 2-hour staleness timeout as a last resort.

What It Does

Automatically detects which mode is active and cancels it:

  • Autopilot: Stops workflow, preserves progress for resume
  • Ralph: Stops persistence loop, clears linked ultrawork if applicable
  • Ultrawork: Stops parallel execution (standalone or linked)
  • UltraQA: Stops QA cycling workflow
  • Swarm: Stops coordinated agent swarm, releases claimed tasks
  • Ultrapilot: Stops parallel autopilot workers
  • Pipeline: Stops sequential agent pipeline
  • Team: Sends shutdown_request to all teammates, waits for responses, calls TeamDelete, clears linked ralph if present
  • Team+Ralph (linked): Cancels team first (graceful shutdown), then clears ralph state. Cancelling ralph when linked also cancels team first.

Usage

/oh-my-claudecode:cancel

Or say: "cancelomc", "stopomc"

Auto-Detection

/oh-my-claudecode:cancel follows the session-aware state contract:

  • By default the command inspects the current session via state_list_active and state_get_status, navigating .omc/state/sessions/{sessionId}/… to discover which mode is active.
  • When a session id is provided or already known, that session-scoped path is authoritative. Legacy files in .omc/state/*.json are consulted only as a compatibility fallback if the session id is missing or empty.
  • Swarm is a shared SQLite/marker mode (.omc/state/swarm.db / .omc/state/swarm-active.marker) and is not session-scoped.
  • The default cleanup flow calls state_clear with the session id to remove only the matching session files; modes stay bound to their originating session.

Active modes are still cancelled in dependency order:

  1. Autopilot (includes linked ralph/ultraqa/ cleanup)
  2. Ralph (cleans its linked ultrawork or )
  3. Ultrawork (standalone)
  4. UltraQA (standalone)
  5. Swarm (standalone)
  6. Ultrapilot (standalone)
  7. Pipeline (standalone)
  8. Team (Claude Code native)
  9. OMC Teams (tmux CLI workers)
  10. Plan Consensus (standalone)

Force Clear All

Use --force or --all when you need to erase every session plus legacy artifacts, e.g., to reset the workspace entirely.

/oh-my-claudecode:cancel --force
/oh-my-claudecode:cancel --all

Steps under the hood:

  1. state_list_active enumerates .omc/state/sessions/{sessionId}/… to find every known session.
  2. state_clear runs once per session to drop that session’s files.
  3. A global state_clear without session_id removes legacy files under .omc/state/*.json, .omc/state/swarm*.db, and compatibility artifacts (see list).
  4. Team artifacts (~/.claude/teams/*/, ~/.claude/tasks/*/, .omc/state/team-state.json) are best-effort cleared as part of the legacy fallback.
    • Cancel for native team does NOT affect omc-teams state, and vice versa.

Every state_clear command honors the session_id argument, so even force mode still uses the session-aware paths first before deleting legacy files.

Legacy compatibility list (removed only under --force/--all):

  • .omc/state/autopilot-state.json
  • .omc/state/ralph-state.json
  • .omc/state/ralph-plan-state.json
  • .omc/state/ralph-verification.json
  • .omc/state/ultrawork-state.json
  • .omc/state/ultraqa-state.json
  • .omc/state/swarm.db
  • .omc/state/swarm.db-wal
  • .omc/state/swarm.db-shm
  • .omc/state/swarm-active.marker
  • .omc/state/swarm-tasks.db
  • .omc/state/ultrapilot-state.json
  • .omc/state/ultrapilot-ownership.json
  • .omc/state/pipeline-state.json
  • .omc/state/omc-teams-state.json
  • .omc/state/plan-consensus.json
  • .omc/state/ralplan-state.json
  • .omc/state/boulder.json
  • .omc/state/hud-state.json
  • .omc/state/subagent-tracking.json
  • .omc/state/subagent-tracker.lock
  • .omc/state/rate-limit-daemon.pid
  • .omc/state/rate-limit-daemon.log
  • .omc/state/checkpoints/ (directory)
  • .omc/state/sessions/ (empty directory cleanup after clearing sessions)

Implementation Steps

When you invoke this skill:

1. Parse Arguments

# Check for --force or --all flags
FORCE_MODE=false
if [[ "$*" == *"--force"* ]] || [[ "$*" == *"--all"* ]]; then
  FORCE_MODE=true
fi

2. Detect Active Modes

The skill now relies on the session-aware state contract rather than hard-coded file paths:

  1. Call state_list_active to enumerate .omc/state/sessions/{sessionId}/… and discover every active session.
  2. For each session id, call state_get_status to learn which mode is running (autopilot, ralph, ultrawork, etc.) and whether dependent modes exist.
  3. If a session_id was supplied to /oh-my-claudecode:cancel, skip legacy fallback entirely and operate solely within that session path; otherwise, consult legacy files in .omc/state/*.json only if the state tools report no active session. Swarm remains a shared SQLite/marker mode outside session scoping.
  4. Any cancellation logic in this doc mirrors the dependency order discovered via state tools (autopilot → ralph → …).

3A. Force Mode (if --force or --all)

Use force mode to clear every session plus legacy artifacts via state_clear. Direct file removal is reserved for legacy cleanup when the state tools report no active sessions.

3B. Smart Cancellation (default)

If Team Active (Claude Code native)

Teams are detected by checking for config files in ~/.claude/teams/:

# Check for active teams
TEAM_CONFIGS=$(find ~/.claude/teams -name config.json -maxdepth 2 2>/dev/null)

Two-pass cancellation protocol:

Pass 1: Graceful Shutdown

For each team found in ~/.claude/teams/:
  1. Read config.json to get team_name and members list
  2. For each non-lead member:
     a. Send shutdown_request via SendMessage
     b. Wait up to 15 seconds for shutdown_response
     c. If response received: member terminates and is auto-removed
     d. If timeout: mark member as unresponsive, continue to next
  3. Log: "Graceful pass: X/Y members responded"

Pass 2: Reconciliation

After graceful pass:
  1. Re-read config.json to check remaining members
  2. If only lead remains (or config is empty): proceed to TeamDelete
  3. If unresponsive members remain:
     a. Wait 5 more seconds (they may still be processing)
     b. Re-read config.json again
     c. If still stuck: attempt TeamDelete anyway
     d. If TeamDelete fails: report manual cleanup path

TeamDelete + Cleanup:

  1. Call TeamDelete() — removes ~/.claude/teams/{name}/ and ~/.claude/tasks/{name}/
  2. Clear team state: state_clear(mode="team")
  3. Check for linked ralph: state_read(mode="ralph") — if linked_team is true:
     a. Clear ralph state: state_clear(mode="ralph")
     b. Clear linked ultrawork if present: state_clear(mode="ultrawork")
  4. Run orphan scan (see below)
  5. Emit structured cancel report

Orphan Detection (Post-Cleanup):

After TeamDelete, verify no agent processes remain:

node "${CLAUDE_PLUGIN_ROOT}/scripts/cleanup-orphans.mjs" --team-name "{team_name}"

The orphan scanner:

  1. Checks ps aux (Unix) or tasklist (Windows) for processes with --team-name matching the deleted team
  2. For each orphan whose team config no longer exists: sends SIGTERM, waits 5s, sends SIGKILL if still alive
  3. Reports cleanup results as JSON

Use --dry-run to inspect without killing. The scanner is safe to run multiple times.

Structured Cancel Report:

Team "{team_name}" cancelled:
  - Members signaled: N
  - Responses received: M
  - Unresponsive: K (list names if any)
  - TeamDelete: success/failed
  - Manual cleanup needed: yes/no
    Path: ~/.claude/teams/{name}/ and ~/.claude/tasks/{name}/

Implementation note: The cancel skill is executed by the LLM, not as a bash script. When you detect an active team:

  1. Read ~/.claude/teams/*/config.json to find active teams
  2. If multiple teams exist, cancel oldest first (by createdAt)
  3. For each non-lead member, call SendMessage(type: "shutdown_request", recipient: member-name, content: "Cancelling")
  4. Wait briefly for shutdown responses (15s per member timeout)
  5. Re-read config.json to check for remaining members (reconciliation pass)
  6. Call TeamDelete() to clean up
  7. Clear team state: state_clear(mode="team", session_id)
  8. Report structured summary to user

If Autopilot Active

Autopilot handles its own cleanup including linked ralph and ultraqa.

  1. Read autopilot state via state_read(mode="autopilot", session_id) to get current phase
  2. Check for linked ralph via state_read(mode="ralph", session_id):
    • If ralph is active and has linked_ultrawork: true, clear ultrawork first: state_clear(mode="ultrawork", session_id)
    • Clear ralph: state_clear(mode="ralph", session_id)
  3. Check for linked ultraqa via state_read(mode="ultraqa", session_id):
    • If active, clear it: state_clear(mode="ultraqa", session_id)
  4. Mark autopilot inactive (preserve state for resume) via state_write(mode="autopilot", session_id, state={active: false, ...existing})

If Ralph Active (but not Autopilot)

  1. Read ralph state via state_read(mode="ralph", session_id) to check for linked ultrawork
  2. If linked_ultrawork: true:
    • Read ultrawork state to verify linked_to_ralph: true
    • If linked, clear ultrawork: state_clear(mode="ultrawork", session_id)
  3. Clear ralph: state_clear(mode="ralph", session_id)

If Ultrawork Active (standalone, not linked)

  1. Read ultrawork state via state_read(mode="ultrawork", session_id)
  2. If linked_to_ralph: true, warn user to cancel ralph instead (which cascades)
  3. Otherwise clear: state_clear(mode="ultrawork", session_id)


Content truncated.

You might also like

flutter-development

aj-geddes

Build beautiful cross-platform mobile apps with Flutter and Dart. Covers widgets, state management with Provider/BLoC, navigation, API integration, and material design.

643969

drawio-diagrams-enhanced

jgtolentino

Create professional draw.io (diagrams.net) diagrams in XML format (.drawio files) with integrated PMP/PMBOK methodologies, extensive visual asset libraries, and industry-standard professional templates. Use this skill when users ask to create flowcharts, swimlane diagrams, cross-functional flowcharts, org charts, network diagrams, UML diagrams, BPMN, project management diagrams (WBS, Gantt, PERT, RACI), risk matrices, stakeholder maps, or any other visual diagram in draw.io format. This skill includes access to custom shape libraries for icons, clipart, and professional symbols.

591705

ui-ux-pro-max

nextlevelbuilder

"UI/UX design intelligence. 50 styles, 21 palettes, 50 font pairings, 20 charts, 8 stacks (React, Next.js, Vue, Svelte, SwiftUI, React Native, Flutter, Tailwind). Actions: plan, build, create, design, implement, review, fix, improve, optimize, enhance, refactor, check UI/UX code. Projects: website, landing page, dashboard, admin panel, e-commerce, SaaS, portfolio, blog, mobile app, .html, .tsx, .vue, .svelte. Elements: button, modal, navbar, sidebar, card, table, form, chart. Styles: glassmorphism, claymorphism, minimalism, brutalism, neumorphism, bento grid, dark mode, responsive, skeuomorphism, flat design. Topics: color palette, accessibility, animation, layout, typography, font pairing, spacing, hover, shadow, gradient."

318398

godot

bfollington

This skill should be used when working on Godot Engine projects. It provides specialized knowledge of Godot's file formats (.gd, .tscn, .tres), architecture patterns (component-based, signal-driven, resource-based), common pitfalls, validation tools, code templates, and CLI workflows. The `godot` command is available for running the game, validating scripts, importing resources, and exporting builds. Use this skill for tasks involving Godot game development, debugging scene/resource files, implementing game systems, or creating new Godot components.

339397

nano-banana-pro

garg-aayush

Generate and edit images using Google's Nano Banana Pro (Gemini 3 Pro Image) API. Use when the user asks to generate, create, edit, modify, change, alter, or update images. Also use when user references an existing image file and asks to modify it in any way (e.g., "modify this image", "change the background", "replace X with Y"). Supports both text-to-image generation and image-to-image editing with configurable resolution (1K default, 2K, or 4K for high resolution). DO NOT read the image file first - use this skill directly with the --input-image parameter.

451339

fastapi-templates

wshobson

Create production-ready FastAPI projects with async patterns, dependency injection, and comprehensive error handling. Use when building new FastAPI applications or setting up backend API projects.

304231

Stay ahead of the MCP ecosystem

Get weekly updates on new skills and servers.