Skill Hunter

Overview

Analyze the repo and user goals to assemble a minimal, justified skill stack. Prefer official sources, inspect every candidate, and install only after user confirmation.

Trigger phrases (use this skill when you hear)

• "Find new skills for this project"
• "Recommend external skills for [technology/domain]"
• "Which skills apply here?"
• "Compare external skills to what we have"
• "Are there better skills than what I have?"
• "What external skills exist for [X]?"
• "Help me find skills for [task]"

Non-triggers (do not use this skill)

• "Which local skills should I use?"
• "How do I use these installed skills?"
• "Explain what this installed skill does"
• Requests limited to already-installed/local skills with no external discovery

Required inputs (confirm before external search)

• Goals and priority tasks
• Trust policy / tiers to target (official-only vs allow maintained vs allow community)
• Category focus (pick any; default to "all categories" if not specified)

If any required input is missing, ask for it and stop. Do not list candidates or recommendations until the user answers or explicitly waives questions.

Internal checks (do not ask the user unless blocked)

• Determine whether external browsing is available and allowed from the client config/tooling.
• If the client exposes a web/browse tool and there is no explicit “do not browse” instruction, treat browsing as granted and proceed without asking.
• Only ask the user about browsing if the client clearly indicates browsing is disabled or permission is explicitly denied.
• If npx skills is available, use it as the primary skills.sh discovery path.

Workflow

Progress tracker (copy into your response and update as you go):

• Dossier: scanned project, identified stack and goals
• Questions: user answered or explicitly waived
• Discovery: searched required sources (skills.sh ☐ Context7 ☐ GitHub ☐)
• Inspection: read SKILL.md for 3+ candidates
• Overlap: capability matrix complete
• Recommendation: stack presented with confidence ratings
• Install: user confirmed, skills installed
• Verify: all skills load correctly

1) Build a project dossier

• Confirm project root; ask if unclear.
• Read: dependency manifests (package.json, pyproject.toml, requirements*, go.mod, Cargo.toml, pom.xml), README*, and AGENTS.md.
• Scan for existing installed skills (overlap awareness).
• If goals or constraints are still unclear after the above, also read: docs/, CHANGELOG*, CI configs, Makefile, infra/IaC files.
• Summarize: domain, stack, critical workflows, tools, constraints, and risks.

2) Ask clarifying questions (required)

• Ask clarifying questions before any external search.
• Do not ask which agent is in use; assume the current client.
• Proceed to Step 3 only after answers or an explicit user waiver such as “skip questions, assume defaults.”
• Do not treat “obvious” goals as a waiver; the waiver must be explicit.
• If the user waives questions, record the assumptions and state them in your response.
• Ask questions in multiple‑choice, multi‑select format with an Other option for custom text. Provide defaults based on the project dossier and allow “use defaults” as a one‑line answer.
  • Goals (pick any): Reliability/quality, UX/design, Integrations, Automation, Documentation, Performance, Other: ___
  • Trust tiers (pick any): Official‑only, Maintained, Community, Other: ___
  • Categories (pick any):
    • Product, UX & Content (frameworks, UI/a11y, design, SEO, copywriting)
    • DevOps & Delivery (deploy, CI/CD, hosting, environment setup)
    • Integrations & SaaS APIs (payments, CRM, auth, analytics)
    • Data & Documents (ETL, DBs, CSV/XLSX/PDF/DOCX/PPTX)
    • Quality & Safety (testing, debugging, security, performance, reliability)
    • Tooling & Automation (browser use, scraping, agent tools, workflow automation)
    • Planning & Orchestration (planning, strategy, task management, logging, subagents)
    • Other (user-defined): ___
• Do not present candidate lists or recommendations in this step.

3) Discover candidate skills (evidence-based)

• Do not browse until required inputs are confirmed.
• If browsing is disabled or the client has no external search capability, skip external search and limit discovery to local skills; state the limitation clearly and stop.
• Search skill registries and sources using the client’s external search/browse capability (if available).
• If permission is granted and capability exists, you must perform external discovery and include a concise search log in the response.

Search targets:

• skills.sh via npx skills find <query> — outputs results directly in non-interactive environments; use freely.
• Context7 registry via CLI search (see CLI guidance below).
• GitHub search: SKILL.md in:path <technology> — use as a fallback when registries return fewer than 2 candidates for a category, or for niche/specialized technologies.
• Optional: Skills Directory for curated, quality-reviewed skills.
• Optional: official vendor .well-known/skills endpoints (if the project vendor publishes them).

Prioritize skills.sh and Context7 via their official tools. Prefer official/trusted sources: skills created/maintained by the tool or company that owns the tech in the codebase. If a registry is unavailable, say so and fall back to GitHub search or the vendor's official docs.

Hard gates:

• skills.sh must be searched via npx skills find <query>.
• Context7 must be attempted via ctx7 skills suggest and/or ctx7 skills search.
• GitHub search should be used when registries return fewer than 2 candidates for a category, or when the technology is niche/specialized.
• If a source is unavailable, log the failure, mark it unavailable in the search summary, and proceed.
• Block only if all sources fail or if required sources were skipped without a stated reason.
• For each source, open at least one relevant skill detail page or repo entry (or explicitly state none were relevant).

Context7 CLI guidance:

• Context7 CLI commands (ctx7 skills search, ctx7 skills suggest) print results before showing an interactive selection prompt. Wrap them with timeout 10 to capture results without hanging: timeout 10 npx -y ctx7 skills suggest or timeout 10 npx -y ctx7 skills search "<query>". A timeout exit code (124) is expected; the results are in the captured output.
• If the project has dependency files (package.json, requirements.txt, pyproject.toml), run ctx7 skills suggest first to get dependency-aware recommendations. Record the output and use it to supplement keyword searches.
• Then run ctx7 skills search "<query>" for targeted category keywords.
• Do not attempt to interact with ctx7 selection prompts. Use the printed results as evidence and install separately via npx skills add or ctx7 skills install with explicit arguments.
• Context7 results include install counts and trust scores (0–10); use these as additional signals during inspection (Step 4).

Search matrix:

• Run ctx7 skills suggest once (covers all categories via dependency analysis).
• For each selected category, run at least one npx skills find <query>. Batch related categories into a single broad query where possible (e.g., "testing security" covers Quality & Safety).
• Use GitHub search for gaps — categories where registries returned fewer than 2 candidates.
• Default budget: 1 query per category for skills.sh, 1 suggest + 1–2 targeted searches for Context7, GitHub only as needed.
• Reuse the same query terms across sources when possible to keep coverage consistent.
• If a candidate is not discoverable via npx skills find, verify it with npx skills add <repo> --list before treating it as installable via Skills CLI.

Search tips:

• Use specific keywords (e.g., "react testing" beats "testing").
• Try sy