Skip to content
Skills Library
Programming · Writing

documenting-code

/documenting-code

Write, rewrite, or update project docs from implementation facts - README front pages, user guides, configuration references, architecture docs, evaluations, agent instructions, and code comments. Use when writing or improving project docs for clarity, concision, accuracy, or useful visuals, or when code changes make docs stale. NOT for release preparation or release notes (releasing-code), external library docs (looking-up-docs), engineering messages (writing-style), scoring instruction files (reviewing-instructions), or ADRs unless explicitly requested.

Repository
cc-thingz ↗
Licence
MIT
Last repository change
25.10.2026

Assessment and security

100/ 100Class: good
Format25 / 25
Frontmatter with name and description, valid name, description up to 1,024 characters, name matching the folder.
Discoverability25 / 25
Description explains when to use the skill, has a reasonable length and uses third person.
Content35 / 35
At least 150 words and at most 500 lines, headings, step lists, examples or code.
Hygiene15 / 15
No placeholders such as TODO, no Windows paths, with a licence.
Riskno signals detected in the scan
Files in this package
15
Scripts
3
HTML comments
0
URLs in SKILL.md
0
Deprecation

No signals detected. Repository changed on 25.10.2026, without references to retired models or APIs.

Licence

MIT, open: use and modify while retaining author attribution.

What to check before installing
  • 3 scripts in this package. Review them before installing, as Claude may execute them.

Scripts: scripts/check-links.py, scripts/prose-lint.py, scripts/render-mermaid.sh

What it does and when to use it

Write, rewrite, or update project docs from implementation facts - README front pages, user guides, configuration references, architecture docs, evaluations, agent instructions, and code comments. Use when writing or improving project docs for clarity, concision, accuracy, or useful visuals, or when code changes make docs stale. NOT for release preparation or release notes (releasing-code), external library docs (looking-up-docs), engineering messages (writing-style), scoring instruction files (reviewing-instructions), or ADRs unless explicitly requested.

Original author description

Write, rewrite, or update project docs from implementation facts - README front pages, user guides, configuration references, architecture docs, evaluations, agent instructions, and code comments. Use when writing or improving project docs for clarity, concision, accuracy, or useful visuals, or when code changes make docs stale. NOT for release preparation or release notes (releasing-code), external library docs (looking-up-docs), engineering messages (writing-style), scoring instruction files (reviewing-instructions), or ADRs unless explicitly requested.

How it works

  1. Pick the mode
  2. Readers
  3. Workflow
  4. Gate
  5. Rules
  6. Output
  7. Failure handling
Original SKILL.md headings · 123 lines, 816 words
SKILL.md preview
---
description: Write, rewrite, or update project docs from implementation facts - README
  front pages, user guides, configuration references, architecture docs, evaluations,
  agent instructions, and code comments. Use when writing or improving project docs
  for clarity, concision, accuracy, or useful visuals, or when code changes make docs
  stale. NOT for release preparation or release notes (releasing-code), external
  library docs (looking-up-docs), engineering messages (writing-style), scoring
  instruction files (reviewing-instructions), or ADRs unless explicitly requested.
name: documenting-code
---

# Documenting Code

Turn implementation facts into docs that a named reader can use. Every claim in
the result matches the code, and every visual renders cleanly.

## Pick the mode

- **Update**: a code change made docs stale. Change the smallest set of docs.
  Done when each changed behavior is documented where its reader looks, and
  nothing unrelated changed.
- **Overhaul**: the user asks to rewrite, restructure, or improve a doc set, for
  example a README front page, guides, or an architecture doc. Done when:
  - each doc has one reader and one job, and each fact has one owner
  - every claim matches the code, and every visual passes its render check
  - the gate passes
- A named doc or a named change is enough scope; start work. Ask only when the
  request names neither, with one question and these options: auto-detect from
  recent changes, README, API docs, or the full doc set.

## Readers

Decide the reader before writing.

- **Human**: short, scannable text. Use a diagram, table, or chart when it
  answers a question faster than prose. Load `references/doc-set.md` only for
  doc-set structure or Overhaul mode, `references/style.md` when rewriting prose,
  and `references/visuals.md` only when changing diagrams or charts.
- **Agent** (AGENTS.md, CLAUDE.md, skills, prompts): terse operational text with
  headers, bullets, numbered steps, exact contracts, and a table where it is the
  clearest form. No diagrams or rationale that a model already knows. To score
  or lint instruction files, use `reviewing-instructions`.
- **Code**: comments and docstrings state contracts, invariants, side effects,
  errors, and non-obvious decisions. Delete comments that restate the code.
  Load `references/code.md` for shared comment rules and per-language doc
  checks.

## Workflow

1. Scope the work from the request and the changed files (`git diff --name-only`),
   and find the existing docs that cover them.
2. List the doc files, the reader and the job of each, and the facts that more
   than one doc states. In Overhaul mode, write the ownership map from
   `references/doc-set.md` before editing.
3. Read the code, tests, and configuration that each doc describes. When docs and
   code conflict, report it and update the docs to the code, unless the user says
   that the doc is the intended contract.
