agentsclimarketplace

Writing guidelines

Skill rohitg00/pro-workflow/skills/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".From its SKILL.md

Install
npx -y skills add rohitg00/pro-workflow --skill writing-guidelines

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.

SKILL.md

2.3 KB, 495 tokens by cl100k_base, as published. Nobody here has run it

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.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most readme changelog skills give in 495 tokens

Counted across 446 of the 460 authors here whose files we hold, read 2026-09-06

  • Follow Keep a Changelog formatin 24 of 446
  • Collect commits since the last git tagin 15 of 446, across 13 files
  • Omit empty sectionsin 14 of 446
  • Put breaking changes first with migration stepsin 14 of 446
  • Include migration guidance for breaking changesin 11 of 446, across 10 files
  • Categorize commits by conventional commit prefixin 11 of 446
  • Mark breaking changes prominentlyin 10 of 446
  • Prepend the new entry to CHANGELOG.mdin 9 of 446
  • Highlight breaking changes with migration notesin 8 of 446, across 7 files
  • Classify changes into Keep a Changelog categoriesin 8 of 446, across 7 files
  • Group related commits into single entriesin 8 of 446
  • Write the changelog from commitsin 8 of 446

Said here and by no other author read

  • Delete filler words and sentences that change nothing
  • Prefer concrete names, numbers, and commands over abstractions
  • Use the project's own vocabulary consistently
  • Say what happened and what to do next
  • Give every failure a next step
  • Strip hollow openers, hedging stacks, binary flourishes, over-structured lists

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.