Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

docs-writer

Étoiles20

Forks4

Mis à jour13 juillet 2026 à 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

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

byerlikaya

byerlikaya/claude-starter-kit

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

Explorateur de fichiers

2 fichiers

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.

Plus depuis ce dépôt

même dépôt

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.