equinor/fusion-discover-skills

Discover Fusion Skills (Deprecated)

Deprecated: This skill has been superseded by fusion-skills. Use the discover mode of fusion-skills instead. All functionality from this skill is available there. Install: npx -y skills add equinor/fusion-skills fusion-skills

When to use

Use this skill when a user needs to discover which Fusion skill fits a task or wants MCP-backed guidance for installing, updating, or removing a skill.

Typical triggers:

• "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

Do not use this skill for:

• 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

Collect before responding:

• 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

If key inputs are missing, ask only the smallest question needed to resolve the intent. Use references/follow-up-questions.md for clarifying vague requests about which skill or workflow the user wants.

Instructions

If subagents are available, use the bundled advisor agents for specific discovery scenarios:

• 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

If the runtime does not support bundled agents, follow the same workflow inline as described below.

Main workflow:

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.
   • For source-backed discovery of what skills exist and what they do, call mcp_fusion_search_skills with the user's wording. This uses semantic search over the local skills index.
   • If mcp_fusion_search_skills results are weak or ambiguous, follow up with mcp_fusion_skills — it can reason about intent, resolve ambiguous names, and provide richer advisory context.
   • For lifecycle operations (install, update, remove), call mcp_fusion_skills with explicit intent set.
   • Use auto intent detection on mcp_fusion_skills by default when the intent is ambiguous.
   • 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

Return:

• 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

Helper agents for specific discovery scenarios (when subagents are available):

• 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

Never:

• 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

Always:

• 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