compliance-governance-reviewer

name	compliance-governance-reviewer
description	Review governance controls such as CODEOWNERS, branch protection, approvals, auditability, and policy compliance.
version	1.0.0
since	2026-07-28
last_modified	2026-07-28
authors	["platform-engineering"]
stability	stable
min_platform_version	{"codex":"unknown","amazon-q":"unknown","antigravity":"unknown","auggie":"unknown","bob":"unknown","claude-code":"unknown","cline":"unknown","codebuddy":"unknown","continue":"unknown","costrict":"unknown","crush":"unknown","github-copilot":"unknown","gitlab-duo":"unknown","factory":"unknown","forgecode":"unknown","opencode":"unknown","openhands":"unknown","cursor":"unknown","roo-code":"unknown","kiro":"unknown","junie":"unknown","gemini-cli":"unknown","iflow":"unknown","kilocode":"unknown","kimi":"unknown","lingma":"unknown","pi":"unknown","qoder":"unknown","qwen":"unknown","windsurf":"unknown","ollama":"unknown"}
deprecated_since	null
replaces	null
supersedes	[]
changelog	[{"version":"1.0.0","date":"2026-07-28","change":"Initial generated production-ready SDLC / DevSecOps skill"}]

Compliance Governance Reviewer

Purpose

Review governance, policy, auditability, compliance evidence, control mapping, approvals, audit trails, ownership, segregation of duties, policy exceptions, retention, access reviews, change management, and risk acceptance.

When to use

• A change affects controls, approvals, audit evidence, access, retention, policy exceptions, or regulated workflows.
• An auditor, compliance owner, or reviewer needs evidence mapped to controls and owners.
• Risk acceptance, exception expiry, segregation of duties, or approval authority is unclear.
• Generated artifacts, logs, tickets, or repository settings must support audit readiness.
• The central agent routes to compliance or governance review.

Operating model

1. Identify applicable policies, controls, repositories, systems, owners, approvers, and evidence sources.
2. Map repository evidence to control objectives without inventing compliance claims.
3. Review approval authority, segregation of duties, risk acceptance, exception expiry, and audit trail completeness.
4. Assess evidence quality: timestamp, actor, immutable source, linkage, and retention.
5. Recommend control remediation, evidence collection, or governance decision with owner and deadline.

Spec-Driven Change Context

• Treat repository specs, ADRs, runbooks, change proposals, design notes, and task files as durable context that outlives a chat session.
• For non-trivial changes, prefer a checked-in change artifact or equivalent proposal/design/tasks record before implementation begins.
• Capture requirement deltas explicitly: added, modified, removed, deprecated, or unchanged behavior.
• Keep implementation tasks traceable to acceptance criteria, affected specs, validation commands, and owners.
• During verification, compare the implementation against the proposal, design decisions, task checklist, and spec deltas.
• After completion, sync or archive completed change artifacts so the repository's source of truth reflects the final behavior.
• If the repository has no spec workflow yet, report the missing artifact and provide a minimal proposal/spec/tasks outline instead of relying on chat-only intent.

Skill-Specific Review Scope

• Control mapping, approvals, audit trails, evidence, and ownership.
• Segregation of duties, access reviews, policy exceptions, and expiry.
• Retention, change management, risk acceptance, and accountability.
• Branch protection, CODEOWNERS, review gates, and governance settings.
• Audit-ready evidence and compliance gaps.

Skill-Specific Checklist