// Universal commenting and documentation conventions across all languages. Load when writing or reviewing substantial comments, docstrings, file headers, or migration documentation. Project-specific commenting standards in `docs/commenting-standard.md` (when present) extend or override this baseline.
Exhaustive post-work audit for any codebase. Run after finishing a feature, sprint, bug fix, or refactoring pass to find overlooked edge cases, discarded response data, missing cross-field validations, misleading success signals, untested failure paths, and implicit assumptions. Invoke with /deep-audit or /deep-audit followed by context. Use this skill whenever the user says audit, review my changes, check my work, what did I miss, post-mortem, sanity check, edge cases, or asks to verify completeness of recent code changes.
Use when modifying the agentic coding environment, including dotfiles, skills/rules wiring, AGENTS.md/CLAUDE.md loading, Stow symlinks, Claude/Codex/OpenCode/Pi config, plugins, MCP, hooks, or harness compatibility. Loads the runbook to avoid breaking cross-harness setup. Defer to skill-creator-global for skill authoring craft, description quality, and progressive disclosure.
Retrieves up-to-date documentation, API references, and code examples for any developer technology via the ctx7 (Context7) CLI. Use this skill whenever the user mentions "ctx7" or "context7", or asks about a specific library, framework, SDK, CLI tool, or cloud service -- even for well-known ones like React, Next.js, Prisma, Express, Tailwind, Django, or Spring Boot. Your training data may not reflect recent API changes or version updates. Always use for: API syntax questions, configuration options, version migration issues, "how do I" questions mentioning a library name, debugging that involves library-specific behavior, setup instructions, and CLI tool usage. Use even when you think you know the answer -- do not rely on training data for API details, signatures, or configuration options as they are frequently outdated. Always verify against current docs. Prefer this over web search for library documentation and API details.
Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.
Create, revise, or review Agent Skills for authoring quality. Use when writing SKILL.md content, improving skill descriptions and trigger words, deciding what belongs in SKILL.md versus references/scripts, or diagnosing why a skill over-triggers or under-triggers. Defer to agentic-coding-harnesses for dotfiles, Stow, symlinks, harness visibility, AGENTS.md, plugins, MCP, or environment wiring.
Search, scrape, and interact with the web via the Firecrawl CLI. Use this skill whenever the user wants to search the web, find articles, research a topic, look something up online, scrape a webpage, grab content from a URL, get data from a website, crawl documentation, download a site, or interact with pages that need clicks or logins. Also use when they say "fetch this page", "pull the content from", "get the page at https://", or reference external websites. This provides real-time web search with full page content and interact capabilities — beyond what Claude can do natively with built-in tools. Do NOT trigger for local file operations, git commands, deployments, or code editing tasks.
| name | commenting |
| description | Universal commenting and documentation conventions across all languages. Load when writing or reviewing substantial comments, docstrings, file headers, or migration documentation. Project-specific commenting standards in `docs/commenting-standard.md` (when present) extend or override this baseline. |
Comments are part of the codebase. Write fewer; make them count.
Comments explain why, code explains what. If a comment just restates the code, delete it and rename the variable, function, component, or file. A good identifier eliminates the need for the comment.
// TODO(av1155, BAI-247): restore jsx-a11y rules once v7 ships. A bare // TODO is dead weight.const i = 0; // initialize i).// 2026-04-15: fixed bug). That belongs in the commit message.// it took a live incident to find this, // after debugging we realized..., // we originally tried X but...). State the constraint; reference the ticket. The story belongs in the PR description or postmortem, not the source.// ===== SECTION =====). Module structure already does this. SQL migrations and globals.css are the documented exceptions where banners help readability.// this is hacky but...). Either fix it or open a ticket.amountCents: number; // amount in cents).// Claude refactored this from useEffect to useReducer). The diff already shows it.// verified, // post-fix verification).// for short notes. Two leading spaces before inline //. Never duplicate a TypeScript signature inside the doc; the signature is the source of truth. Forbidden tags: @type, inline @param {type} (TypeScript already owns types). See the typescript rule for full details.Args:, Returns:, Raises: sections. Don't repeat type hints in the docstring. See the python rule for full details./* ... */. Comment the intent of token groups, not the value. Never comment individual utility classes; the class name is the doc. Long class strings (>10-12 utilities) signal an extraction, not a comment.-- for non-obvious indexes, cascade choices, RLS predicates, partial-index predicates. Decorative section banners are tolerated in long migration files for readability.# comments. Comment non-default settings only (a non-default tracesSampleRate, a paths-ignore, a runner.environment gate). Don't comment image:, restart:, WORKDIR.<!-- --> for structural markers only. Use {# ... #} for developer notes in Jinja; <!-- --> ships to the browser. Never put secrets in HTML comments..md. JSON-with-comments (.jsonc) is the exception.#!/usr/bin/env bash then set -euo pipefail then a header comment block (purpose, required env vars, exit codes). Always comment any || true, 2>/dev/null, trap, or subshell construct. These are where bugs hide.<!-- --> sparingly (TOC markers, <!-- markdownlint-disable -->). Don't hide prose in HTML comments. Front-matter (---) is acceptable for tooling that consumes it.Format: <TAG>(<author>, <tracker-ID>): <description>.
TODO: known work to do.FIXME: bug to fix.HACK: deliberate workaround; explain why and what would let it go.XXX: warning to future readers (uncommon, reserve for genuine landmines).The tracker ID is a Linear / Jira / GitHub issue number, not a date or a vague "later". A TODO without a tracker is a comment that will rot.
Always carry a reason:
// eslint-disable-next-line <rule> — name the specific rule, never bare.// @ts-expect-error <reason> — one-line justification, never bare.# type: ignore[code] — specific error code, never bare.# noqa: <rule> — specific ruff rule, never bare.A bare disable directive is a code smell; the next reader has no way to know if it is still needed.
If you cannot answer "yes" to question 4, the comment is probably dead weight.
A project's docs/commenting-standard.md (or equivalent) extends or overrides this baseline. If the project has stack-specific rules (TSDoc tag policy, Sphinx domain choice, Rustdoc style), follow those. This skill is the floor, not the ceiling.