agentleFS
Sign inStart free
mattmirelesmattmireles/gemma-tuner-multimodal/.claude/skills/documentation/SKILL.md

documentation

Skill1.5k starsChanged 4 days agoMITView on GitHub

Write or review inline code documentation that captures domain knowledge, non-obvious constraints, non-greppable cross-file contracts, and state lifecycle. Use when the task is adding or reviewing docstrings, module headers, constant rationale, or training/data invariants. Do not use for README files, markdown guides, plan documents, or code changes where comments are incidental.

We split this skill into the rules it gives an agent

5 rules. 0 are common, 4 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 95 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read references/index.md first.

    line 27
  2. Distinctive:

    Add or tighten docs only where they capture:

    line 30
  3. Distinctive:

    Prefer short, durable comments over boilerplate:

    line 35
  4. Distinctive:

    Do not add manual call graphs, line-by-line prose, or comments that are more likely to drift than to help.

    line 39
  5. Very specific:

    If the missing context belongs in a canonical guide, update the guide under README/guides/ instead of burying the whole explanation in code …

    line 41

“Common” is measured: kept by at least 6 in 10 of the 95 edited versions of this file we could read. “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

Documentation

Purpose

Enforce the repo's inline code documentation standards. Document what a future editor cannot safely derive from the code itself.

Use When

  • Adding or reviewing module/class/function docstrings or short file headers.
  • Documenting training state, checkpoint, or config invariants.
  • A review flags missing or low-quality documentation.

Do Not Use When

  • Writing README, plan, or notes documents.
  • General code changes where documentation isn't the focus.
  • Markdown formatting issues (use markdown).

Procedure

  1. Read references/index.md first.
  2. Inspect the target file and the smallest set of related files needed to confirm what context is truly missing.
  3. Add or tighten docs only where they capture:
    • domain knowledge
    • non-obvious constraints
    • non-greppable cross-file contracts
    • state lifecycle or constant rationale
  4. Prefer short, durable comments over boilerplate:
    • short file headers when a whole module has one responsibility story
    • docstrings that explain why or constraints—not a rephrasing of the signature
    • notes on MPS vs CUDA assumptions when non-obvious
  5. Do not add manual call graphs, line-by-line prose, or comments that are more likely to drift than to help.
  6. If the missing context belongs in a canonical guide, update the guide under README/guides/ instead of burying the whole explanation in code comments.

References

Read references/index.md first.

Handoff Rules

  • Hand off to debug if the problem is a runtime defect, not missing docs.
  • Hand off to markdown for prose-heavy documentation files.

Download now (ZIP)

  • Other versions106 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 106

    1. anthropics/knowledge-work-plugins★ 34ksame name
    2. comet-ml/opik★ 23ksame name
    3. mozilla-firefox/firefox★ 14ksame name
    4. microsoft/fast★ 9.7ksame name
    5. mufeedvh/code2prompt★ 7.7ksame name
    6. BrowserWorks/waterfox★ 6.3ksame name
    7. samchon/typia★ 6ksame name
    8. github/gh-aw★ 5.5ksame name
    9. epicenter-md/epicenter★ 4.8ksame name
    10. EpicenterHQ/epicenter★ 4.8ksame name

    96 more not listed

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use project-preferences, response-style and 10 more.

    Other files people use alongside this one.

    Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
    • DepressionCenterSkill

      project-preferences

      Apply repository-specific preferences when planning, implementing, or reviewing changes in this project.

      Also in 4 projects that use this

    • DepressionCenterSkill

      response-style

      Write prose in plain, natural English. Apply to every response, design discussion, review comment, commit message, pull request, and document, in any task.

      Also in 4 projects that use this

    • BrowserWorksSkill

      accessibility-frontend-review

      Performs an accessibility code review of a local diff or Phabricator revision in the style of the Firefox accessibility team. Use this skill whenever the user asks to review a Phabricator patch or revision for accessibility issues, mentions a D-number (like D284142) in the context of accessibility review, asks "does this patch have any a11y issues", or wants to check a diff against accessibility guidelines. Also use it when the user says things like "can you review this for a11y", "check this patch", or "give me an accessibility review of D[number]". Invoke proactively when the user pastes a phabricator.services.mozilla.com URL or shares a revision ID alongside any accessibility concern. Invoke when questions about the following topics are raised: aria properties, aria roles, high contrast mode, forced colors, prefers contrast, focus order, screen readers, assistive technology.

      Also in 4 projects that use this

    • BrowserWorksSkill

      android-new-module

      Guide for creating new Android gradle modules in the android-components project.

      Also in 4 projects that use this

    • +8 more from BrowserWorks
  • In this repository20 other files it gives its agents.

Does it work?

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

Reviews can't be read right now.

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.

Check your setup, free