cancel
Cancel any active OMC mode (autopilot, ralph, ultrawork, ultraqa, swarm, ultrapilot, pipeline, team)
41
41%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/cancel/SKILL.mdQuality
Discovery
54%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description is highly distinctive and includes excellent trigger terms by listing all specific mode names. However, it lacks a 'Use when...' clause, which significantly hurts completeness, and it only describes a single action rather than multiple concrete capabilities.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user wants to stop, exit, or cancel an active OMC mode such as autopilot, ralph, or ultrawork.'
Include common natural language variations users might say, such as 'stop', 'exit', 'quit', 'turn off', or 'disable' in addition to 'cancel'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names a specific action ('Cancel') and lists specific modes by name (autopilot, ralph, ultrawork, etc.), but it only describes one action rather than multiple concrete capabilities. | 2 / 3 |
Completeness | The description answers 'what' (cancel active OMC modes) but has no explicit 'when' clause or trigger guidance. Per the rubric, a missing 'Use when...' clause caps completeness at 2, and since the 'when' is entirely absent, this scores a 1. | 1 / 3 |
Trigger Term Quality | Includes strong natural trigger terms: 'cancel', 'OMC mode', and lists all specific mode names (autopilot, ralph, ultrawork, ultraqa, swarm, ultrapilot, pipeline, team) that users would naturally reference when wanting to stop these modes. | 3 / 3 |
Distinctiveness Conflict Risk | This is a very specific niche action—canceling named OMC modes—that is unlikely to conflict with other skills. The enumerated mode names create clear, distinct triggers. | 3 / 3 |
Total | 9 / 12 Passed |
Implementation
27%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is a comprehensive but excessively verbose document that reads more like an internal design specification than an actionable skill for Claude. Its main strengths are thorough coverage of all modes and their dependencies, plus concrete tool call examples. However, it severely suffers from poor token efficiency — the legacy file lists, detailed bash fallback scripts, and exhaustive team shutdown protocols should be split into referenced files, and the overall content could be reduced by 50-60% while preserving all actionable information.
Suggestions
Extract the legacy compatibility file list, bash fallback script, and team shutdown protocol into separate referenced files (e.g., LEGACY_FILES.md, FALLBACK.sh, TEAM_SHUTDOWN.md) to dramatically reduce the main skill's token footprint.
Condense the main SKILL.md to a concise overview: detection flow, dependency order, tool calls for each mode (one line each), and pointers to detailed references.
Add explicit validation checkpoints after each state_clear call (e.g., 'Verify mode is no longer listed by state_list_active before proceeding to next mode') to improve workflow reliability.
Remove descriptive/explanatory text that Claude doesn't need (e.g., 'Teams are detected by checking for config files in...') and replace with direct instructions ('Check ${CLAUDE_CONFIG_DIR:-~/.claude}/teams/*/config.json').
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~350+ lines. Includes exhaustive lists of legacy files, detailed bash fallback scripts, lengthy team shutdown protocols, and implementation details that could be in separate reference files. Much of this (e.g., the full legacy compatibility list, the orphan detection script details, the two-pass team cancellation protocol) bloats the skill far beyond what's needed for Claude to execute the cancel command. | 1 / 3 |
Actionability | Provides concrete tool calls (state_clear, state_read, state_list_active) and executable bash fallback code, but much of the guidance is descriptive rather than directly executable. The implementation steps mix pseudocode-style descriptions with actual commands, and the team cancellation protocol reads more like a design doc than actionable instructions. | 2 / 3 |
Workflow Clarity | The dependency order is clearly documented (autopilot → ralph → ultrawork, etc.) and the multi-step team cancellation has explicit sequencing with timeouts. However, validation checkpoints are largely missing — there's no explicit 'verify cancellation succeeded' step after each state_clear call, and error recovery is mentioned only briefly (retry with --force or wait for staleness timeout) without structured feedback loops. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of text with no references to external files despite having extensive content that should be split out (e.g., the full legacy file list, the bash fallback script, the team shutdown protocol, the MCP worker cleanup details). Everything is inlined into a single massive document with no bundle files to support it. | 1 / 3 |
Total | 6 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
- Repository
- Yeachan-Heo/oh-my-claudecode
- Commit
679b418
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.