一键导入
write-readme
Use when writing or improving README files. Not all READMEs are the same — provides templates and guidance matched to your audience and project type.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when writing or improving README files. Not all READMEs are the same — provides templates and guidance matched to your audience and project type.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Build, launch, and drive the mindwalk web UI end-to-end for verification.
Set up or troubleshoot Yassimba's curated agent skills, Pi packages, Herdr, and Herdr plugins through the ai-setup CLI. Use when the user asks to install this collection, configure Herdr, add one of its capabilities, update the setup, or diagnose installation problems.
Backlog management: use when the user mentions a backlog, asks what's next, wants work recorded before implementation, or wants queued ideas or specs prioritized, transitioned, completed, or removed; also use when another skill needs to record lifecycle changes.
Use when the user wants to brainstorm or explore an idea — a feature, product direction, or "what if" — before deciding whether it deserves a plan. Ideation only — ends in an idea brief, not a design.
Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (this repo's documented coding standards) and Spec (what the originating issue/PRD asked for). Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".
Use when creating a git commit — the user asks to commit, or a unit of work is complete and ready to commit.
| name | write-readme |
| description | Use when writing or improving README files. Not all READMEs are the same — provides templates and guidance matched to your audience and project type. |
READMEs answer questions your audience will have. Different audiences need different information - a contributor to an OSS project needs different context than future-you opening a config folder.
Always ask: Who will read this, and what do they need to know?
Ask: "What README task are you working on?"
| Task | When |
|---|---|
| Creating | New project, no README yet |
| Adding | Need to document something new |
| Updating | Capabilities changed, content is stale |
| Reviewing | Checking if README is still accurate |
Creating initial README:
Adding a section:
Updating existing content:
Reviewing/refreshing:
After drafting, ask: "Anything else to highlight or include that I might have missed?"
| Type | Audience | Key Sections | Template |
|---|---|---|---|
| Open Source | Contributors, users worldwide | Install, Usage, Contributing, License | templates/oss.md |
| Personal | Future you, portfolio viewers | What it does, Tech stack, Learnings | templates/personal.md |
| Internal | Teammates, new hires | Setup, Architecture, Runbooks | templates/internal.md |
| Config | Future you (confused) | What's here, Why, How to extend, Gotchas | templates/xdg-config.md |
Ask the user if unclear. Don't assume OSS defaults for everything.
Every README needs at minimum:
section-checklist.md - Which sections to include by project typestyle-guide.md - Common README mistakes and prose guidanceusing-references.md - Guide to deeper reference materials