docs-team-voice
Skill445 starsChanged 12 days agoMITView on GitHub
Write or revise documentation prose so it reads like the rest of this site, in the docs team's shared voice. Covers sentence length, cross-link density, how to state defaults and conditions, naming exact identifiers, and what to cut in a revision pass. Use when drafting or rewriting a page, a section, a concept overview, a how-to, a callout, or landing copy.
In this repository25 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .github/copilot-instructions.mdCopilot instructions
- .cursor/rules/docs-style.mdcCursor rule
- add-docs-pageSkill
- docs-code-samplesSkill
- docs-editSkill
- docs-restructureSkill
- docs-reviewSkill
- docs-tooling-notionSkill
- submit-integrationSkill
- update-integrations-prsSkill
- verify-against-sourceSkill
- deepagents-codeSkill
- deepagentsjsSkill
- deepagentsSkill
- openwikiSkill
- release-researchSkill
- ship-docs-updateSkill
- langgraph-docsSkill
- write-timestampSkill
- pandas-patternsSkill
- deep-agentsSkill
- langchainSkill
- langgraphSkill
- langsmithSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 4 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 58
Put the trigger first, then the behavior.
- Distinctive: line 90
If you cannot supply a real example, say less rather than inventing one.
- Very specific: line 102
Use the product name as the subject when the reader is not the actor: "LangSmith uses zstandard", not "we use zstandard".
- Distinctive: line 107
Read the draft once looking only for these:
- Very specific: line 122
A claim you did not verify: Check it against the product source with the verify-against-source skill, or cut it.
- Distinctive: line 152
Write the split as the replacement.
- Very specific: line 163
Every finding is minor and suggest.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Write in the house voice
AGENTS.md holds the rules a linter can check: no contractions, no first
person, no future tense, sentence-case headings, Oxford commas, spacing around
dashes. make lint_prose is the gate, but it fails only on error-level Vale
rules. Contractions, first person, future tense, and filler pass it, so a clean
run does not prove the page follows them. This skill covers what a linter cannot check:
rhythm, density, and the shape of a sentence that carries information.
The targets below are measured from this repository's own pages, not invented.
Keep sentences short
Median sentence length on this site is 13 to 15 words. Roughly one sentence in twelve runs past 25 words, one in forty past 30. Treat 25 as the point where you look for a split and 35 as a defect.
One idea per sentence. When a sentence carries two, split it and let the second stand alone.
The agent definition selects the model and core capabilities of a managed deep agent.
Set the
compressionfield to control how exported Parquet files are compressed. When omitted, LangSmith useszstandard.
The second example is two sentences where one long one would have hidden the default inside a subordinate clause.
The target is a floor as well as a ceiling. Keep the condition, the actor, and the exact value even when they push a sentence long, and split it rather than dropping one of them to get under 15 words.
Link about half the time
Close to half of all prose sentences here carry a link. Cross-linking is not decoration: it is how a reader escapes a page that does not answer the question they arrived with.
Link a term on first mention only. Pointing forward at the end of a section is standard, and two pointer forms are both established:
Refer to Spend policies.
For the full project layout, see Project structure.
Neither is canonical. Different authors favor different ones, so match the form the page already uses and do not mass-convert one into the other.
State defaults and conditions as bare facts
Put the trigger first, then the behavior. No hedging, no "please note".
When omitted, LangSmith uses
zstandard.
Defaults to the last 7 days, newest first.
Task planning is opt-in.
Non-zero exits and timeouts from
--startup-cmdwarn but do not abort the session.
Constraints read the same way, as plain statements of fact rather than warnings about them.
Name the exact identifier
Backtick every field, flag, value, environment variable, and status. Between a
quarter and a half of prose sentences on this site contain one. Name the actual
value rather than gesturing at it: zstandard, not "the appropriate
compression"; CREATED, RUNNING, COMPLETED, not "the various statuses".
If your API key is linked to multiple workspaces, specify the workspace in the header with
"x-tenant-id".
Reach for a concrete example early
"For example" appears in roughly one sentence in thirty, almost always followed by a real value rather than a shape.
For example, in SCIM, the resolved
subclaim and SCIMexternalIdmust match in order for login to succeed.
If you cannot supply a real example, say less rather than inventing one. Never fabricate a field name, a response body, or a policy detail to fill a slot.
Address the reader, and prefer the active voice
Second person carries a quarter to a half of sentences, most heavily in procedures and UI steps. Passive voice appears in only about one sentence in eight, and usually where the actor genuinely does not matter.
When viewing a trace that was generated by a run in LangSmith, you can access the associated server logs directly from the Details view.
Use the product name as the subject when the reader is not the actor: "LangSmith
uses zstandard", not "we use zstandard".
Revision pass
Read the draft once looking only for these:
- Sentences over 25 words. Split, or cut a clause.
- Hedges and filler. "simply", "just", "very", "basically", "note that", "be sure to", "in order to", "has the ability to". These are near-absent from this site's prose, well under one percent of sentences. Delete or replace.
- A spaced em dash.
word — wordfailsLangChain.DashesSpacesand blocks CI. Prefer a comma, a colon, or two sentences, and reach forword—wordonly when nothing else reads. A bold label opening a paragraph takes a colon:**Tier assignment**:, measured at 177 uses insrc/against 1 for the dash. - A vague identifier where the exact one belongs.
- A cut that took a fact with it. A tightened sentence that lost its condition, its actor, or its exact value reads cleanly and says something else. Restore the fact and split the sentence.
- A first mention with no link, and repeat mentions that are linked again.
- A claim you did not verify. Check it against the product source with the
verify-against-sourceskill, or cut it. Another docs page is not a source. Name every claim you could not confirm in the PR body. - A fact that disagrees with a related page. Grep
src/for the feature and read the pages that cover it from another angle, such as a CLI reference or a permissions table. Thedocs-editskill covers what to look for. - An added "key features" list, or a horizontal rule used to separate sections. Neither belongs here.
Then run the gate:
make lint_prose FILES="<changed files>"For a full review against the style guide, with the rule each finding breaks,
use the docs-review skill.
CI mode
In CI mode, this skill reviews a PR's prose for voice and writes findings
instead of editing. Read
ci-mode.md first: its rules and findings format
apply, with "skill": "docs-team-voice".
Apply the revision pass above to lines the diff added or changed, and report only these:
- A sentence that carries two ideas. The tell is a join with "so", "which", "and" between two clauses, or a semicolon, usually past 20 words. Write the split as the replacement. A long sentence that holds one idea, such as an exact value, a condition, or a list, is fine.
- A sentence a reader has to parse twice: a construction such as "so ... that", a stacked clause, or an abstraction where a concrete example from the same page would say it plainer. Write the plainer sentence.
- Hedges and filler, as listed in the revision pass.
- A default or condition buried in a subordinate clause where a bare fact would state it.
- A vague identifier where the diff itself names the exact one elsewhere.
- Passive voice where the actor is known.
Every finding is minor and suggest. Never auto, because rewording can
change meaning, and never human. Keep each replacement to the sentence it
fixes, and keep every fact, condition, and exact value in it.
Report at most five findings per file, choosing the ones a reader would notice
most. Skip a sentence that is already clear, even if a rule could be stretched
to reach it. Leave rules, links, structure, and facts to docs-review and
verify-against-source, which run alongside this pass.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

