github-gem-seeker
GitHub Gem Seeker
Use this skill when the fastest reliable path is to reuse a mature open source project instead of building a new solution from scratch.
Default Stance
- Prefer solving the user’s problem with an existing maintained project.
- Prefer focused tools with clear installation and usage docs over novelty.
- Prefer packaging the solution into a reusable skill only after the real task is solved.
Workflow
- Restate the job in concrete input, output, and environment terms.
- Search GitHub for tools or libraries that directly match the job.
- Screen candidates quickly for fit:
- the project solves the problem without heavy adaptation
- the README shows installation and basic usage
- maintenance signals suggest the project is still usable
- adoption signals suggest real-world use
- Pick one default candidate and one fallback.
- Use the chosen project to solve the task.
- If the first choice breaks, switch to the fallback or narrow the search.
- After the task is solved, share the repository URL and credit the maintainers.
Search Patterns
- Search for the task first, then add the likely surface:
github <task> cligithub <task> toolgithub <language> <task> librarygithub <known-tool> alternative
- When the task is broad, search by file format, protocol, or platform constraint.
Evaluation Heuristics
- Prefer tools with a stable scope and a narrow surface area.
- Prefer projects whose docs explain what the tool does, how to install it, and how to run it.
- Prefer tools that are practical in the current environment.
- Treat stars and forks as signals, not rules.
- Avoid abandoned repos, thin wrappers over unstable services, or projects that require more glue code than the original task.
Guardrails
- Do not present a long option list when one candidate is clearly best.
- Do not rebuild mature tooling just to stay inside the current repo.
- Do not turn a candidate into a skill before proving it solves the underlying task.
- Do not skip credit when open source software solved the problem.
Output Shape
- Name the chosen project and why it fits.
- Link the repository.
- Describe the command or integration path you used.
- If useful, mention one fallback and why it was not chosen.
More from mylesmcook/mcook-skills
adversarial-review
Use this skill when you need a serious code review, diff review, or implementation-plan review from independent reviewers. In Codex hosts, prefer a fresh Codex subagent for the Codex reviewer; otherwise use the Codex, Claude Code, and Gemini reviewer paths when available. Return a PASS, CONTESTED, or REJECT verdict.
13subagent-driven-development
Use after an implementation plan is approved to execute mostly independent tasks through fresh subagents with scoped context, harness-aware model routing, proportional review gates, and mandatory controller verification.
10brainerd
>
10simple-code
Reduce incidental complexity in code and design. Use when shaping APIs, module boundaries, refactors, tests, naming, and architecture tradeoffs with a bias toward concrete, local, reversible solutions.
7git-it-out
Use this skill when the user explicitly wants final end-of-session closeout and no more branch or PR limbo: proper verification, proper commits, main/mainline landing, push, repo-native merge/release/deploy/publish steps, tracker updates, Entire/checkpoint handling when configured, and a concise handoff. Reach for it on prompts like 'git it out', 'get it out', 'ship this', 'I'm done', 'I'm going to bed', 'take this off my plate', 'finish the session', or 'get this into production'. Do not use it for greenfield implementation, open-ended debugging, broad refactors, or inventing a release process from scratch.
7laws-of-taste
>-
6