feat(skills): add search-first skill#258
Conversation
📝 WalkthroughWalkthroughA new Markdown file documenting the Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@skills/search-first/SKILL.md`:
- Around line 126-133: Example 1 contradicts the skill's evaluation criteria:
the maintenance dimension (mentioned in the evaluate step) rates
textlint-rule-no-dead-link at 9/10 even though Snyk flags it as Inactive; update
the Example 1 block by either replacing textlint-rule-no-dead-link with a
well-maintained alternative like markdown-link-check (and update the
Search/Found/Action/Result lines to reflect that adoption) or adjust the score
and add a short maintenance rationale for textlint-rule-no-dead-link (e.g.,
lower the maintenance score and note Snyk's inactive status) so the ADOPT
recommendation and scoring are consistent with the evaluate criteria.
- Around line 9-15: Rename the non-standard "## Trigger" heading to "## When to
Use" and ensure there is an explicit "## How It Works" section (you can move or
merge the existing "## How to Use" content under this new "## How It Works"
heading); update any subheading names accordingly so the file contains the three
required top-level sections exactly: "## When to Use", "## How It Works", and
"## Examples" (leave the examples block as-is or create it if missing) and keep
existing content under the new headings to preserve intent.
- Around line 36-54: The DECIDE diagram (the ASCII art block showing "Adopt",
"Extend / Wrap", and "Build Custom") is missing the "Compose" option that
appears in the Decision Matrix; update the ASCII-art DECIDE box to include a
fourth box labeled "Compose" (matching wording used in the Decision Matrix) so
the visual workflow and the table are consistent—edit the ASCII diagram near the
existing "Adopt", "Extend / Wrap", and "Build Custom" boxes to add a "Compose"
box and adjust spacing/alignment accordingly.
| ## Trigger | ||
|
|
||
| Use this skill when: | ||
| - Starting a new feature that likely has existing solutions | ||
| - Adding a dependency or integration | ||
| - The user asks "add X functionality" and you're about to write code | ||
| - Before creating a new utility, helper, or abstraction |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
## Trigger should be renamed ## When to Use
The coding guideline (and repo learning) requires skills to have explicit ## When to Use, ## How It Works, and ## Examples sections. ## Trigger maps to "When to Use" but uses a non-standard heading. Additionally, neither ## Workflow nor ## How to Use is named ## How It Works, so that required section is absent entirely.
✏️ Proposed section renames
-## Trigger
+## When to Use-## Workflow
+## How It WorksThen the separate ## How to Use block (lines 56–80) can be retained as a sub-section or merged under ## How It Works.
As per coding guidelines: "Skills should be formatted as Markdown with clear sections for When to Use, How It Works, and Examples".
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ## Trigger | |
| Use this skill when: | |
| - Starting a new feature that likely has existing solutions | |
| - Adding a dependency or integration | |
| - The user asks "add X functionality" and you're about to write code | |
| - Before creating a new utility, helper, or abstraction | |
| ## When to Use | |
| Use this skill when: | |
| - Starting a new feature that likely has existing solutions | |
| - Adding a dependency or integration | |
| - The user asks "add X functionality" and you're about to write code | |
| - Before creating a new utility, helper, or abstraction |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@skills/search-first/SKILL.md` around lines 9 - 15, Rename the non-standard
"## Trigger" heading to "## When to Use" and ensure there is an explicit "## How
It Works" section (you can move or merge the existing "## How to Use" content
under this new "## How It Works" heading); update any subheading names
accordingly so the file contains the three required top-level sections exactly:
"## When to Use", "## How It Works", and "## Examples" (leave the examples block
as-is or create it if missing) and keep existing content under the new headings
to preserve intent.
| │ ┌─────────┐ ┌──────────┐ ┌─────────┐ │ | ||
| │ │ Adopt │ │ Extend │ │ Build │ │ | ||
| │ │ as-is │ │ /Wrap │ │ Custom │ │ | ||
| │ └─────────┘ └──────────┘ └─────────┘ │ | ||
| ├─────────────────────────────────────────────┤ | ||
| │ 5. IMPLEMENT │ | ||
| │ Install package / Configure MCP / │ | ||
| │ Write minimal custom code │ | ||
| └─────────────────────────────────────────────┘ | ||
| ``` | ||
|
|
||
| ## Decision Matrix | ||
|
|
||
| | Signal | Action | | ||
| |--------|--------| | ||
| | Exact match, well-maintained, MIT/Apache | **Adopt** — install and use directly | | ||
| | Partial match, good foundation | **Extend** — install + write thin wrapper | | ||
| | Multiple weak matches | **Compose** — combine 2-3 small packages | | ||
| | Nothing suitable found | **Build** — write custom, but informed by research | |
There was a problem hiding this comment.
Compose is missing from the DECIDE step in the workflow diagram but present in the Decision Matrix
The ASCII art at step 4 (lines 36–39) shows only three paths — Adopt, Extend/Wrap, and Build Custom — while the Decision Matrix directly below (line 53) introduces a fourth distinct action: Compose. A reader following the diagram alone would never see the compose option.
✏️ Proposed fix — add Compose to the DECIDE box
-│ 4. DECIDE │
-│ ┌─────────┐ ┌──────────┐ ┌─────────┐ │
-│ │ Adopt │ │ Extend │ │ Build │ │
-│ │ as-is │ │ /Wrap │ │ Custom │ │
-│ └─────────┘ └──────────┘ └─────────┘ │
+│ 4. DECIDE │
+│ ┌────────┐ ┌────────┐ ┌─────────┐ ┌────────┐ │
+│ │ Adopt │ │ Extend │ │ Compose │ │ Build │ │
+│ │ as-is │ │ /Wrap │ │ 2-3 pkg │ │ Custom │ │
+│ └────────┘ └────────┘ └─────────┘ └────────┘ │🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@skills/search-first/SKILL.md` around lines 36 - 54, The DECIDE diagram (the
ASCII art block showing "Adopt", "Extend / Wrap", and "Build Custom") is missing
the "Compose" option that appears in the Decision Matrix; update the ASCII-art
DECIDE box to include a fourth box labeled "Compose" (matching wording used in
the Decision Matrix) so the visual workflow and the table are consistent—edit
the ASCII diagram near the existing "Adopt", "Extend / Wrap", and "Build Custom"
boxes to add a "Compose" box and adjust spacing/alignment accordingly.
| ### Example 1: "Add dead link checking" | ||
| ``` | ||
| Need: Check markdown files for broken links | ||
| Search: npm "markdown dead link checker" | ||
| Found: textlint-rule-no-dead-link (score: 9/10) | ||
| Action: ADOPT — npm install textlint-rule-no-dead-link | ||
| Result: Zero custom code, battle-tested solution | ||
| ``` |
There was a problem hiding this comment.
Example 1's score for textlint-rule-no-dead-link contradicts the skill's own evaluation criteria
The skill's evaluate step lists maintenance as a scoring dimension (line 33), but the example rates textlint-rule-no-dead-link at 9/10 despite the package being flagged as inactive by Snyk — Snyk's maintenance analysis determined its status is Inactive, noting it hasn't seen any new versions released to npm in the past 12 months. Using a poorly-maintained package as the flagship "ADOPT" example in a skill intended to teach quality evaluation undermines the lesson. Consider swapping for a well-maintained alternative (e.g., markdown-link-check) or adjusting the score to reflect maintenance accurately.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@skills/search-first/SKILL.md` around lines 126 - 133, Example 1 contradicts
the skill's evaluation criteria: the maintenance dimension (mentioned in the
evaluate step) rates textlint-rule-no-dead-link at 9/10 even though Snyk flags
it as Inactive; update the Example 1 block by either replacing
textlint-rule-no-dead-link with a well-maintained alternative like
markdown-link-check (and update the Search/Found/Action/Result lines to reflect
that adoption) or adjust the score and add a short maintenance rationale for
textlint-rule-no-dead-link (e.g., lower the maintenance score and note Snyk's
inactive status) so the ADOPT recommendation and scoring are consistent with the
evaluate criteria.
1 participant
Summary
Adds a research-before-coding skill that systematizes the workflow of searching for existing tools, libraries, and patterns before writing custom code.
Type
Testing
Checklist
Summary by CodeRabbit