Run any Skill in Manus with one click

docs-writer

Stars20

Forks4

UpdatedJuly 13, 2026 at 12:04

Keeps documentation in sync with the code: README, usage and related docs when a public API or behavior changes. Leaves no dead or misleading docs behind. Trigger phrases: "documentation", "docs", "update README", "API docs", "write docs", "document it", "write usage"

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

byerlikaya

byerlikaya/claude-starter-kit

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

2 files

SKILL.md

readonly

name	docs-writer
description	Keeps documentation in sync with the code: README, usage and related docs when a public API or behavior changes. Leaves no dead or misleading docs behind. Trigger phrases: "documentation", "docs", "update README", "API docs", "write docs", "document it", "write usage"

Documentation

Goal: the docs must match the code. Wrong/stale docs are worse than no docs (they inspire trust and mislead). Trigger: when a public API, command, configuration, or user-visible behavior changes.

When it is mandatory

A public function/endpoint/CLI signature or behavior changed.
A new feature, configuration key, or environment variable was added.
The install/run steps changed.
A breaking change was made (also coordinate via release/CHANGELOG).

Checklist

Docs are up to date for the changed public surface
Examples work (copy-paste tested / mentally traced)
Dead/misleading wording removed (no leftover old name/parameter)
New configuration/env documented (default + whether required)
Scope minimal — not a repetition of the code, but "why/how to use it"
No secret/real credential in the docs (use a placeholder)

How

Identify the changed surface — extract the public signature/behavior diff from the diff.
Find the right doc — README, docs/, docstring, OpenAPI, command --help. If there is more than one, update them all.
Write: what it does · how it is called (example) · input/output · limits/error cases. Short and correct.
Verify the examples — does the command/code example actually run.
Clean up the old — delete references to removed APIs/parameters.
Translation: if the user-visible doc is multilingual, coordinate with i18n-integrity.

Principles

Single source — behavior lives in the code; the doc explains it, does not copy it (a copied doc goes stale).
Example > paragraph — a working example beats three paragraphs.
Minimal — don't write a giant doc no one will maintain; answer the most-asked question.

Co-authoring a longer doc (guide, tutorial, README rewrite)

For a substantial doc the content lives in the author's head, not the diff — don't guess it. Interview for intent and audience, draft in passes, and let the user steer before you polish. The collaborative workflow (audience/intent questions, outline-first, section-by-section drafting, revision loop): references/coauthoring.md.

Invariant rules

Correctness > completeness — don't write a wrong doc; if unsure, flag it/ask.
Examples must work.
Leave no stale/dead docs.
No secret/real credential — use a placeholder (aligned with §4).
Don't repeat the code — don't just copy the signature; explain the usage.

More from this repository

same repository

eval-grader

byerlikaya/claude-starter-kit

Measure output quality, don't vibe it: score a generative task with a two-layer grader — deterministic code metrics + per-dimension LLM-as-judge — over a fixed task set, as signed deltas vs a pinned baseline. Grades cost alongside correctness (pass-slow). Trigger phrases: "eval", "grader", "measure output quality", "LLM-as-judge", "score the output"

2026-07-1920

frontend

byerlikaya/claude-starter-kit

Stack-agnostic frontend discipline (web · mobile · desktop): component structure, state, data fetching, loading/empty/error states, i18n, accessibility, performance. frontend-expert-csk applies it on every stack. Trigger phrases: "frontend", "screen", "component", "page", "UI", "state management", "interface"

2026-07-1920

iterate

byerlikaya/claude-starter-kit

Refine-to-Done loop: repeat until tests green + review clean + nothing deferred; bounded. Not the harness /loop. Trigger phrases: "iterate", "loop until done", "keep going until"

2026-07-1920

security-scan

byerlikaya/claude-starter-kit

Stack-agnostic security audit: map the attack surface, trace untrusted input to dangerous calls, surface dependency and configuration flaws. Severity-ranked report with fixes. Trigger phrases: "security scan", "run a security scan", "OWASP check", "scan for vulnerabilities", "find security vulnerabilities", "security audit"

2026-07-1920

threat-model

byerlikaya/claude-starter-kit

Scope a security audit BEFORE scanning, to cut false positives: map assets, entry points, trust boundaries and 5-8 domain-specific attack classes into a parseable THREAT_MODEL.md. A threat survives a patch; a vulnerability is only evidence for one. Feeds security-scan. Trigger phrases: "threat model", "attack surface", "scope the audit", "trust boundary"

2026-07-1920

sonarqube-check

byerlikaya/claude-starter-kit

SonarQube quality gate (language-agnostic, local-first): 0 Bugs/Vulns/Hotspots/Code Smells, 0 build warnings. If no analyzer exists, install the language's local server-less Sonar analyzer and run it — never a remote server. Trigger phrases: "sonarqube", "quality gate", "code smell", "sonar scan"

2026-07-1620

name	docs-writer
description	Keeps documentation in sync with the code: README, usage and related docs when a public API or behavior changes. Leaves no dead or misleading docs behind. Trigger phrases: "documentation", "docs", "update README", "API docs", "write docs", "document it", "write usage"

Documentation

Goal: the docs must match the code. Wrong/stale docs are worse than no docs (they inspire trust and mislead). Trigger: when a public API, command, configuration, or user-visible behavior changes.

When it is mandatory

A public function/endpoint/CLI signature or behavior changed.
A new feature, configuration key, or environment variable was added.
The install/run steps changed.
A breaking change was made (also coordinate via release/CHANGELOG).

Checklist

Docs are up to date for the changed public surface
Examples work (copy-paste tested / mentally traced)
Dead/misleading wording removed (no leftover old name/parameter)
New configuration/env documented (default + whether required)
Scope minimal — not a repetition of the code, but "why/how to use it"
No secret/real credential in the docs (use a placeholder)

How

Identify the changed surface — extract the public signature/behavior diff from the diff.
Find the right doc — README, docs/, docstring, OpenAPI, command --help. If there is more than one, update them all.
Write: what it does · how it is called (example) · input/output · limits/error cases. Short and correct.
Verify the examples — does the command/code example actually run.
Clean up the old — delete references to removed APIs/parameters.
Translation: if the user-visible doc is multilingual, coordinate with i18n-integrity.

Principles

Single source — behavior lives in the code; the doc explains it, does not copy it (a copied doc goes stale).
Example > paragraph — a working example beats three paragraphs.
Minimal — don't write a giant doc no one will maintain; answer the most-asked question.

Co-authoring a longer doc (guide, tutorial, README rewrite)

Invariant rules

Correctness > completeness — don't write a wrong doc; if unsure, flag it/ask.
Examples must work.
Leave no stale/dead docs.
No secret/real credential — use a placeholder (aligned with §4).
Don't repeat the code — don't just copy the signature; explain the usage.