Software Development Skills

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). Do not use for conversion structure (use awesome-landing-audit) or search discoverability (use awesome-seo-audit).

Designs or reviews the shape of an HTTP API before code exists — resource modeling, versioning strategy, pagination, idempotency, filtering, and how the error contract plugs in. Use when asked to 'design the API', 'review my API design', 'how should we version / paginate', 'add an endpoint' at the design stage, or when awesome-design-doc needs the API contract detailed. Do not use for the error envelope internals and retry semantics — use awesome-error-standards; not for auth/injection review of implemented handlers — use awesome-security-audit; not for auditing an implemented codebase's architecture — use awesome-architecture-audit.

Read-only whole-project deep audit — architecture and module boundaries, documentation-vs-code fidelity, design-principle adherence (YAGNI/KISS/SOLID), and extensibility (how easily someone builds from source and adds a new provider/plugin/adapter) — producing a prioritized report with a SHIP / FIX / BLOCK verdict. Framework- and language-agnostic. Use when the user asks to 'audit/analyze the architecture', 'review the whole codebase design', 'does the code match the README/docs', 'how hard is it to add a new X', 'is this codebase ready to build on', or 'проведи глубокий анализ проекта', 'оцени архитектуру', 'соответствует ли код документации'. Do not use for a single diff/PR (use awesome-code-review), a named vulnerability (awesome-security-audit), runtime latency/memory (awesome-performance-audit), public-client disclosure (awesome-leak-audit), comment/naming cleanup (awesome-code-cleanup), or design-stage shaping of a new system or API (awesome-design-doc, awesome-api-design).

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.

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 (code, not prose), 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. Do not use to de-slop prose, Markdown, or documentation text — use awesome-humanize-en or awesome-document-style for that.

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 awesome-code-review-feedback) or for docs-only and formatting-only changes.

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, when reviewer or bot findings need addressing, or when the user says 'address the review', 'ответь на ревью', 'поправь по замечаниям'. Applies to any team or culture. Do not use for performing the review itself — use awesome-code-review.

Universal coding standards: naming, structure, immutability, error handling, type safety, plus backend layering and frontend architecture/motion 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. Do not use for a repo-wide comment/noise cleanup pass (use awesome-code-cleanup) or for designing the API error contract (use awesome-error-standards).

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).

Read-only audit of a project's third-party dependencies — lockfile discipline, hallucinated and typosquatted package names (slopsquatting), dependency confusion, install-script exposure, maintenance and provenance, license conflicts, and CVE reachability — producing evidence-backed findings and a SHIP / FIX / BLOCK verdict. Use when the user asks to 'audit dependencies', 'check the supply chain', 'is this package safe', 'проверь зависимости', to review a package.json/requirements/go.mod change, before adding a dependency, or after a bot PR bumps versions. Do not use for vulnerabilities in the project's own source code (use awesome-security-audit), for CI workflow hardening (its CI/CD category covers that), or to execute the upgrades the audit calls for — use awesome-dependency-upgrade; this skill audits the dependency graph itself.

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 dependencies', 'bump packages', 'fix the audit findings', 'update to the latest version', 'обнови зависимости', or to act on an awesome-dependency-audit report. Do not use for detection and risk assessment — use awesome-dependency-audit; adding a brand-new dependency is an ask-first decision outside this skill.

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', 'design this feature/system', 'which approach should we take', 'спроектируй', or when awesome-code-review requests an ADR for a load-bearing decision. Do not use for auditing an existing architecture — use awesome-architecture-audit; not for HTTP resource modeling details — use awesome-api-design.

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.

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', 'обработка ошибок'. Do not use for log format, levels, or PII redaction — use awesome-logging-standards.

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 an explicit confirmation gate before anything irreversible. Use when asked to 'wipe git history', 'squash all commits into one', 'reset history to a single Initial commit', 'start the history fresh', 'clean/erase the commit log', or in Russian 'очистить историю git', 'схлопнуть все коммиты в один', 'переписать историю с нуля'. Takes a repository URL: '/awesome-git-history-reset '. Do not use to squash a feature branch before merge (that's an interactive rebase) or to remove one secret from history (that's git-filter-repo + rotation).

