Inline docs
Document code using efficient inline comments. Use whenever writing, editing, or reviewing code or if the user mentions documentation.From its SKILL.md
npx -y skills add ethan-ngai/skills --skill inline-docsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its file declares
Copied from the file, not written here
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
1.7 KB, 341 tokens by cl100k_base, as published. Nobody here has run it
Inline Documentation
Documentation remedies ambiguity and supplies missing context. Good code is self-documenting — it shows the what, so a comment must earn its place by adding the why. Keep docs lean.
What to document
- Comment where the code surprises: intent, constraints, workarounds, logic that looks wrong but works. Add the why when it spares the reader a wrong guess; let plain code speak for itself.
- Reserve inline comments for genuinely complicated logic; short phrases.
- Mark unfinished work with TODO/FIXME.
- Keep a comment beside its code and revise both in one edit; comments rot as code drifts.
- Write for the future reader, who knows the code but not your session or the surrounding stack: keep comments timeless and self-contained.
How to write it
- Use block doc comments (JavaDoc, JSDoc, docstrings) for the standard, dev-readable format.
- Write like a senior developer: terse fragments, human names, specific over generic.
- Every comment is signal: cut the noise (keeps, so, because, stays), and prefer commas and semicolons to full sentences.
- Shun ceremony: structure speaks for itself, so section headers like
// -------- Variables --------only bloat tokens. - Use typeable ASCII only; it keeps docs easy to edit.
Language References
Load in the specific documentation standard(s) for the current project:
| Language | Reference |
|---|---|
| JavaScript/TypeScript | JSDoc |
What ships with it: 2 files
3.1 KB alongside SKILL.md
Gives 0 of the 12 instructions most docs writing skills give in 341 tokens
Counted across 1,951 of the 3,904 authors here whose files we hold, read 2026-09-06
- Use third-person for skill descriptionsin 54 of 1951, across 35 files
- Start descriptions with Use whenin 43 of 1951, across 29 files
- Run baseline scenarios before writing any skillin 40 of 1951, across 26 files
- Use active voicein 40 of 1951, across 36 files
- Map file responsibilities before defining tasksin 36 of 1951, across 29 files
- Use checkbox syntax for tracking stepsin 35 of 1951, across 27 files
- Ask one question at a timein 35 of 1951
- Offer execution options after saving the planin 33 of 1951, across 24 files
- Include complete code in every stepin 33 of 1951, across 27 files
- Design units with clear boundaries and interfacesin 31 of 1951, across 23 files
- Announce the skill usage at the startin 30 of 1951
- Verify agent compliance after adding the skillin 29 of 1951, across 17 files
Said here and by no other author read
- Mark unfinished work with TODO
- Revise comments alongside code edits
- Write comments for future readers
- Use block doc comments for standards
- Write in terse fragments
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.