[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6NK3C68MGDACSHXF0MAF07Y":3,"skill-same:01M6NK3C68MGDACSHXF0MAF07Y":70},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":14,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":6,"updatedAt":55,"install":56,"resources":69},"01M6NK3C68MGDACSHXF0MAF07Y","readme-updater",null,"Bring a project's README up to date with the current state of the codebase. Audits the existing README for stale commands, dead links, renamed tools, and drifted status claims; surveys what's changed since the README was last touched; rewrites it with verified facts; then commits and pushes. Use this skill whenever the user says \"update the README\", \"the readme is stale\", \"refresh the README\", \"rewrite README.md\", \"add new features to the readme\", or otherwise asks for documentation that reflects the current state of the project. Also trigger when a README clearly hasn't kept pace with the codebase (e.g. recent feature commits not reflected, broken examples).","mistakenot\u002Fauto-stack","mistakenot","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F7852099?v=4","01M6CY3K3NE7B30VD9C8HP815J","Charlie","01M6NHYR6FB2SEZ7DFHD3PS3D6",0,"MIT","https:\u002F\u002Fgithub.com\u002Fmistakenot\u002Fauto-stack\u002Fblob\u002Fmain\u002Fskills\u002Freadme-updater\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"readme updater","README","updater","feature","features","for","claims","verified","bring","links","add","status","commands","project","up","broken","commits","Tools","update","documentation","2026-11-10 10:12:30",false,"---\nname: readme-updater\ndescription: >-\n  Bring a project's README up to date with the current state of the codebase.\n  Audits the existing README for stale commands, dead links, renamed tools, and\n  drifted status claims; surveys what's changed since the README was last\n  touched; rewrites it with verified facts; then commits and pushes. Use this\n  skill whenever the user says \"update the README\", \"the readme is stale\",\n  \"refresh the README\", \"rewrite README.md\", \"add new features to the readme\",\n  or otherwise asks for documentation that reflects the current state of the\n  project. Also trigger when a README clearly hasn't kept pace with the\n  codebase (e.g. recent feature commits not reflected, broken examples).\nlicense: MIT\n---\n\n# README Updater\n\nBring a stale README back into sync with reality, end to end, in one pass.\nThe skill runs four phases sequentially without pausing for human input,\nthen commits and pushes the result.\n\n## When this skill triggers\n\n- \"update the README\", \"the README is out of date\", \"refresh README.md\"\n- \"the README doesn't mention \u003Cfeature>\"\n- \"rewrite the README to cover what we've shipped\"\n- Any request to bring docs in line with the current state of the code\n\nIt does **not** trigger for:\n- Small spot-edits to a README (just edit directly)\n- Drafting a brand-new README from scratch in an empty repo (different problem)\n- Generating per-package docs (use a docgen tool)\n\n## The most important lesson\n\n**Never trust your memory or the existing README for CLI claims.**\nOn every prior run, the model has shipped at least one snippet referencing\na flag that no longer exists or a subcommand that was renamed. The\nverification phase below is non-negotiable — it is the one step that\ndistinguishes a useful README update from a confidence-damaging one.\n\n## Phase 1 — Scope\n\nFind when the README was last meaningfully updated and what's changed\nsince. This bounds the work.\n\n```bash\n# Last commits that touched README.md (not just chore renames)\ngit log --oneline -20 README.md\n\n# Pick the most recent substantive update commit — call it $LAST_README_SHA\ngit log --oneline $LAST_README_SHA..HEAD | wc -l   # how many commits since\ngit log --oneline $LAST_README_SHA..HEAD           # the actual list\n```\n\nIf the README has never been written (empty repo or new file), there is no\nprior state to audit — skip Phase 2 and treat Phase 3 as a fresh inventory.\n\n## Phase 2 — Audit (inconsistency check)\n\nBefore drafting anything new, scan the **existing** README for claims that\nno longer match reality. This is faster than rewriting from scratch and\ncatches drift the user may not know about.\n\nRun these checks. Don't pause for user input — log findings inline and\ncarry them into Phase 4.\n\n### 2.1 CLI commands and flags\n\nFor every code block in the README that looks like a CLI invocation\n(`\u003Cbinary> \u003Csubcommand> --flag value`), check that the binary, subcommand,\nand flag still exist.\n\n```bash\n# Get the real command tree\n\u003Cbinary> --help\n\u003Cbinary> \u003Csubcommand> --help\n```\n\nFlag the snippet as **stale** if any of:\n- The binary doesn't exist (renamed, removed)\n- The subcommand is renamed (e.g. `cochange` → `co-change`)\n- The flag is renamed, removed, or moved to a different subcommand\n- The default value drifted\n\n### 2.2 File paths and directory layouts\n\nFor every `path\u002Fto\u002Ffile` or `dir\u002F` mentioned, verify it exists:\n\n```bash\nls path\u002Fto\u002Ffile 2>\u002Fdev\u002Fnull || echo \"STALE: path\u002Fto\u002Ffile\"\n```\n\n### 2.3 Tool \u002F package inventory\n\nIf the README lists tools, packages, or sub-projects in a table, compare\nthat list to what the repo actually contains. New tools added since the\nlast README touch are the most common source of staleness.\n\n```bash\n# For monorepos with discoverable sub-projects\nls -d \u003Cprefix>-*\u002F  # e.g. auto-*\u002F, packages\u002F*, apps\u002F*\n```\n\nFlag missing entries (tool exists in repo, not in README) and dead entries\n(README lists tool, repo doesn't have it).\n\n### 2.4 Naming consistency\n\nSkim the README for inconsistent naming of the same thing:\n- `auto-eval` vs `autoeval` vs `auto_eval`\n- `myproject-cli` vs `myproject` vs `mp`\n\nPick one canonical name (usually the binary name) and standardise.\n\n### 2.5 Status claims\n\nIf the README labels things as \"Active\", \"Beta\", \"Coming Soon\", \"Deprecated\":\n- Has a \"Coming Soon\" tool now shipped? → Promote it.\n- Has an \"Active\" tool been removed? → Demote or delete.\n- Does the \"Beta\" claim still hold given recent stability work?\n\n### 2.6 External references\n\n- Install URLs (`curl … | bash`) — fetch the URL or confirm the repo path.\n- Badge URLs — fetch and confirm they render.\n- Cross-links to other docs — confirm targets exist.\n- Version numbers (`Go 1.22+`, `Node 18+`) — confirm against `go.mod` \u002F\n  `package.json` \u002F CI config.\n\nKeep findings in a short scratch list (`audit_findings`) — you'll address\nthem in Phase 4.\n\n## Phase 3 — Survey\n\nDispatch parallel research agents to inventory the current state. Run them\nconcurrently — this is the longest phase and the agents are independent.\n\n### Agent A — Project \u002F tool inventory\n\nFor monorepos, the inventory is per-sub-project. For single-project repos,\nsubstitute \"the project\" for \"each sub-project\".\n\nPrompt template:\n\n> For each directory below, read its README\u002FCLAUDE.md, list the binary's\n> available commands (look at main.go \u002F cmd\u002F \u002F package.json scripts \u002F\n> cobra command tree), and identify whether it is fully implemented or\n> scaffolded.\n>\n> For each, report under 100 words:\n> - One-line description\n> - Status: Active \u002F Working \u002F Scaffolded\n> - Binary name\n> - Top-level commands\n> - Notable recent features\n>\n> Total report under 1500 words.\n\n### Agent B — Feature mining from git history\n\nPrompt template:\n\n> The README was last updated at commit $LAST_README_SHA. Run\n> `git log --oneline $LAST_README_SHA..HEAD` and for each `feat:` commit\n> summarise the user-visible feature added. Group by tool\u002Farea. For each\n> feature give: tool, feature name, one-sentence description, commit hash.\n> Focus on user-facing features, not refactors or CI changes.\n> Under 1000 words.\n\nSending both agents in **one message** (parallel tool calls) is important —\nthey run concurrently and you get both reports back before Phase 4 starts.\n\n## Phase 4 — Draft\n\nRewrite the README using the audit findings (Phase 2) and survey reports\n(Phase 3). Some structural defaults that have proven to work:\n\n### Diagrams\n\nReplace ASCII diagrams with **Mermaid**. GitHub renders Mermaid natively in\nthe web UI, in PRs, and in issues. Mermaid is text-based, diff-friendly,\nand requires no build step. Use `flowchart LR` for pipelines and\n`flowchart TD` for data architecture.\n\nOther options considered (in case the user asks):\n- Checked-in SVG \u002F PNG → high quality but binary, hard to diff, needs a\n  build step or an external editor.\n- D2 → newer than Mermaid, less broadly rendered.\n- ASCII → diff-friendly but ugly. Only use if the user specifically asks.\n\nStyle classes give a polished look:\n\n```mermaid\nflowchart LR\n    A[Foo] --> B[Bar]\n    classDef active fill:#1f6feb,stroke:#1f6feb,color:#fff;\n    class A,B active;\n```\n\n### Status badges\n\nFor status-of-tool tables, use [shields.io](https:\u002F\u002Fshields.io) badges:\n\n```\n![Active](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fstatus-active-brightgreen)\n![Coming Soon](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fstatus-coming%20soon-yellow)\n![Beta](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fstatus-beta-blue)\n![Deprecated](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fstatus-deprecated-red)\n```\n\nBadges read at a glance and survive markdown rendering everywhere.\n\n### Tool tables\n\nOrder rows by **role in the pipeline \u002F system**, not alphabetically.\nFoundation \u002F input tools first, derived tools in the middle, infra and\norchestration last, \"coming soon\" at the bottom. Add a one-line lede above\nthe table explaining the ordering, so readers know the order is\nintentional.\n\n### Quick Start\n\nIf the project has a non-trivial workflow, write a numbered \"Quick Start:\nThe Full Loop\" section. Each step should be runnable as-is, paired with\none or two lines of explanation. The goal: someone copies the entire\nblock, runs it, sees the system end-to-end.\n\n### Feature Highlights\n\nA bulleted section grouped by domain (e.g. \"Ingest & analytics\",\n\"Search & discovery\", \"Code context\", \"Documentation\"). Pulls from the\ngit-history mining agent's report. Each bullet is one sentence, name in\nbold.\n\n### Writing rules\n\nThese rules apply to every change you make in the README. They keep the\nprose feeling consistent and prevent the document from drifting into a\nchangelog.\n\n- **Present tense, current state only.** Describe the system as it is —\n  as if it had always been this way. Never say \"we added X\", \"X is now\n  Y\", \"new in v2\", \"now supports Z\", or anything that implies a\n  before\u002Fafter. The git log carries the change history; the README\n  carries the current state. This is the single most common drift\n  pattern and the easiest to catch yourself doing.\n- **Match the existing tone and style.** If the README uses terse bullet\n  points, keep that style. If it uses full paragraphs, match that. Don't\n  impose a new voice mid-document.\n- **Preserve existing structure where it works.** Add new sections or\n  entries in the logical place within the existing document. Don't\n  reorganise unless the current structure genuinely can't accommodate\n  the new content. Other docs and external sites may link to existing\n  heading anchors.\n- **Be specific.** Use actual command names, flag names, file paths, and\n  concrete examples — not vague descriptions (\"supports several\n  options\"). Specificity is what makes a README useful as a reference,\n  not just an introduction.\n- **Don't pad.** If a feature is simple, a one-liner is fine. Don't\n  inflate descriptions to seem thorough. Short and accurate beats long\n  and hedging.\n\n### What to keep\n\nSections worth preserving by default: Install, Quick Start, Data\nArchitecture, Configuration, Development, License. Don't rewrite for\nthe sake of it.\n\n## Phase 5 — Verify (non-negotiable)\n\nFor **every CLI snippet** in the new draft, run the actual command's\n`--help` output and confirm the binary, subcommand, and every flag is\nspelt correctly and accepts the value type shown.\n\n```bash\n# For each snippet in the README, verify:\n\u003Cbinary> --help\n\u003Cbinary> \u003Csubcommand> --help\n\n# If the snippet uses --flag value, confirm --flag exists and accepts that type.\n```\n\nA short, automatable pattern: grep the README for lines starting with\n`\u003Cbinary> ` inside code blocks, then for each one diff against\n`\u003Cbinary> \u003Csubcommand> --help`. Doing this catches roughly five wrong\nflags per rewrite on real codebases.\n\nIf a verification fails:\n- The intended feature exists but the flag is named differently → fix the\n  snippet.\n- The intended feature doesn't exist at all → cut the snippet, pick a\n  feature that does work, and document that instead. Don't aspirational-document.\n\nAlso verify any URLs, file paths, version numbers, and `make` targets\nquoted in the README still resolve.\n\n## Phase 6 — Commit and push\n\nStage only the README (and any directly related doc updates the audit\nturned up — e.g. a renamed file the README pointed at). Don't sweep in\nunrelated working-tree changes.\n\n```bash\ngit add README.md\n```\n\nWrite a commit message that names what was done and why. The format used\non the auto-stack repo:\n\n```\ndocs(readme): \u003Cone-line subject under 70 chars>\n\n\u003Ctwo or three paragraphs explaining what changed and why, calling out the\nbiggest categories of update (new tools, restructured sections, verified\nCLI snippets, replaced ASCII with Mermaid, etc.).>\n\nCo-Authored-By: …\n```\n\nThen push:\n\n```bash\ngit push origin \u003Ccurrent-branch>\n```\n\nIf the repo has a pre-commit hook that runs format \u002F vet \u002F lint, let it\nrun. If it fails, fix the underlying issue rather than passing\n`--no-verify`.\n\n## Communicating with the user\n\nBrief updates per phase, not a running monologue:\n\n- Start of Phase 2: \"Auditing the current README — checking commands,\n  paths, status claims.\"\n- Start of Phase 3: \"Dispatching survey agents in parallel — project\n  inventory and git-history feature mining.\"\n- Start of Phase 4: \"Drafting the new README.\"\n- Start of Phase 5: \"Verifying every CLI snippet against --help.\"\n- End: \"Pushed as \u003Csha>. Summary of what changed: …\"\n\nIf the verification phase catches the model contradicting itself\n(documenting a flag that doesn't exist), say so explicitly in the final\nreport — it builds trust and helps the user spot the same kind of error\nthe next time around.\n\n## Common pitfalls\n\n1. **Memorised flags.** \"I'm sure `--bash-exit-code` exists.\" Don't\n   trust this. Run `--help`.\n2. **Inventing aspirational features.** If a tool is scaffolded, label\n   it \"Coming Soon\" — don't write a Quick Start for it.\n3. **Skipping the audit because the rewrite \"covers it anyway\".**\n   The audit catches things you'd otherwise carry forward unchanged\n   (renamed file paths, dead install URLs, naming drift).\n4. **Sweeping unrelated changes into the commit.** Stage explicitly,\n   don't `git add -A`.\n5. **Breaking existing anchors.** If other docs or external sites link\n   to `#section-name` in the README, preserve the heading or leave a\n   redirect-style link.\n\n## Why phases run without pausing\n\nThe user typically already trusts the workflow when they invoke this\nskill. Pausing for confirmation at the end of each phase wastes a turn.\nThe verification phase (5) is the safety net — it catches almost every\nmistake before the commit lands. If something genuinely needs human\njudgement (e.g. a tool's status is ambiguous), surface it in the final\nsummary so the user can amend, rather than blocking the whole flow.\n","# README Updater\n\nBring a stale README back into sync with reality, end to end, in one pass.\nThe skill runs four phases sequentially without pausing for human input,\nthen commits and pushes the result.\n\n## When this skill triggers\n\n- \"update the README\", \"the README is out of date\", \"refresh README.md\"\n- \"the README doesn't mention \u003Cfeature>\"\n- \"rewrite the README to cover what we've shipped\"\n- Any request to bring docs in line with the current state of the code\n\nIt does **not** trigger for:\n- Small spot-edits to a README (just edit directly)\n- Drafting a brand-new README from scratch in an empty repo (different problem)\n- Generating per-package docs (use a docgen tool)\n\n## The most important lesson\n\n**Never trust your memory or the existing README for CLI claims.**\nOn every prior run, the model has shipped at least one snippet referencing\na flag that no longer exists or a subcommand that was renamed. The\nverification phase below is non-negotiable — it is the one step that\ndistinguishes a useful README update from a confidence-damaging one.\n\n## Phase 1 — Scope\n\nFind when the README was last meaningfully updated and what's changed\nsince. This bounds the work.\n\n```bash\n# Last commits that touched README.md (not just chore renames)\ngit log --oneline -20 README.md\n\n# Pick the most recent substantive update commit — call it $LAST_README_SHA\ngit log --oneline $LAST_README_SHA..HEAD | wc -l   # how many commits since\ngit log --oneline $LAST_README_SHA..HEAD           # the actual list\n```\n\nIf the README has never been written (empty repo or new file), there is no\nprior state to audit — skip Phase 2 and treat Phase 3 as a fresh inventory.\n\n## Phase 2 — Audit (inconsistency check)\n\nBefore drafting anything new, scan the **existing** README for claims that\nno longer match reality. This is faster than rewriting from scratch and\ncatches drift the user may not know about.\n\nRun these checks. Don't pause for user input — log findings inline and\ncarry them into Phase 4.\n\n### 2.1 CLI commands and flags\n\nFor every code block in the README that looks like a CLI invocation\n(`\u003Cbinary> \u003Csubcommand> --flag value`), check that the binary, subcommand,\nand flag still exist.\n\n```bash\n# Get the real command tree\n\u003Cbinary> --help\n\u003Cbinary> \u003Csubcommand> --help\n```\n\nFlag the snippet as **stale** if any of:\n- The binary doesn't exist (renamed, removed)\n- The subcommand is renamed (e.g. `cochange` → `co-change`)\n- The flag is renamed, removed, or moved to a different subcommand\n- The default value drifted\n\n### 2.2 File paths and directory layouts\n\nFor every `path\u002Fto\u002Ffile` or `dir\u002F` mentioned, verify it exists:\n\n```bash\nls path\u002Fto\u002Ffile 2>\u002Fdev\u002Fnull || echo \"STALE: path\u002Fto\u002Ffile\"\n```\n\n### 2.3 Tool \u002F package inventory\n\nIf the README lists tools, packages, or sub-projects in a table, compare\nthat list to what the repo actually contains. New tools added since the\nlast README touch are the most common source of staleness.\n\n```bash\n# For monorepos with discoverable sub-projects\nls -d \u003Cprefix>-*\u002F  # e.g. auto-*\u002F, packages\u002F*, apps\u002F*\n```\n\nFlag missing entries (tool exists in repo, not in README) and dead entries\n(README lists tool, repo doesn't have it).\n\n### 2.4 Naming consistency\n\nSkim the README for inconsistent naming of the same thing:\n- `auto-eval` vs `autoeval` vs `auto_eval`\n- `myproject-cli` vs `myproject` vs `mp`\n\nPick one canonical name (usually the binary name) and standardise.\n\n### 2.5 Status claims\n\nIf the README labels things as \"Active\", \"Beta\", \"Coming Soon\", \"Deprecated\":\n- Has a \"Coming Soon\" tool now shipped? → Promote it.\n- Has an \"Active\" tool been removed? → Demote or delete.\n- Does the \"Beta\" claim still hold given recent stability work?\n\n### 2.6 External references\n\n- Install URLs (`curl … | bash`) — fetch the URL or confirm the repo path.\n- Badge URLs — fetch and confirm they render.\n- Cross-links to other docs — confirm targets exist.\n- Version numbers (`Go 1.22+`, `Node 18+`) — confirm against `go.mod` \u002F\n  `package.json` \u002F CI config.\n\nKeep findings in a short scratch list (`audit_findings`) — you'll address\nthem in Phase 4.\n\n## Phase 3 — Survey\n\nDispatch parallel research agents to inventory the current state. Run them\nconcurrently — this is the longest phase and the agents are independent.\n\n### Agent A — Project \u002F tool inventory\n\nFor monorepos, the inventory is per-sub-project. For single-project repos,\nsubstitute \"the project\" for \"each sub-project\".\n\nPrompt template:\n\n> For each directory below, read its README\u002FCLAUDE.md, list the binary's\n> available commands (look at main.go \u002F cmd\u002F \u002F package.json scripts \u002F\n> cobra command tree), and identify whether it is fully implemented or\n> scaffolded.\n>\n> For each, report under 100 words:\n> - One-line description\n> - Status: Active \u002F Working \u002F Scaffolded\n> - Binary name\n> - Top-level commands\n> - Notable recent features\n>\n> Total report under 1500 words.\n\n### Agent B — Feature mining from git history\n\nPrompt template:\n\n> The README was last updated at commit $LAST_README_SHA. Run\n> `git log --oneline $LAST_README_SHA..HEAD` and for each `feat:` commit\n> summarise the user-visible feature added. Group by tool\u002Farea. For each\n> feature give: tool, feature name, one-sentence description, commit hash.\n> Focus on user-facing features, not refactors or CI changes.\n> Under 1000 words.\n\nSending both agents in **one message** (parallel tool calls) is important —\nthey run concurrently and you get both reports back before Phase 4 starts.\n\n## Phase 4 — Draft\n\nRewrite the README using the audit findings (Phase 2) and survey reports\n(Phase 3). Some structural defaults that have proven to work:\n\n### Diagrams\n\nReplace ASCII diagrams with **Mermaid**. GitHub renders Mermaid natively in\nthe web UI, in PRs, and in issues. Mermaid is text-based, diff-friendly,\nand requires no build step. Use `flowchart LR` for pipelines and\n`flowchart TD` for data architecture.\n\nOther options considered (in case the user asks):\n- Checked-in SVG \u002F PNG → high quality but binary, hard to diff, needs a\n  build step or an external editor.\n- D2 → newer than Mermaid, less broadly rendered.\n- ASCII → diff-friendly but ugly. Only use if the user specifically asks.\n\nStyle classes give a polished look:\n\n```mermaid\nflowchart LR\n    A[Foo] --> B[Bar]\n    classDef active fill:#1f6feb,stroke:#1f6feb,color:#fff;\n    class A,B active;\n```\n\n### Status badges\n\nFor status-of-tool tables, use [shields.io](https:\u002F\u002Fshields.io) badges:\n\n```\n![Active](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fstatus-active-brightgreen)\n![Coming Soon](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fstatus-coming%20soon-yellow)\n![Beta](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fstatus-beta-blue)\n![Deprecated](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fstatus-deprecated-red)\n```\n\nBadges read at a glance and survive markdown rendering everywhere.\n\n### Tool tables\n\nOrder rows by **role in the pipeline \u002F system**, not alphabetically.\nFoundation \u002F input tools first, derived tools in the middle, infra and\norchestration last, \"coming soon\" at the bottom. Add a one-line lede above\nthe table explaining the ordering, so readers know the order is\nintentional.\n\n### Quick Start\n\nIf the project has a non-trivial workflow, write a numbered \"Quick Start:\nThe Full Loop\" section. Each step should be runnable as-is, paired with\none or two lines of explanation. The goal: someone copies the entire\nblock, runs it, sees the system end-to-end.\n\n### Feature Highlights\n\nA bulleted section grouped by domain (e.g. \"Ingest & analytics\",\n\"Search & discovery\", \"Code context\", \"Documentation\"). Pulls from the\ngit-history mining agent's report. Each bullet is one sentence, name in\nbold.\n\n### Writing rules\n\nThese rules apply to every change you make in the README. They keep the\nprose feeling consistent and prevent the document from drifting into a\nchangelog.\n\n- **Present tense, current state only.** Describe the system as it is —\n  as if it had always been this way. Never say \"we added X\", \"X is now\n  Y\", \"new in v2\", \"now supports Z\", or anything that implies a\n  before\u002Fafter. The git log carries the change history; the README\n  carries the current state. This is the single most common drift\n  pattern and the easiest to catch yourself doing.\n- **Match the existing tone and style.** If the README uses terse bullet\n  points, keep that style. If it uses full paragraphs, match that. Don't\n  impose a new voice mid-document.\n- **Preserve existing structure where it works.** Add new sections or\n  entries in the logical place within the existing document. Don't\n  reorganise unless the current structure genuinely can't accommodate\n  the new content. Other docs and external sites may link to existing\n  heading anchors.\n- **Be specific.** Use actual command names, flag names, file paths, and\n  concrete examples — not vague descriptions (\"supports several\n  options\"). Specificity is what makes a README useful as a reference,\n  not just an introduction.\n- **Don't pad.** If a feature is simple, a one-liner is fine. Don't\n  inflate descriptions to seem thorough. Short and accurate beats long\n  and hedging.\n\n### What to keep\n\nSections worth preserving by default: Install, Quick Start, Data\nArchitecture, Configuration, Development, License. Don't rewrite for\nthe sake of it.\n\n## Phase 5 — Verify (non-negotiable)\n\nFor **every CLI snippet** in the new draft, run the actual command's\n`--help` output and confirm the binary, subcommand, and every flag is\nspelt correctly and accepts the value type shown.\n\n```bash\n# For each snippet in the README, verify:\n\u003Cbinary> --help\n\u003Cbinary> \u003Csubcommand> --help\n\n# If the snippet uses --flag value, confirm --flag exists and accepts that type.\n```\n\nA short, automatable pattern: grep the README for lines starting with\n`\u003Cbinary> ` inside code blocks, then for each one diff against\n`\u003Cbinary> \u003Csubcommand> --help`. Doing this catches roughly five wrong\nflags per rewrite on real codebases.\n\nIf a verification fails:\n- The intended feature exists but the flag is named differently → fix the\n  snippet.\n- The intended feature doesn't exist at all → cut the snippet, pick a\n  feature that does work, and document that instead. Don't aspirational-document.\n\nAlso verify any URLs, file paths, version numbers, and `make` targets\nquoted in the README still resolve.\n\n## Phase 6 — Commit and push\n\nStage only the README (and any directly related doc updates the audit\nturned up — e.g. a renamed file the README pointed at). Don't sweep in\nunrelated working-tree changes.\n\n```bash\ngit add README.md\n```\n\nWrite a commit message that names what was done and why. The format used\non the auto-stack repo:\n\n```\ndocs(readme): \u003Cone-line subject under 70 chars>\n\n\u003Ctwo or three paragraphs explaining what changed and why, calling out the\nbiggest categories of update (new tools, restructured sections, verified\nCLI snippets, replaced ASCII with Mermaid, etc.).>\n\nCo-Authored-By: …\n```\n\nThen push:\n\n```bash\ngit push origin \u003Ccurrent-branch>\n```\n\nIf the repo has a pre-commit hook that runs format \u002F vet \u002F lint, let it\nrun. If it fails, fix the underlying issue rather than passing\n`--no-verify`.\n\n## Communicating with the user\n\nBrief updates per phase, not a running monologue:\n\n- Start of Phase 2: \"Auditing the current README — checking commands,\n  paths, status claims.\"\n- Start of Phase 3: \"Dispatching survey agents in parallel — project\n  inventory and git-history feature mining.\"\n- Start of Phase 4: \"Drafting the new README.\"\n- Start of Phase 5: \"Verifying every CLI snippet against --help.\"\n- End: \"Pushed as \u003Csha>. Summary of what changed: …\"\n\nIf the verification phase catches the model contradicting itself\n(documenting a flag that doesn't exist), say so explicitly in the final\nreport — it builds trust and helps the user spot the same kind of error\nthe next time around.\n\n## Common pitfalls\n\n1. **Memorised flags.** \"I'm sure `--bash-exit-code` exists.\" Don't\n   trust this. Run `--help`.\n2. **Inventing aspirational features.** If a tool is scaffolded, label\n   it \"Coming Soon\" — don't write a Quick Start for it.\n3. **Skipping the audit because the rewrite \"covers it anyway\".**\n   The audit catches things you'd otherwise carry forward unchanged\n   (renamed file paths, dead install URLs, naming drift).\n4. **Sweeping unrelated changes into the commit.** Stage explicitly,\n   don't `git add -A`.\n5. **Breaking existing anchors.** If other docs or external sites link\n   to `#section-name` in the README, preserve the heading or leave a\n   redirect-style link.\n\n## Why phases run without pausing\n\nThe user typically already trusts the workflow when they invoke this\nskill. Pausing for confirmation at the end of each phase wastes a turn.\nThe verification phase (5) is the safety net — it catches almost every\nmistake before the commit lands. If something genuinely needs human\njudgement (e.g. a tool's status is ambiguous), surface it in the final\nsummary so the user can amend, rather than blocking the whole flow.\n",{"name":5,"license":15,"description":7},"main","8075db80b0f662909c8c49bbf04da1acb03c24e1","skills\u002Freadme-updater","https:\u002F\u002Fgithub.com\u002Fmistakenot\u002Fauto-stack","https:\u002F\u002Fgithub.com\u002Fmistakenot","charliedaly.co.uk","2026-10-29 07:32:11",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add mistakenot\u002Fauto-stack --skill readme-updater",{"tool":62,"command":63},"bunx","bunx skills add mistakenot\u002Fauto-stack --skill readme-updater",{"tool":65,"command":66},"pnpm","pnpm dlx skills add mistakenot\u002Fauto-stack --skill readme-updater","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmistakenot\u002Fauto-stack\u002Fblob\u002Fmain\u002Fskills\u002Freadme-updater\u002FSKILL.md",true,[],[71,86,107,132,149,169],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":44},"01M6NK49FNTVKG4KNN4ZZ1XH84","release","Create a new auto-stack release by tagging a commit and pushing the tag. The GitHub Actions release workflow builds binaries and publishes the release.","https:\u002F\u002Fgithub.com\u002Fmistakenot\u002Fauto-stack\u002Fblob\u002Fmain\u002Fskills\u002Frelease\u002FSKILL.md",[],[73,78,79,80,81,82,83,84,85],"github","workflow","commit","create","actions","github actions","stack","auto",{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":44},"01M6NK3M6TNEBZBBTMY0JM6884","recall","Reconstruct and narrate the current development context from contextual commits. Run at session start, when resuming work, or when switching branches. Produces a brief, conversational summary of where things stand.","https:\u002F\u002Fgithub.com\u002Fmistakenot\u002Fauto-stack\u002Fblob\u002Fmain\u002Fskills\u002Frecall\u002FSKILL.md",[],[88,93,94,95,96,40,97,98,99,100,101,102,103,104,105,106],"run","session","context","work","start","brief","switching","development","summary","branches","session start","at","things","resuming",{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":113,"publishedAt":44},"01M6NK2W0073Z14AYD6FBQH3V8","contextual-commit","Write contextual commits that capture intent, decisions, and constraints alongside code changes. Use when committing code, finishing a task, or when the user asks to commit. Extends Conventional Commits with structured action lines in the commit body that preserve WHY code was written, not just WHAT changed.","https:\u002F\u002Fgithub.com\u002Fmistakenot\u002Fauto-stack\u002Fblob\u002Fmain\u002Fskills\u002Fcontextual-commit\u002FSKILL.md",[],[80,114,115,116,117,118,119,120,121,122,123,40,124,125,126,127,128,129,130,131],"contextual commit","preserve","changes","action","with","user","task","code","constraints","why","capture intent","just","capture","decisions","write","use","conventional commits","intent",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":141,"publishedAt":44},"01M6NK2JEGH6QC2EPQSZNCTDWC","deploy-checklist","A pre-deployment checklist for safe releases.","https:\u002F\u002Fgithub.com\u002Fmistakenot\u002Fauto-stack\u002Fblob\u002Fmain\u002Fharness\u002Fscenarios\u002Fskill-remote\u002Ffixtures\u002Fskills\u002Fdeploy-checklist\u002FSKILL.md",[138],{"categoryNo":139,"categoryName":140,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",[142,143,144,145,146,147,148,29],"deploy checklist","checklist","deploy","deployment checklist","safe","deployment","releases",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":163,"publishedAt":44},"01M6NK2EDH7XHR830B51AA750P","code-review","Structured code review with severity labels.","https:\u002F\u002Fgithub.com\u002Fmistakenot\u002Fauto-stack\u002Fblob\u002Fmain\u002Fharness\u002Fscenarios\u002Fskill-remote\u002Ffixtures\u002Fskills\u002Fcode-review\u002FSKILL.md",[155,158],{"categoryNo":156,"categoryName":157,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":159,"categoryName":160,"taxonomyType":161,"taxonomyTypeDesc":162},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[164,165,121,166,167,118,168],"code review","review","severity","structured","labels",{"skillNo":170,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":173,"publishedAt":44},"01M6NJZZ8XRE9TZ2X3VFPK38QE","https:\u002F\u002Fgithub.com\u002Fmistakenot\u002Fauto-stack\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Frelease\u002FSKILL.md",[],[73,79,80,81,82,83,84,85,78]]