4. Write. Keep each fact in one place and link to it from the others. Replace
   adjectives with measured facts. Name actors, conditions, and referents; use
   one term per concept. Cut words only when meaning and necessary context survive.
5. Check changed claims against their source; use `references/claims.md` for
   configuration, API, or measured-performance claims. Generate sample output
   when changing examples. Mark unconfirmed claims and say where you looked.
6. If visuals changed, load `references/visuals.md`, render them, inspect the
   images, and fix the faults.
7. Run the gate once. Run it again only after further edits.
8. Report with the output contract.

## Gate

Run the bundled scripts on the changed docs from the project root.
`<skill-dir>` is the directory that contains this SKILL.md, as the host
reports it. Do not use a `scripts/` directory of the project instead.

```bash
python3 <skill-dir>/scripts/check-links.py <files or dirs>   # relative links and #anchors
bash <skill-dir>/scripts/render-mermaid.sh <files or dirs>   # renders each Mermaid block to PNG
python3 <skill-dir>/scripts/prose-lint.py <files or dirs>    # advisory plain-language lint
```

- Open the rendered images. A diagram that parses can still have a bad layout.
- Also run the repo's own docs checks, for example `markdownlint-cli2` or a
  `make` docs target, when they exist.
- Run documented commands and examples when practical.

Done when the relevant build/test/lint checks pass on what you changed, or you
name each check that did not run and why.

## Rules

- No speculative, future, or dead behavior.
- History (decision dates, "agreed with", replaced designs) belongs in git or
  the changelog, not in design docs.
- No secrets, tokens, private paths, or internal hosts.
- Generated docs: edit the source and run the generator.
- No ADRs or `docs/adr/` changes unless explicitly requested.
- Do not commit, push, or publish unless the user asks.

## Output

```markdown
## Documentation Update

Mode: update | overhaul

Updated:

- `path` — <what changed> (reader: <human | agent | code>)

Moved (overhaul only):

- <fact> → owned by `path`; other docs now link to it

Checked:

- claims: <n> checked against source; unconfirmed: none | <claim — where looked>
- visuals: <n> rendered and inspected | none changed
- gate: links <passed | failed>, diagrams <passed | skipped (reason)>, prose <n findings>

Issues: none | <remaining issue>
```

Without write access, return proposed changes (file, change, reason) instead of
applying them.

## Failure handling

- No stale docs found: say so and list what you checked.
- Large audit: one bounded read-only helper can map docs against code. Do not
  trust its report. Check its claims and the actual diff (`git diff --stat`)
  before you report success.
- A check fails: quote the failure in Issues.
Files in this package (15)
  • SKILL.md 6 KB
  • .agentbundler/targets/claude.json 1 KB
  • assets/examples/decision-outcomes.mmd 1 KB
  • assets/examples/lifecycle.mmd 1 KB
  • assets/examples/pipeline.mmd 1 KB
  • assets/examples/request-flow.mmd 1 KB
  • assets/examples/system-context.mmd 1 KB
  • references/claims.md 3 KB
  • references/code.md 1 KB
  • references/doc-set.md 4 KB
  • references/style.md 3 KB
  • references/visuals.md 5 KB
  • scripts/check-links.py 4 KB
  • scripts/prose-lint.py 4 KB
  • scripts/render-mermaid.sh 3 KB

Versions

The database has no other skills named documenting-code.

Database snapshot: 13.11.2026 · package version 10ef38fbb111 (SHA-256 digest of the entire package)

Downloads in the last 30 days: 0 · ranking

Report a problem with this skill: harmful content, incorrect descriptions or an author’s removal request.

Similar skills

  • 100tech-docs-writer
    Writes and rewrites technical documentation for software projects: README files, API references, architecture docs, user guides, and inline doc comments. Use when the user wants to create, improve, or restructure documentation for a codebase, library, CLI tool, or API. Also use…
  • 100code-documentation
    Writing effective code documentation - API docs, README files, inline comments, and technical guides. Use for documenting codebases, APIs, or writing developer guides.
  • 100agent-documentation-writer
    Specialist subagent: Generates comprehensive documentation including READMEs, API docs, architecture docs, and inline comments. Use when documenting code, creating guides, or explaining systems.
  • 100documentation
    Use this skill when the user asks you to write, update, or fix project documentation — READMEs, API docs, user guides, ADRs, or other Markdown docs. Also use when code changes need user-facing docs updates. Only write Markdown files; do not use for implementation, planning or test work.
  • 100codebase-documenter
    Write codebase documentation: READMEs, architecture docs, getting-started guides, API docs, and code comments. Use when documenting code or making a project easier for new developers.
  • 100documenting-projects
    Use when generating, improving, or auditing project documentation. Triggers: 'document this project', 'write docs', 'generate documentation', 'docs are outdated', 'need a README', 'create tutorials', 'API reference docs', 'doc audit', 'documentation review'. Standalone README:…

Feedback and reports

Your message goes to Bartosz Sokoliński. An email address is needed only for a reply. See the privacy policy.