khasky
UserSkills for AI coding agents: code review, debugging, security audits, refactoring, cleaning up AI-written code and text, and more.
Categories
Indexed Skills (58)
awesome-post-publisher
Publishes a prepared batch of scheduled posts to the user's own accounts through their live browser (Playwright MCP --extension bridge to Chrome): bridge preflight, post-source scan with hard-stop format validation, per-platform login checks with a wait-or-skip choice (login itself is never automated), a persistent ledger that survives restarts and prevents duplicate posts, timezone-mapped scheduling that can idle for days between posts, and strictly sequential, human-paced posting with read-back verification of every post and a confirmation gate before anything goes public. Use when asked to 'publish the campaign', 'post these files to my accounts', 'post on schedule', or in Russian 'опубликуй посты', 'публикуй по расписанию', 'запости в соцсети'. Do not use to write the posts — use awesome-content-campaign; not to crawl or learn a site — use awesome-style-mimic.
awesome-db-audit
Read-only audit of a database layer — schema design against a catalog of SQL anti-patterns (EAV, generic keys, imprecise types), query patterns (SELECT *, N+1, unindexable predicates), integrity and concurrency (constraints in the DB, transactions, locking), and migration/operations hygiene (forward-only, expand/contract, restore path, tenancy model) — producing evidence-backed findings and a SHIP / FIX / BLOCK verdict. Use when the user asks to 'audit the database', 'review the schema', 'check our migrations', 'is this data model sound', 'why are queries slow' (static analysis), or 'проверь схему базы'. It audits and reports; it never edits schema or data. Do not use for runtime latency profiling (use awesome-performance-audit), SQL injection and access control (use awesome-security-audit), or app-layer data-access style (use awesome-code-standards).
awesome-commit-plan
Turns a codebase into a commit plan: a navigation map of its modules and their dependency direction, then a split where every commit builds and tests on its own, so the series is bisectable end to end. Each commit is verified by replaying the ladder in a scratch clone against the repository's own gates, never asserted. Messages follow a strict ruleset that keeps machine-written prose out of the log. The only output is a plan file numbered #1 to #N, no dates, no preamble. Use when asked to 'split this project into commits', 'plan the commit history for this repo', 'how should I break this into commits', 'prepare a bisectable commit series', or in Russian 'разбей проект на коммиты', 'составь план коммитов', 'как разбить это на коммиты'. Takes a repository URL or a local path: '/awesome-commit-plan <url-or-path>'. Do not use to execute the plan against git history — that is awesome-git-history-rebuild; not to squash an existing history — awesome-git-history-reset; not to review a diff — awesome-code-review.
awesome-claims-audit
Audits every checkable public claim — marketing pages, README, store listing, privacy policy, docs, structured data — against the constants, manifests, catalogs and locale strings that decide it, across repos, then fixes the drift in a separate phase. Use when asked whether the site still matches the code, to find outdated claims, before a store submission or privacy-policy review, or 'проверь факты на сайте'. Do not use for prose quality (awesome-document-style), conversion structure (awesome-landing-audit), or internal docs fidelity (awesome-architecture-audit).
awesome-git-author-rewrite
Rewrites the author and committer identity on a commit — or on every commit carrying a wrong identity — and force-pushes it safely: ownership and write-access checks, a verified mirror backup, a counted hash blast radius, and a confirmation gate before anything irreversible. Takes a commit URL plus the replacement identity. Use when the wrong name or email is on a commit, when commits are not linked to the user's account, or 'переписать автора коммита'. Do not use to collapse a history into one commit (awesome-git-history-reset) or to change only a commit message (git commit --amend).
awesome-regression-sweep
Read-only regression sweep over a codebase and its live surfaces, answering in deltas against a recorded baseline: a layered aspect pass (typecheck, lint, generated-artifact drift, unit and integration suites, black-box wire contract, cross-implementation parity, downstream consumer build) plus nine rotating deep angles from shuffled test order to deployed-vs-committed drift. Never deploys, never writes, never calls a mutating route. Use when asked to verify everything before or after a deploy, check for regressions, or 'проверь что ничего не сломалось'. Do not use to design tests (awesome-test-writing), diagnose one failure (awesome-bug-fix), or profile latency (awesome-performance-audit).
awesome-dependency-audit
Read-only audit of third-party dependencies — lockfile discipline, typosquats and hallucinated package names, dependency confusion, install-script exposure, provenance, licenses, CVE reachability — with a SHIP / FIX / BLOCK verdict. Use when asked to audit dependencies or the supply chain, judge whether a package is safe, review a manifest change, after a bot version bump, or 'проверь зависимости'. Do not use for vulnerabilities in your own code (awesome-security-audit) or to execute the upgrades (awesome-dependency-upgrade).
awesome-style-mimic
Learns a website's writing style by deep-crawling it in a live browser, distills a reusable style guide (voice, tone rules, lexicon, rhythm, structure, golden samples), then rewrites documents or page sources in that voice with a cross-document consistency pass. Use when asked to learn the style of a site, build a style guide from a website, rewrite text in a site's voice, or 'изучи стиль сайта', 'перепиши в стиле'. Learn mode needs browser automation; apply mode needs only the guide. Do not use for an author's own voice (awesome-content-voice), stripping AI voice (awesome-humanize-en), or translation (awesome-translate-ru-en).
awesome-code-review
Reviews a diff, patch or pull request for correctness, security and team standards, with confidence-scored findings in severity buckets (Critical / Suggestions / Nice to have). Use when asked to review a change, before merging, after finishing a feature, or 'сделай ревью'. Do not use for responding to review feedback you received (awesome-code-review-feedback) or for docs-only and formatting-only changes.
awesome-leak-audit
Audits a public-facing client (extension, mobile or desktop app, SPA, CLI, SDK) so its published surface reveals nothing about the private backend: leaked internals in comments, docs and tests (rate limits, anti-abuse, quotas, test backdoors, infra, schema, env-var names), plus client hardening (permissions, message-sender validation, token handling, DOM sinks, bundled secrets). Use when asked whether a repo leaks backend details, before open-sourcing or a store submission, to harden a client, or 'что раскрывает наш клиент'. Do not use for server-side vulnerability hunting (awesome-security-audit).
awesome-root-cause
Structured root-cause analysis for incidents, recurring failures and process problems with no failing test to run — 5-Whys, fishbone, PDCA, and a one-page A3 write-up. Use for a postmortem or incident retro, when asked why something keeps happening, to find the root cause of a non-code issue, or 'найди первопричину'. Do not use for a code bug with a reproducible failure (awesome-bug-fix).
awesome-architecture-audit
Read-only whole-project audit of design: module boundaries and dependency direction, docs-vs-code fidelity, YAGNI/KISS/SOLID, and extensibility (build from source, add a provider), producing a prioritized report with a SHIP / FIX / BLOCK verdict. Language-agnostic. Use when asked to audit the architecture of a whole codebase, check whether the docs still match the code, judge how hard it is to extend, or 'оцени архитектуру'. Do not use for one diff (awesome-code-review), a vulnerability (awesome-security-audit), runtime latency (awesome-performance-audit), or comment cleanup (awesome-code-cleanup).
awesome-humanize-en
Removes the signs of AI generation from English text (Russian via a calibration file): clichés, filler, corporate jargon, sycophantic tone, emoji bullet lists, gratuitous em-dashes, fabricated sources, plus venue rules for release notes, PR and issue replies, postmortems, tickets and technical articles. Two operations: review (diagnose only, evidence-first report) and edit at four intensities. Use when asked to humanize, de-slop, or check text for AI voice ('this reads like a chatbot', 'убери следы ИИ в тексте'), or when copy-paste chatbot markers are present: ':contentReference', '?utm_source=chatgpt.com', 'oai_citation', '[cite: 8]'. Do not use on source code, on legal documents, on other languages, or on literary prose and résumés, where rhythm and the em-dash are authorial devices.
awesome-document-style
Clean and line-edit Markdown documents for clear, specific, publication-ready prose. Use when asked to de-bloat, de-template, remove chatbot artifacts, fix vague wording, settle whether numbers are written as digits or spelled out, make Markdown read like careful human editorial writing, or 'отредактируй документ'. Do not use to fabricate facts or bypass detectors.
awesome-landing-audit
Read-only mechanical audit of a landing page's conversion structure — one primary CTA per view, form friction, ad-to-headline message match, trust elements, above-the-fold value, CLS-safe banners — with a SHIP / FIX / BLOCK verdict per page. Use when asked to audit a landing page, why a page is not converting, whether it is conversion-ready, or 'почему лендинг не конвертит'. Do not use for copy voice (awesome-humanize-en), SEO (awesome-seo-audit), or accessibility (awesome-accessibility-audit).
awesome-performance-audit
Read-only audit of performance and reliability — event-loop discipline, streaming and backpressure, memory and CPU diagnostics, shutdown/timeout/job habits, resilience topology (circuit breakers, retry budgets, queue bounds), and frontend delivery (Core Web Vitals, bundle size, hydration) — with evidence per finding and a SHIP / FIX / BLOCK verdict. Use when a service or page is slow, memory climbs, tail latency is bad, a worker OOMs, before a load event, or 'почему тормозит'. Measures and reports; rewrites no hot paths. Do not use for retry/idempotency contracts (awesome-error-standards) or render style rules (awesome-code-standards).
awesome-seo-audit
Read-only SEO and AI-discoverability audit of a site or codebase — technical SEO, programmatic and scaled-content safety, and agent/LLM readability (crawler access, snippet directives, render-blindness) — with evidence per finding, a SHIP / FIX / BLOCK verdict, and a baseline/diff mode that catches what a deploy quietly broke. Use when asked to audit SEO, check for thin or cannibalizing pages, judge whether LLMs and agents can read the site, confirm a release changed nothing that ranks, or 'проверь SEO'. Reports only; writes no content. Do not use for WCAG accessibility (awesome-accessibility-audit) or landing conversion mechanics (awesome-landing-audit).
awesome-content-publisher
Publishes a prepared batch of scheduled posts to the user's own accounts through their live browser (Playwright MCP bridge): bridge and format preflights, per-platform login checks that never automate a login, a persistent ledger that prevents duplicate posts across restarts, timezone-mapped scheduling that can idle for days, sequential human-paced posting with read-back verification and a confirmation gate before anything goes public, plus an opt-in engagement harvest. Use when asked to publish a campaign, post prepared files to accounts, post on schedule, or 'опубликуй посты'. Do not use to write the posts (awesome-content-campaign, awesome-content-repurpose) or to learn a site's style (awesome-style-mimic).
awesome-content-voice
Builds one reusable author-voice profile from whatever evidence exists — the user's own posts read through their logged-in browser, files, pasted samples, or an interview plus a tuned archetype — and writes it as a file other skills read instead of re-deriving a voice: presence and counted absence signals, per-platform register, protected personal tics, a source-and-confidence stamp. Thin evidence yields a low-confidence profile that says so. Use when asked to build, learn or update the user's writing voice, or 'собери мой авторский стиль'. Do not use for a website's brand voice (awesome-style-mimic), to write posts (awesome-content-campaign), or to strip AI voice (awesome-humanize-en).
awesome-git-history-salvage
Reconstructs every commit a repository has ever held, force-pushed-away history included, by merging current refs, pull-request refs, any mirror backup and every ref state the host's activity log recorded, then fetching unreachable commits by SHA over the git protocol. Emits sha/date/author/subject rows at the detail level the user picks. Read-only: never writes to a remote. Use when asked what a repo held before a rewrite, to recover erased history or deleted commits, or 'найти удалённые коммиты'. Do not use to restore a branch, to recover a local branch alone (git reflog), or to erase history (awesome-git-history-reset).
awesome-skills-purge
Removes installed agent skills from every AI agent on the machine — Claude Code, Codex, Gemini CLI, Cursor, Copilot, opencode, Amp, Windsurf, any agent that reads a skills directory — behind a keep list (one collection, this skill alone, or a named set), with an archive and a confirmation gate before anything goes. Platform detected at run time. Use when asked to delete or uninstall installed skills, clean out skills but keep some, or 'удали все навыки'. Do not use to uninstall a plugin that ships skills, or to delete the git clone a symlinked install points at.
awesome-security-audit
Read-only audit of code for injection, secrets, auth and authorization flaws, dependency CVEs, CI/CD pipeline exposure and cryptographic misuse — confidence-gated, evidence-backed findings mapped to CWE/OWASP, each carrying the fix it calls for. Use when asked for a security review or audit, before a release, after adding auth, payments or sensitive-data handling, when hardening CI workflows, or 'проверь безопасность'. Reports; never edits code. Do not use for what a public client discloses about a private backend (awesome-leak-audit).
awesome-code-cleanup
Repo-wide cleanup of AI-like code noise, behavior-preserving: a comment pass (delete narration, condense bloat, fix stale, keep load-bearing), a read-only audit mode, an opt-in refactor mode for vague names and over-abstraction, a detection mode for dead code and logical inconsistencies, and an execution mode that applies another audit's findings. Use when asked to clean up or condense comments, de-slop vibe-coded files, apply a YAGNI pass, find dead code, apply a slop-audit report, or 'почисти код', 'найди мёртвый код'. Do not use for prose (awesome-humanize-en, awesome-document-style) or for the read-only marker sweep (awesome-slop-audit), whose report it executes.
awesome-slop-audit
Read-only audit of a repository for machine-written 'AI slop' across code, comments, tests, docs, configs and CI, against a verified catalog: glyph pockets, stale and false comments, change-narration, drift-bait numbers, template stamps, impossible defensiveness, copy-paste drift, negative-parallelism prose. Every suspect is verified against the code, absence is proven per category, and the ranked findings hand off to awesome-code-cleanup, which owns every edit. Use when asked to find AI slop or machine-written markers, or 'проверь код на следы ИИ'. Do not use to fix what it finds, for prose line-editing (awesome-document-style), or for public-claims drift (awesome-claims-audit).
awesome-content-campaign
Builds a scheduled batch of platform-fit marketing posts from any sources (repos, sites, files): a knowledge map where every claim traces to evidence, an interview for voice, frequency, platforms and timezone, live checks of each platform's limits, posts written to a per-genre register, a two-stage anti-slop audit, one dated file per slot plus a manifest. A single-post mode writes one unit for named platforms, no schedule. Use when asked to plan a content campaign, write posts about a product, write a post for named platforms, or 'контент-план', 'посты для соцсетей на неделю'. Do not use to publish them (awesome-content-publisher), to build the voice profile (awesome-content-voice), or to de-slop existing text (awesome-humanize-en).
awesome-git-history-rebuild
Erases a repository's git history and rebuilds it as a curated commit series over the same tree: an approved split plan (proposed here or supplied by awesome-git-commit-plan), the repo's own commit rules and hooks, paced timestamps, signed commits, a verified mirror backup, a confirmation gate before every irreversible step, and a tree-hash proof that nothing was lost. It repairs the files that describe the erased history. Use when asked to rewrite a history as readable commits or 'очистить историю и закоммитить по частям'. Do not use to collapse a history into one commit (awesome-git-history-reset) or to fix authorship (awesome-git-author-rewrite).
awesome-pentest
Runs an authorization-gated penetration test against a target (repo, web app, API, network, cloud, mobile client) following PTES, OWASP WSTG/MASTG/API Top 10 and NIST SP 800-115: scoping and rules of engagement, recon, attack-surface mapping, testing, exploitation-to-proof, findings with CWE/CVSS, retest. Every active probe is hard-gated behind written authorization and scope. Use on 'pentest', 'red team', 'attack surface assessment', 'проведи пентест'. Do not use for static white-box review (awesome-security-audit), client disclosure (awesome-leak-audit), or dependency CVEs (awesome-dependency-audit).
awesome-code-standards
Universal coding standards — naming, structure, immutability, error handling, type safety, backend layering, frontend architecture — that fill the gaps after the project's own conventions. Use when starting a module, refactoring to team conventions, setting up lint rules, onboarding, or 'стандарты кода'. Do not use for a repo-wide comment cleanup pass (awesome-code-cleanup) or for designing the API error contract (awesome-error-standards).
awesome-content-repurpose
Turns one existing text — a URL, a file, or pasted notes — into platform-native posts for a canonical set of 26 platforms: source notes every claim traces back to and verifies, an interview for platforms, voice and length, an opener catalog and paragraph-shape rules that keep posts from reading as generated, hard character caps and a per-platform depth band each version is written to, a two-stage anti-slop audit, one dated file per platform in the format awesome-content-publisher reads. Use when asked to repurpose an article into posts, adapt a text for named platforms, or 'адаптируй статью под соцсети'. Do not use for a scheduled campaign from product sources (awesome-content-campaign), to publish (awesome-content-publisher), or to build the voice profile (awesome-content-voice).
accessibility-audit
Audits UI and markup for accessibility (WCAG 2.1/2.2, keyboard, screen readers) and suggests concrete fixes. Use when checking a11y, before shipping a page or component, reviewing forms/modals/interactive UI, or when the user says 'accessibility', 'a11y', 'WCAG', 'screen reader', 'keyboard navigation', 'доступность'. Covers semantic HTML, focus management, labels, contrast, dynamic content, and WCAG 2.2 additions (target size, focus obscured, accessible authentication).
clean-markdown-human
Clean and line-edit Markdown documents for clear, specific, publication-ready prose. Use when asked to de-bloat, de-template, remove chatbot artifacts, fix vague wording, or make Markdown read like careful human editorial writing. Do not use to fabricate facts or bypass detectors.
code-review
Reviews diffs and PRs for correctness, security, and team standards, with confidence-scored findings in severity buckets (Critical / Suggestions / Nice to have). Use when reviewing a pull request, merge request, patch, or diff; before merging; after completing a feature; or when the user says 'review this PR', 'check this change', 'review my diff', 'сделай ревью'. Do not use for responding to review feedback you received (use receiving-code-review) or for docs-only and formatting-only changes.
code-surgeon
Repo-wide audit and cleanup of AI-like code noise — comments to a strict best-practice bar (delete redundant/narrating, condense bloated, fix stale or misleading, keep only load-bearing knowledge), plus a read-only audit mode and an opt-in refactor mode for vague names, dead/duplicated/speculative code, and over-abstraction — all strictly behavior-preserving and verified. Use whenever the user asks to clean up / prune / audit / condense comments, remove "obvious" or AI-generated comments, make code self-documenting or human-readable, de-slop vibe-coded files, apply a "comments only when necessary" or YAGNI/KISS pass, or says things like "чистка комментариев", "убери лишние комментарии", "comment hygiene", "de-comment", "почисти код". Also use when a code review found comment bloat or naming noise and the user wants it fixed repo-wide rather than file by file.
coding-standards
Universal coding standards: naming, structure, immutability, error handling, and type-safety patterns for consistent code. Use when starting a project or module, refactoring to team conventions, setting up lint/format rules, onboarding, or when the user says 'coding standards', 'naming conventions', 'code style'. Discovers and follows the project's own conventions first; these rules fill the gaps.
error-handling-patterns
Applies consistent error handling, logging, and user-facing messages: typed errors, operational-vs-programmer classification, API error envelopes, HTTP status mapping. Use when adding or refactoring error handling, designing an API error contract, reviewing failure paths, or when the user says 'error handling', 'consistent errors', 'обработка ошибок'.
humanizer-en
Use when: the user asks you to check, rewrite, humanize, or de-slop English text that shows signs of AI generation (ChatGPT, Claude, Gemini, Grok, DeepSeek, GPT-5, Qwen, Llama, any LLM). Trigger for requests like: 'humanize this', 'make it sound human / natural', 'remove the AI voice', 'this reads like a chatbot', 'AI detector for English', 'check for AI', 'de-slop', 'reduce AI-isms', remove clichés / filler / corporate jargon / emoji bullet lists 🚀 / gratuitous em-dashes / sycophantic tone / fabricated sources. Also when visible copy-paste chatbot markers are present: `:contentReference`, `?utm_source=chatgpt.com`, `oai_citation`, `grok_card://`, `vertexaisearch`, `turn0search`, `[cite_start]`, `[cite: 8]`. Do NOT use: text that is not in English, source code / scripts (even about NLP), legal documents (officialese is the genre), literary prose / poetry / résumés (there the em-dash, rhythm and compression are an authorial device).
logging-standards
Applies structured logging, levels, PII handling, and wide-event (canonical log line) patterns. Use when adding or reviewing logs, choosing log levels, designing request logging, after an incident where logs were insufficient or leaked data, or when the user says 'logging', 'log format', 'what should we log', 'логирование'.
public-client-leak-audit
Audit a public-facing client (browser extension, mobile/desktop app, SPA, CLI, SDK, or any open-sourced client that talks to a private backend) so its public surface stays self-contained and doesn't help attackers. Use when asked to review a repo for leaked backend internals, secrets, or abuse-enabling disclosure; to check that comments/docs/tests don't reveal server-side mechanics (rate limits, anti-abuse, quotas, test backdoors, infra/tech stack, DB/schema, env-var names); to scrub a client before open-sourcing or a store/app-store submission; or for client-side security hardening (permissions, IPC/message sender validation, auth-token handling, DOM/XSS sinks, build-time config, secret bundling). Triggers: 'audit for leaks', 'does this leak backend details', 'is this safe to make public', 'security review of the client/extension', 'what does our API disclose', 'harden the client'.
receiving-code-review
How to respond to code review feedback: verify before implementing, clarify unclear items, and push back with technical reasoning when needed. Use when receiving PR feedback or review comments. Applies to any team or culture.
security-audit
Audits code for common vulnerabilities: injection, secrets, auth, and dependency CVEs — with confidence-gated, evidence-backed findings mapped to CWE/OWASP. Use when reviewing security, before a release, after adding auth/payments/sensitive-data handling, or when the user says 'security review', 'security audit', 'check for vulnerabilities', 'is this secure'. Do not use for auditing what a public client discloses about a private backend — use public-client-leak-audit for that.
systematic-debugging
Debugs by building a runnable pass/fail reproduction, isolating the root cause, then fixing — no fixes without root cause first. Use when fixing bugs, investigating test/build failures, or when the user reports an error, crash, flaky behavior, or says 'debug this', 'why does X happen', 'не работает'. Use especially under time pressure or after several failed fix attempts. Do not use for feature work with no failing behavior to explain.
translate-ru-en
Translate Russian text of any kind into natural English while preserving every structural element, formatting marker, link, identifier, and the author's human voice. Use when translating Russian articles, docs, prose, fiction, marketing copy, technical content, transcripts, or any other Russian-language text to English; when mirroring a directory of Russian files into an English equivalent; or when the user asks to "translate to English", "convert to en", or "make an English version" of a Russian source.
awesome-test-writing
Designs and writes tests that catch real regressions — placement (unit/integration/E2E), factories and fixtures, behavior-first assertions, characterization tests for legacy code, property/fuzz tests for parsers. Use when asked to write tests or add coverage for a module, 'напиши тесты', when a bug fix needs its regression test, or when awesome-bug-fix, awesome-code-review or awesome-security-audit calls for one. Do not use for judging existing tests in a review (awesome-code-review) or for diagnosing the bug itself (awesome-bug-fix).
awesome-accessibility-audit
Read-only WCAG 2.1/2.2 audit of UI and markup — semantic HTML, keyboard and focus, labels, contrast, dynamic content, target size — with the concrete fix beside each finding. Use when asked to check accessibility, a11y, WCAG, screen-reader or keyboard support, 'доступность', or before shipping a page, form or modal. Reports; never edits files. Do not use for conversion structure (awesome-landing-audit) or discoverability (awesome-seo-audit).
awesome-content-graphics
Produces post graphics offline: a user-chosen set size (5, 25, 50, 100 or any number) of self-contained HTML/CSS variants rendered locally to PNG across a type-led family of statements, tinted-glyph canvases, display-scale number lockups and readable data figures, built from the supplied facts and the user's own look inputs (brand palette, reference images, an approved render). The source may be a URL, file or text in any language, and three gates settle it: which language the canvas speaks, the headline before anything is drawn, and — when a post skill called — which render ships. Called on its own it hands over the whole set and offers another batch. No image service, no API key, nothing uploaded. Use when asked to make an image or graphic for a post or campaign, 'сделай картинку для поста', or whenever awesome-content-campaign or awesome-content-repurpose reach a platform that cannot post without media. Do not use for photographic scenes, illustrated characters, video, or writing the posts themselves.
awesome-database-audit
Read-only audit of a database layer — schema anti-patterns (EAV, generic keys, imprecise types), query and index fit (SELECT *, N+1, unindexable predicates), integrity and concurrency, migration and tenancy hygiene — with evidence per finding and a SHIP / FIX / BLOCK verdict. Use when asked to audit the database, review the schema or migrations, judge a data model, or 'проверь схему базы'. Never edits schema or data. Do not use for runtime profiling (awesome-performance-audit), SQL injection (awesome-security-audit), or data-access style (awesome-code-standards).
awesome-git-commit-plan
Turns a codebase into a commit plan: a navigation map of its modules and their dependency direction, then a split where every commit builds and tests on its own, so the series is bisectable end to end. Each commit is verified by replaying the ladder in a scratch clone against the repo's own gates. Output is one plan file numbered #1 to #N, no dates. Takes a repository URL or local path. Use when asked to split a project into commits, plan a commit history, or 'разбей проект на коммиты'. Do not use to execute the plan (awesome-git-history-rebuild) or to review a diff (awesome-code-review).
awesome-bug-fix
Debugs by building a runnable pass/fail reproduction, isolating the root cause, then fixing — no fixes without root cause first. Use when fixing a bug, investigating a test or build failure, when the user reports an error, crash or flaky behavior, or 'не работает'. Use especially under time pressure or after several failed fix attempts. Do not use for feature work with no failing behavior to explain, or for slowness and memory growth (awesome-performance-audit).
awesome-code-review-feedback
How to respond to code review feedback: verify before implementing, clarify unclear items, and push back with technical reasoning when needed. Use when asked to address a review, when reviewer or bot findings need answering, or 'ответь на ревью'. Applies to any team or culture. Do not use for performing the review itself (awesome-code-review).
awesome-error-standards
Applies consistent error handling and user-facing messages: typed errors, operational-vs-programmer classification, API error envelopes, HTTP status mapping. Use when adding or refactoring error handling, designing an API error contract, reviewing failure paths, or 'обработка ошибок'. Do not use for log format, levels or PII redaction (awesome-logging-standards).
awesome-grammar-check
Advisory copy-edit of prose — reports grammar, logic and flow issues as suggestions without rewriting the text. Use when asked to proofread or copy-edit an article, email, doc or post, or 'проверь грамматику', and the author wants to keep control of the wording. Do not use for removing AI voice and markers (awesome-humanize-en) or for rewriting and de-bloating Markdown in place (awesome-document-style).
awesome-logging-standards
Applies structured logging, levels, PII handling, and wide-event (canonical log line) patterns. Use when adding or reviewing logs, choosing log levels, designing request logging, after an incident where logs were insufficient or leaked data, or 'логирование'. Do not use for designing the error contract or retry policy itself (awesome-error-standards).
awesome-translate-ru-en
Translates Russian text of any genre into natural English, preserving every structural element, formatting marker, link, identifier, and the author's voice. Use when translating Russian articles, docs, prose, marketing or technical text, when mirroring a directory of Russian files into an English one, or on 'переведи на английский'. Do not use for removing AI voice from text already in English (awesome-humanize-en).
awesome-git-history-reset
Erases a repository's entire git history and replaces it with a single fresh commit, then force-pushes — safely: access checks, a verified mirror backup, a secret scan, and a confirmation gate before anything irreversible. Takes a repository URL. Use when asked to wipe git history, squash every commit into one Initial commit, start the history fresh, or 'очистить историю git'. Do not use to squash a feature branch before merge (an interactive rebase) or to remove one secret from history (git-filter-repo plus rotation).
awesome-api-design
Designs or reviews the shape of an HTTP API before code exists — resources, versioning, pagination, idempotency, filtering, and where the error contract plugs in. Use when asked to design or review an API, decide versioning or pagination, add an endpoint at the design stage, 'спроектируй API', or when awesome-design-doc needs the contract detailed. Do not use for the error envelope itself (awesome-error-standards), vulnerability review of handlers (awesome-security-audit), or auditing an implemented architecture (awesome-architecture-audit).
awesome-dependency-upgrade
Plans and executes dependency upgrades safely — batching by risk, changelog-driven major migrations, overrides for unfixed CVEs, verification between steps, one revertable commit per batch. Use when asked to upgrade or bump dependencies, act on an awesome-dependency-audit report, or 'обнови зависимости'. Do not use for detection and risk assessment (awesome-dependency-audit); adding a brand-new dependency is an ask-first decision outside this skill.
awesome-design-doc
Produces a design document or ADR for a feature or architectural decision: requirements and scale numbers first, real alternatives with trade-offs, a recommendation grounded in the requirements, explicit non-goals and migration path. Use when asked to write a design doc, write an ADR, decide which approach to take, run a pre-mortem on a plan before committing to it, 'спроектируй', 'сделай pre-mortem', or when awesome-code-review requests an ADR for a load-bearing decision. Do not use for auditing an existing architecture (awesome-architecture-audit) or for HTTP resource modeling detail (awesome-api-design).
awesome-copywriting
Writes the short copy a product ships on its own surfaces: headlines and page titles, meta and store descriptions, button, empty-state and error microcopy, email subject lines, CTAs. Starts from the reader's state at the moment the line reaches them and the plainest way to say the thing; runs an ICP/category/story intake that probes for quality rather than filled fields, gates a weak story before drafting, and delivers variants with a pick justified by that reader state. Use when asked to write or punch up a headline, product description, button label, empty state, error message, subject line or CTA, or 'напиши заголовок', 'текст кнопки', 'текст для лендинга'. Do not use to edit prose that already exists (awesome-humanize-en, awesome-document-style), to write scheduled social posts (awesome-content-campaign, awesome-content-repurpose), or to audit a page's conversion structure (awesome-landing-audit).
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.