writing-guidelines
Apply clear-writing standards to any prose the agent produces - READMEs, docs, UI copy, error messages, commit and PR text, release notes. Use when writing or editing documentation, interface copy, or any text a human will read. Says "write the README", "improve this copy", "draft the docs", "word this error".
git clone --depth 1 https://github.com/rohitg00/pro-workflow /tmp/writing-guidelines && cp -r /tmp/writing-guidelines/skills/writing-guidelines ~/.claude/skills/writing-guidelinesSKILL.md
# writing-guidelines Write for a reader who is busy and did not see your work. Readability beats cleverness; clarity beats completeness. ## Rules - **Lead with the outcome.** The first sentence answers what happened or what the thing is - the line the reader would ask for if they said "just the TLDR". Supporting detail comes after. - **Cut filler.** Delete "just", "simply", "basically", "in order to", "it is important to note". If a sentence changes nothing when removed, remove it. - **Concrete over abstract.** Name the file, the number, the command. "Faster" is weaker than "cuts the build from 40s to 9s". - **Active voice, one idea per sentence.** Short sentences that each carry one point read faster than long ones that carry three. - **Consistent terms.** Use the project's own vocabulary, the same word for the same thing every time. Tie names to the shared-language `CONTEXT.md` when one exists (see `domain-modeling`). - **Readable, not clipped.** Being short and being clear are different. Achieve short by dropping what the reader does not need, not by compressing prose into fragments, arrow chains (`A -> B -> fails`), or invented abbreviations. ## Error messages and UI copy - Say what happened and what to do next: `Config not found at ./app.config.ts. Create it or pass --config <path>.` beats `Error: config missing`. - No dead ends. Every failure names a next step. - Match the product's voice; drop exclamation marks and filler enthusiasm. ## AI-slop tells to strip - Em-dashes and en-dashes - use a spaced hyphen or a full stop. This is the most reliable machine-written tell. - Hollow openers: "In today's fast-paced world", "It's worth noting that". - Hedging stacks: "might potentially perhaps". - Binary flourishes: "Not X. But Y." as a rhetorical beat. - Over-structured lists where a sentence would do. ## Output When editing, show the tightened version and, on request, a one-line note per change. Do not pad the edit with praise for the original.
Coordinate multiple Claude Code sessions as a team — lead + teammates with shared task lists, mailbox messaging, and file-lock claiming. Patterns for team sizing, task decomposition, and when to use teams vs sub-agents vs worktrees.
Auto-configure quality gates, hooks, and settings for a new project. Detects project type and sets up appropriate tooling. Use when onboarding a new codebase.
Decompose large-scale changes into independent units and spawn parallel agents in isolated worktrees. Use for migrations, refactors, codemods, and any change touching 10+ files with the same pattern.
Capture a user-reported defect as a durable GitHub issue written in the project's own domain language. Explores the codebase in parallel for context but never leaks file paths or line numbers into the issue. Use when the user reports a bug conversationally, runs a QA pass, or says "file an issue", "log this as a bug", "capture this".
Smart context compaction with state preservation. Saves critical files, task progress, and working state before compaction, restores after. Use before manual compact or when auto-compact triggers.
Analyzes and optimizes context window usage across sessions. Use when context feels bloated, sessions run slow, or approaching compaction limits.
Master the four operations of context engineering — Write, Select, Compress, Isolate. Manage token budgets, compaction strategies, and context partitioning to keep AI sessions sharp and efficient.
Optimize token usage and context management. Use when sessions feel slow, context is degraded, or you're running out of budget.