documentation-style

Applies team style rules when writing README, CHANGELOG, JSDoc, and technical documentation.

Updated Mar 22, 2026
One-click install
npx skills add https://github.com/TECH-HY/SKILLS --skill documentation-style-tech-hy
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: documentation-style
Source: https://github.com/TECH-HY/SKILLS/tree/main/skills/documentation-style
Command: npx skills add https://github.com/TECH-HY/SKILLS --skill documentation-style-tech-hy

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Technical documentation often ends up inconsistent, verbose, or missing examples, forcing readers to dig through source code to understand an API. This Skill enforces a single team style so every README, CHANGELOG, and JSDoc comment follows the same clear, example-driven format. ## Core Features & Use Cases - README Structure Enforcement: Defines a standard section layout (Installation, Quick Start, API, Configuration) with rules like copy-paste-runnable quick start code and no unrequested badges. - CHANGELOG Formatting: Applies the Keep a Changelog format with categorized entries (Added, Changed, Fixed, Deprecated, Removed, Security) and versioned date headers. - JSDoc Standards: Requires typed @param, @returns, @throws, and mandatory @example tags for public functions, with concrete error types and realistic values. - Use Case: When adding a new public function to a library, ask the agent to document it — the result includes a one-line verb-first summary, typed parameters, a runnable example, and a matching CHANGELOG entry. ## Quick Start Use the documentation-style skill to write a README section and JSDoc comment for the new login function in this project.

Frequently Asked Questions about documentation-style

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a good README for a software project?

A good README starts with a one-line description of what the project does and for whom, followed by Installation, a Quick Start with copy-paste-runnable code under 15 lines, API usage with examples, and a Configuration options table. Keep installation commands free of preamble and avoid badges unless requested.

How to format a CHANGELOG using Keep a Changelog?

Use versioned sections with dates like ## [2.3.0] - 2026-03-03, then group entries under only the categories that apply: Added, Changed, Fixed, Deprecated, Removed, and Security. Deprecated entries should name the replacement, and fixed entries can reference issue numbers.

What JSDoc tags are required for public functions?

Public functions should include a one-line verb-first description, @param with type, name, and description, @returns with the concrete type and meaning, @throws with specific error types, and an @example whenever arguments are non-trivial. Optional parameters use bracket syntax like [options.remember=false].

Should code examples in documentation use placeholder values like foo and bar?

No. Examples should use realistic values such as [email protected] instead of foo, bar, or baz, and every code block must specify its language (js, bash, json). Bash commands should omit the $ prompt so they can be copy-pasted directly.

When should documentation be updated in a project?

Documentation should be updated whenever public behavior changes, and the CHANGELOG must be updated on any change to the public interface. Every API or concept should ship with at least one working code example rather than placeholder TODO notes.