From odin
Routes contributors to concrete, data-backed contribution opportunities by collecting repository signals and matching them to stated interests.
How this skill is triggered — by the user, by Claude, or both
Slash command
/odin:can-i-helpThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
`extend` op-cell: turn repository state into contributor action. Collect project context, ask the developer what kind of contribution they want, map that interest to the strongest native signals, then return exact file/line recommendations with data-backed rationale and an executable first step.
extend op-cell: turn repository state into contributor action. Collect project context, ask the developer what kind of contribution they want, map that interest to the strongest native signals, then return exact file/line recommendations with data-backed rationale and an executable first step.
The invariant: no vague “look around src/”. Every recommendation names a file and preferably a line, states why the target matters, explains the local code in 2–3 sentences, and gives the first command or edit.
Apply:
NOT:
Resolve target and collect base context. Default target = current repo unless the user supplied a path. Capture the project shape before ranking anything:
fd '^(package.json|pyproject.toml|Cargo.toml|go.mod|pom.xml|build.gradle|deno.json|bun.lockb|pnpm-lock.yaml|requirements.txt)$' <repo>.fd --max-depth 3 --type f <repo>; exclude generated/vendor directories.fd '^(README|CONTRIBUTING|DEVELOPMENT|HACKING)(\..*)?$' <repo> then read the relevant file ranges.fd '(^test$|^tests$|__tests__|spec$|\.test\.|\.spec\.)' <repo>.Collect contribution signals with native recipes. Prefer indexed codegraph when available; otherwise use ast-grep, rg, fd, and git history recipes. Keep every signal as {kind, file, line?, metric, confidence, evidence}.
codegraph_impact on candidate symbols and codegraph_files for local neighborhoods. Fallback: count importers with rg -n 'from .*/<module>|require\(.*/<module>|use .*<module>|import .*<module>' and prefer files with few dependents plus visible sibling tests.git --no-pager log --since='180 days ago' --name-only --format='commit:%H' -- <src-paths>; rank source files by touches, then subtract files whose commits include a matching test|tests|spec|__tests__ path. Certainty HIGH when source churn ≥5 and zero matching test co-change; MEDIUM when no test root exists but naming conventions are unclear.git --no-pager log --since='365 days ago' --name-only --format='commit:%H' -- docs README* CONTRIBUTING*; compute doc commits with no source files. Symbol recipe: extract backticked identifiers/import paths from docs, check via codegraph search, else rg -n '<identifier-or-path>' <repo>. Certainty HIGH for broken import/path; MEDIUM for zero code coupling.git --no-pager log --since='365 days ago' --regexp-ignore-case --grep='fix|bug|regression|crash|panic|race|leak|broken' --name-only --format='commit:%H' -- <repo>; bug-fix rate = fix_touches / max(total_touches, 1). Certainty HIGH when fix_touches ≥3 and rate ≥0.25.gh issue list --state open --limit 15 --json number,title,labels. Treat labels bug, good first issue, help wanted, documentation, test, testing, cleanup, refactor as routing hints. If gh fails, mark issue signal unavailable and continue.Ask the developer's interest — mandatory and first before recommendations. Use the ODIN ask tool, single-select, exactly one Recommended option. Do this even if signals already look obvious.
Prompt: What kind of contribution do you want to make?
Options:
New to the stack — Recommended when good-first areas or cleanup candidates exist.Experienced — hard problems, bugspots, architecture-adjacent issues.Want to write tests — test gaps and bugspot overlap.Want to fix bugs — bug-labelled issues, bugspots, suspicious conditions.Want to improve docs — stale references, doc drift, documentation issues.Want quick cleanup — verified deletion-only or tightly-contained cleanup.Route interest to signals. Use references/interest-routing.md as the contract. Lead with the strongest non-empty primary signal for the chosen interest; skip empty subsections with one sentence, not a filler apology. If the chosen interest has no supporting signal, say which signal was empty and pivot to the nearest adjacent interest with data.
Read before explaining. For every candidate that survives ranking, read the target file range plus enough surrounding code to understand the local pattern. For docs, read the stale doc and the current code target. For tests, read one nearby existing test pattern. Structural claims without a read are Graft.
Emit 2–5 recommendations. Each recommendation MUST use the four-field shape:
bat -P -p -n src/parser/expr.ts, rg -n 'parseExpr' tests src, gh issue view 42, or edit src/foo.ts:88-93 after reading context.Offer the next depth step. Close with: Want me to walk you through one of these? I can read the target code, outline the exact diff, or draft the PR description. Do not stop at the recommendation list.
test gap ∩ bugspot beats standalone test gap; doc drift ∩ open documentation issue beats standalone stale doc.Cleanup candidates are attractive but dangerous because “deletion-only” is easy to overclaim.
Before any cleanup recommendation says “zero behavior change”:
rg -n '<symbol>' <repo> and language-specific ast-grep for import/export sites.| Gate | Pass Criteria | Blocking |
|---|---|---|
| Interest asked | ODIN ask single-select used before recommendations | Yes |
| Signals collected | At least base context plus one of test gaps / doc drift / bugspots / issues / cleanup candidates | Yes |
| File-level target | Every recommendation includes exact file and line/range when available | Yes |
| Data-backed why | Every recommendation has a metric, label, confidence, or observed coupling fact | Yes |
| Code read | Each recommendation's How is based on a read source/doc range | Yes |
| Cleanup verified | Cleanup claims passed caller + context checks | Yes for zero-behavior wording |
| Four-field shape | What / Why / How / First step present for each item | Yes |
| Go-deeper close | Final question offers walkthrough/diff/PR help | Yes |
npx claudepluginhub outlinedriven/odin-claude-plugin --plugin odinHunts high-impact OSS contribution opportunities in trending GitHub repositories by discovering active repos, extracting help-wanted/good-first-issue/bug labels, analyzing feasibility, and generating dossiers with fix strategies.
Analyzes open-source GitHub libraries for contribution readiness. Produces structured Markdown reports on codebase structure, project lifecycle, and contribution paths.
Discovers approachable issues on GitHub repos you star or use, determines fix/review/propose actions, sets up workspaces, and guides PR submissions using gh CLI and git.