agentleFS
tiago-oliveira-catiago-oliveira-ca/zenodotus-harness/skills/zeno-stack/zeno-comment-analysis/SKILL.md

zeno-comment-analysis

Skill1 starsChanged 8 days agoMITView on GitHub

Audit inline code comments for accuracy against the implementation, coverage of non-obvious logic, low-value restatement, staleness, and misleading claims — read-only, reports findings rather than rewriting comments. Trigger on: "check the comments", "comment rot", "are these comments accurate", "stale comments", "TODO/FIXME audit", "comment review".

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Does it match the code it describes?: Read the comment's claim, then the implementation it's attached to.

    line 18

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Comment Accuracy & Rot Audit

A comment is a claim about the code that the compiler never checks. Read each comment against the code it describes and judge whether it's still true, still useful, and worth the maintenance burden of keeping it true.

What to check per comment

Does it match the code it describes? Read the comment's claim, then the implementation it's attached to. Check parameter/return descriptions against what the function actually takes and returns. Flag anything referencing a function, file, or behavior that no longer exists.

Does it cover what actually needs explaining? Complex or non-obvious logic should give a reader enough context that they don't have to reverse-engineer intent from the code alone. Side effects and edge cases not visible from the signature deserve a mention.

Is it worth keeping as-is? A comment that just restates the line below it in English adds reading time without information — flag as low-value. A comment tightly coupled to implementation details that change often will go stale fast. Surface TODO/FIXME/HACK markers as unresolved debt worth tracking, not noise to skim past.

Does it actively mislead? The most damaging category — a comment that contradicts what the code does is worse than no comment, because a reader trusts it by default.

Output format

Group findings by severity, most damaging first:

  • Inaccurate — actively contradicts the code
  • Stale — describes something that no longer exists
  • Incomplete — real logic/side-effects/edge-cases with no explanation
  • Low-value — adds no information beyond what the code already says

For each finding: location, a one-line description of the gap, and — where it's a quick fix — the corrected wording. This is read-only: propose corrected wording, don't rewrite comments in place.

Agent counterpart: agents/zeno-comment-analyzer.md — the spawned standalone audit over this same taxonomy (this skill is its Codex fold home).

Anti-pattern quick reference

Anti-patternInstead
Flagging every comment as equally importantGroup by severity — inaccurate/misleading first
Rewriting comments directly during the auditReport only; hand corrections to the human or the owning implementation work
Treating a TODO as noise to skipSurface it as tracked debt
Auditing external docs (README, API reference) hereThat's documenting-code's domain, not this one

Pre-flight checklist — run before delivering any comment-accuracy report

  • Every flagged comment names its category (Inaccurate/Stale/Incomplete/Low-value).
  • Each finding has a location and a one-line gap description.
  • Quick fixes include corrected wording, without editing the file directly.
  • External/generated documentation drift was routed to documenting-code, not folded in here.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.