A monthly review keeps dependency work from piling up. In 30 minutes a design system team can look at open update pull requests, peer ranges, adoption across apps, duplicate copies and active exceptions. Use a fixed agenda, name an owner for each action, and carry nothing over without a date.
Before the meeting
Prepare four things, ideally from your tools rather than from memory: the list of open update pull requests, the adoption table of library versions per app, the scan summary for the library and for the top apps, and the list of active overrides or exceptions.
The agenda
| Minutes | Topic | Question to answer |
|---|---|---|
| 5 | Open update PRs | Which are stale, blocked, or waiting on review? |
| 5 | Security findings | Any open item past its fix window? Any reachable one? |
| 5 | Peer ranges and host versions | Is a new host release out that we have not tested? |
| 5 | Adoption lag | Which apps are behind, and who is chasing them? |
| 5 | Duplicates and bundled packages | Any new second copy or bundled dependency? |
| 5 | Exceptions and overrides | Anything expiring in the next month? |
Steps for each topic
- Open pull requests. Merge, close or assign. A pull request open for weeks is a signal that the update policy needs a change, not that people are lazy.
- Findings. Check each against your written fix window. Use reachability where available to sort what truly matters. See which apps still use an old design system version for the adoption view.
- Peer ranges. Run the oldest and newest host in CI. If a new host release exists, add it to the matrix. See how wide should a design system's peer dependency range be.
- Adoption. Update the table. For laggards, message the owner with the app, version and a fix link.
- Duplicates. Run the list and explain commands from how do you find duplicate copies of a library in a frontend app.
- Exceptions. Remove expired ones or renew with a reason. See temporary overrides need an expiry.
Outputs
End with a short list: action, owner, date. Post it where app teams can see it. Keep the list short, three to five items, so it gets done.
Signs the review is working
Fewer stale pull requests each month, a shrinking spread of library versions across apps, and no exceptions past their end date. Do not measure by number of updates merged, since that rewards noise.
When to skip or shorten
Skip a topic that had nothing new, and say so in the notes. During a release freeze, keep the review but defer merges, as in pause dependency updates before a release freeze.
Safeguard can produce the scan summary, the per app version view and the list of open policy exceptions in one place, which turns preparation into a few minutes. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Who should attend?
The design system maintainers, one security contact, and a rotating app team representative.
What if there is nothing to discuss?
Shorten the meeting, but still check expiring exceptions and adoption lag.
Last reviewed: 19 October 2026.
