skills.rest
Eyhenij
EyhenijCOMMUNITY
Explore all skills by this author →
GitHub

doc-style-human

Rewrites tasks, PR descriptions, and chat replies into plain language for non-technical readers.

1|Updated Jan 14, 2024
Search Tags:#documentation#writing#stakeholder communication#jargon#plain language#pr description#task writing
One-click install
npx skills add https://github.com/Eyhenij/rt-tools --skill doc-style-human-eyhenij
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: doc-style-human
Source: https://github.com/Eyhenij/rt-tools/tree/main/.claude/skills/doc-style-human
Command: npx skills add https://github.com/Eyhenij/rt-tools --skill doc-style-human-eyhenij

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Engineering jargon like "PR", "run", "guard", and "gate" is meaningless to product owners and stakeholders who never read the internal rules layer. This Skill converts work-queue tasks, PR descriptions, and chat replies into plain language the addressee actually understands, in the language they write in. ## Core Features & Use Cases - Jargon Replacement Table: Maps internal layer words (PR, run, guard, agreement, change size) to phrases a person outside the team understands. - Three Text Templates: Provides "so" and "not so" examples for work-queue tasks, PR descriptions, and chat replies to the owner. - Language Matching: Ensures the text is written in the owner's language rather than the language of the rules layer. - Use Case: A developer finishes a fix and must write a PR description. Instead of "gate suite green, second flag added", the Skill guides them to write what changes for the user, what confirms it, and to put file names last. ## Quick Start Ask the assistant to rewrite this PR description so the product owner understands it without knowing any internal terminology.

Frequently Asked Questions about doc-style-human

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

FAQPage Schema
How do I write a PR description that non-technical stakeholders understand?▼

Start the first paragraph with what changes for the person, then state what confirms it, and put file names at the end. Replace internal terms like "gate" or "suite" with concrete phrases such as "the checks passed" or what exactly blocked the change.

How to write a task ticket for a product owner without jargon?▼

Name the subject in the title and describe in the body what the person cannot do. Place the failing check as the last line, stating where to look without explaining why to fix it, and avoid internal layer vocabulary.

What words should be avoided when communicating with product owners?▼

Avoid internal layer words like PR, run, suite, guard, gate, agreement, and change size. Replace them with phrases such as "the change that waits for your word", "the checks passed", or what specifically did not let something through and why.

Does this writing style apply to status reports about work progress?▼

No, status replies about work state follow a separate rule called status-report. This pattern covers only work-queue tasks, PR descriptions, and general chat replies to the owner.

Why should claims in chat replies include numbers?▼

A statement like "done" without a number reads as an unverified fact. Include the run id, how many scenarios passed out of how many, or the time of the check so the owner can verify the claim.

Related Skills

Explore More Content & Communication Skills→
HybridAIOneHybridAIOne
126

brand-voice

Draft assistant messages that comply with configured brand voice rules.

Official
Basic
reedmayhew18reedmayhew18
23

oc-respond

Route formatted user replies through the message queue to web chat.

Community
Basic
the-homeless-godthe-homeless-god

bilingual-documentation

Keeps paired bilingual documentation surfaces stating identical facts with verifiable numbers.

Community
Intermediate
dfirs1car1odfirs1car1o

report-gen

Generate governance reports in DOCX, Markdown, and JSON from OSCAL backlog.

Official
Intermediate