Compliance Checklist

Compliance Checklist

Purpose

Surface potentially applicable application-compliance obligations for a project's declared jurisdictions, citing only primary sources, behind a mandatory disclaimer that this output is not legal advice.

The Skill's contribution is structure, not legal substance. It ensures that:

1. Recurring failure modes (chat features missed under 電気通信事業法, payment flows missed under 特定商取引法 §11, PII surfaces missed under 改正個人情報保護法 / GDPR Art. 3 / CCPA) are brought to the surface during release prep, not silently shipped.
2. Every applicability claim points the human reviewer at a primary source they can read themselves.
3. The output never asserts non-applicability — only "applies", "may apply, verify", or "out of scope for declared jurisdictions".
4. The output never marks items as "complied with" or "no further action needed". Compliance status is something only the human reviewer (and ultimately a qualified attorney) can confirm.

When to invoke

This Skill ships default-off. It is invoked only when both:

• .claude/compliance.yml exists and has compliance.enabled: true.
• The CLAUDE.md or sibling config declares target_jurisdictions: with at least one of JP, EU, US-CA, platform.

If compliance.enabled is true but target_jurisdictions is missing or empty, the Skill refuses to run and emits a single-line error asking the operator to declare jurisdictions. It does not guess.

Typical invocation triggers (called by other agents):

• product-manager — when writing acceptance criteria for any capability listed in triggers.md.
• security-reviewer — when reviewing PII-handling, authentication, or external-data-export surfaces.
• technical-writer — when authoring or updating Terms of Service, Privacy Policy, or refund-policy text.

Do not invoke for:

• Internal CLI tools that never reach end users.
• Test fixtures or seed data work (these paths are explicitly refused — see Invariant 3).
• Bug fixes that do not change the capability surface.

Invariant Core

The six rules below are inlined here because they are load-bearing for the Skill's safety profile. Deviation from any of them is a defect, not a tuning choice.

For full rationale and original-source citations, see ADR-011.

1. No negative-applicability claims. The Skill must never assert "this law does not apply" or "you are exempt". Permitted forms:

   • applies — clear positive applicability.
   • may apply, verify — likely applicable, requires human confirmation.
   • out of scope for declared jurisdictions — neutrally states the law was not evaluated because it is not in the project's target_jurisdictions. This is a scope statement, not an applicability statement.

2. Primary-source-only citation, with a Tier 1.5 allowance for issuing-regulator official interpretive guidance. Every applicability claim must cite a Tier 1 primary source. Tier 1.5 guidance is admissible only paired with a Tier 1 citation on the same item. Secondary sources are disqualifying. The full tier structure is fixed by ADR-013 and propagates to the rest of the verification-layer.

   • Tier 1 — primary statute and first-party platform spec. e-Gov 法令検索 for Japanese statutes, EUR-Lex for EU regulations and directives, California Legislative Information for CCPA / CPRA, the official Apple App Store Review Guidelines and Google Play Policy Center for platform rules.

   • Tier 1.5 — issuing-regulator official interpretive guidance. Closed allowlist, fixed at the ADR layer (extending it requires a new ADR, not a Skill body edit):

     • EDPB Guidelines, Recommendations, Opinions adopted under GDPR Art. 70(1)(e).
     • 個人情報保護委員会 (PPC) ガイドライン, Q&A, 通達 under 個人情報保護法 §147–§149 delegation.
     • California Privacy Protection Agency (CPPA) Regulations under CCPA §1798.185.
     • Apple Privacy Manifest specification and Required Reasons API documentation under Apple's first-party platform authority.
     • Google Play User Data policy and SDK Index documentation under Google's first-party platform authority.

     Tier 1.5 admits only formal instruments under the regulator's enabling-statute authority. Excluded as Tier 1.5: regulator blog posts, press releases, staff op-eds, social-media posts, FAQ landing pages. A Tier 1.5 citation must always appear alongside a Tier 1 citation on the same checklist item.

   • Disqualifying. Blog summaries, Q&A sites, AI summaries, news articles, law-firm explainers, regulator informal output (blog posts, press releases). Same rule as the research domain of ADR-008/010.

3. PII path refusal. The Skill must refuse to ingest paths likely to contain test data, seeds, environment files, or database dumps. The concrete glob list and PII regex masks live in triggers.md. On refusal, the Skill emits a single-line message naming the offending path and stops.

4. Default-off, opt-in per project. The Skill runs only when both compliance.enabled: true (in .claude/compliance.yml) and a non-empty target_jurisdictions are declared. Either condition missing is a hard refusal, not a fallback.

5. Project-declared jurisdictions, never guessed. The Skill does not infer jurisdiction from currency, language, domain TLD, or user-list samples. Jurisdiction is a project assertion. If the declared list is wrong, that is a project-level configuration defect surfaced by the Skill's behavior, not a bug for the Skill to compensate around.

6. Capability-based triggers only. Trigger detection works on capabilities (manifest dependencies, AST patterns of HTTP routes, form-field schemas), not on file or route names. The trigger rules are in triggers.md. When a dependency signal is ambiguous, the Skill asks the human a closed-form question (yes / no / "I don't know — skip and re-run later") and records the answer in the output's audit trail.

Output contract

Every invocation produces a Markdown report with these sections, in this order, all required:

# Compliance Checklist — <feature or release name>

## Disclaimer

<contents of disclaimers.md, EN + JA, verbatim — must not be edited
or removed by the Skill>

## Project context

