omc-teams
CLI-team runtime for claude, codex, or gemini workers in tmux panes when you need process-based parallel execution
58
67%
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/omc-teams/SKILL.mdQuality
Discovery
57%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 identifies a clear and distinctive niche (orchestrating AI CLI workers in tmux for parallel execution) but lacks specificity about concrete actions and comprehensive trigger terms. The 'when' clause exists but is informal and uses second person voice, and the description would benefit from listing specific capabilities and more natural user trigger phrases.
Suggestions
Add specific concrete actions like 'Spawns, monitors, and coordinates multiple AI CLI workers across tmux panes, collects results, and manages worker lifecycle'.
Restructure with an explicit 'Use when...' clause containing natural trigger terms: 'Use when the user wants to run tasks in parallel, fan out work across multiple agents, orchestrate concurrent Claude/Codex/Gemini processes, or manage multi-agent workflows'.
Switch from second person ('when you need') to third person voice ('Provides process-based parallel execution') to match style guidelines.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (CLI-team runtime, tmux panes, parallel execution) and mentions specific tools (claude, codex, gemini workers), but doesn't list concrete actions like 'spawn workers', 'manage panes', 'collect results', etc. | 2 / 3 |
Completeness | The 'what' is partially addressed (runtime for CLI workers in tmux panes) and there's a partial 'when' clause ('when you need process-based parallel execution'), but it uses second person ('you need') and the trigger guidance is not explicit enough with a proper 'Use when...' structure. | 2 / 3 |
Trigger Term Quality | Includes some relevant keywords like 'tmux', 'parallel execution', 'claude', 'codex', 'gemini', and 'workers', but misses common user phrasings like 'run in parallel', 'multiple agents', 'concurrent tasks', 'fan out', or 'multi-agent'. | 2 / 3 |
Distinctiveness Conflict Risk | The combination of CLI-team runtime, tmux panes, and specific AI worker tools (claude, codex, gemini) creates a very distinct niche that is unlikely to conflict with other skills. | 3 / 3 |
Total | 9 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured, highly actionable skill with clear phased workflows and concrete CLI commands throughout. Its main weakness is verbosity in certain sections (particularly Phase 0 and Phase 2.5) and the monolithic structure that could benefit from splitting detailed edge-case handling into separate reference files. The error reference table and comparison table with `/team` are excellent additions that add value efficiently.
Suggestions
Consider extracting Phase 2.5 (multi-repo workspace resolution) into a separate reference file, as it's a detailed edge case that adds significant length to the main workflow.
Condense Phase 0 prerequisite checks—the four conditional branches (TMUX set, CMUX_SURFACE_ID set, neither set, both missing) could be presented as a compact decision table rather than verbose bullet points.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient but includes some sections that could be tightened. Phase 2.5 (multi-repo workspace resolution) is quite verbose with extensive bullet points that could be condensed. The Phase 0 prerequisite checks also over-explain the tmux/cmux detection logic with repetitive conditional descriptions. However, it avoids explaining basic concepts Claude already knows. | 2 / 3 |
Actionability | The skill provides concrete, executable bash commands throughout every phase—from prerequisite checks (`command -v tmux`), to launching (`omc team <N>:<agent> "<task>"`), monitoring (`omc team status`), verification (`tmux capture-pane`), and shutdown. Examples are copy-paste ready with clear parameter substitution patterns. | 3 / 3 |
Workflow Clarity | The workflow is clearly sequenced across 7 phases (0-6) with explicit validation checkpoints: Phase 0 verifies prerequisites before proceeding, Phase 1 validates input before decomposition, Phase 3 includes post-launch verification of pane output, and Phase 5 recommends non-force shutdown before force. The feedback loop of checking pane output after launch is a strong validation step for this type of process-spawning operation. | 3 / 3 |
Progressive Disclosure | The content is well-structured with clear sections and tables, but it's a long monolithic document (~180 lines) with no references to external files for detailed content like the multi-repo workspace resolution logic or the full API reference. Phase 2.5 and the detailed tmux/cmux detection logic could be split into separate reference files. No bundle files are provided to support progressive disclosure. | 2 / 3 |
Total | 10 / 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.