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
- daledesilva/obsidian_inktheir own version, first seen Nov 9, 2026
- domengabrovsek/agent-configtheir own version, first seen Nov 8, 2026
- domengabrovsek/claudetheir own version, first seen Nov 8, 2026
- dimsedra/skillstheir own version, first seen Nov 8, 2026
- codewhale-hq/codewhale-plugin-marketplacetheir own version, first seen Nov 8, 2026
- jisuzzzz/haechitheir own version, first seen Nov 8, 2026
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.
hong9LeeSkilldevelop
빌드, 아키텍처, git 관련 작업 시 OMS MSA 공통 인프라 규칙을 적용한다. 기술 스택, 빌드 명령, 헥사고날 아키텍처 구조, git 워크플로우, AI Context 동기화 규칙을 다룬다. 코드 작성 컨벤션은 /convention, 테스트 컨벤션은 /test-guide 스킬을 참조.
Also in 5 projects that use this
YuriNachosSkillscope
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
ralphkraussSkillresolve-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
MicrosoftSkillsync
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
kt057Skillcheck
lint, typecheck, test を一括実行して結果をサマリーする
Also in 7 projects that use this
Microsoft AzureSkilltest
Also in 12 projects that use this
Other versions54 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 54
- Akylas/OSS-DocumentScanner★ 2.6ksame name
- jsmastery-pro/skills★ 1.4ksame name
- daledesilva/obsidian_ink★ 1.4ksame name
- adobe/S3Mock★ 1.2ksame name
- ZimoLiao/scholaraio★ 585same name
- vladikk/modularity★ 538same name
- Akylas/oss-weather★ 478same name
- spiriMirror/libuipc★ 351same name
- nitinjain999/platform-skills★ 71same name
- jsmastery-pro/jsm-hq★ 47same name
44 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.
In this repository29 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- benchmarkSkill
- agent-introspectionSkill
- auditSkill
- commitSkill
- contextSkill
- councilSkill
- _criticSkill
- debugSkill
- discoverSkill
- _dispatchSkill
- evalSkill
- evolveSkill
- goSkill
- orbitSkill
- orchestrateSkill
- perfSkill
- reflectSkill
- secureSkill
- shipSkill
- simplifySkill
- specSkill
- tddSkill
- teamSkill
- threat-modelSkill
- triageSkill
- verifySkill
- vuln-scanSkill
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
- Distinctive: line 24
Follow the project's existing doc style.
- Distinctive: line 75
Before claiming documentation is done, show ALL applicable:
“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.
Files
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
| Excuse | Rebuttal | What 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/@throwspresent for non-trivial functions- At least one
@examplefor 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
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.

