Software Development Skills

Use this skill to walk through a pull request and answer every comment left by a reviewer: list all review comments and review-summary comments, decide for each one whether to push back with a technical reason or to fix the code, apply the fix and commit it when the suggestion is right, and reply to the reporter on the same thread either way. One pull request per run, every comment answered exactly once — then stop.

Use when reviewing English prose — essays, blog posts, opinion pieces, README sections, design documents, technical arguments, or any text that defends a thesis — in order to find flaws in the argumentation. Map the argument before judging it, name each flaw with a quoted snippet and a one-line explanation, and report findings as a structured list. Do NOT rewrite the prose, soften the author's tone, or replace the conclusion with your own opinion; the job is diagnosis, not surgery.

Use when writing, editing, or reviewing the architecture section of a repository's README.md file. Explain key architectural decisions to a newcomer — one decision per paragraph, each tied to a concrete design constraint, each highlighting how the repo differs from traditional or competing solutions. Stay concise, technical, emotion-free, and rational. Assume the reader is fluent in coding but new to this repo and to the problem domain.

Use this skill to find a single bug in a GitHub repository by reading the source code only — no builds, no tests — and to file it as a new issue. Study the code base, read the currently open issues to avoid duplicates, pick exactly one flaw, inconsistency, or defect, and submit a concise bug report that names the problem, points to the code, and suggests a fix. Then post a short follow-up comment on the new issue asking the repository owner to take a look. One bug per run, one issue per run, one ping per run — then stop.

Use when a build is broken — failing tests, linters, type checks, or any other check that prevents a clean full build. Run the full build (tests and linters together), fix the single most critical issue, re-run, repeat until clean, then run once more to confirm. Fix every issue regardless of when it appeared.

Use this skill to fix a single issue end-to-end: read the repo README and CLAUDE.md, sync master, confirm the baseline build is green, branch by the issue name, write a failing test that reproduces the bug, commit the test, fix the source, stabilize the build and linters, commit the fix, push, and open a pull request. One issue per run, one branch per run, one pull request per run — then stop.

Use when creating or editing plain text documents — Markdown (.md), TeX (.tex), or .txt files. Apply the three rules below to every sentence: one sentence per line, wrap long sentences across multiple lines, and indent continuation lines by two spaces. Do NOT apply to source code files, code blocks inside Markdown, YAML, JSON, or any file where line breaks change meaning.

Use when creating a Git commit. Follow the Conventional Commits 1.0.0 specification, write a short imperative subject, keep the body concise and factual, and never add a co-author trailer for Claude, Claude Code, or any other agent.

Use this skill to merge low-risk pull requests opened by automation bots across a list of GitHub repository owners: walk every repository, pick the open pull requests authored by renovate, renovate[bot], or github-actions[bot], keep only the ones where every required CI check has finished successfully, and merge them one by one. Stop after merging two hundred pull requests or after spending thirty minutes of wall-clock time on the run, whichever happens first. One run, one budget — then stop.

Use this skill to pick exactly one GitHub repository that needs a refresh: scan a given list of owners, collect signals of neglect — long stretches without commits, failing or absent CI runs on the default branch, outdated or vulnerable dependencies — score every candidate, and pick the single most neglected repository. If every repository looks reasonably fresh, still pick one — the least fresh of the bunch — because the contract of this skill is to always end with exactly one repository chosen. One repository per run, then stop.

Use this skill to pick exactly one open GitHub issue that genuinely needs an outside contributor: scan a given list of repository owners, prefer repositories with little recent activity, narrow to issues labeled "bug" or "enhancement" that are unassigned and have no claimed work in the thread, filter for actionable and reproducible reports, and prefer the oldest surviving candidate. Then post a single short comment announcing intent to work, addressed to the reporter and to the project architect — the repo owner or the most active recent committer. One issue per run, one comment per run, then stop.

Use this skill to walk through an existing code base and fix surface-level problems that are obvious on a careful read: typos, grammar mistakes in comments and strings, inconsistent naming or formatting, dead imports, stale references, broken links, mismatched casing, and small contradictions between neighboring files. Stay on the visible layer — do not refactor logic, do not run unit tests, and do not chase deep design issues. Apply each fix directly when it is obvious, and report borderline cases for the author to decide.

Use when proofreading a .srt subtitle file produced by Whisper or another voice-to-text engine. Fix punctuation, capitalization, sentence boundaries, and over-long lines, but leave timestamps, cue numbers, and the overall block structure untouched. Apply to English and Russian subtitles alike, and keep computer jargon in its conventional form.

Use when writing, proofreading, or polishing the wording of plain text documents — Markdown (.md), TeX (.tex), or .txt files — and the English text embedded in source code: comments, docstrings, log messages, error messages, and user-facing strings. Apply the rules conservatively: preserve the author's voice and meaning, replace awkward phrasing with cleaner alternatives, fix grammar, and cut filler words, clichés, and tautologies. Do NOT apply to the surrounding code, YAML, JSON, or quoted material.

Use this skill to upgrade every dependency in a repository end-to-end: read the repo README and CLAUDE.md, sync master, confirm the baseline build is green, branch for the upgrade, lift every runtime and development dependency to its latest stable release, lift every CI plugin and GitHub Action to its latest version too, stabilize the build, commit, push, open a pull request whose description talks like a human, and wait until every CI job is green. One repository per run, one branch per run, one pull request per run — then stop.