Agent skill

Technical Writing

by ericrisco in ericrisco/rsc-harness

A skill your agent uses when writing or fixing user-facing technical docs — a README, a getting-started tutorial, a how-to guide, or API/CLI/config reference — especially when a page tries to teach…

MITAuto-check passedWriting & Content

Install Technical Writing

skills CLI
$ npx skills add ericrisco/rsc-harness --skill technical-writing -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install ericrisco/rsc-harness technical-writing --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/ericrisco/rsc-harness.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/technical-writing .claude/skills/technical-writing && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
technical-writing
GitHub stars
156
Token cost
~3k tokens
SKILL.md length
1,047 words
Files
6 (incl. scripts, references)
Skills in repo
229
Repo updated
First seen
Licence
MIT

At a glance

A skill your agent uses when writing or fixing user-facing technical docs — a README, a getting-started tutorial, a how-to guide, or API/CLI/config reference — especially when a page tries to teach…

  • Fixing user-facing technical docs — a README
  • SKILL.md covers First move: classify the doc, Tutorial, Reference and Explanation, plus 6 more sections
  • Runs Shell scripts from its folder; calls pip; needs ACME_KEY and DD_API_KEY
  • A getting-started tutorial

What it does

Technical Writing is an agent skill from ericrisco/rsc-harness. Use when writing or fixing user-facing technical docs — a README, a getting-started tutorial, a how-to guide, or API/CLI/config reference — especially when a page tries to teach, explain and enumerate at once, a tutorial branches, a reference is padded with opinions, a README reads like a sales pitch, samples are stale, or weasel words have crept in. NOT an SEO blog article (that is article-writing), NOT the content calendar or pipeline (that is content-engine).

Its SKILL.md is about 3k tokens, which your agent loads only when the skill is triggered. The skill folder holds 8 other files, including scripts and reference files (for example `evals/README.md`, `evals/cases.yaml` and `references/diataxis-modes.md`).

It sits in Writing & Content, covering Technical writing, Blog and article writing and Technical documentation. The repository describes itself as: Your agent invents things because it has no memory, and can't touch your database because it has no arms. rsc is the meta-harness that gives it both, plus the trade to know the… The licence is MIT.

When your agent uses it

  • Fixing user-facing technical docs — a README
  • A getting-started tutorial
  • API/CLI/config reference — especially when a page tries to teach
  • Explain and enumerate at once

Example prompts

  • “/technical-writing”

Requirements

  • Python 3
  • A Bash shell
  • A credential in ACME_KEY
  • A credential in DD_API_KEY

What it can do on your machine

Read from SKILL.md and the folder at commit 92fde8f. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Ships 1 file in scripts/ (Shell), which the agent can run.

    Shell commands in SKILL.md call:

    • pip

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use pip, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names these keys or tokens, usually read from environment variables:

    • ACME_KEY
    • DD_API_KEY

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Technical Writing loads about 3k tokens when it runs, and up to ~4.6k if it reads all its reference files. Until then it costs about 122 tokens; SKILL.md has 1,047 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~122
When it runs · the whole SKILL.md, loaded when a task matches
~3k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~4.6k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.

SKILL.md

The full file from ericrisco/rsc-harness at commit 92fde8f, republished under its MIT licence (© ericrisco). 1,047 words, ~2,974 tokens.

