エージェントのCLI/モデルをライブ切替するスキル。settings.yaml更新→/exit→新CLI起動→ pane metadata更新を一発で実行。Thinking有無も制御。 「モデル切替」「Sonnetにして」「Opusに変えて」「足軽全員切替」「Thinking切って」で起動。
84
82%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a strong skill description that concisely communicates a specific multi-step workflow (settings update → exit → restart → metadata update) with excellent natural trigger terms in Japanese. It clearly defines both what the skill does and when to invoke it, with domain-specific terminology that minimizes conflict risk. The description uses third-person voice appropriately and avoids vague language.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: settings.yaml更新, /exit, 新CLI起動, pane metadata更新, and Thinking有無制御. These are clearly defined steps in a pipeline. | 3 / 3 |
Completeness | Clearly answers both 'what' (live-switch agent CLI/model via settings.yaml update, exit, restart, pane metadata update, thinking control) and 'when' (explicit trigger phrases like 「モデル切替」「Sonnetにして」etc.). The trigger guidance is explicit. | 3 / 3 |
Trigger Term Quality | Includes excellent natural trigger terms that users would actually say: 「モデル切替」「Sonnetにして」「Opusに変えて」「足軽全員切替」「Thinking切って」. These cover model switching, specific model names, bulk switching, and thinking toggle — all natural user phrases. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive — targets a very specific niche of live-switching agent CLI/models with tmux pane metadata updates. The trigger terms reference specific model names (Sonnet, Opus) and domain-specific concepts (足軽, pane metadata) making conflicts with other skills unlikely. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
64%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides highly actionable, concrete bash commands for model switching across multiple scenarios, which is its greatest strength. However, it's somewhat verbose with internal implementation details and architecture diagrams that could be externalized or trimmed. The lack of explicit verification steps after switching (e.g., confirming the new CLI is running) is a notable gap given the destructive potential mentioned in Constraints.
Suggestions
Add a verification step after switch_cli.sh execution, e.g., checking pane metadata or capturing CLI output to confirm the switch succeeded.
Move the 'What switch_cli.sh Does (internal)' section and Architecture diagram to a separate INTERNALS.md file, keeping SKILL.md focused on usage.
Add error handling guidance: what to do if the switch fails, the pane doesn't return to shell prompt, or the new CLI doesn't start.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is mostly efficient but includes some sections that could be tightened - the Architecture ASCII diagram, the full internal workings section ('What switch_cli.sh Does'), and the Display Name Mapping table add bulk that may not be necessary for execution. The core actionable content (Instructions section) is well-written, but the overall document is verbose for what is essentially a wrapper around a shell script. | 2 / 3 |
Actionability | Excellent concrete, copy-paste ready bash commands for every scenario: single switch, bulk switch, thinking control, and inbox-based switching. The examples cover real use cases with specific agent IDs, model names, and flags. | 3 / 3 |
Workflow Clarity | The Thinking control section has a clear 3-step workflow, and the internal steps of switch_cli.sh are well-documented. However, there are no explicit validation/verification steps after switching - no way to confirm the switch succeeded, check the new model is running, or handle failures. For a potentially destructive operation (data loss warning in Constraints), this is a gap. | 2 / 3 |
Progressive Disclosure | The content is structured with clear sections and a Files table pointing to related scripts, but the 'What switch_cli.sh Does (internal)' section is detailed implementation info that could be in a separate file. The Architecture diagram and Display Name Mapping could also be externalized. Everything is inline in one document when some content would benefit from separation. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
3dafe0a
Table of Contents
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.