Discover Fusion Skills

When to use

• "find a skill for this"
• "what Fusion skill should I use?"
• "is there a skill for GitHub issue authoring?"
• "how do I install the right Fusion skill?"
• "how do I update or remove installed Fusion skills?"
• "what skills are available for this workflow?"

When not to use

• creating or editing skills in a repository
• doing the underlying task directly instead of helping with discovery
• guessing skill matches when discovery data is unavailable
• automatically installing, updating, or removing skills without the user's request

Required inputs

• the user's goal or query in their own words
• the intended action:

  query

  ,

  install

  ,

  update

  , or

  remove

• the kind of skill the user is looking for: domain, workflow, or desired outcome
• the active agent/client name when install guidance is needed and not already obvious
• any constraints that materially change the recommendation, such as target runtime or repository context

references/follow-up-questions.md

Instructions

• agents/fusion-mcp-advisor.md

  when Fusion MCP is available — this is the primary discovery path

• agents/github-mcp-advisor.md

  when Fusion MCP is unavailable but GitHub MCP search is available

• agents/github-raw-search-advisor.md

  as a final fallback using read-only CLI and GraphQL inspection

1. Detect the user's intent.
   • Treat broad "what skill fits this?" requests as

     query

     .
   • Treat "install/add", "update/check updates", and "remove/uninstall" requests as explicit lifecycle intent.
   • If the request mixes discovery and lifecycle steps, prioritize discovery first, then include the lifecycle guidance that follows from the selected skill.
2. Ask follow-up questions when the target skill is still unclear.
   • If the request is vague, ask a minimal clarifying question about the task, domain, or workflow they want help with.
   • Prefer questions that narrow the search space quickly: what they are trying to do, whether they want to discover, install, update, or remove a skill, and whether they already know a likely area such as GitHub workflow, MCP setup, or skill authoring.
   • Use

     references/follow-up-questions.md

     as the default question bank.
3. Ask for missing agent context only when needed.
   • If the user wants install guidance and the active agent is not clear, ask which agent/client the command should target.
   • Do not ask for agent details for plain discovery requests.
4. Query Fusion MCP first when available.
   • Call

     mcp_fusion_skills

     with the user's wording.
   • Use auto intent detection by default, but set

     intent

     explicitly when the user clearly wants

     install

     ,

     update

     ,

     remove

     , or

     query

     .
   • Pass

     agent

     for install intent when known so the advisory command is directly usable.
   • Start with a small ranked set, usually top 3 to top 5 results.
5. Fall back to GitHub-backed discovery when Fusion MCP is unavailable or too weak.
   • Prefer GitHub MCP repository or search tools when they are available in the current client.
   • Otherwise use read-only shell-based inspection against trusted sources only, such as

     npx skills add --list <source>

     , local

     skills/**/SKILL.md

     searches,

     gh search code

     , or

     gh api graphql

     against the catalog repository.
   • Use GraphQL only when structured repository data is needed and the higher-level MCP or search tools do not expose it cleanly.
   • GraphQL read queries cost at least 1 point; keep

     first

     /

     last

     small (≤ 30) and avoid nested connections to minimize point cost. Do not retry on rate-limit errors; surface the failure and suggest retrying later.
   • Budget awareness: a typical skill-discovery session should need at most 2–3 GitHub API calls (one search + one or two content reads). If the first search returns weak results, do one refinement pass and stop — do not loop.
   • Treat GitHub-derived lifecycle guidance as fallback guidance unless Fusion MCP returned an explicit advisory command.
   • Never use remote-script execution patterns or shell pipelines that execute fetched content.
6. Do one refinement pass when the first result set is weak.
   • Rephrase the query with clearer domain keywords from the user's request.
   • Stop after one refinement pass; do not keep searching indefinitely.
7. Return actionable results.
   • For each recommended skill, include:
     • skill name
     • one-sentence purpose
     • why it matches the user's task
     • the next best action
   • When MCP returns lifecycle guidance, relay the advisory command or instruction exactly, including any placeholder that still needs user input.
   • When fallback discovery is used instead, label the source clearly as GitHub MCP, shell listing, code search, or GraphQL-derived guidance.
   • When a skill is selected, include enough usage guidance that the user can proceed without another discovery round.
8. Handle low-confidence or no-match outcomes explicitly.
   • Say that no strong match was found or that the recommendation is uncertain.
   • If there are near matches, present them as tentative.
   • Suggest the next best action: broaden the query, continue without a skill, or capture the gap for future skill authoring.
9. Keep the response scoped to discovery.
   • Do not install, update, or remove anything unless the user explicitly asks you to execute that step.
   • If Fusion MCP is unavailable, say so clearly and identify which GitHub-backed fallback path was used instead of inventing catalog results.

Examples

• User: "Find a Fusion skill for GitHub issue authoring."
  • Result: return

    fusion-issue-authoring

    , explain that it routes to issue-type-specific skills, and include the install guidance or next step returned by MCP.
• User: "How do I update my installed Fusion skills?"
  • Result: call

    mcp_fusion_skills

    with

    intent: update

    and return the advisory update command or instructions from MCP.
• User: "Is there a skill for this obscure workflow?"
  • Result: if Fusion MCP is unavailable or yields weak matches, use GitHub-backed fallback discovery, say whether the match is tentative, and suggest the next best action.

Expected output

• detected intent (

  query

  ,

  install

  ,

  update

  , or

  remove

  )
• source used for the recommendation (

  mcp_fusion_skills

  , GitHub MCP, shell listing, code search, or GraphQL fallback)
• ranked skill suggestions when available
• concise description of each recommended skill
• next-step guidance for the chosen result
• advisory install/update/remove command when MCP provides one
• clear uncertainty language and a fallback next action when no strong match exists

Agents

• agents/fusion-mcp-advisor.md — use when Fusion MCP is available
• agents/github-mcp-advisor.md — use when Fusion MCP is unavailable but GitHub MCP is available
• agents/github-raw-search-advisor.md — use as final fallback with read-only CLI/GraphQL

References

• references/follow-up-questions.md — clarifying questions for vague requests

Safety & constraints

• invent skill names, availability, or install/update/remove commands
• present low-confidence matches as certain
• use remote-script execution patterns or unsafe shell pipelines during fallback discovery
• mutate the user's environment unless they explicitly ask you to execute the next step

• prefer Fusion MCP first, then GitHub MCP, then read-only shell or GraphQL fallback
• keep suggestions concise and task-focused
• preserve any advisory command text exactly when MCP returns it
• label GitHub-derived fallback guidance clearly when MCP was not the source
• state uncertainty plainly when the evidence is weak