writing

Applies Zinsser-based clarity and brevity standards to documentation, commit messages, and PR descriptions.

Updated Jul 29, 2026
One-click install
npx skills add https://github.com/MaiconGambini/opencode-harness-guide --skill writing-maicongambini
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: writing
Source: https://github.com/MaiconGambini/opencode-harness-guide/tree/main/skills/writing
Command: npx skills add https://github.com/MaiconGambini/opencode-harness-guide --skill writing-maicongambini

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Technical writing often suffers from passive voice, redundant words, jargon, and vague phrasing, making documentation, commit messages, and PR descriptions hard to read and maintain. ## Core Features & Use Cases - Clarity and Brevity Rules: Enforces one idea per sentence, short sentences under 25 words, active voice, and removal of clutter based on Zinsser's principles. - Ready-Made Patterns: Provides templates for commit messages, PR descriptions, error messages, and documentation structure. - Use Case: When drafting a pull request, apply the PR description pattern with Summary, Why, and Testing sections so reviewers can understand the change at a glance. ## Quick Start Use the writing skill to rewrite my PR description following the clarity and brevity standards.

Frequently Asked Questions about writing

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

FAQPage Schema
How do I write better commit messages?

Use the pattern verb plus what, such as "Add user authentication" or "Fix payment validation". Keep it short, active, and specific, and avoid vague messages like "Fixed stuff" or "Updates".

How to structure a PR description for code review?

Use three sections: Summary with one sentence on what changed, Why with one paragraph on motivation, and Testing explaining how to verify. This lets reviewers skim and understand the change quickly.

What are Zinsser's principles for clear writing?

Zinsser's principles emphasize clarity, brevity, and simplicity: one idea per sentence, short sentences, active voice, cutting redundant words, and preferring simple concrete words over complex abstract ones.

How do I write good error messages for users?

Follow the pattern: what happened, then what to do. For example, "User not found. Check the email." State the problem plainly and give a concrete next action.

When should I avoid passive voice in technical writing?

Avoid passive voice in almost all technical writing because it hides the actor and adds words. Write "We fixed the bug" instead of "The bug was fixed" to keep sentences direct and shorter.