- target_jurisdictions: [<list from CLAUDE.md / compliance.yml>]
- triggered capabilities: [<list from triggers.md detection>]
- ambiguous-trigger answers: [<list of human Q&A, if any>]
- evaluation date: <YYYY-MM-DD>

## Findings per jurisdiction

### JP (if in scope)
- 電気通信事業法 — `applies` | `may apply, verify` | `out of scope ...`
  - Citation: <e-Gov URL>
  - Reason: <one-line rationale tied to the triggered capability>
  - Human action: <what the human reviewer must verify or decide>
- 特定商取引法 §11 — ...
- 改正個人情報保護法 — ...
- 資金決済法 — ...

### EU (if in scope)
- GDPR — ...

### US-CA (if in scope)
- CCPA / CPRA — ...

### platform (if in scope)
- App Store Review Guidelines — ...
- Google Play Policy Center — ...

## Required human follow-up

- [ ] Qualified-attorney review before launch (always, never marked
      complete by the Skill).
- [ ] Each `applies` and `may apply, verify` item above resolved by a
      human.
- [ ] If Terms of Service / Privacy Policy / refund-policy text was
      derived from this checklist, that text reviewed by counsel
      before publication.

## Audit trail

- Skill version: <semver from this SKILL.md frontmatter, when
  introduced>
- Jurisdiction reference files consulted:
  [`JP.md`](./jurisdictions/JP.md), [`EU.md`](./jurisdictions/EU.md),
  ...
- Operator: <git user.email if available, else "unknown">

The Skill never writes a ## Compliance status section. There is no field for "complied with" or "verified". The closest the report gets is the unchecked checkbox under "Required human follow-up". A human checks those boxes outside the Skill's authoring path.

Override Protocol

Adopting projects can disable individual Invariant rules only when the rule does not fit their context, and only with an explicit declaration in the project's own CLAUDE.md:

## Compliance Skill overrides

- Invariant 5 (project-declared jurisdictions): partially overridden.
  We auto-derive `target_jurisdictions` from the customer-billing
  country code at runtime because we serve >40 jurisdictions and
  manual declaration is impractical.
  Reason: <why>. Date: <YYYY-MM-DD>. Risk acceptance signed by:
  <human name>.

What you cannot override:

• Invariants 1 (no negative-applicability claims), 2 (primary-source citation), and 3 (PII path refusal). These are safety-critical; removing them turns the Skill from "useful but limited" into "actively harmful".
• The mandatory disclaimer block (Invariant — implicit in disclaimers.md).
• The English-only meta-files of this Skill (this SKILL.md and triggers.md are operator-facing references).

If you find yourself overriding two or more invariants, the Skill is not a fit for your project. Delete the directory; that is also a supported state.

Skill update cadence

This Skill's jurisdiction reference files (jurisdictions/*.md) cite laws that change. Re-verification cadence:

• Half-yearly (180 days) for the JP, EU, and US-CA jurisdictions, manually, by docs-researcher per the research-domain protocol of verification-layer (ADR-008/010). Citations are re-fetched from primary sources only.
• Quarterly (90 days) for the platform jurisdiction, because Apple App Store Review Guidelines and Google Play policies change materially more often than statutory text. The shorter cadence is reflected in .claude/compliance.yml.example's reverification_days.platform default.
• On amendment notice, when an operator becomes aware of a law change in any of target_jurisdictions. The operator opens an Issue using the citation as evidence; the next half-yearly pass picks it up sooner if needed.

If a re-verification finds that a cited statute or platform policy has changed, the right response is: (1) update the relevant jurisdictions/<X>.md, (2) record the change in the project CHANGELOG with the verification date, (3) re-run the Skill on any recently-shipped capability that depended on the changed citation.

If the cadence is missed for two consecutive intervals (i.e., one year without re-verification), the Skill's output should include a prominent staleness warning in the Disclaimer section. Implementation of that warning is part of disclaimers.md's rendering logic, not this overview.

Out-of-scope by design

The Skill does not:

• Author Terms of Service, Privacy Policy, refund-policy, or any other legal document text. It produces the requirements list that technical-writer uses as input. Document drafting, even derived from a Skill checklist, has too high a blast radius for LLM-only output.
• Cover vertical-specific compliance regimes. For healthcare PHI, point to ECC's hipaa-compliance and healthcare-phi-compliance Skills. For financial KYC/AML, point to the operator's specialized legal counsel — ECC has no equivalent Skill, and this Skill should not pretend to. The same applies to broadcasting, gambling, gun sales, alcohol, controlled substances, and any other regime where a small mistake has large legal consequences.
• Make cross-jurisdictional decisions. If a capability triggers obligations in JP and EU and US-CA simultaneously, the Skill lists each independently. Synthesizing "if you do X for JP, you also satisfy EU" is the kind of cross-regime reasoning that requires a qualified attorney.

See also

• disclaimers.md — the mandatory disclaimer block, EN and JA.
• triggers.md — capability-detection rules and PII-path refusal globs.
• jurisdictions/JP.md, jurisdictions/EU.md, jurisdictions/US-CA.md, jurisdictions/platform.md — per-jurisdiction citation tables.
• ADR-011 — design rationale, the six invariants, and the rejected-alternatives table that produced this Skill rather than an agent.
• ADR-013 — Invariant 2 source tier model. Defines Tier 1 / Tier 1.5 / disqualifying, the closed Tier 1.5 regulator allowlist, the pairing rule, and the verification-layer-wide scope.