Find Skills Combo

Find Skills Combo

Discover and install skill combinations from the open agent skills ecosystem. Unlike single-skill search, this skill decomposes complex tasks into subtasks, searches for candidates per subtask, evaluates coverage, and recommends two strategies: Maximum Quality (best skill per subtask, highest output quality) and Minimum Dependencies (fewest installs, lean setup). Users pick the strategy that fits their priorities.

When to Use This Skill

Use this skill when the user:

• Asks "how do I do X" where X involves multiple capabilities or domains
• Says "find a skill for X" or "is there a skill for X"
• Describes a task that spans several concerns (e.g., "build a quarterly report with charts, risk analysis, and executive summary")
• Wants to compose a workflow from multiple skills
• Asks "can you do X" where X is a complex, multi-step task
• Expresses interest in extending agent capabilities for a non-trivial project

Fallback: If the task is genuinely single-domain and simple (one clear capability), skip the decomposition — run a single npx skills find query, present results, and offer to install. Don't over-engineer simple requests.

What is the Skills CLI?

The Skills CLI (npx skills) is the package manager for the open agent skills ecosystem.

Key commands:

• npx skills find [query] — Search for skills by keyword
• npx skills add <package> — Install a skill from GitHub or other sources
• npx skills add <package> -g -y — Install globally, skip confirmation
• npx skills check — Check for skill updates
• npx skills update — Update all installed skills

Browse skills at: https://skills.sh/

The 5-Phase Pipeline

For complex tasks, follow all five phases in order. For simple tasks, see the Fallback section above.

Phase 1: Task Decomposition

Break the user's request into independent subtasks. Each subtask represents a distinct capability needed to complete the overall task.

Step 1: Extract Task-Specific Constraints

Before decomposing, scan the user's request for task-specific constraints — these are requirements that narrow the problem space and must be preserved in the subtasks. Look for:

• Domain-specific terminology: Jargon, proper nouns, named standards, or specialized vocabulary the user explicitly uses (e.g., "WCAG 2.1 AA compliance", "GAAP reporting", "OpenAPI 3.1 spec"). These terms signal that generic skills won't suffice — the subtask must target this exact domain.
• Scenario constraints: Environmental or contextual restrictions (e.g., "offline-only", "must run in CI", "single-page app with no backend", "monorepo with pnpm workspaces"). These filter out skills that technically do the right thing but in the wrong context.
• Format / output requirements: Specific file formats, templates, or delivery formats (e.g., "output as PDF", "Helm chart", "Jupyter notebook", "Markdown with Mermaid diagrams").
• Toolchain lock-ins: Explicit technology choices the user has already committed to (e.g., "using Svelte, not React", "PostgreSQL only", "must integrate with our existing FastAPI backend").

Collect these into a Constraints List — a flat list of non-negotiable requirements extracted verbatim (or near-verbatim) from the user's request. Every subtask you create must trace back to at least one constraint, and no constraint should be orphaned.

Step 2: Decompose into Subtasks

1. Read the user's request carefully. Identify every distinct outcome or deliverable they need.
2. Group related outcomes into subtasks. Each subtask should be a "capability unit" — something one skill could plausibly handle.
3. Write a short completion criterion for each subtask so you know what "covered" means later.
4. Attach relevant constraints from the Constraints List to each subtask. A subtask without any attached constraint is likely too generic — refine it. A constraint not attached to any subtask is a gap — either create a subtask for it or fold it into an existing one.

Constraints:

• Aim for 2–7 subtasks. Fewer than 2 means the task is simple — use the fallback. More than 7 means you're splitting too fine — merge related items.
• Each subtask needs a clear boundary. If two subtasks always require the same skill, merge them.
• Preserve the user's own words: When a subtask maps to a domain-specific term the user used, keep that term in the subtask description and completion criteria — don't paraphrase it into a generic synonym. This ensures Phase 2 keyword generation stays precise.

Output format (present this to the user for confirmation):

Constraints List:

• C1: [verbatim constraint from user]
• C2: [verbatim constraint from user]
• ...

Before proceeding to Phase 2, briefly show the user the decomposition and constraints list: "I've identified N constraints and broken this into M subtasks — does this look right?" If they want to adjust, iterate. Don't spend too long here — a reasonable decomposition is better than a perfect one.

Phase 2: Precision-Focused Search

For each subtask, the goal is precision over recall — find the skills that most closely match the subtask's specific requirements, not just loosely related ones.

Step 1: Subtask Intent Analysis

Before generating keywords, write a one-sentence intent statement for each subtask that captures:

• The specific action (e.g., "generate", "analyze", "validate", not vague terms like "handle" or "process")
• The domain object (e.g., "Sharpe ratio", "Docker container", "React component")
• The expected output format (e.g., "a chart", "a score", "a config file")
• The attached constraints from Phase 1 — weave the user's domain-specific terms and scenario restrictions directly into the intent statement

This intent statement is the anchor for keyword generation — every keyword group must map back to it. Constraints ensure the intent stays grounded in the user's actual context rather than drifting to generic descriptions.

Step 2: Keyword Generation (Precision-First)

For each subtask, generate 2–3 keyword groups using different precision levels:

• Exact-match keywords: Use the most specific terms from the intent statement — tool names, metric names, framework names, file formats. These find skills purpose-built for the subtask. (e.g., sharpe ratio beta drawdown calculator)
• Functional-match keywords: Describe the capability at one level of abstraction higher — what the skill does rather than what it is. These catch skills that solve the same problem with different terminology. (e.g., portfolio risk analysis metrics)
• Domain-match keywords (only if exact + functional return < 3 results): Broaden to the domain level as a safety net. (e.g., quantitative finance)

Priority rule: Always run exact-match first. Only fall back to broader keywords if the precise search returns too few results (< 3 candidates).

Step 3: Search Execution

1. Build a keyword plan table with precision level annotated:

2. Run all exact-match searches in parallel first:

npx skills find "<exact-match-keywords>"

3. Check result counts. For any subtask with < 3 candidates from exact-match, run the functional-match search. If still < 3, run domain-match.

4. Merge and deduplicate results. For each candidate, record:

   • Which subtask found it
   • Which precision level matched (exact > functional > domain)
   • The skill's self-described purpose (from search output)

Step 4: Relevance Pre-Filter

Before passing candidates to Phase 3, do a quick relevance check per candidate:

1. Re-read the candidate's one-line description from the search output.
2. Compare it against the subtask's intent statement.
3. Keep if the description shares at least one specific term (tool name, metric, framework) with the intent statement, OR if it describes the same functional capability.
4. Drop if the connection is only at the domain level (e.g., a skill about "financial news aggregation" found via domain-match for a "risk metrics" subtask).

Keep the top 3–5 candidates per subtask after filtering. Fewer but more precise candidates produce better evaluations in Phase 3.