# Refresh Project Docs

> Use when repository documentation is stale and the user asks to refresh docs to match the current codebase and workflows.

- Skill: `quanpersie2001/refresh-project-docs` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add quanpersie2001/refresh-project-docs`
- Raw SKILL.md: https://api.skillmd.com/api/skills/quanpersie2001/refresh-project-docs/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: quanpersie2001 (https://skillmd.com/u/quanpersie2001)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/quanpersie2001/refresh-project-docs

---


# Refresh Project Docs

Update documentation from the live repo state, not from outdated docs or feature-memory summaries.

If the user asks to improve or templatize a docs-refresh prompt, route to `pulse:prompt-leverage` first, then return here for docs execution.

## Mode

- `Docs execution`: inspect the repo and update the relevant docs directly.

## Workflow

### 1. Inventory the documentation surface

Find the docs that may need to move together:

- `README.md`
- contributor or setup docs
- `docs/` pages
- examples, templates, or onboarding guides
- CLI or API docs generated from source-adjacent files

Do not assume the README is the only source that matters.

### 2. Rebuild the current product and workflow state

Treat the repository as the source of truth.

Check the most authoritative artifacts available, such as:

- command help text, scripts, task runners, and package manifests
- config files, environment examples, and migration files
- implementation code for user-facing features
- tests that document supported behavior
- existing docs only after comparing them to the code

When commands, flags, options, or workflows can be verified from source, verify them instead of inferring.

### 3. Identify documentation deltas

Capture what the docs need to describe in their current form:

- current commands, subcommands, flags, and options
- current setup, install, deploy, and development flows
- current features, integrations, and limitations
- renamed, removed, or superseded behavior that should disappear from the docs
- duplicated guidance that now needs to be synchronized across files

### 4. Rewrite in evergreen current-state language

Write as if the documented behavior has always been part of the project.

Use these rules without exception:

- describe the present state, not the history of how it changed
- remove stale wording instead of narrating the transition
- preserve the project's voice and structure unless a clearer structure is needed
- update every relevant doc file that carries the affected information

Avoid release-note phrasing such as:

- `we added`
- `now supports`
- `recently`
- `has been updated`
- `X is now Y`

### 5. Verify before finishing

Check that:

- commands and examples match the real interface
- options and configuration names match the current code
- duplicated docs agree with each other
- stale statements, placeholders, and contradictions are removed
- links still resolve if you touched public docs

## Red Flags

Stop and correct the approach if any of these appear:

- trusting existing docs without checking source
- updating only `README.md` when the same information lives elsewhere
- documenting commands or flags that were not verified
- keeping historical phrasing like a mini changelog
- leaving contradictory old guidance in secondary docs

## Done Criteria

This skill is complete when the edited docs:

- describe only the current state of the project
- include the relevant commands, options, features, and workflows
- remove stale or transitional wording
- are internally consistent across the touched documentation set