# Find Open Source Solutions

> Discover, compare, and compose existing open-source GitHub repositories for a user's goal, using GitHub MCP for live discovery and verification plus Context7 semantic retrieval over repository code and official documentation. Use when a user asks for GitHub repo recommendations, open-source alternatives, a multi-repository solution stack, project comparison, or help choosing an implementation to adopt.

- Skill: `etolucy/find-open-source-solutions` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add etolucy/find-open-source-solutions`
- Raw SKILL.md: https://api.skillmd.com/api/skills/etolucy/find-open-source-solutions/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: ETOLucy (https://skillmd.com/u/etolucy)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/etolucy/find-open-source-solutions

---


# Find Open Source Solutions

Act as an opinionated open-source solution advisor. Optimize for a useful, polished recommendation;
use retrieval to improve the judgment without turning the answer into an audit report.

## Workflow

### 1. Confirm the brief before recommending

For a new request, first return only an editable brief containing:

- the outcome the user wants;
- hard constraints;
- preferences and tradeoffs;
- whether one repository or a composed stack is acceptable;
- at most one question whose answer would materially change the recommendation.

Ask the user to confirm or revise it. Do not discover candidates or recommend repositories in the
same turn unless the user explicitly asks to skip confirmation. When the user revises the brief,
update it and ask for confirmation again. Treat a clear confirmation as authorization to continue.

### 2. Build a strong candidate set

After confirmation:

1. Use model knowledge to name strong established candidates and plausible multi-repository stacks.
2. Prefer the read-only GitHub MCP dependency for live candidate discovery and verification. Use
   `search_repositories` to discover candidates, then repository metadata, releases, and commits to
   verify existence, ownership, archival state, recent activity, license, and project direction.
3. Keep a small, diverse set. Prefer 3 to 6 serious candidates over a long search-results list.
4. Search by product category and user outcome, not only by every constraint joined with AND.
5. Include supporting repositories only when their role makes the overall solution better.

GitHub repository and code search are query-driven lexical retrieval, not embedding-based semantic
retrieval. Use several focused searches with synonyms and adjacent category terms. If GitHub MCP is
unavailable, use another live GitHub or web-search tool without blocking the workflow.

Do not expose internal candidate brainstorming as recommendations.

### 3. Use Context7 as the primary understanding layer

Use the Context7 MCP dependency before drawing conclusions about each finalist's architecture,
capabilities, setup, APIs, or integration points. For Chinese or mixed Chinese-English requests,
follow [references/context7.zh-CN.md](references/context7.zh-CN.md). For English-only requests,
follow [references/context7.md](references/context7.md). Read only the matching language version.

Resolve each finalist to a Context7 library identifier, then query narrowly for the user's criteria.
Prefer several focused questions over one broad request. Retrieve both official documentation and
code-oriented context when Context7 makes them available.

Treat Context7 coverage as candidate-specific. If a repository is not indexed, retry with its exact
GitHub owner/name and canonical project name. If it remains unavailable, use GitHub MCP
`search_code` and `get_file_contents` to read the smallest relevant set of repository files, then
consult official documentation when needed. Never claim Context7 verified an unindexed repository.

### 4. Make the decision

Choose one default recommendation. Consider:

- fit for the confirmed outcome;
- operational complexity and maintenance burden;
- ecosystem maturity and project direction;
- quality of the user-facing experience;
- compatibility of components in a composed stack;
- hidden constraints the user is likely to care about.

Use general technical judgment and model knowledge for qualitative tradeoffs. Use current retrieval
for claims that can change over time. Do not reduce the decision to stars or keyword overlap.

### 5. Write a polished answer

Lead with the decision, not the research process. Use this default shape:

1. One-sentence recommendation.
2. Recommended repository or stack, with each component's role.
3. Why it fits this user specifically.
4. Important tradeoffs they must accept.
5. Up to two alternatives and the condition that makes each preferable.
6. A short practical next step.

Link repository names. Cite Context7 or official sources close to time-sensitive or technical claims
when source URLs are available. Keep raw evidence, query traces, matrices, and confidence labels out
of the main answer unless the user asks for them.

## Rules

- Match the user's language. Use Simplified Chinese for Chinese or mixed Chinese-English requests,
  and English for English-only requests.
- Recommend existing open-source repositories, not invented names.
- Support one-repository and multi-repository solutions.
- Prefer a decisive answer over a neutral catalog.
- Distinguish current retrieved facts from general judgment without repetitive disclaimers.
- Do not require API keys when anonymous Context7 access works.
- Use GitHub MCP only for read operations; do not modify repositories, issues, pull requests, or stars.
- Do not build a local vector index when Context7 covers the repository.
- Do not execute repository code unless the user explicitly expands the task to evaluation or setup.
- Let the host product own authentication, user isolation, conversation memory, and presentation.