serhiy-bzhezytskyy
UserClaude Code skills for contributing to someone else's repo — each rule backed by a real receipt. Bring help, not noise.
Categories
Indexed Skills (16)
comments-about-code-not-change
Source comments explain what the DELIVERED code does, in the present tense — never the change history: no issue/PR numbers, no maintainer @handles, no "the previous code did X", no "confirmed by", no "aligned per". Change-narrative in source is a top AI tell, and it rots in the codebase; that context belongs in the PR body and commit message. Grep the diff's added comment lines before every push. Use before committing any code change to a repo you don't own. Trigger terms: code comment, "// previously", issue number in comment, @handle in source, over-explaining, AI smell, delivered documentation.
consolidate-a-scattered-thread
When a maintainer says "unclear where this should live" or "unclear where to further that conversation," the high-value move is not to reply in place — it's to do the consolidation FOR them. Traverse the JIRA/GitHub link graph across every linked ticket, read ALL comments plus related PRs, commits, and mail, untangle the conflated concerns into distinct threads each with a home, verify each claim in code, and hand back a map: "here's where each sub-thread belongs." This is a SOURCING/communication move — it turns a maintainer's "where do I continue?" into a delivered map. Use when a discussion is fragmented across many tickets/PRs and a maintainer signals they can't see the shape. Trigger terms: unclear where this belongs, fragmented discussion, scattered across tickets, link graph, issuelinks, consolidate, untangle, which issue tracks this, where should this live.
discuss-in-issue-first
For a non-trivial change, open or comment on the tracking issue and get the approach discussed BEFORE opening the PR — to make the change land FASTER, not to make it more likely to be accepted. Measured on Apache Solr: PRs with prior issue discussion merged at a median 3.4 days vs 5.8 days for cold PRs (~1.7× faster, p<0.001), with NO difference in merge rate (both ~83%). So discuss first to move faster, not to get in. Use before opening a PR for anything beyond a trivial typo/dep-bump. Trigger terms: issue-first, discuss first, open an issue, cold PR, RFC, design before code, faster merge.
follow-the-thread
When a red CI test, a failing check, or a single bug crosses your path, follow it instead of dismissing it — one thread reliably sources many issues worth working. A failing test maps to an existing issue whose root cause is often an existing UPSTREAM bug (downstream symptom → upstream cause); fixing that bug means reading the surrounding subsystem, where adjacent open issues surface; searching near the one you're fixing (same area / same reporter) seeds the next. A convenient "it also fixes X" is a hypothesis, not a finding — verify the mechanism. This is a SOURCING method: it finds where the help actually is, before any PR. Use when you hit a red CI on your own PR, a flake, or one bug and want to find the real work around it. Trigger terms: red CI, flaky test, follow the thread, downstream symptom, upstream root cause, adjacent issue, sibling bug, "not my bug", where's the real work.
match-the-house-shape
Before shaping a PR, mine what ACTUALLY merges in this house — the median churn, changed-file count, title convention, and test-touch rate of recently merged PRs — and size/shape your contribution to that median. A reviewer's implicit expectation is set by what they routinely merge, not by what CONTRIBUTING.md states; a PR in the house's usual shape is cheaper to review and so more likely to land as help. Measured on Apache Solr: 3,510 merged PRs settle on a clear median shape (churn 58, 4 changed files, 67.6% JIRA-key titles, 4.0 d to merge). Use before opening a PR, after picking the work. Trigger terms: house shape, median PR size, right-size the PR, split the PR, title convention, what actually merges.
no-force-push-a-reviewed-pr
On a PR that already has reviewers, push follow-up changes as plain new commits only — never `git commit --amend`, never `git push --force` / `--force-with-lease`. Force-push rewrites the commits reviewers' inline comments anchor to, resets the GitHub review state, and forces a cold re-read — the opposite of the incremental trust you are building. Use whenever you push any change to a PR someone has already looked at. Trigger terms: force-push, --amend, --force-with-lease, rebase, "clean up history", pushing to an under-review PR.
obey-the-houses-own-tooling
Before generating any project artifact a repo has a generator for (changelog, formatted source, build/lock files, license lists), create it with the repo's OWN documented tooling — never hand-craft a file a task owns. A maintainer detects careless or AI-assisted work by tool BYPASS, not by code style: a hand-made file doesn't match the pattern the generator produces. Use before writing any file the project ships a task/command for, and before saying "done". Trigger terms: changelog, AGENTS.md, gradle task, tidy, formatter, generated file, lock file, "it compiles and tests pass".
offer-dont-grab
To work an issue that's assigned to a maintainer, is the maintainer's own design, or has a dormant prior attempt: check whether the assignment is actually dormant (last activity, has the assignee ever commented, any linked PR), build a TDD-verified fix, then OFFER it — credit the prior work, ask the design question, open the PR on the maintainer's nod. Do NOT silently open a PR that grabs owned work. Assigned ≠ actively-worked; the rule is offer-don't-grab, not avoid-don't-touch. Use when the best-fit issue is already owned or has a stalled attempt. Trigger terms: assigned issue, dormant, stalled PR, "I'll take this", credit predecessor, revive, take over.
one-fix-one-pr-then-coordinate
Use when one investigation produced fixes for several related issues and you are deciding how to package them. Split by ISSUE — one PR per issue, each proven to stand alone on a clean base — rather than shipping the branch you happened to develop on. Then coordinate the cluster instead of flinging PRs: answer any open reviewer concern on the live PR FIRST, open the spin-offs, credit each reporter's own dig, and post ONE hub comment on the neutral root ISSUE linking the whole web. Never bundle independent fixes because they share a branch, and never bump a contested PR with cross-links. Trigger terms: several fixes one branch, split the PR, one PR per issue, bundle, cluster of issues, related PRs, spin-off, hub comment, cross-link, how do I package this, stacked fixes.
port-the-report-upstream
Use when the repo you found a bug in is a fork or port of another project and you are asking whether the original still has the same bug — or whether to report it there too. A port inherits its parent's bugs, so a defect found downstream is probably still live upstream, and vice versa. Check it, then report in both houses with each artifact cross-referencing its counterpart. But re-derive every anchor against the OTHER repo's own origin/main: line numbers drift, subcommands get deprecated, issue numbers autolink to the wrong project, label sets differ, and one house requires a DCO sign-off the other doesn't. Never copy a claim across a fork. Trigger terms: fork, port, upstream, downstream, vendored, same code, inherited bug, does upstream have this, does the original have this, is this fixed upstream, report it upstream too, cross-reference.
read-the-houses-agent-file-first
Before applying ANY skill in this repo, look for the house's own agent instructions — AGENTS.md (or CLAUDE.md, or any other agent-instruction file the house ships) — read it, and treat it as the higher authority. Where the house's file contradicts a skill here, the HOUSE wins: these skills are cross-house defaults, its file is local law. A house that ships an AGENTS.md has told you exactly how it wants agent-assisted work done; ignoring it while following a generic rulebook is the fastest way to read as noise. This is the meta-skill that runs first, before the rest of the front-gate. Use when starting on any repo you don't own, before invoking any other skill here, or when two rules conflict. Trigger terms: AGENTS.md, CLAUDE.md, agent-instruction file, agent instructions, house conventions, which rule wins, precedence.
sign-off-the-house-way
Before opening a PR, know which contributor sign-off THAT house requires and make sure it's present — the contracts differ by house and a missing one is an instant, automated "didn't read the rules" bounce. Eclipse projects (e.g. Jetty) gate every PR on an ECA plus a DCO `Signed-off-by` trailer on each commit; Apache projects (Solr/Lucene) use a CLA with the committer resolving on merge and need no per-commit trailer; other houses need neither. Check the house's contract first, not after a bot rejects you. Use at front-gate, before the first commit. Trigger terms: DCO, ECA, CLA, Signed-off-by, sign-off, `git commit -s`, eca check, contributor agreement.
track-whose-court
To answer "is anything waiting on me?", run a channel-complete status check across EVERY channel a maintainer can reach you on — GitHub PR issue-comments, GitHub inline review-comments, GitHub reviews, watched-issue comments, ASF JIRA, and the dev@ mailing list — plus git diffs as a seventh source. Compare the last HUMAN commenter (filtering commit-bot authors) to you to decide whose turn it is. Hand-checking one channel silently misses the others. Use on any "check status" / "whose turn" / "anything waiting on me" request. Trigger terms: check status, whose court, turn tracking, ball on me, follow-up, did they reply, nudge vs wait.
use-the-tool-for-its-purpose
To find real bugs in an unfamiliar project, don't audit its code hunting for smells — USE the tool for its actual purpose, on real data, at realistic N. The defects that survive green CI live in the step everyone skips: the gap between "it ran" and "you have a result" (aggregate, compare, report, export, the second run). Then reproduce each finding against the REAL method with a passing control, rule out your own setup, and check whether the thing you call missing is actually documented. Use when picking what to contribute in a repo you don't know. Trigger terms: find a bug, what should I fix, unfamiliar repo, where to contribute, audit the code, N=1, test-mode, demo path, real data.
verify-before-a-committer-comment
Before asserting a technical claim in a public JIRA/PR/committer-facing comment — "PR X fixes Y", "the bug is in layer Z", "test T still fails", "commit C did D" — verify it by reading the actual code path and running the test on clean state. Do NOT infer from PR titles, commit messages, or the issue link-graph. State your confidence (verified / inferred / open). A confident-wrong claim to a committer, especially about your OWN PR's scope, costs trust fast. Use before any committer-facing technical assertion. Trigger terms: post a comment, "this fixes", root cause, which layer, still fails, commit did X, assumed or checked.
write-in-your-own-voice
The PROSE you put in front of humans — PR body, issue text, review replies — should read as your own terse voice, not the generic-LLM register maintainers spot instantly ("comprehensive", "robust", "leverages", "this PR addresses the issue where…", over-hedged padding). AI-register prose gets flagged; house-voice prose lands. Cut the jargon, say what changed in one plain line, and match the house's short PR-body length; optionally few-shot from your OWN merged PRs to calibrate. Use when drafting any human-facing text on a repo you don't own. Trigger terms: PR body voice, AI tell, generic LLM prose, comprehensive/robust/leverages, press- release tone, write plainly, own voice.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.