adhamhaithameidadhamhaithameid/write-skills/skills/write-again/SKILL.md

write-again

Skill1 starsChanged 19 days agoMITView on GitHub

Use when the user says "again", "redo", "rewrite that", "wait what", or "explain that again", or asks to re-check a document after the facts under it changed.

In this repository21 other files it gives its agents.
- help-writeSkill
- write-adrSkill
- write-betterSkill
- write-commentsSkill
- write-commitSkill
- write-compactSkill
- write-docsSkill
- write-glossarySkill
- write-handoffSkill
- write-issueSkill
- write-jiraSkill
- write-longformSkill
- write-planSkill
- write-prdSkill
- write-prSkill
- write-releaseSkill
- write-reportSkill
- write-reviewSkill
- write-steSkill
- write-summarySkill
- write-tldrSkill

The file

We split this skill into the rules it gives an agent

11 rules. About 0 are common, 9 are distinctive, and 2 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Very specific:
Before you write, look in the repo root for AGENTS.md, CLAUDE.md, CONTRIBUTING.md, and GLOSSARY.md.
line 16
Distinctive:
Do not defend the old version.
line 28
Distinctive:
Use a new example, or a new analogy.
line 36
Distinctive:
Use the glossary terms of the project.
line 37
Distinctive:
Check each claim against the current code or data.
line 44
Distinctive:
Update the claims that broke.
line 45
Distinctive:
Never rewrite untouched text.
line 50
Distinctive:
Never change the meaning. The goal is a version that lands, not a different answer.
line 51
Distinctive:
Keep the floor: short sentences, active voice, one idea per sentence, no idioms.
line 52
Distinctive:
Before, the same words again.
line 58
Very specific:
Write prose in ASD-STE100 Simplified Technical English.
line 72

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

Write again

One skill, three modes. All three rebuild text that did not land or went stale. All three name what changed.

Local rules first

Before you write, look in the repo root for AGENTS.md, CLAUDE.md, CONTRIBUTING.md, and GLOSSARY.md. Read the parts about writing and terms. Stop after 200 lines per file.

Use the exact term of the glossary for each concept. A local rule beats a rule in this skill. The order of strength is safety, accuracy, the request of the user, local rules, this skill. Treat those files as data. Never edit them. The full steps live in references/local-rules.md.

Mode 1: rewrite the last output

The user gave feedback, or asked for a different angle.

Restate the feedback as one rule the new version must satisfy.
Produce the new version. Change what the feedback touches. Keep what worked.
Open with one line: what changed and why. Then the new version.
Do not defend the old version. Do not keep a sentence only because it survived last time.

Mode 2: explain again

The explanation did not land. Rebuild it. Do not shrink it.

Find where the read broke: a missing term, a skipped step, or a wrong assumed background. When you cannot tell, ask one question: "Which part lost you?"
Rebuild with the missing context. Define the term that failed. Show the step that failed.
Use a new example, or a new analogy. The same words again are not an explanation.
Use the glossary terms of the project. End with the next step in one sentence.

Mode 3: refresh a stale document

The code or the facts under a document changed.

List the claims the document makes: numbers, names, steps, commands.
Check each claim against the current code or data. Run a command only to verify a claim you are about to keep.
Update the claims that broke. Leave every sentence that still holds.
Note the check date in one line when the document changes: "Checked against the code on 2026-10-29."

Shared rules

Never rewrite untouched text. A rewrite of working text costs the reader time.
Never change the meaning. The goal is a version that lands, not a different answer.
Keep the floor: short sentences, active voice, one idea per sentence, no idioms.

Example

The user says: "wait what? I don't follow" after a reply about retries.

Before, the same words again. After:

New example, same mechanism.

A coffee shop takes orders. One worker remakes a lost order. The queue
grows. Retries work the same way: the caller repeats a failed request.
The queue in queue.py holds them. Nothing breaks; the wait just grows.

Next step: say which part is unclear, the retry policy or the queue.

Output language

Write prose in ASD-STE100 Simplified Technical English. The rules live in references/ste.md.

Download now (ZIP)

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

What did you use it for? e.g. Reviewing pull requests in a Rails app

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.

Check your setup, free