plugin-router
Analyze broad, mixed, or unclear Plugin Factory follow-up requests and select the correct plugin lane. Use when plugin intent lacks a clear lane owner.
55
62%
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 ./Plugins/plugin-factory/skills/team_automation/plugin-router/SKILL.mdQuality
Discovery
75%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 well-structured with both a 'what' and an explicit 'when' clause, and it occupies a clear niche as a routing/triage skill for ambiguous plugin requests. However, it is somewhat vague on the specific concrete actions it performs beyond 'analyze and select,' and the trigger terms lean heavily on internal jargon rather than natural user language.
Suggestions
Add more specific concrete actions, e.g., 'Classifies ambiguous requests, disambiguates overlapping plugin intents, and routes to the appropriate lane (create, edit, debug, etc.)'
Include more natural trigger terms or synonyms a user might use, such as 'unclear plugin request', 'not sure which plugin', 'mixed plugin needs', or 'route plugin request'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | It names a domain ('Plugin Factory follow-up requests') and describes a general action ('analyze and select the correct plugin lane'), but does not list multiple specific concrete actions—it's essentially one action (routing/triage) described at a moderate level of detail. | 2 / 3 |
Completeness | It clearly answers both 'what does this do' (analyze mixed/unclear requests and select the correct plugin lane) and 'when should Claude use it' ('Use when plugin intent lacks a clear lane owner'), with an explicit trigger clause. | 3 / 3 |
Trigger Term Quality | It includes some relevant terms like 'Plugin Factory', 'follow-up requests', 'plugin lane', and 'plugin intent', but these are fairly domain-specific jargon. It lacks natural user-facing trigger terms a user might actually say (e.g., 'which plugin', 'route my request', 'unclear plugin type'). | 2 / 3 |
Distinctiveness Conflict Risk | The description carves out a clear niche as a triage/routing skill for ambiguous Plugin Factory requests, which is distinct from skills that handle specific plugin lanes. The qualifier 'lacks a clear lane owner' makes it unlikely to conflict with lane-specific skills. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
50%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 routing helper that clearly defines its scope, boundaries, and failure modes, which is valuable. However, it delegates nearly all actionable routing logic to an external workflow.md file that isn't provided, leaving the skill itself as mostly a framing document rather than an executable guide. The output schema is described but not shown as a concrete example, and the routing decision process lacks an inline decision tree or flowchart.
Suggestions
Include an inline decision tree or abbreviated routing table showing how request signals map to lanes, rather than deferring 100% of the routing logic to references/workflow.md.
Provide a concrete example of the routing handoff output object (JSON) with all fields populated, so Claude knows exactly what to produce.
Consolidate the 'Read when' block and the flat 'References' list at the bottom into a single well-signaled reference section to avoid duplication.
Trim the 'Philosophy' and 'When to Use' sections which partially repeat the introductory paragraph and each other.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is moderately efficient but includes some unnecessary philosophical framing ('Route first, execute second'), redundant explanations of what the router does vs. doesn't do, and sections like 'When to Use' that partially overlap with the intro paragraph. Some tightening is possible. | 2 / 3 |
Actionability | The skill provides a structured output schema (routing handoff object fields) and examples of input-to-lane mappings, but the actual routing logic is deferred entirely to 'references/workflow.md'. The examples are illustrative but not executable—there's no concrete code, command, or decision tree to follow directly from this file. | 2 / 3 |
Workflow Clarity | The workflow section simply says 'Use the detailed routing protocol in references/workflow.md' without providing the actual steps. While failure modes and anti-patterns add some guardrails, the core multi-step routing process is absent from this file, and there are no explicit validation checkpoints within the routing workflow itself (only a bash validation script at the end). | 2 / 3 |
Progressive Disclosure | References are listed and some are inline-linked with context ('Read when:' section is well done), but bundle files were not provided so we can't verify the references exist. The deeply nested relative paths (../../../../../) are a concern, and the References section at the bottom is a flat list without clear signaling of what each file contains, unlike the better-organized 'Read when' block above it. | 2 / 3 |
Total | 8 / 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 |
|---|---|---|
metadata_version | 'metadata.version' is missing | Warning |
Total | 10 / 11 Passed | |
- Repository
- jscraik/Agent-Skills
- Commit
4c78f98
- 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.