Download SKILL.mdSave it as .claude/skills/technical-writing/SKILL.md (or your agent's skills folder). This skill also uses 5 other files; get the full folder from GitHub.
name
technical-writing
description
Use when writing or fixing user-facing technical docs — a README, a getting-started tutorial, a how-to guide, or API/CLI/config reference — especially when a page tries to teach, explain and enumerate at once, a tutorial branches, a reference is padded with opinions, a README reads like a sales pitch, samples are stale, or weasel words have crept in. NOT an SEO blog article (that is `article-writing`), NOT the content calendar or pipeline (that is `content-engine`).
tags
documentation, technical-writing, diataxis, readme, docs-as-code, developer-docs
recommends
article-writing, content-engine, course-storytelling, translation-l10n, brand-voice, accessibility
origin
risco

Technical writing

You write the document a person reads to use a product or codebase: a README, a tutorial, a how-to, API/CLI/config reference. Not marketing prose, not an SEO article, not a course. The craft is mostly one decision made early and held: what kind of doc does this reader actually need, then writing that one kind in its correct shape.

The backbone is Diátaxis — four documentation modes, each serving a distinct need (diataxis.fr). The sentence-level rules come from the Google developer documentation style guide (developers.google.com/style). The shipping discipline is docs-as-code: docs live with the code and lint in CI.

First move: classify the doc

Before you write a line, name the reader's need and pick exactly one mode. Mixing modes in one page is the single biggest reason docs fail readers — the learner gets buried in parameters, the expert wades through a beginner tutorial to find one flag.

Reader is…They want…ModeShape
Learning, new, hands need holdingTo acquire skill by doingTutorialLinear, runnable, guaranteed to work
Competent, has a specific goalTo get a task done nowHow-toGoal-titled, ordered steps, no teaching
Working, needs a factTo look something upReferenceDry, complete, mirrors the product
Curious, wants the "why"To understandExplanationDiscursive, trade-offs, no steps

Rule: one page, one mode. Why: a tutorial answers "how do I start?", reference answers "what are the flags?" — a reader arrives with one question, and a page serving two answers neither well.

If a page already mixes modes, do not patch it — split it. See references/diataxis-modes.md for a worked split of one bad page into four.

Tutorial

A lesson a beginner runs end to end and succeeds. You are the instructor; their success is your responsibility, not theirs.

  • Title it for the learner's gain: "Build your first X", not "X configuration".
  • State prerequisites and exact versions up top before step 1.
  • Number every step. Each step produces a visible result the reader can check against.
  • It must run start-to-finish on a clean machine. Test it on one.
  • No branching. No "if you prefer Y…", no "depending on your setup". One path.
  • No explanation of why. A learner doing 12 new things cannot also absorb design rationale. Link the "why" to an explanation page.

Bad → Good opening:

md
<!-- Bad: assumes context, branches, explains -->
Depending on your package manager, install the SDK (we use a monorepo
because it scales better). Configure your environment as needed.

<!-- Good: one path, concrete, checkable -->
## Build your first report

You need Python 3.12+ and a free API key from example.com/keys.

1. Install the SDK:
   ```bash
   pip install acme-sdk==4.2.0
  1. Save your key:
    bash
    export ACME_KEY="your-key-here"
    Run echo $ACME_KEY — you should see your key printed back.

## How-to

A recipe for someone who already knows the product and has a real goal right now.

- Title it as the goal: **"How to rotate an API key"**, not "API keys".
- Assume competence. Do not re-teach concepts; link to reference/explanation instead.
- Ordered steps, but the reader may adapt — state the goal so they can.
- Address one real-world task. "How to configure logging" is reference; "How to ship logs to Datadog" is a how-to.
- No tutorial hand-holding, no narrative.

Bad → Good:

```md
<!-- Bad: teaches, no clear goal in the title -->
## Logging
Logging is important. A logger has levels: DEBUG, INFO… Here is how
levels work, and then some setup.

<!-- Good: goal title, competent reader, straight to it -->
## How to send logs to Datadog
1. Set `LOG_SINK=datadog` and `DD_API_KEY` in the environment.
2. Restart the worker: `acme worker restart`.
3. Confirm delivery in Datadog → Logs within ~1 min.

Reference

The technical facts, structured to mirror the product. The reader is not reading top to bottom — they are scanning for one entry.

  • Dry, complete, consistent. Same structure for every entry.
  • Structure follows the code: one section per command, endpoint, or config key.
  • Use tables for parameters, flags, return values, and errors.
  • No opinions, no recommendations, no "you should". Reference states what is. Move "which one to pick" to a how-to or explanation.
  • Document every parameter, including defaults and required/optional.
md
### `GET /reports/{id}`

| Param | In | Type | Required | Description |
|---|---|---|---|---|
| `id` | path | string (uuid) | yes | Report identifier. |
| `fields` | query | string | no | Comma-separated fields to return. Default: all. |

**Responses**

| Status | Meaning |
|---|---|
| `200` | Report returned. |
| `404` | No report with that `id`. |
| `429` | Rate limit exceeded; retry after `Retry-After` seconds. |

Explanation

Background and the "why" — context, design decisions, trade-offs, alternatives considered.

  • Discursive prose, free to make connections and admit nuance.
  • Never numbered steps. If you are writing "1. … 2. …", it is a tutorial or how-to, not an explanation.
  • Free to hold an opinion and explain the reasoning — this is the only mode where opinion belongs.
  • Title with "About…", "Why…", or a concept name. Read at leisure, not while doing.

README recipe

The one doc everyone gets wrong by turning it into a pitch. A README lives in the top-level directory, orients a new reader, and at minimum says what the thing is, what it is for, and links to fuller docs (Google docguide).

Skeleton, in order: what + why (two lines) → install → one minimal runnable example → link to deeper docs → status/license.

Bad → Good opening lines:

md
<!-- Bad: a sales page -->
# Acme SDK 🚀
The most powerful, blazing-fast, developer-friendly toolkit to
effortlessly supercharge your data workflows!

<!-- Good: what it is, what it's for, in two lines -->
# Acme SDK
A Python client for the Acme reporting API. Fetch, filter, and export
reports without writing HTTP by hand.

## Install
```bash
pip install acme-sdk==4.2.0

## Sentence-level rules

Apply these to every mode. Each ships clearer prose at no cost.

| Rule | Why | Bad → Good |
|---|---|---|
| Second person, imperative steps | The reader is *doing* this | "The user should run…" → "Run…" |
| Active voice | Names who acts | "The file is created by the script" → "The script creates the file" |
| Present tense | Docs describe how it works now | "This will return a list" → "This returns a list" |
| Define before use | No forward references | Spell out a term the first time, then use it |
| One idea per sentence | Scannable, translatable | Split the 40-word sentence into two |
| Cut "in order to" | It is always just "to" | "in order to deploy" → "to deploy" |
| Ban weasel/AI-tell words | They lie about difficulty and add nothing | "simply run X" → "run X" |

Banned words: **simply, just, easy, effortless, seamless, robust, powerful, leverage, utilize, in order to, blazing-fast, supercharge**. If a step is "simple", the reader either already knows it (delete the word) or does not (the word mocks them). Full banlist with replacements is in `references/diataxis-modes.md`.

## Code examples

- Minimal: the fewest lines that work. Cut every line not required to run.
- Runnable and **tested** — copy-paste it onto a clean machine and confirm. Untested samples rot and misinform.
- Language-tag every fence (`bash`, `python`, `json`, `yaml`, `ini`).
- Show expected output so the reader knows they succeeded.
- No `...` standing in for required lines. Elide only genuinely irrelevant detail, and say so.

```python
# Good: minimal, runnable, shows what comes back
from acme import Client

client = Client(api_key="your-key")
report = client.reports.get("3f9a-...")
print(report.title)
# -> "Q2 revenue"
Show full SKILL.md (439 more words)Show less

Docs-as-code

Treat docs like code, or they go stale and mislead.

  • Change docs in the same PR as the code they describe. Dead docs are worse than no docs — they actively misinform and slow developers (Google docguide best practices).
  • Lint prose in CI. Vale is the de-facto open-source prose linter: config in .vale.ini at the repo root, custom rules in a styles dir, run as a blocking check on every PR touching Markdown. Common rules ban "simply/just/easy" and enforce "sign in" over "log in". Used in production by GitLab, Datadog, and ING.
  • Test samples and check links in CI (writethedocs.org). A broken pip install line in a tutorial breaks every reader.

A starter .vale.ini, a custom banned-terms style, and a GitHub Actions blocking job are in references/vale-starter.md.

Anti-patterns

Anti-patternWhy it failsDo instead
One page teaches + explains + lists paramsServes no reader well; all three are dilutedSplit by mode (classify table above)
Tutorial that branches ("if you prefer…")Beginner cannot judge the choice; loses the pathOne guaranteed path; defer choices to a how-to
How-to that teaches conceptsWastes the competent reader's timeLink to reference/explanation; just give steps
Reference with opinions ("we recommend…")Pollutes a lookup with judgementMove recommendations to how-to/explanation
README as a sales pageNew reader still does not know what it isWhat/why in two lines, then install + example
Untested or ...-gapped code samplesThey rot; reader copies a broken commandTest on a clean machine; show expected output
Weasel words (simply, just, seamless)Lie about difficulty, add zero informationDelete the word; the imperative stands alone
Wall of text, no headings or stepsUnscannable; reader cannot find their answerShort sentences, one idea each, real headings

Before you ship

  • Page is exactly one Diátaxis mode (tutorial / how-to / reference / explanation).
  • Prerequisites and versions are stated before step 1 (tutorial/how-to).
  • Every code sample runs on a clean machine and shows expected output.
  • No ... hides a line the reader needs.
  • Banlist is clean (scripts/verify.sh path/to/doc.md).
  • All links resolve.
  • README says what it is + what it's for + links to deeper docs.
  • Doc changed in the same PR as the code it documents.

References

  • references/diataxis-modes.md — per-mode templates, a worked split of one mixed page into four, and the full weasel-word/AI-tell banlist with replacements.
  • references/vale-starter.md — starter .vale.ini, a custom banned-terms Vale style, and a GitHub Actions job running Vale as a blocking check.

Siblings

  • SEO blog post / long-form article with schema and FAQ → ../article-writing/SKILL.md.
  • Editorial calendar, pillars, content pipeline → ../content-engine/SKILL.md.
  • Teaching a syllabus over time with narrative → ../course-storytelling/SKILL.md.
  • Brand tone and voice rules → ../brand-voice/SKILL.md.
  • Making docs and samples accessible → ../accessibility/SKILL.md.
  • Localizing finished docs into another language → translation-l10n.

© ericrisco, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 5 other files (scripts, references) in skills/technical-writing of ericrisco/rsc-harness.

  • SKILL.md
  • evals/README.md
  • evals/cases.yaml
  • references/diataxis-modes.md
  • references/vale-starter.md
  • scripts/verify.sh

Open the folder on GitHubat commit 92fde8f

Compare with similar skills

Technical Writing next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Technical Writing compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Technical Writing this skillericrisco/rsc-harness156—~3kAutomated safety check: PassMIT
Content Creatorthatrebeccarae/claude-marketing162—~1.1kAutomated safety check: PassMIT
Rnd Technical Writerchendongqi/OPB-Skills125—~2.5kAutomated safety check: PassNone
Money Contentiamzifei/show-me-the-money1k—~9.6kAutomated safety check: PassCustom licence
Content Engineindranilbanerjee/digital-marketing-pro8541 repos~8.9kAutomated safety check: PassMIT
Content Briefindranilbanerjee/digital-marketing-pro8541 repos~1.2kAutomated safety check: PassMIT

Similar skills

  • Content Creator

    thatrebeccarae/claude-marketing

    Comprehensive content marketing toolkit with brand voice analysis, SEO optimization scripts, content frameworks, social media strategy, and content calendar planning.

    162 GitHub stars~1.1k tokensUpdated 4 mo ago
    Writing & ContentAuto-check passed
  • Rnd Technical Writer

    chendongqi/OPB-Skills

    Technical article writing assistant. An agent skill from chendongqi/OPB-Skills.

    125 GitHub stars~2.5k tokensUpdated 7 mo ago
    Writing & ContentAuto-check passed
  • Money Content

    iamzifei/show-me-the-money

    Automated content creation pipeline for business growth. An agent skill from iamzifei/show-me-the-money.

    1k GitHub stars~9.6k tokensUpdated 1 mo ago
    Writing & ContentAuto-check passed
  • Content Engine

    indranilbanerjee/digital-marketing-pro

    Draft marketing content in brand voice — blog posts, ad copy, email sequences, social posts, landing pages, and brand-voice guides — through a gated pipeline (research, outline, draft, fact-check…

    854 GitHub starsUsed in 1 repo~8.9k tokens
    Writing & ContentAuto-check passed
  • Content Brief

    indranilbanerjee/digital-marketing-pro

    Create a production-ready content brief a writer can execute without extra context — keyword map (primary, secondary, related questions), H2/H3 outline with key points and word-count targets, brand…

    854 GitHub starsUsed in 1 repo~1.2k tokens
    Writing & ContentAuto-check passed
  • Creator Analytics Master

    FerroxLabs/wayland

    Cross-platform analytics mastery for content creators covering YouTube, Instagram, TikTok, Twitter/X, podcast, and newsletter metrics, audience demographic analysis, content performance patterns…

    608 GitHub stars~3.6k tokensUpdated yesterday
    Writing & ContentAuto-check passed

More from ericrisco/rsc-harness

All 229 skills in this repo
  • Ab Testing

    ericrisco/rsc-harness

    A skill your agent uses when designing or analyzing a controlled experiment — falsifiable hypothesis, sample size from an MDE, reading significance/CI/power, CUPED, or rescuing tests that won't go…

    156 GitHub stars~2.4k tokensUpdated yesterday
    Auto-check passed
  • Accessibility

    ericrisco/rsc-harness

    A skill your agent uses when making a web UI conform to WCAG 2.2 Level AA — axe-core or Lighthouse a11y violations, keyboard operability, focus management, ARIA roles/names/live regions, contrast…

    156 GitHub stars~3.4k tokensUpdated yesterday
    Auto-check passed
  • Ads

    ericrisco/rsc-harness

    A skill your agent uses when running or fixing paid acquisition on Google or Meta — campaign structure (Performance Max, Demand Gen, Search, Advantage+), platform-fit creative, budget/scaling rules…

    156 GitHub stars~2.2k tokensUpdated yesterday
    Auto-check passed
  • Agent Eval

    ericrisco/rsc-harness

    A skill your agent uses when measuring whether an LLM or agent system actually got better and gating merges on it: golden sets, fixing an inflated LLM-as-judge, scoring RAG (faithfulness, contextual…

    156 GitHub stars~3.2k tokensUpdated yesterday
    Auto-check passed
  • AI Media

    ericrisco/rsc-harness

    A skill your agent uses when a creative goal must become a finished media file: pick and order generative-media models per modality — AI voiceover, image-to-video clips, score — then glue them with…

    156 GitHub stars~3.3k tokensUpdated yesterday
    Auto-check passed
  • Analytics

    ericrisco/rsc-harness

    A skill your agent uses when instrumenting product or web analytics — GA4/PostHog SDK wiring, event taxonomy, funnels, double-counted events, consent gating, PII scrubbing.

    156 GitHub stars~2.8k tokensUpdated yesterday
    Auto-check passed

Questions about Technical Writing

What does Technical Writing do?

A skill your agent uses when writing or fixing user-facing technical docs — a README, a getting-started tutorial, a how-to guide, or API/CLI/config reference — especially when a page tries to teach…. Technical Writing is an agent skill from ericrisco/rsc-harness. Use when writing or fixing user-facing technical docs — a README, a getting-started tutorial, a how-to guide, or API/CLI/config reference — especially when a page tries to teach, explain and enumerate at once, a tutorial branches, a reference is padded with opinions, a README reads like a sales pitch, samples are stale, or weasel words have crept in.

When should I use Technical Writing?

Technical Writing fits situations like: fixing user-facing technical docs — a README; A getting-started tutorial; API/CLI/config reference — especially when a page tries to teach; explain and enumerate at once.

How do I install Technical Writing in Claude Code?

Run `npx skills add ericrisco/rsc-harness --skill technical-writing -a claude-code`. Or copy the skill folder (skills/technical-writing in ericrisco/rsc-harness) into .claude/skills/technical-writing in your project. Claude Code loads it when a task matches its description.

How do I install Technical Writing in Codex?

Run `npx skills add ericrisco/rsc-harness --skill technical-writing -a codex`. Or copy the skill folder (skills/technical-writing in ericrisco/rsc-harness) into .agents/skills/technical-writing in your project. Codex loads it when a task matches its description.

Can I use Technical Writing in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add ericrisco/rsc-harness --skill technical-writing -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/technical-writing, .gemini/skills/technical-writing, .github/skills/technical-writing and .opencode/skills/technical-writing in your project.

What does Technical Writing need to run?

Going by SKILL.md and its folder, Technical Writing needs a shell for the scripts in its folder, the command-line tools its instructions call (pip) and credentials named ACME_KEY and DD_API_KEY. Our summary lists: Python 3; A Bash shell; A credential in ACME_KEY; A credential in DD_API_KEY.

Does Technical Writing access the network?

SKILL.md contains no URLs. Its commands use pip, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Technical Writing safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.

What licence does Technical Writing use?

Technical Writing is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Technical Writing use?

About 3k tokens (SKILL.md is roughly 12k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 1.6k tokens, read only when the agent opens those files.

What are the alternatives to Technical Writing?

Skills that share tags, products or a category with Technical Writing: Content Creator (thatrebeccarae/claude-marketing, 162 stars), Rnd Technical Writer (chendongqi/OPB-Skills, 125 stars), Money Content (iamzifei/show-me-the-money, 1k stars) and Content Engine (indranilbanerjee/digital-marketing-pro, 854 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Technical Writing?

ericrisco (a GitHub user) maintains it in ericrisco/rsc-harness, which has 156 GitHub stars. The repository holds 229 skills in this directory. The repository was last updated on October 6, 2026.

Source: ericrisco/rsc-harness on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.