Skip to content
Back to skills

Update Readme

ASecurity

Refreshes README structure favoring concision (an index, not a manual). Use when the README needs a structural update after significant project changes.

  • 342 stars
  • 0 votes
  • 0 copies
  • 3 views
  • Added December 19, 2025
developmenttypescriptrustgogitfrontendbackendperformancedocumentation

Works with

  • cli

Security analysis

A100/100

Pro scans all 3 files and shows the line behind each finding

Scanned September 20, 2026

npx -y skills add athola/claude-night-market --skill update-readme --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Update Readme?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Update Readme
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/athola-update-readme/badge)](https://www.skillsdirectory.com/skills/athola-update-readme)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: update-readme
description: Refreshes README structure favoring concision (an index, not a manual). Use when the README needs a structural update after significant project changes.
alwaysApply: false
category: artifact-generation
tags:
- readme
- documentation
- exemplars
- research
- structure
tools: []
complexity: high
model_hint: deep
estimated_tokens: 1200
modules:
- modules/language-audit.md
- modules/exemplar-research.md
progressive_loading: true
dependencies:
- sanctum:git-workspace-review
- imbue:proof-of-work
- scribe:slop-detector
- scribe:doc-generator
---
# README Update Workflow

## When To Use
Use this skill whenever the README requires a structural refresh.
Run `Skill(sanctum:git-workspace-review)` first to capture repo context and diffs.

## When NOT To Use

- Updating inline docs: use doc-updates
- Consolidating ephemeral reports: use doc-consolidation

## Required TodoWrite Items
1. `update-readme:language-audit`
2. `update-readme:exemplar-research`
3. `update-readme:outline-aligned`
4. `update-readme:edits-applied`
5. `update-readme:slop-scanned` - AI marker detection via scribe
6. `update-readme:verification-reporting`

## Step 1 - Language Audit (`update-readme:language-audit`)
- Confirm `pwd`, `git status -sb`, and the baseline branch for reference.
- Detect dominant languages using repository heuristics (manifest files, file counts).
- Note secondary languages that influence documentation (e.g., a TypeScript frontend and a Rust backend) so the README can surface both.
- Record the method and findings.

See `modules/language-audit.md` for detailed detection patterns and commands.

## Step 2 - Exemplar Research (`update-readme:exemplar-research`)
- For each primary and secondary language, use web search to locate high-quality READMEs (star count, recency, maintainer activity).
- Capture 2-3 exemplar repositories per language and summarize why each is relevant (section order, visuals, quickstart clarity, governance messaging, math exposition, etc.).
- Store citations for every exemplar so the final summary references them explicitly.

See `modules/exemplar-research.md` for search query patterns and evaluation criteria.

## Step 3 - Outline Alignment (`update-readme:outline-aligned`)

**The README is an index, not a manual.** Lead with what the
project is, how to install it, and a scannable table of its
units (plugins, commands, packages); link out for everything
else.

**A README is a `newcomer` document.** Its reader has never seen
this project, so the test for every candidate section is whether
that reader needs it before they can install and run one thing.
Rationale, alternatives considered, and internals are `expert`
material: extract them to `docs/deep-dive/<topic>.md` or the
`book/`, linked from the README in one line naming who the page
is for. Never delete them to shorten the README. Tier table and
cut test: `scribe:slop-detector` module `audience-targeting.md`.

A README that declares a different tier (an internal tool whose
only readers already run it) says so in its lead.

When this repo's root README was simplified in 2026, it
dropped from 435 to 200 lines (65% fewer words) by deleting
inlined depth and linking to `book/` instead. Aim for that
shape, not a section-by-section coverage sweep.

- Compare current README headings (`rg -n '^#' README.md`)
  against the exemplars from Step 2. Lean marketplace and
  CLI-tool READMEs (asdf-vm/asdf-plugins, ohmyzsh/ohmyzsh,
  ryoppippi/ccusage) are index-shaped: prose intro under ~500
  words, a unit table doing the work, depth behind links.
- Keep only the sections that earn a place in an index: a
  one-line value proposition, one install path, a compact
  command or unit table, a short "what's inside" summary, a
  single Documentation link section, and metadata
  (requirements, contributing, license) last. For every other
  candidate section ask: **does this belong in the README, or
  behind a link?**
- Default to linking out. Send deep architecture, FAQ,
  roadmap, changelog, alternate install methods, and per-unit
  detail to their own pages. Per-unit docs live with the unit
  (hub-and-spoke), never duplicated in the root.
- Order signals priority: title and tagline first, then
  install, then the index table, then a short feature summary,
  then Documentation links, with housekeeping (requirements,
  contributing, license) last.
- Map internal documents (docs/, book/, specs/, commands/) to
  the section that links them, so the README anchors depth
  without restating it.

**Soft budget**: a marketplace or collection root README runs
roughly 150-400 lines of prose plus any index table. A section
that grows over time (roadmap, FAQ, changelog) belongs in a
linked page, not the README.

## Step 4 - Apply Edits (`update-readme:edits-applied`)
- Implement the new structure directly in `README.md`
  (or the specified file).
- Follow `Skill(leyline:markdown-formatting)` conventions:
  wrap prose at 80 chars (prefer sentence/clause boundaries),
  blank lines around headings, ATX headings only, blank line
  before lists, reference-style links for long URLs.
- Maintain concise, evidence-based prose; avoid marketing fluff.
- Prefer deletion and linking over inlining. If a section
  duplicates a docs page, cut it and link the page; if it
  grows over time, move it out of the README entirely.
- Add comparison tables, feature lists, or diagrams only if
  they originate from current repository assets (no speculative
  content).
- When referencing algorithms or performance claims, point to
  benchmarks or tests within the repository or documented math
  reviews.

## Step 4.5 - AI Slop Detection (`update-readme:slop-scanned`)

Run `Skill(scribe:slop-detector)` on the updated README to detect AI-generated content markers.

### Scribe Integration

The scribe plugin provides AI slop detection:

```
Skill(scribe:slop-detector) --target README.md
```

This detects:
- **Tier 1 words**: delve, tapestry, comprehensive, leveraging, etc.
- **Phrase patterns**: "In today's fast-paced world", "cannot be overstated"
- **Structural markers**: Excessive em dashes, bullet overuse, sentence uniformity
- **Marketing language**: "enterprise-ready", "cutting-edge", "seamless"

### Remediation

If slop score exceeds 2.0 (moderate), apply `Skill(scribe:doc-generator)` principles:

1. Ground every claim with specifics
2. Remove formulaic openers/closers
3. Use numbers, commands, filenames over adjectives
4. Balance bullets with narrative prose
5. Show authorial perspective (trade-offs, reasoning)

For significant cleanup needs, use:

```
Agent(scribe:doc-editor) --target README.md
```

## Step 5 - Verification & Reporting (`update-readme:verification-reporting`)
- Re-read the updated README for clarity, accessibility (section lengths, bullet balance), and accurate links.
- Run `git diff README.md` (or the edited file) and capture snippets for the final report.
- Summarize detected languages, exemplar sources (with citations), key structural decisions, and follow-up TODOs (e.g., add badges, upload diagrams).

## Exit Criteria

- [ ] All `TodoWrite` items are complete.
- [ ] The README is index-shaped: prose intro within the soft
  budget (roughly 150-400 lines plus any unit table), one
  install path, and a scannable unit/command table.
- [ ] No README section duplicates a `book/` or `docs/` page;
  depth is linked, not inlined (`rg -n '^#' README.md` headings
  each map to a section that earns a place in an index).
- [ ] The README serves a `newcomer`, or declares the tier it
  serves instead in its lead.
- [ ] Content cut for tier fit landed in a linked page, not the
  bin (`docs/deep-dive/` or `book/`).
- [ ] The README references internal docs and external
  exemplars with citations.
- [ ] Research notes and command references are captured so
  future reviewers can reproduce the process.

## Troubleshooting

### Common Issues

**Documentation out of sync**
Run `make docs-sync-check` to verify the capabilities docs still
match the plugin registrations

**Build failures**
Check that all required dependencies are installed

**Links broken**
Verify relative paths in documentation files

Files in this skill

  • SKILL.md3.6 KB
  • modules/exemplar-research.md3.9 KB
  • modules/language-audit.md2.3 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…