القائمة
Writing style for technical documentation, README files, guides, and any user-facing text. Use when writing or reviewing prose, docs, comments, commit messages, or PR descriptions. Trigger terms: writing, prose, documentation style, tone, clarity, technical writing.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Write Architecture Decision Records when making significant technical choices. Use when selecting tools, patterns, frameworks, or making structural changes that future developers need to understand.
Write AGENTS.md files that serve as operating contracts for AI agents. Use when creating or updating AGENTS.md for a project. Trigger terms: AGENTS.md, agent instructions, agent contract, agent configuration, coding agent setup.
Quality rules for changelog entries. Use when validating, writing, or reviewing changelog content to ensure user-facing value communication.
Task completion sequence including verification, git, signaling, and handoff. Use when finishing a task or reporting status.
Architecture diagrams for documentation. Covers ASCII, Mermaid, C4, and D2. Applies C4 methodology by default. Trigger terms: diagram, flowchart, architecture diagram, sequence diagram, C4, mermaid, ascii diagram.
Classify documentation by audience and content type. Use when planning, auditing, or placing project documentation.
| name | writing-style |
| description | Writing style for technical documentation, README files, guides, and any user-facing text. Use when writing or reviewing prose, docs, comments, commit messages, or PR descriptions. Trigger terms: writing, prose, documentation style, tone, clarity, technical writing. |
Every sentence earns its place. Cut until cutting would lose meaning.
Answer-first. Lead with the conclusion. The reader gets value from sentence one.
Impact over mechanism. State what changed or what the reader should know — not how the code does it.
process_queue to use a deque instead of a list and updated the sentinel from -1 to None."Specific words. Name the thing. "The deploy failed because the config references a deleted secret" — not "There was an issue with the deployment process."
Active voice. "The script deletes old logs" — not "Old logs are deleted by the script." Passive only when the actor is unknown or irrelevant.
Proportional depth. Short answer for yes/no. Thorough analysis for architectural decisions. Don't pad short answers; don't truncate complex ones.
Prose by default. Paragraphs communicate relationships a list cannot. Lists earn their place when items are parallel, independent, and there are 3+ of them.
Filler. Never open with: "Sure! I'd be happy to help," "Great question!," "Let me think about that," "Before we dive in." Start with substance.
Slop words. Avoid unless precisely right:
Hedging stacks. One qualifier per claim. "This might cause issues because..." — not "It might perhaps be worth considering that this could potentially..."
Not-X-It's-Y pivot. State what something is directly. Don't negate first.
Sausage-making. Don't narrate implementation steps as summary. Present conclusions directly.
Narrating the obvious. Don't inventory what the reader already has — file lists in a diff, commit subjects in the log, UI elements on screen.
Emphasis inflation. Bold is for terms being defined or critical warnings. If everything is bold, nothing is.
Header proliferation. A section shorter than three sentences rarely needs a header. Three levels maximum.
Always keep full detail for: security warnings, irreversible actions, step-by-step procedures where skipping causes errors, error explanations where the why matters, nuance that prevents incorrect conclusions.
Before publishing any documentation: