Doc Generator
Generate READMEs, guides, and API docs that read like a human wrote them—not generic AI preamble.
Overview
doc-generator is an agent skill most often used in Build (also Validate landing copy, Launch distribution pages) that applies human-quality documentation rules—openings, section lengths, paragraphs, and 80-char wrapping—
Install
npx skills add https://github.com/athola/claude-night-market --skill doc-generatorWhat is this skill?
- Opening-pattern rules: start with what the tool IS or DOES, not “welcome to the comprehensive guide” fluff
- Section length targets for overview (50–100 words), features (30–60), steps (20–50), and API blocks (40–80)
- Paragraph discipline: one idea per block, split anything beyond five sentences
- 80-character hybrid line wrapping for readable git diffs and mobile prose
- Anti-patterns catalog for common AI-doc openings and preambles
- Section length targets: overview 50–100 words, features 30–60, guide steps 20–50, API endpoints 40–80
- Paragraph rule: 2–4 sentences per paragraph; split beyond five sentences
- Prose wrap target: 80 characters per line with hybrid wrapping
Adoption & trust: 1 installs on skills.sh; 304 GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
Agent-generated documentation often opens with filler, runs long unstructured paragraphs, and produces unreadable diffs because lines are never wrapped.
Who is it for?
Solo builders who want coding agents to draft or rewrite READMEs, setup guides, and API sections without sounding like generic AI marketing copy.
Skip if: Teams that already enforce a strict corp style guide in CI, or when you only need a one-line changelog with no narrative structure.
When should I use this skill?
Whenever an agent is generating or rewriting project documentation, guides, or API reference prose.
What do I get? / Deliverables
Your agent outputs tight, direct docs with consistent section sizes, one-idea paragraphs, and 80-character wrapped prose suitable for commit and publish.
- Human-quality markdown sections with prescribed openings and lengths
- Wrapped prose lines suitable for readable git diffs
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Documentation is shelved under Build because that is when solo builders most often ship first-run docs with their product, even though the same style rules apply earlier and later. The docs subphase is the canonical home for writing-quality modules that shape how agent output becomes project documentation.
Where it fits
Rewrite hero and feature blurbs to lead with what the product does instead of welcome-style preamble.
Draft a README with install-first openings and 50–100 word overview sections.
Tighten release notes and migration guides before tagging a public release.
Polish docs linked from Product Hunt or npm so first paragraphs are citable and direct.
How it compares
Use as procedural writing rules inside the agent, not as a separate doc linter or static site generator.
Common Questions / FAQ
Who is doc-generator for?
Solo and indie developers using Claude Code, Cursor, or similar agents who ship docs alongside code and care how those docs read in git and on the web.
When should I use doc-generator?
During Build when writing READMEs and API docs; during Validate when tightening landing or scope copy; during Launch when polishing distribution pages; and anytime an agent is about to generate long-form project documentation.
Is doc-generator safe to install?
It is a local guidelines module with no shell, network, or secrets requirements by design; review the Security Audits panel on this Prism page before trusting any third-party skill package in your agent.
SKILL.md
READMESKILL.md - Doc Generator
# Documentation Generation Guidelines Detailed guidance for creating human-quality documentation. ## Opening Patterns ### What to Avoid ```markdown BAD: "In today's fast-paced development environment, documentation plays a crucial role..." BAD: "Welcome to the comprehensive guide to..." BAD: "This document aims to provide an in-depth overview of..." ``` ### What to Use ```markdown GOOD: "scribe detects AI-generated content and helps you fix it." GOOD: "Install with: npm install scribe" GOOD: "This guide covers installation, configuration, and common workflows." ``` Start with what it IS or what it DOES. Skip the preamble. ## Section Structure ### Length Targets | Section Type | Target Length | |--------------|---------------| | Overview | 50-100 words | | Feature description | 30-60 words | | Step in guide | 20-50 words | | API endpoint | 40-80 words | ### Paragraph Guidance Paragraphs should contain 2-4 sentences on a single topic. If a paragraph exceeds 5 sentences, split it. One paragraph = one idea. ## Line Wrapping Wrap prose text at 80 characters per line using hybrid wrapping. This makes git diffs readable and mobile-friendly. ### Rules (in priority order) 1. Keep sentences on one line if they fit within 80 chars 2. Break long sentences at clause boundaries (after `, ; :`) 3. Break before conjunctions (`and`, `but`, `or`) 4. Break at word boundaries as a last resort ### Exempt from wrapping Tables, code blocks, headings, frontmatter, HTML blocks, link definitions, and image references stay on one line. ### Example ```markdown BEFORE: The system validates all input against the schema and rejects malformed requests with a 400 status code, logging the validation failure for debugging. AFTER: The system validates all input against the schema and rejects malformed requests with a 400 status code, logging the validation failure for debugging. ``` ### Additional formatting rules - Blank line before and after every heading - ATX headings only (`#` style, never setext underlines) - Blank line before every list - Use reference-style links when inline links push past 80 chars Full specification: `Skill(leyline:markdown-formatting)` ## Concrete Examples Every feature claim needs a concrete example: ```markdown BAD: "The system provides flexible configuration options." GOOD: "Configure via `scribe.yaml` or environment variables. Set `SCRIBE_STRICT=1` to treat warnings as errors." ``` ## Trade-off Discussions Include reasoning, not just conclusions: ```markdown BAD: "We recommend Redis for caching." GOOD: "We chose Redis over Memcached for its sorted sets, which power the leaderboard. Memcached would use less memory but require additional application logic." ``` ## Ending Patterns ### What to Avoid ```markdown BAD: "In conclusion, we have covered the essential aspects of..." BAD: "We hope this guide has been helpful in your journey..." BAD: "Happy coding!" ``` ### What to Use End with the last useful piece of information. No summary paragraph unless the document exceeds 2000 words. ```markdown GOOD: "For issues, open a ticket at github.com/org/repo/issues." GOOD: "Next: Advanced Configuration" GOOD: [Just end. No closing needed.] ``` ## Voice Consistency Maintain consistent perspective throughout: | Style | Example | |-------|---------| | Direct | "Run `npm install`" | | Team | "We recommend..." | | Instructional | "You can configure..." | Don't mix: "One should note that you can..." ## Handling Uncertainty When information is incomplete: ```markdown GOOD: "Exact performance varies by hardware. Our tests showed 50-200ms on M1 Mac." GOOD: "This feature is experimental. API may change." GOOD: "We haven't tested on Windows. Linux and macOS confirmed working." ``` Acknowledge limits rather than overgeneralizing. --- module: quality-gates category: writing-quality dependencies: [TodoWri