update-readme

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.

523 stars

Best use case

update-readme is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

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.

Teams using update-readme should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/update-readme/SKILL.md --create-dirs "https://raw.githubusercontent.com/FradSer/dotclaude/main/utils/skills/update-readme/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/update-readme/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How update-readme Compares

Feature / Agentupdate-readmeStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

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.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# 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.

## Header Format (Required)

Every README must open with this exact structure — adapt the badges, project name, and description to the project at hand:

```markdown
# <Project Name> ![](https://img.shields.io/badge/<label>-<message>-<color>)

[![<Badge1 Label>](<badge-url>)](<link>) [![<Badge2 Label>](<badge-url>)](<link>)

**English** | [简体中文](README.zh-CN.md)
```

For README.zh-CN.md, reverse the language toggle:

```markdown
# <Project Name> ![](https://img.shields.io/badge/<label>-<message>-<color>)

[![<Badge1 Label>](<badge-url>)](<link>) [![<Badge2 Label>](<badge-url>)](<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):
1. Header — title + badges + language toggle
2. One-liner description (one sentence)
3. Logo, banner, or demo GIF — optional, but place it early if the project has one
4. Main content sections (Available Items, Usage, etc.)
5. Contributing / Adding a new item
6. 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)

Related Skills

update-gitignore

523
from FradSer/dotclaude

Creates or updates a .gitignore file using git-agent AI generation. This skill should be used when the user asks to "update gitignore", "create gitignore", "add ignore rules", or needs to initialize ignore rules for a project.

swiftui-review

523
from FradSer/dotclaude

Reviews SwiftUI code for best practices on modern APIs, maintainability, and performance. This skill should be used when the user asks to review SwiftUI code, check for deprecated iOS/macOS APIs, validate data flow patterns, or audit accessibility compliance in Swift projects.

writing-plans

523
from FradSer/dotclaude

Creates executable implementation plans that break down designs into detailed tasks. This skill should be used when the user has completed a brainstorming design and asks to "write an implementation plan" or "create step-by-step tasks" for execution.

systematic-debugging

523
from FradSer/dotclaude

Provides a systematic debugging methodology with a 4-phase root cause analysis process. This skill should be used when the user reports a bug, error, test failure, or unexpected behavior, ensuring thorough investigation precedes any code changes.

need-vet

523
from FradSer/dotclaude

This skill should be used when the user invokes /need-vet to enable work verification for the current task. Claude must verify completion and append the verified tag before the session can end.

executing-plans

523
from FradSer/dotclaude

Executes written implementation plans efficiently using agent teams or subagents. This skill should be used when the user has a completed plan.md, asks to "execute the plan", or is ready to run batches of independent tasks in parallel following BDD principles.

build-like-iphone-team

523
from FradSer/dotclaude

Applies Apple's Project Purple design philosophy for radical innovation. This skill should be used when the user wants to challenge industry conventions, approach open-ended problems requiring disruptive thinking, or when standard brainstorming needs a breakthrough approach.

brainstorming

523
from FradSer/dotclaude

Structures collaborative dialogue to turn rough ideas into implementation-ready designs. This skill should be used when the user has a new idea, feature request, ambiguous requirement, or asks to "brainstorm a solution" before implementation begins.

behavior-driven-development

523
from FradSer/dotclaude

Applies behavior-driven development principles including Gherkin scenarios and test-driven development. This skill should be used when the user asks to implement features, fix bugs, or when writing executable specifications and tests before writing production code.

agent-team-driven-development

523
from FradSer/dotclaude

Provides guidance on coordinating multiple specialized teammates working in parallel. This skill should be used when the user needs to execute complex implementation plans, resolve cross-cutting concerns, or coordinate independent work streams requiring communication.

shadcn

523
from FradSer/dotclaude

Manages shadcn components and projects — adding, searching, fixing, debugging, styling, and composing UI. Provides project context, component docs, and usage examples. Applies when working with shadcn/ui, component registries, presets, --preset codes, or any project with a components.json file. Also triggers for "shadcn init", "create an app with --preset", or "switch to --preset".

refactor

523
from FradSer/dotclaude

Executes automated refactoring for specific files, directories, or semantic queries. This skill should be used when the user asks to refactor specific files or directories, simplify recently changed code, clean up dead code in a limited scope, or invokes "/refactor".