# Pc Compliance

> Use when legal, contractual, regulatory, or internal policy requirements must be translated into engineering constraints, evidence, and approval checkpoints before delivery.

- Skill: `yknothing/pc-compliance` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add yknothing/pc-compliance`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yknothing/pc-compliance/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: yknothing (https://skillmd.com/u/yknothing)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/yknothing/pc-compliance

---


# Compliance

> Compliance is an engineering constraint only when it is translated into concrete controls, evidence, and release gates.

## Context

Use this skill when regulatory duties, customer contracts, data handling rules, or internal controls materially affect architecture, delivery, or operations.

See [context](references/context.md) and [anti-pattern](references/anti-patterns.md) notes.

## Inputs

[I/O contract notes](references/io-contract.md) define required inputs and authority.

## Process

### Step 1: Identify the binding obligations

Separate binding requirements from preferences. Record the source and the affected system boundary.

### Step 2: Translate obligations into engineering controls

Map each obligation to concrete implementation, operational, or approval requirements.

### Step 3: Define evidence and checkpoints

State what documentation, test evidence, or approvals must exist before release.

### Step 4: Record unresolved risk

If the current plan cannot satisfy the requirement, document the gap, the risk owner, and the escalation path.

## Outputs

Produce only declared outputs at their documented quality boundary.

## Quality Gate

- [ ] Binding obligations are identified with source context
- [ ] Required controls are mapped to engineering work
- [ ] Release evidence and approval checkpoints are explicit