Advisory copy-edit of prose — reports grammar, logic, and flow issues as suggestions without rewriting the text. Use when the user asks to 'check grammar', 'proofread', 'copy-edit', 'find errors in', or 'review the writing' of an article, email, doc, or post, and wants to keep control of the wording. Not for removing AI-generated voice/markers (use awesome-humanize-en) and not for rewriting or de-bloating Markdown in place (use awesome-document-style).

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, ?utmsource=chatgpt.com, oaicitation, grokcard://, vertexaisearch, turn0search, [citestart], [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).

Read-only, mechanical audit of a landing or marketing page's conversion structure — single primary CTA per view, form-field friction, ad-to-headline message match, trust/social-proof presence, above-the-fold value, and CLS-safe banners/interstitials — producing evidence-backed findings and a SHIP / FIX / BLOCK verdict per page. Use when the user asks to 'audit my landing page', 'why isn't this page converting', 'check the CTA / form / hero', or 'is this page conversion-ready'. Do not use for copy voice or persuasiveness (awesome-humanize-en, awesome-document-style), SEO / discoverability (awesome-seo-audit), or WCAG accessibility (awesome-accessibility-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', 'what does our API disclose', 'harden the client'. Do not use for server-side vulnerability hunting — use awesome-security-audit.

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', 'логирование'. Do not use for designing the error contract or retry policy itself — use awesome-error-standards.

Runs an authorization-gated penetration-test engagement against a target (repo, web app, API, network, cloud, or mobile client) following PTES, OWASP WSTG/MASTG/API Top 10, and NIST SP 800-115 — from scoping and rules of engagement through recon, attack-surface mapping, testing, exploitation-to-proof, and a findings report with CWE/CVSS and retest. Passive review of your own code needs no gate; any active probe, scan, or exploitation is hard-gated behind written authorization and scope. Use when the user says 'pentest', 'penetration test', 'pen test', 'red team', 'attack surface assessment', 'offensive security', 'OWASP WSTG', 'PTES engagement', 'проведи пентест', 'тест на проникновение'. Do not use for white-box static review of files or a diff — use awesome-security-audit; for what a public client discloses about its backend — use awesome-leak-audit; for dependency/supply-chain CVEs — use awesome-dependency-audit.

Read-only audit of performance and reliability — event-loop discipline, streaming and backpressure, memory/CPU diagnostics, production shutdown/timeout/job habits, cross-service resilience topology (circuit breakers, retry budgets, queue bounds, dual-writes), and frontend delivery (Core Web Vitals, bundle size, hydration) — producing evidence-backed findings and a SHIP / FIX / BLOCK verdict. Use when the user asks to 'audit performance', 'why is the service slow', 'why is my page slow', 'memory keeps climbing', 'tail latency is bad', 'the worker OOMs', 'is this ready for load', 'review this for throughput', or 'will this survive a dependency outage'. It audits and reports; it does not rewrite hot paths. Do not use for retry/backoff/idempotency header contracts (use awesome-error-standards — this skill audits the failure topology, that one owns the contract format) or for animation/render style standards (use awesome-code-standards — this skill measures, that one prescribes).

Structured root-cause analysis for incidents, recurring failures, and process problems that have no failing test to run — 5-Whys, fishbone, PDCA, and a one-page A3 write-up. Use for a postmortem, incident retro, 'why does this keep happening', quality or process breakdown, or 'find the root cause' of a non-code issue. For an actual code bug with a reproducible failure, use awesome-bug-fix instead.

Audits code for common vulnerabilities: injection, secrets, auth, dependency CVEs, CI/CD pipeline exposure, and cryptographic misuse — with confidence-gated, evidence-backed findings mapped to CWE/OWASP. Use when reviewing security, before a release, after adding auth/payments/sensitive-data handling, when hardening GitHub Actions or other CI workflows, 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 awesome-leak-audit for that.