jbvc/search-first
Research-before-coding workflow. Search for existing tools, libraries, and patterns before writing custom code. Invokes the researcher agent.
60
60%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Advisory
Suggest reviewing before use
Quality
Discovery
50%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 communicates a clear concept (research before writing code) but lacks explicit trigger guidance ('Use when...'), specific concrete actions beyond searching, and natural user-facing keywords. It reads more like an internal workflow label than a description optimized for skill selection among many options.
Suggestions
Add an explicit 'Use when...' clause with natural trigger phrases like 'Use when the user asks to find existing libraries, check for existing solutions, look up packages, or wants to research before implementing something from scratch.'
Include more natural user keywords and variations such as 'find a package', 'existing solution', 'npm/pip/crate library', 'don't reinvent the wheel', 'look up alternatives'.
Expand the concrete actions beyond just 'search' — e.g., 'Searches package registries, reads documentation, evaluates library fitness, and recommends existing solutions before writing custom implementations.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (research-before-coding) and some actions ('search for existing tools, libraries, and patterns'), but doesn't list multiple concrete specific actions beyond searching. 'Invokes the researcher agent' is an implementation detail rather than a user-facing capability. | 2 / 3 |
Completeness | The 'what' is partially addressed (search for existing tools/libraries/patterns before coding), but there is no explicit 'Use when...' clause. The 'when' is only implied by the workflow description rather than stated as explicit trigger guidance. | 2 / 3 |
Trigger Term Quality | Includes some relevant terms like 'tools', 'libraries', 'patterns', and 'research', but misses common user phrases like 'find a library for', 'is there an existing package', 'look up', 'check if there's already a solution', or 'before I build this'. The term 'researcher agent' is internal jargon. | 2 / 3 |
Distinctiveness Conflict Risk | The concept of 'research-before-coding' is somewhat distinctive, and mentioning the researcher agent helps differentiate it. However, it could overlap with general coding assistance skills or documentation lookup skills since the boundaries aren't sharply defined. | 2 / 3 |
Total | 8 / 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 provides a reasonable conceptual framework for research-before-coding but leans more toward a process description than actionable instructions. The decision matrix and examples are its strongest elements, providing clear guidance on when to adopt vs. build. However, it suffers from including reference material Claude already knows (common tool names), lacks validation checkpoints in the workflow, and the core 'how to actually search' guidance is vague rather than executable.
Suggestions
Replace the 'Search Shortcuts by Category' section with a reference to an external file or remove it entirely — Claude already knows these common tools
Add validation steps to the workflow: e.g., 'Check package health: last publish date, open issues, download count' and 'Test import/basic usage before committing to the dependency'
Make the 'Full Mode' agent invocation use actual tool syntax (e.g., specific MCP calls, actual CLI commands for npm search/pip search) rather than pseudo-syntax
Condense the ASCII workflow diagram into a numbered list to save tokens while preserving the same information
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is moderately efficient but includes some content Claude already knows (e.g., listing common tools like eslint, prettier, pytest is reference material Claude has). The ASCII workflow diagram, while visually appealing, consumes significant tokens for information that could be conveyed more concisely. The 'Search Shortcuts by Category' section is essentially a lookup table Claude doesn't need. | 2 / 3 |
Actionability | The decision matrix and examples provide useful guidance, but the core workflow is more conceptual than executable. The 'Full Mode' agent invocation uses a pseudo-syntax (Task with subagent_type) that isn't clearly tied to a real tool or API. The 'Quick Mode' is essentially 'think about searching' rather than concrete commands. | 2 / 3 |
Workflow Clarity | The 5-step workflow is clearly sequenced and the decision matrix provides good branching logic. However, there are no validation checkpoints — no step to verify the chosen package actually works, no compatibility check, no 'if the package doesn't install correctly' recovery path. For a workflow that results in adding dependencies, validation is important. | 2 / 3 |
Progressive Disclosure | The content is well-structured with clear sections and headers, but it's monolithic — everything is in one file with no references to external files for the detailed category shortcuts or integration patterns. The integration points section and search shortcuts could be split out to keep the main skill lean. | 2 / 3 |
Total | 8 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
Reviewed
Table of Contents