agentleFS
epicsagasepicsagas/epic-harness/skills/document/SKILL.md

document

Skill20 starsChanged 2 months agoApache-2.0View on GitHub

Documentation generator for public APIs, functions, and modules. Use when exports, signatures, or new modules are added or changed.

54 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use develop, scope and 7 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.
  • hong9LeeSkill

    develop

    빌드, 아키텍처, git 관련 작업 시 OMS MSA 공통 인프라 규칙을 적용한다. 기술 스택, 빌드 명령, 헥사고날 아키텍처 구조, git 워크플로우, AI Context 동기화 규칙을 다룬다. 코드 작성 컨벤션은 /convention, 테스트 컨벤션은 /test-guide 스킬을 참조.

    Also in 5 projects that use this

  • YuriNachosSkill

    scope

    Configure claude-scope status line widgets for Claude Code. Use when user wants to customize widgets, change theme, reorder elements, or modify display style.

    Also in 5 projects that use this

  • ralphkraussSkill

    resolve-conflicts

    Resolve git merge conflicts or re-apply changes from a stale branch onto current main. Use when user says "resolve conflicts", "merge conflicts", "rebase branch", "branch is behind", "re-apply changes", "port branch", or a branch is too far behind main to merge cleanly.

    Also in 3 projects that use this

  • MicrosoftSkill

    sync

    Sync the current session branch with its upstream branch, or publish the current session branch to a remote. Use when the user asks to sync a branch, pull latest changes, rebase onto upstream, push current branch, publish branch, or set upstream.

    Also in 5 projects that use this

  • kt057Skill

    check

    lint, typecheck, test を一括実行して結果をサマリーする

    Also in 7 projects that use this

  • Microsoft AzureSkill

    test

    Also in 12 projects that use this

The file

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 50 edited versions we read keep these.

  • 2

    Distinctive

    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:

    Follow the project's existing doc style.

    line 24
  2. Distinctive:

    Before claiming documentation is done, show ALL applicable:

    line 75

“Common” is measured: kept by at least 6 in 10 of the 50 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

Document — Auto-Documentation

When to Trigger

  • New public function, class, or API endpoint
  • Function signature changed (params added/removed)
  • Module purpose unclear from code alone
  • User explicitly asks for documentation

Process

1. Detect what changed

  • New exports? → Add JSDoc/docstring
  • Changed params? → Update existing docs
  • New file? → Add module-level doc comment

Why: Undocumented changes are the most common source of onboarding friction. Catching every diff ensures no public surface is left without context.

2. Write docs

Follow the project's existing doc style. If none exists:

TypeScript/JavaScript:

/**
 * Brief description of what this does.
 *
 * @param name - Description of parameter
 * @returns Description of return value
 * @throws ErrorType - When this happens
 *
 * @example
 * const result = myFunction("input");
 */

Python:

def my_function(name: str) -> str:
    """Brief description.

    Args:
        name: Description of parameter.

    Returns:
        Description of return value.

    Raises:
        ValueError: When this happens.
    """

Why: Consistent doc style across the project reduces cognitive load for every reader. Inlining examples prevents the "how do I call this?" round-trip.

3. Don't over-document

  • Skip obvious getters/setters
  • Skip internal/private helpers unless complex
  • Code should be self-documenting first, comments second

Why: Noise docs train readers to ignore all comments. Document only where the code cannot speak for itself.

Anti-Rationalization

ExcuseRebuttalWhat to do instead
"The code is self-documenting"Good naming helps readers, but doesn't explain intent, constraints, or edge cases.Document the why, the constraints, and the non-obvious.
"I'll document it later"Later never comes. If it's worth exporting, it's worth documenting now.Document as you write. Updating is cheaper than reconstructing intent.
"Docs go stale anyway"Stale docs are better than no docs. They at least signal intent. Keep them in sync with code changes.Put docs near code (JSDoc/docstring). They update with the code.

Evidence Required

Before claiming documentation is done, show ALL applicable:

  • Every new public function/class has a doc comment (show one example)
  • Changed signatures have updated docs (show the diff)
  • @param / @returns / @throws present for non-trivial functions
  • At least one @example for complex APIs

"I added docs" without showing them = not documented.

Red Flags

  • Comments that restate the code: // increment i → i++
  • Outdated comments that contradict the code
  • Missing docs on public API that others will call

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.

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.