agentleFS
YassimbaYassimba/loom/skills/clarify-code/SKILL.md

clarify-code

Skill9 starsChanged 2 months agoApache-2.0View on GitHub

First-read clarity for working code: rename opaque identifiers and align nearby prose while preserving behavior and architecture. Use when a newcomer cannot infer purpose from the local code.

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    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:

    Use the project's established domain vocabulary.

    line 24
  2. Distinctive:

    Keep existing abstractions, control flow, validation, and error behavior in place.

    line 31
  3. Distinctive:

    Update project context only when shared vocabulary or a user-facing workflow changed.

    line 37
  4. Distinctive:

    Search for every old name.

    line 41

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 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

First Read

Make the requested scope self-explanatory to a reader with no prior context. This is a semantic-preserving clarity pass.

Map Meaning

Trace the target end to end: definitions, callers, tests, inputs, and outputs. Classify each identifier in the requested scope:

  • Precise — its meaning is clear at the use site; keep it.
  • Opaque — the code owns it, but a reader must inspect its implementation or remember hidden context; rename it.
  • Contract — storage, wire, CLI, environment, public API, or third-party vocabulary; preserve it or migrate it only when requested.

Build a rename map from each opaque name to its meaning, owner, and complete use set. This step is complete when every identifier in scope has one classification and every rename has a known blast radius.

Rename Concepts, Not Words

Rename at the owning definition, then update every caller, test, type annotation, and relevant document.

  • Use the project's established domain vocabulary.
  • Name values for the concept they hold and functions for the result or state change they provide.
  • Include a role, state, unit, or collection distinction only when the use site needs it.
  • Choose the shortest name that is unambiguous at the use site; local context already supplies the rest.
  • Replace an opaque tuple or dictionary with a typed record only when its structure otherwise has to be memorized.
  • Change a requested public code name directly. Add a compatibility alias only when compatibility is requested.

Keep existing abstractions, control flow, validation, and error behavior in place. Report any separate design problem instead of folding it into this pass.

Align Prose

Invoke write-simply. Make nearby docstrings and comments agree with the new vocabulary. Keep prose that states purpose, contract, invariant, or a necessary reason. Remove narration and correct stale claims.

Update project context only when shared vocabulary or a user-facing workflow changed. An internal rename ends at its callers and focused documentation.

Read It Cold

Search for every old name. Run the focused checks that cover the changed seams, then the repository's required gate. Read the diff without relying on the rename map: each changed name must reveal the concept or action at its use site.

Done means the rename map is fully applied, old names are absent, contract names changed only by request, the diff preserves behavior, and all required checks pass.

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.