--- name: approval-governor description: Decide whether proposed changes require explicit approval before execution, especially for roster changes, role/permission changes, structural reconfiguration, destructive operations, policy exceptions, or other high-impact governance decisions. Use when work involves approving, denying, escalating, or framing guarded actions. Do not use for ordinary low-risk execution that is already clearly authorized. --- # Approval Governor Apply approval discipline without turning every task into bureaucracy. This skill exists to separate work that can proceed autonomously from work that needs explicit authorization, tighter review, or a better decision record. Use it to classify risk, define the approval ask, and prevent silent high-impact changes. ## Scope Use this skill for: - approval gating before roster changes - role, ownership, or permission changes - structural reconfiguration of teams, systems, or routing - destructive or difficult-to-reverse actions - policy exceptions - risk-based escalation decisions - drafting concise approval requests - documenting why a guarded action should proceed, wait, or be denied ## Do not use this skill for Do not use this skill for: - ordinary low-risk tasks already covered by the user's instruction - implementation planning after approval is already granted - legal sign-off pretending to be counsel - security review in depth when a security specialist is needed - generic project management status updates ## Inputs to gather Before deciding, identify: - the exact proposed action - what will change if it proceeds - who or what is affected - reversibility and rollback difficulty - blast radius if the change is wrong - whether the user or policy has already granted authorization - time sensitivity and cost of waiting - safer alternatives or narrower scopes - what evidence supports the recommendation If the action is fuzzy, tighten the scope first. Approval on an ambiguous action is bad governance. ## Output expectations Return outputs such as: - proceed / require approval / deny / escalate recommendation - short approval memo - risk classification - decision rationale - approval request text with exact action scope - safer alternative or phased plan - conditions that must be met before execution Be concrete about what is and is not authorized. ## Working method ### 1. Define the action exactly State the proposed change in one sentence. Include: - what will be changed - in which environment or scope - by whom or for whom - whether it is reversible Do not evaluate a vague cloud of intent. Evaluate a specific action. ### 2. Check existing authority first Determine whether approval already exists through: - explicit user instruction - standing policy - prior documented approval that clearly covers this exact action - role-based authority already granted Do not invent extra gates where authority is already clear. Do not assume prior approval covers a materially different action. ### 3. Classify the risk Review the action across these lenses: - **impact**: how much changes if this goes wrong? - **reversibility**: can it be undone cleanly? - **scope**: how many users, systems, teams, or records are affected? - **sensitivity**: does it touch permissions, identity, money, compliance, privacy, or production structure? - **precedent**: does approving it establish a broader norm or bypass? High-impact structural or permission changes should rarely be treated as routine. ### 4. Decide the governance path Use one of these outcomes: - **Proceed** — clearly authorized, low risk, and within scope - **Require approval** — action is legitimate but needs explicit sign-off first - **Escalate** — action crosses functional, security, compliance, or ownership boundaries - **Deny** — action is unsafe, under-specified, out of policy, or unjustified If approval is needed, define the smallest safe approvable unit. ### 5. Frame the approval ask cleanly A good approval request includes: - exact action - reason for the change - expected benefits - risks and blast radius - rollback or mitigation plan - deadline or urgency if real - decision needed: approve / deny / choose option Do not make approvers decipher a wall of context to understand what they are authorizing. ### 6. Prefer scoped alternatives over hard blocks If the proposed action is too broad, propose a narrower path such as: - pilot instead of full rollout - temporary permission instead of permanent role change - staging first, production later - one team or one resource instead of global change - read-only access instead of write/delete authority Good governance preserves velocity by narrowing risk. ### 7. Record the boundary When finalizing, make the boundary unmistakable: - what is approved - what is not approved - who must sign off - what conditions apply - what evidence or follow-up is still required The output should prevent accidental overreach. ## Heuristics Require or escalate approval more readily when the action involves: - roster additions/removals - role or permission elevation - ownership transfer - structural or routing changes - destructive deletion or irreversible mutation - spending, compliance, privacy, or public-facing risk - broad automation changes that could cascade Proceed more readily when the action is: - already explicitly authorized - reversible with low cost - tightly scoped - low blast radius - operationally routine - supported by clear rollback and observability ## Adjacent skill boundaries - **delegation-governor**: decides delegation shape and routing discipline; this skill governs whether a risky action should be authorized - **compliance-officer / privacy-specialist / security-auditor**: provide deeper specialist review when risk type is domain-specific - **operations-manager / project-operator**: execute approved plans; this skill frames the approval boundary first ## Quality bar A strong result should: - classify the action clearly - avoid both reckless autonomy and pointless bureaucracy - define the exact approval boundary - surface risk, reversibility, and blast radius succinctly - recommend the narrowest safe path forward - leave no ambiguity about whether execution may proceed ## References to use Use `prompt.md` for decision posture and wording. Use `examples/README.md` for output shapes. Use `guides/qa-checklist.md` before finalizing. Use `meta/skill.json` for boundaries and metadata.