Terms in this guide: Evaluation · Prompt · Skill
A maintenance collection for evaluating dependency changes, keeping documentation aligned, and planning regression evidence.
A small maintenance loop
Maintenance work should begin with the current state and a reason to change it. Review release information, affected code, project constraints, and recovery path. Make one coherent update, run impact-based checks, and update the documentation that would otherwise become false.
The collection contains dependency review, documentation synchronization, and regression planning skills. It is useful for periodic upkeep and for preparing scheduled maintenance tasks.
Dependency review
This skill compares the installed and proposed versions, reads primary release and security information, identifies runtime consumers, checks compatibility constraints, and recommends update, defer, replace, or investigate. It separates known breaking changes from speculation.
Documentation synchronization
This skill finds documentation affected by a real change, verifies commands and links, and updates only the claims the implementation changed. It keeps examples aligned with current paths and records source dates for volatile product behavior.
Regression planning
This skill maps a change to user-visible behavior, contracts, callers, shared templates, and meaningful edge cases. It proposes the smallest set of checks that can detect likely regressions and distinguishes automated, browser, and manual evidence.
A scheduling pattern
A monthly private maintenance review can identify stale dependencies, docs, and broken checks. Let the scheduled run prepare a report or isolated patch. Keep publication, deployment, and dependency installation behind the normal review process.
Evaluate the pack
Use a small dependency with a documented version change, one code path that consumes it, and one related guide. Check whether the skills connect the source, implementation, test, and documentation without expanding into unrelated modernization.
Turn maintenance into small reviewable runs
Start by separating observation from mutation. Inventory dependency changes, documentation drift, or missing regression coverage before applying an update. Group only changes that share a compatibility boundary, then keep their lockfile, documentation, and tests in the same reviewable unit.
A scheduled run should report only meaningful change: a newly available update with relevant release notes, a command that no longer matches the project, or a regression gap introduced by current work. Repeating an unchanged list creates noise and teaches readers to ignore the automation.
Keep recovery close to the change
For every maintenance change, record the starting versions, changed files, required migration, focused checks, and rollback path. Database migrations, generated lockfiles, and runtime requirements need special care because reverting one file may not restore the old state.
Review deferred work explicitly. A major version can wait because the project lacks a compatible runtime or test environment; that is more useful than silently omitting it. Revisit the reason on the next maintenance cycle rather than carrying an unexplained exception forever. Keep the reason visible to future maintainers.
Progress stays in this browser. No account needed.
Updates and upgrade guidance
- Learning context added
Added prerequisites, a suggested practice estimate, expected output, and connected definitions. The article procedure was not independently re-evaluated in this change.
What to do: Use the opening checklist to prepare. No software update is required for this editorial change.
This log starts with the first recorded review; it is not a reconstruction of earlier revisions.