| name | compliance-governance-reviewer |
| description | Review governance controls such as CODEOWNERS, branch protection, approvals, auditability, and policy compliance. |
| version | 1.0.0 |
| since | 2026-08-27 |
| last_modified | 2026-08-27 |
| 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-08-27","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.
Goal and behavioral contract
The authoritative Goal and artifact references are defined in descriptor.yaml. Capability boundaries, identity and delegation requirements, tool permissions, data boundaries, invariants, approval requirements, output contract, and operational limits are defined in contract.yaml. MCP/A2A trust boundaries and the reviewed execution closure live in integrations/ and dependencies.yaml; ASPS and assurance requirements live in assurance.yaml.
Treat those declarations as mandatory execution constraints. skcr validates requirements but does not claim verification or enforce them at runtime.
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
- Identify applicable policies, controls, repositories, systems, owners, approvers, and evidence sources.
- Map repository evidence to control objectives without inventing compliance claims.
- Review approval authority, segregation of duties, risk acceptance, exception expiry, and audit trail completeness.
- Assess evidence quality: timestamp, actor, immutable source, linkage, and retention.
- 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.
