/scheduledocshigh riskintermediatesafety D · 45 · open-endedForward Futurepre-dates current gate · under review

Keep the changelog current nightly

Review yesterday's changes each night and keep user-facing release history complete and accurate.

prompt
→ Claude
Each night, review changes from the previous day and update the changelog with anything users should know.
claude-code · codex

Use this when

Use this when a project changes frequently enough that user-facing release notes can drift from merged pull requests, commits, deployments, and product changes.

How it runs

  1. Collect the previous day's merged pull requests, commits, deployments, and other in-scope changes.
  2. Identify which changes affect users and compare them with the current changelog.
  3. Add concise dated entries with useful references while preserving existing content and avoiding duplicates.
  4. Run the relevant checks and record either the validated update or the fact that no user-facing entry was needed.

Done when

Every user-relevant change from the previous day is accounted for. The changelog is updated and validated, or the no-change result is recorded.

Why it works

A daily reconciliation makes omissions visible while the context is still fresh. Limiting entries to what users should know keeps the changelog useful instead of turning it into a raw commit feed.

Implementation note

Use the underlying change and product behavior as the source of truth. Commit titles alone can overstate, understate, or misclassify what users experienced.

Source: Forward Future

More docs loops

Changelog generation from commits

/goalloopreponew

Turn the commit history since the last release tag into a human-readable, categorized CHANGELOG entry ready for the next version.

prompt
→ Claude
/goal CHANGELOG.md has a complete entry for the next release — read every commit since the last version tag, group changes into Added, Changed, Fixed, and Removed, write user-facing descriptions (not commit messages), link PR numbers, and flag anything that looks like a breaking change; stop after 5 turns
docslow risk

Close the gaps before you build

Fill documentation gaps until requirements, technical design, acceptance criteria, and test strategy describe one buildable system.

prompt
→ Claude
Prepare [project] for implementation. Ensure its documents cover requirements, technical design, tasks with acceptance criteria, and test strategy. Each round, fix the largest gap or contradiction that could make two competent engineers build different systems. Keep details traceable, record assumptions, and ask before product forks. Recheck consistency, then have two independent reviewers describe the components, data model, dependencies, and definition of done. Stop when they materially agree and every artifact is testable, or a decision needs the user.
docslow risk

Fix doc drift, ship a PR

/scheduleForward Futurenew

Compare every doc against the current code, fix what's stale, verify commands and links, and open a reviewable PR.

prompt
→ Claude
Whenever a documentation pass is needed, review the codebase in full and make sure all documentation reflects the current implementation. Update stale documentation, verify the changes, then open a pull request.
docslow risk