cancel
Cancel any active OMC mode (autopilot, ralph, ultrawork, ultraqa, swarm, ultrapilot, pipeline, team)
47
49%
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
72%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 concise and clearly communicates a single specific action (canceling OMC modes) with good enumeration of the relevant mode names, providing strong trigger terms. Its main weakness is the lack of an explicit 'Use when...' clause, which limits completeness, and it only describes one action rather than a broader set of capabilities.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user wants to stop, cancel, exit, or turn off any active OMC mode.'
Include common synonyms users might say such as 'stop', 'exit', 'disable', 'turn off', or 'end' to improve trigger term coverage for the cancel action.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names a specific action ('Cancel') and lists specific modes by name, but it only describes one action rather than multiple concrete capabilities. It's more specific than vague but not comprehensive. | 2 / 3 |
Completeness | The 'what' is clear (cancel active OMC modes), but there is no explicit 'Use when...' clause or equivalent trigger guidance. The when is only implied by the action itself. | 2 / 3 |
Trigger Term Quality | Includes strong natural trigger terms users would say: 'cancel', 'autopilot', 'ralph', 'ultrawork', 'ultraqa', 'swarm', 'ultrapilot', 'pipeline', 'team', and 'OMC mode'. Users wanting to stop these modes would naturally use these exact terms. | 3 / 3 |
Distinctiveness Conflict Risk | This is a very specific niche — canceling named OMC modes. The enumerated mode names (autopilot, ralph, ultrawork, etc.) make it highly distinctive and unlikely to conflict with other skills. | 3 / 3 |
Total | 10 / 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 comprehensive in coverage but severely over-engineered for a SKILL.md body. It contains implementation-level detail (full bash fallback scripts, legacy file lists, team two-pass protocols, orphan detection) that should be in separate reference files, resulting in a token-heavy document that buries the core cancel workflow. The content would benefit greatly from splitting into a concise overview with references to detailed implementation files.
Suggestions
Extract the bash fallback script, legacy compatibility file list, team cancellation protocol, and MCP worker cleanup into separate reference files (e.g., FALLBACK.md, LEGACY-FILES.md, TEAM-CANCEL.md) and link to them from the main SKILL.md.
Reduce the main SKILL.md to ~80 lines covering: usage, auto-detection summary, dependency order, force mode summary, and links to detailed docs.
Add explicit validation checkpoints after cancellation steps, e.g., 'After state_clear, call state_get_status to confirm mode is no longer active; if still active, retry or escalate to --force.'
Remove the full legacy compatibility file list from the body — this is implementation detail that changes over time and belongs in a separate reference or generated dynamically.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~350+ lines. Includes extensive implementation details (team two-pass cancellation protocol, orphan detection, full bash fallback scripts, legacy compatibility file lists) that could be in separate reference files. Much of this is internal implementation detail that bloats the context window significantly. | 1 / 3 |
Actionability | Contains concrete code snippets (bash fallback, ToolSearch query, state_clear calls) and specific commands, but much of the guidance is procedural description rather than directly executable code. The team cancellation protocol is described narratively rather than as executable steps, and the skill mixes LLM-executed logic with bash scripts in a way that's sometimes ambiguous. | 2 / 3 |
Workflow Clarity | The dependency order is clearly documented (autopilot → ralph → ultrawork, etc.) and the team cancellation has a detailed two-pass protocol with timeouts. However, validation checkpoints are largely absent — there's no explicit 'verify cancellation succeeded' step after each state_clear call, and the error recovery path (retry with --force, or wait for 2-hour timeout) is mentioned only briefly at the top rather than integrated into the workflow. | 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., legacy compatibility list, team cancellation protocol, bash fallback script, MCP worker cleanup). Everything is inlined into a single massive SKILL.md 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
3e94567
- 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.