Use this when policy reviews come due on their cadence, when an audit is approaching and the approval records are stale, or when a big change (new product, acquisition, reorganisation, new law) makes the whole set suspect. You get, in a new folder ./policy-review-cycle-refresh/: a table of every policy with its owner, approver and review status (review-register.md), one short note per policy showing each proposed edit as old text and new text with the reason (in changes/), and a plan for telling staff what changed (communication-plan.md). This skill drafts for a human to review and sign; this skill never marks a control effective. Each policy's approver decides; the agent proposes.

Inputs to gather

Read the policy set with each document's version, owner, approver and last approval record. Then collect what happened since each last approval: the incident log, internal and external audit findings, the exception or waiver register, the risk register changes, new or retired systems and vendors, organisation changes, and customer contract changes. Ask the reader, in one message: who approves which policies, whether the company has written document control rules (versioning, who may approve editorial changes), and whether any law or framework scope changed.

Step 1: build the review register

In the review table (review-register.md), write one row per policy: id, title, current version, owner role, approver role, last approval, review due, the evidence window considered (last approval to this review), the version staff last acknowledged, and status (due, overdue, not due, proposed for withdrawal). Flag documents with no approval record at all; for an auditor those are drafts, whatever their file name says. Flag owners who have left or changed role; the first fix is a new owner, not new text. Do the same for approvers: where the approver role is vacant or no longer senior enough, propose an interim approver to be named and minuted, or the cycle stalls. Flag policies staff acknowledged at an older version than the one now in force. Propose withdrawal, with the last version archived and the approver's sign-off, for a policy whose subject no longer exists, instead of carrying it as a permanent "no change" row.

Step 2: collect the triggers per policy

For each policy, list what since its last approval touches it, with a source:

Incidents and near misses where the policy was silent, wrong or ignored.
Audit findings that cite it or the practice it governs.
Exceptions granted against it. Three or more similar exceptions mean the policy is wrong, not the people asking.
New systems, vendors, locations or services the policy does not cover, and retired ones it still names.
Changes in law, contracts or framework scope. Run a framework lookup when a framework's expectation for the policy may have changed, rather than assuming.