| name | update-readme |
| description | Updates README.md and README.zh-CN.md to reflect the project's current state. Use this skill whenever the user asks to "update the README", "sync the docs", "update documentation", "reflect latest changes in README", or wants both the English and Chinese READMEs to match the current project. Always triggers when the user mentions updating or regenerating README files, especially for bilingual (EN/ZH) projects. |
| user-invocable | true |
| allowed-tools | ["Read","Write","Edit","Glob","Grep","Bash(git:*)"] |
| disable-model-invocation | true |
Update README
Keep README.md (English, primary) and README.zh-CN.md (Simplified Chinese, secondary) in sync with the project's actual current state. Both files must be accurate, complete, and consistent with each other.
CRITICAL: Ground Truth and Header Format
- Write from ground truth, not from memory or assumption. Every skill/component listed in the README MUST exist in the repository at the time of writing. Verify existence before writing.
- Every README MUST open with the exact header structure shown in the "Header Format" section below, including the language toggle. Adapt badges, project name, and description to the project; do not omit the structure.
- Do not output README content as a code block in the conversation. Use the Edit or Write tool to write the files directly.
Header Format (Required)
Every README must open with this exact structure โ adapt the badges, project name, and description to the project at hand:
# <Project Name> 
[](<link>) [](<link>)
**English** | [็ฎไฝไธญๆ](README.zh-CN.md)
For README.zh-CN.md, reverse the language toggle:
# <Project Name> 
[](<link>) [](<link>)
[English](README.md) | **็ฎไฝไธญๆ**
Choose badges that reflect what is genuinely true about the project. Common types: CI status, license, language/runtime version, package registry version, code coverage. Use shields.io static badges when there is no live endpoint. Prefer reference-style Markdown links for badge rows with more than two badges โ it keeps the source readable. Broken or always-failing badges are worse than no badges; only include ones that are maintained.
Process
1. Survey the project
Before writing anything, read the actual project state:
- Scan all skill/module directories and their SKILL.md or equivalent descriptor files
- Note each component's name, one-line purpose, installation method, and any notable prerequisites
- Check git log for recent additions or removals
- Read the existing README files to understand what is already there and what has gone stale
Write from ground truth, not from memory or assumption.
2. Draft README.md (English)
Use references/template.md as the structural starting point. Adapt section names to the project's domain โ the template shows the skeleton, not the words.
Section order (omit what doesn't apply, don't add sections just to fill space):
- Header โ title + badges + language toggle
- One-liner description (one sentence)
- Logo, banner, or demo GIF โ optional, but place it early if the project has one
- Main content sections (Available Items, Usage, etc.)
- Contributing / Adding a new item
- License
For READMEs over ~300 lines, add a Table of Contents after the one-liner.
The README is a directory, not a tutorial. Keep each component description to one or two sentences. Installation commands must be copy-pasteable โ exact commands, no ambiguity. Always use fenced code blocks with a language tag (```bash, ```json).
Write with a human voice. README prose is some of the most AI-trope-prone writing that exists โ it tends to accumulate "robust", bold-first bullet points, and "serves as" constructions without anyone noticing. Specific things to watch for:
- Word choice: avoid "leverage", "streamline", "robust", "utilize", "delve". Say the plain thing.
- Bullets: don't start every item with a bolded phrase. It reads as AI-generated documentation.
- Descriptions: say what the component does, not what it "serves as" or "stands as".
- Marketing tone: "powerful", "seamless", "comprehensive" add nothing. Cut them.
- Filler transitions: "It's worth noting", "Importantly", "Notably" โ delete these.
A useful test: read each sentence aloud. If it sounds like promotional copy, rewrite it as a plain statement of fact.
3. Draft README.zh-CN.md (Chinese)
Translate the English README faithfully. Rules:
- Use natural Simplified Chinese โ do not translate technical terms that are universally used in English (CLI tool names, package manager commands, GitHub URLs, code blocks).
- Keep all code blocks, commands, and file paths identical to the English version.
- Section headings should be idiomatic Chinese (e.g., "ๅฏ็จๆ่ฝ", "ๆทปๅ ๆฐๆ่ฝ"), not word-for-word translations.
- The language toggle must be
[English](README.md) | **็ฎไฝไธญๆ**.
- Apply the same plain-language discipline as the English version. Chinese technical writing has its own AI tells โ avoid ใ่ต่ฝใ, ใๅฉๅใ, ใ็ๆใ where a simpler word works.
4. Review before writing
Before writing either file, verify:
- Every skill/component listed actually exists in the repository right now
- Installation commands are copy-pasteable and accurate
- No section describes something that has been removed
- Both files cover the same content in the same order
Then scan the draft for writing issues:
- Em-dashes used more than 2-3 times total? Cut most of them.
- Any sentence starts with "The X serves as..."? Rewrite as "The X is...".
- Bold-first bullet pattern throughout? Remove the bold.
- Same word or metaphor repeated across multiple descriptions? Vary it.
- Unicode arrows (โ)? Replace with plain text.
5. Write the files
Write README.md first, then README.zh-CN.md. Use the Edit or Write tool โ do not output the content as a code block in the conversation.
After writing, briefly confirm what changed (e.g., "Added update-readme skill, removed stale apple-events prerequisite note").
References
references/template.md โ README structure template (load when drafting)
