AGENT SKILL

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:

  1. Relevance to the task domain (highest weight)
  2. Quality signals above
  3. 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):

  1. Re-read ./docs/skill-discovery.md to pick up any notes they added
  2. 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}
  1. Invoke /skill-creator with 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

O-Marsters-1997
O-Marsters-1997/my-claude-code

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).

★ 0
O-Marsters-1997
O-Marsters-1997/my-claude-code

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).

★ 0
O-Marsters-1997
O-Marsters-1997/my-claude-code

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.

★ 0
O-Marsters-1997
O-Marsters-1997/my-claude-code

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.

Skill与智能体开发
★ 0
O-Marsters-1997
O-Marsters-1997/my-claude-code

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.

产品经理
★ 0
O-Marsters-1997
O-Marsters-1997/my-claude-code

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).

产品经理
★ 0