Regulatory-to-product requirements translator

Purpose

Turn dense regulatory language into a build-ready requirements package — obligations parsed, requirements written in engineering-usable form, acceptance criteria testable, and every requirement traced back to the exact clause that mandates it — so product and engineering can ship compliant features and defend every decision in an audit.

When to Use

Invoke this skill when the user asks to:

• Translate a new regulation, statute, or rule (e.g., GDPR article, HIPAA provision, PCI-DSS requirement, KYC/AML guidance) into product requirements
• Convert a compliance team's brief or legal memo into engineering-ready tickets
• Turn an audit finding or regulator remediation notice into a scoped requirements set
• Build acceptance criteria and test cases that prove a feature satisfies a regulatory obligation
• Create a traceability matrix mapping features back to regulatory sources for an upcoming audit
• Scope a compliance-driven change and separate "must-build" obligations from "should-consider" guidance

Inputs Required

Before starting, collect:

• Regulatory source: The regulation name, jurisdiction, and the specific text, article numbers, or clauses (pasted text preferred; a citation is acceptable)
• Product area affected: The feature, flow, or system the regulation touches (e.g., onboarding, payments, data retention, patient records)
• Existing product context: What the product currently does in this area, if anything, and the tech stack constraints
• Effective date / deadline: When compliance is required, if known
• Compliance interpretation: Any position already taken by legal/compliance on ambiguous clauses
• Scope boundary: Which user types, regions, or data categories are in or out of scope

If a compliance interpretation is not provided for an ambiguous clause, flag it explicitly as an open interpretation question rather than guessing.

Instructions

Step 1: Parse and Classify Obligations

Break the source text into discrete, atomic obligations. For each one, extract:

• Source clause: The exact article/section number and a short verbatim quote
• Obligation type: Mandatory ("must/shall") / Conditional ("if X then Y") / Prohibitive ("must not") / Discretionary ("should/may")
• Trigger: The event or condition that activates the obligation (e.g., "user requests data deletion," "transaction exceeds threshold")
• Actor: Who or what must perform (the system, the user, an admin, a third party)
• Deadline / timing: Any regulatory time limit (e.g., "within 30 days," "before account opening")

Number each obligation (O1, O2, O3…) — these IDs anchor the traceability matrix.

Flag every clause containing ambiguous language ("reasonable," "without undue delay," "appropriate measures") as an interpretation dependency requiring legal sign-off.

Step 2: Derive Functional Requirements

For each obligation, write one or more functional requirements the product must satisfy. Each requirement:

• Uses the format: "The system shall [capability] when [trigger] so that [obligation satisfied]"
• Is atomic (one testable behavior per requirement)
• Carries a requirement ID (FR-1, FR-2…) and references its parent obligation ID
• States the user-visible behavior AND the system-side behavior separately when they differ

Step 3: Derive Non-Functional & Data Requirements

Capture the requirements regulations frequently mandate but engineers miss:

• Data handling: Retention periods, deletion, encryption at rest/in transit, residency/localization
• Access & audit: Who can view/act, role restrictions, immutable logging of regulated actions
• Timing & SLAs: Response deadlines the regulation imposes (deletion within N days, breach notification windows)
• Consent & disclosure: Required notices, consent capture, and record of consent
• Recordkeeping: What must be stored, for how long, and in what retrievable form

Give each a non-functional requirement ID (NFR-1…) tied to its obligation.

Step 4: Write Acceptance Criteria (Gherkin Format)

For every functional requirement, write testable acceptance criteria in Given/When/Then form:

Scenario: [name]
  Given [precondition / state]
  When [trigger action]
  Then [expected system behavior]
  And [audit/log/timing assertion]

Include at least one compliance-critical negative scenario per obligation (e.g., what must NOT happen — the system must never retain data past the deletion deadline). Each scenario references its FR ID.

Step 5: Define the Evidence & Audit-Trail Plan

For each obligation, specify how compliance will be proven to an auditor:

• Artifact produced: log entry, timestamped record, consent receipt, config setting, report
• Where it's stored and how it's retrieved on demand
• Retention of the evidence itself This is the difference between "we built it" and "we can prove it" — auditors ask for the latter.

Step 6: Build the Traceability Matrix

Produce a table mapping the full chain so nothing is orphaned:

Every obligation must appear. Every requirement must trace to an obligation. Flag any requirement with no clear source (scope creep) and any obligation with no requirement (compliance gap).

Step 7: Surface Risks & Open Questions

List the interpretation dependencies from Step 1 as explicit open questions for legal/compliance, each with: the ambiguous clause, why it's ambiguous, and the two or more reasonable readings and their differing product implications. Note any obligation whose deadline is at risk given the effective date.

Output Format

• Structure: Seven sections in sequence, with the traceability matrix as a table and acceptance criteria as fenced Gherkin blocks
• Length: 1,000–1,500 words depending on obligation count
• Format: Structured document — numbered obligations, ID-tagged requirement lists, Gherkin code blocks, one markdown table
• Sections: Parsed Obligations → Functional Requirements → Non-Functional & Data Requirements → Acceptance Criteria → Evidence & Audit-Trail Plan → Traceability Matrix → Risks & Open Questions
• Tone: Precise and audit-defensible — the voice of a product manager who has sat across from a regulator; no hand-waving on ambiguity, every claim traceable

Quality Checklist

Before delivering output, verify:

• [ ] Every obligation carries a verbatim source quote and a clause reference — not a paraphrase
• [ ] Every functional and non-functional requirement references a parent obligation ID (no orphaned requirements)
• [ ] Every obligation maps to at least one requirement in the traceability matrix (no compliance gaps)
• [ ] Each obligation has at least one negative/compliance-critical acceptance scenario
• [ ] Ambiguous clauses are flagged as interpretation dependencies rather than silently resolved
• [ ] Every regulatory deadline appears as a timing requirement or SLA, not just prose
• [ ] The evidence plan names a concrete, retrievable artifact for each obligation

Notes

• The most common failure mode is translating what a regulation says without capturing how compliance will be proven — the evidence plan is not optional in a regulated build.
• Discretionary "should/may" clauses are not requirements by default; list them separately as recommendations so they don't inflate scope, but flag any that legal has elevated to mandatory internally.
• When a clause is genuinely ambiguous, do not pick a reading to look decisive — the audit-defensible move is to present the interpretations and route the decision to legal.
• Recommended workflow: deliver this package, resolve interpretation dependencies with compliance, then hand the FR/NFR IDs and Gherkin criteria directly to engineering as ticket bodies.

How to use this skill

This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.

Installing in Claude Code:

• ~/.claude/skills/<folder-name>/SKILL.md — auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)
• <your-project>/.claude/skills/<folder-name>/SKILL.md — auto-loads only when working in that project (recommended for project-specific skills)

Restart Claude Code or open a new session to register.

Using in Claude.ai, ChatGPT, Gemini, or other AI tools:

1. Drag this file into a new chat, or copy and paste its contents
2. Send your task or request as your next message — the AI will apply the skill where it fits

For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills