skills/code-comments/SKILL.md
Write clear, plain-spoken code comments and documentation that lives alongside the code. Use when writing or reviewing code that needs inline documentation—file headers, function docs, architectural decisions, or explanatory comments. Optimized for both human readers and AI coding assistants who benefit from co-located context.
npx skillsauth add petekp/claude-skills code-commentsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Write documentation that lives with the code it describes. Plain language. No jargon. Explain the why, not the what.
Co-location wins. Documentation in separate files drifts out of sync. Comments next to code stay accurate because they're updated together.
Write for three audiences:
The "why" test: Before writing a comment, ask: "Does this explain why this code exists or why it works this way?" If it only restates what the code does, skip it.
Every file should open with a brief explanation of its purpose and how it fits into the larger system.
// UserAuthContext.tsx
//
// Manages authentication state across the app. Wraps the root component
// to provide login status, user info, and auth methods to any child.
//
// Why a context instead of Redux: Auth state is read-heavy and rarely
// changes mid-session. Context avoids the ceremony of actions/reducers
// for something this simple.
// NetworkRetryPolicy.swift
//
// Handles automatic retry logic for failed network requests.
// Uses exponential backoff with jitter to avoid thundering herd
// when the server comes back online after an outage.
//
// Used by: APIClient, BackgroundSyncManager
// See also: NetworkError.swift for error classification
Include:
Document the contract, not the implementation.
/**
* Calculates shipping cost based on weight and destination.
*
* Uses tiered pricing: under 1lb ships flat rate, 1-5lb uses
* regional rates, over 5lb triggers freight calculation.
*
* Returns $0 for destinations we don't ship to rather than
* throwing—caller should check `canShipTo()` first if they
* need to distinguish "free shipping" from "can't ship."
*/
function calculateShipping(weightLbs: number, zipCode: string): number
def sync_user_preferences(user_id: str, prefs: dict) -> SyncResult:
"""
Pushes local preference changes to the server and pulls remote changes.
Conflict resolution: server wins for security settings, local wins
for UI preferences. See PREFERENCES.md for the full conflict matrix.
Called automatically on app foreground. Can also be triggered manually
from Settings > Sync Now.
"""
Include:
Skip for: Simple getters, obvious one-liners, private helpers with descriptive names.
Use sparingly. When you need them, explain the reasoning.
// Debounce search by 300ms to avoid hammering the API on every keystroke.
// 300ms feels responsive while cutting API calls by ~80% in user testing.
const debouncedSearch = useMemo(
() => debounce(executeSearch, 300),
[executeSearch]
);
// Force unwrap is safe here—viewDidLoad guarantees the storyboard
// connected this outlet. If it's nil, we want to crash immediately
// rather than fail silently later.
let tableView = tableView!
# Process oldest items first. Newer items are more likely to be
# modified again, so processing them last reduces wasted work.
queue.sort(key=lambda x: x.created_at)
For code that embodies important design decisions, explain the tradeoffs.
// ARCHITECTURE NOTE: Event Sourcing for Cart
//
// Cart state is rebuilt from events (add, remove, update quantity)
// rather than stored directly. This lets us:
// - Show complete cart history to users
// - Replay events for debugging
// - Retroactively apply promotions to past actions
//
// Tradeoff: Reading current cart state requires replaying all events.
// We cache the computed state in Redis with 5min TTL to keep reads fast.
// Cache invalidation happens in CartEventHandler.
// WHY COORDINATOR PATTERN
//
// Navigation logic lives here instead of in view controllers because:
// 1. VCs don't need to know about each other (loose coupling)
// 2. Deep linking becomes straightforward—just call coordinator methods
// 3. Navigation is testable without instantiating UI
//
// The tradeoff is more files and indirection. Worth it for apps with
// 10+ screens; overkill for simple apps.
Make them actionable and traceable.
// TODO(pete): Extract to shared util once mobile team needs this too.
// Blocked on: Mobile API parity (see MOBILE-123)
// HACK: Workaround for Safari flexbox bug. Remove after dropping Safari 14.
// Bug report: https://bugs.webkit.org/show_bug.cgi?id=XXXXX
// FIXME: Race condition when user rapidly toggles. Need to cancel
// in-flight requests. Reproduced in issue #892.
See references/language-examples.md for detailed examples in:
Plain language. Write like you're explaining to a smart colleague who doesn't have context.
Active voice. "This function validates..." not "Validation is performed..."
Be specific. "Retries 3 times with 1s backoff" not "Handles retries."
Skip the obvious. If the code says user.isAdmin, don't comment "checks if user is admin."
Date things that expire. Workarounds, version-specific code, and temporary solutions should note when they can be removed.
Reference constants, don't duplicate values. When a behavior is controlled by a constant, reference it by name—don't restate its value in the comment.
// Bad: duplicates the value, will drift when constant changes
/// Returns true if stale (not updated in last 5 minutes)
pub fn is_stale(&self) -> bool { ... }
// Good: references the constant
/// Returns true if stale (not updated within [`STALE_THRESHOLD_SECS`])
pub fn is_stale(&self) -> bool { ... }
Unit translations for magic numbers are fine (1048576 // 1MB) since they add clarity, not duplication.
development
Draft short, plainspoken notes in the author's voice that help reviewers understand non-obvious choices, boundaries, and preserved behavior in the author's own pull request or local diff. Use when the user asks to self-review, annotate, or add reviewer context to their PR or changes. Draft locally when no PR exists, and post approved notes as one GitHub review when a PR does exist. Do not use for reviewing someone else's PR, writing code comments, explaining code generally, or drafting a PR description. Never post without explicit approval.
tools
Design and build pure-CSS (zero-JavaScript) Tailwind CSS v4 plugins of unusual depth and craft. Use when the user wants to create, architect, or refine a Tailwind utility plugin or CSS effect — e.g. "make a tailwind plugin", "build a tw-* plugin", "a CSS-only shimmer/fade/glow/grain/noise utility", "tailwind v4 @utility", "package this effect as a plugin", or wants an effect with surprising visual depth (gradients, masks, filters, SVG filter tricks, scroll-driven animation). Pairs deep CSS/SVG technique research with a bespoke tuning workbench for dialing the effect in. Inspired by tw-fade and tw-shimmer.
content-media
Create clear, polished before-and-after screenshots for a GitHub pull request. Use when a UI change needs visual proof: capture matching states, crop to the relevant UI, stitch and caption one comparison image, attach it natively to the PR, and keep the image out of the repository.
testing
--- name: latent-potential description: First-principles, team-of-experts assessment of a software project that surfaces latent potential; underexploited assets, a sharper north star, missing high-leverage capabilities, better framing and messaging. Produces a prioritized, evidence-grounded report with cheap probes, a reframe candidate, a stop-doing list, and an honest skeptic's case. Use whenever the user wants fresh eyes on a project they have built: "what am I sitting on", "what could this be