find-skills
Not for building skills — for finding them. Use when the intent is to discover, search, or inventory what agent skills already exist for a topic. The user wants to know "what's out there for X" rather than "make me something." Triggers on: "find a skill for X", "skill search: X", "what skills exist for X", "discover skills for X", "is there already a skill for X", "before I build this, has someone done it?", or any pre-build audit. Also trigger proactively before any skill-creator session when the user hasn't searched yet — finding what exists prevents duplicate effort. Output is a ranked table plus a thematic synthesis document, never a new skill.
- License 许可
- MIT
- 最近更新
- 2026-11-11
- Stars
- ★ 0
- Forks
- 0
01 前言 Front Matter
- name
- find-skills
- description
- Not for building skills — for finding them. Use when the intent is to discover, search, or inventory what agent skills already exist for a topic. The user wants to know "what's out there for X" rather than "make me something." Triggers on: "find a skill for X", "skill search: X", "what skills exist for X", "discover skills for X", "is there already a skill for X", "before I build this, has someone done it?", or any pre-build audit. Also trigger proactively before any skill-creator session when the user hasn't searched yet — finding what exists prevents duplicate effort. Output is a ranked table plus a thematic synthesis document, never a new skill.
03 SKILL.md 正文
Find Skills
You've been asked to find existing skills relevant to a description. Search the sources below in order, rank by relevance and quality, produce a discovery document, then hand off to skill-creator on confirmation.
Sources
Work through these in order — earlier sources carry richer quality signals:
| # | Source | How |
|---|---|---|
| 1 | skills.sh (SkillsMP) | Fetch https://skills.sh/ and search the leaderboard; this is the primary marketplace with install counts |
| 2 | Skills CLI | Run bunx skills find {keywords} (fall back to npx skills find {keywords} if Bun isn't available) |
| 3 | GitHub code search | WebSearch for site:github.com filename:SKILL.md {keywords} — finds skills not yet in the marketplace |
| 4 | GitHub collections | WebSearch known skill collections: ComposioHQ/awesome-claude-skills, vercel-labs/agent-skills, xixu-me/skills, openai/skills |
| 5 | Local | Scan installed skills in ~/.claude/skills/, .claude/skills/, and the project's skills/ directory |
From each skill found, extract:
- name — skill identifier from frontmatter
- author — publisher, GitHub org, or username
- url — skills.sh page or direct link to SKILL.md
- installs — from skills.sh if available, otherwise N/A
- description — one sentence from frontmatter
description:field
Quality signals
Use these to rank, not to hard-exclude:
- Install count — prefer 1K+; flag anything under 100 as low-confidence
- Publisher reputation — known publishers (vercel-labs, anthropics, openai, microsoft, xixu-me) rank higher
- Repository quality — check GitHub stars; treat skills from repos with <100 stars with skepticism
A niche but highly relevant skill from a small repo beats a popular but off-topic one.
Ranking
Score each candidate against the user's description. Weight:
- Relevance to the task domain (highest weight)
- Quality signals above
- Breadth — broader coverage is more reusable
Pick the top 10. If fewer than 10 exist, include all.
Output
1. Write the discovery document
Write to ./docs/skill-discovery.md (create ./docs/ if needed):
# Skill Discovery: {user's description}
_Sources: skills.sh · Skills CLI · GitHub code search · GitHub collections · Local_
_Add comments anywhere in this file, then reply "build it" to proceed._
---
## Top 10 Relevant Skills
| # | Skill | Author | Source | Installs | Description |
|---|-------|--------|--------|----------|-------------|
| 1 | [skill-name](url) | Author | skills.sh / GitHub / Local | 12K / N/A | One sentence |
...
---
## Synthesis
[3–5 thematic paragraphs in the style of a literature review. Group skills by what they
emphasise rather than listing them one by one. Note variation in approach, scope, or
workflow philosophy across the set. Write in flowing prose — no sub-headers, no bullets,
no gaps or recommendation section. The goal is a readable overview of the landscape.]
---
## Your notes
<!-- Add comments here, or inline above any row in the table -->
_Nothing yet._
2. Tell the user
- Confirm the file was saved
- Name the top 3 picks with one sentence each in the conversation
- Say: "Full table and synthesis in
./docs/skill-discovery.md— add notes directly there, then reply build it to hand off to skill-creator."
On confirmation
When the user replies "build it" (or equivalent):
- Re-read
./docs/skill-discovery.mdto pick up any notes they added - Build a skill-creator prompt from:
- The original description
- Patterns and approaches from the synthesis worth borrowing
- Specific techniques to adopt, with source URLs
- Any user notes from the document
Handoff prompt structure:
Build a skill for: {description}
Patterns worth borrowing from existing skills:
- {pattern} — from [{skill-name}]({url})
User notes: {anything from the discovery document}
- Invoke
/skill-creatorwith that prompt.
What not to do
- Don't skip skills.sh — install counts are the strongest signal of real-world adoption.
- Don't run
bunx skills add— this skill only discovers; the user decides what to install. - Don't fabricate URLs — if a URL can't be confirmed, mark it
(unverified). - Don't make the synthesis a disguised bullet list or a rehash of the table — it should surface patterns that only emerge when you read the skills as a set.
04 同仓库更多 Skills
vault-recall
Answer the user's conceptual or technical question using their Obsidian vault as well as general knowledge. Use when the user asks a question (not a task) whose topic appears in the vault MOC digest from session start. Not for task instructions, not mid-task, and not for writing to the vault (that is to-vault).
ingest
Ingest one external source (an article, course lesson, doc, PDF or URL) into the user's Obsidian vault: save the original to raw/, then build wiki/ pages per the vault's § Ingest. Use when the user types /ingest, or says "ingest this", "add this source to my wiki", "put this article/lesson in the vault as a wiki page". Works from any repo. Routing rule: someone else's words go to wiki/ (this skill); the user's own learnings and decisions go to notes/ (/to-vault).
to-tickets
Breaks a source into independently-grabbable GitHub tickets. For a code feature the source is the plan (`docs/plans/<feature>.md`, from /to-plan) and every new or changed symbol lands in exactly one ticket, its signatures copied into the ticket body; a non-code feature is cut from the PRD's slices. Cuts tickets for one feature per run. If a code feature has no approved plan, offers /to-plan instead of cutting from prose. In a repo that runs command-centre, also emits `[[task]]` blocks into its config; in a plain treepad repo, emits a Batch Manifest instead so the tickets materialise as stacked worktrees.
to-seams
Records an agreed-but-unlanded cross-repo interface as a seam: the file a consumer's agent gets pasted into its prompt as ground truth, plus the `[[seam]]` block command-centre reads for the retirement pointer. Use when two repos need to build against an interface neither has landed yet — "record a seam for X", "we agreed on this schema, seam it", "add a seam so Y can build against Z's new field". Halts for approval before writing either file.
to-roadmap
Prioritises settled features into a Now / Next / Later kanban board, rendered as a self-contained ./ideas/roadmap.html. Each card is a feature, not a ticket — one card later becomes several tickets via /to-prd -> /to-plan -> /to-tickets. Boards the features in ./docs/approach.md, or the "## Accepted ideas" in ./ideas/CONTEXT.md when there is no approach doc. The approach doc is settled truth: this assigns tiers and reasons about ordering, it never re-litigates what was decided.
to-prd
Turns one feature idea into a PRD built on journeys: a one-line problem, journeys (each ending in an observable state) and delivery slices that say what is usable after each. Interviews, explores the codebase, and saves to docs/prds/<feature>.md. Covers exactly one feature: given a multi-feature source, ask which one. Reads any approach doc or ideate report as priors so it doesn't re-ask what's settled, but needs none. Starts the per-feature spine (/to-prd -> /to-plan -> /to-tickets).