khasky
UserSkills for AI coding agents: code review, debugging, security audits, refactoring, cleaning up AI-written code and text, and more.
Categories
Indexed Skills (31)
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-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).
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 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.
awesome-code-cleanup
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.
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 receiving PR feedback or review comments. Applies to any team or culture.
awesome-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 awesome-code-review-feedback) or for docs-only and formatting-only changes.
awesome-code-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.
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, or make Markdown read like careful human editorial writing. Do not use to fabricate facts or bypass detectors.
awesome-error-standards
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', 'обработка ошибок'.
awesome-grammar-check
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).
awesome-humanize-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).
awesome-landing-audit
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).
awesome-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'.
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 when the user says 'logging', 'log format', 'what should we log', 'логирование'.
awesome-performance-audit
Read-only audit of server/runtime performance and reliability — event-loop discipline, streaming and backpressure, memory/CPU diagnostics, and production shutdown/timeout/job habits — producing evidence-backed findings and a SHIP / FIX / BLOCK verdict. Use when the user asks to 'audit performance', 'why is the service slow', 'memory keeps climbing', 'tail latency is bad', 'the worker OOMs', 'is this ready for load', or 'review this for throughput'. It audits and reports; it does not rewrite hot paths. Do not use for retry/backoff/idempotency contracts (use awesome-error-standards) or frontend render/animation perf (use awesome-code-standards).
awesome-root-cause
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.
awesome-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 awesome-leak-audit for that.
awesome-seo-audit
Read-only SEO and AI-discoverability audit of a site or codebase — technical SEO, generated-page (programmatic SEO) safety, and agent/LLM readability — producing evidence-backed findings and a SHIP / FIX / BLOCK verdict. Use when the user asks to 'audit my SEO', 'check for thin content / cannibalization', 'will Google penalize these pages', 'am I blocking GPTBot/ClaudeBot', 'llms.txt', 'AI discoverability', 'will LLMs see my site', or 'is my site agent-readable'. It audits and reports; it does not write content or edit files.
awesome-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.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.