agentsclimarketplace
Sign in

Refresh project docs

Skill quanpersie2001/pulse/skills/refresh-project-docs

Use when repository documentation is stale and the user asks to refresh docs to match the current codebase and workflows.From its SKILL.md

Install
npx -y skills add quanpersie2001/pulse --skill refresh-project-docs

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.3 KB, 636 tokens by cl100k_base, as published. Nobody here has run it

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

What ships with it: 2 files

3.0 KB alongside SKILL.md

agents/

references/

Gives 0 of the 12 instructions most docs writing skills give in 636 tokens

Counted across 1,637 of the 3,044 authors here whose files we hold, read 2026-08-07

  • Announce the skill at startin 54 of 1637, across 26 files
  • Convert legacy doc files before editingin 45 of 1637, across 7 files
  • Predict questions readers might askin 42 of 1637, across 4 files
  • Generate clarifying questions for initial contextin 42 of 1637, across 3 files
  • Create document scaffold with placeholder textin 42 of 1637, across 3 files
  • Brainstorm content options for each sectionin 42 of 1637, across 3 files
  • Test the document with a fresh context-less instancein 42 of 1637, across 3 files
  • Include exact file paths in every taskin 42 of 1637, across 15 files
  • Ask interview questions one at a timein 42 of 1637, across 27 files
  • Apply surgical edits during refinementin 41 of 1637, across 2 files
  • Offer structured workflow or freeformin 40 of 1637, across 1 file
  • Ask for document meta-contextin 40 of 1637, across 2 files

Said here and by no other author read

  • update documentation from live repo state
  • verify commands and workflows from source
  • identify deltas between code and documentation
  • rewrite docs in evergreen current-state language
  • describe the present state only
  • remove stale wording instead of narrating transitions

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,537. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.