Skill

compliance-pci

PCI DSS compliance: SAQ A vs SAQ D scope, Stripe Elements for card data isolation, tokenization patterns, cardholder data environment (CDE) scoping, network segmentation, encryption in transit/at rest, audit logging requirements. Never store raw card data. Use when implementing payment systems, reviewing card data handling, PCI scope reduction.

Install

npx claudepluginhub rnavarych/alpha-engineer --plugin billy-milligan

Tool Access

This skill is limited to using the following tools:

ReadGrepGlob

Preview

- Implementing payment card processing

Supporting Assets

references/cardholder-data.mdreferences/network-segmentation.mdreferences/saq-selection.md

SKILL.md

Similar Skills

agent-eval

Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.

everything-claude-code

156.2k

agent-harness-construction

Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.

everything-claude-code

156.2k

accessibility

Designs, implements, and audits WCAG 2.2 AA accessible UIs for Web (ARIA/HTML5), iOS (SwiftUI traits), and Android (Compose semantics). Audits code for compliance gaps.

everything-claude-code

156.2k

Stats

Parent Repo Stars9

Parent Repo Forks0

Last CommitFeb 23, 2026

Actions

View Source View Plugin View on GitHub View README

compliance-pci

Core principles

Never store raw card data — full PAN, CVV, magnetic stripe data must never touch your servers

Reduce scope, don't solve scope — use Stripe Elements / Braintree Hosted Fields to push scope to the processor

Tokenize, never transmit — use processor tokens (pm_xxx, tok_xxx); your app never sees raw card numbers

CVV must never be stored — not even transiently in logs; PCI Req 3.3 is absolute

SAQ A is achievable for most SaaS — if you use hosted card collection, you avoid SAQ D's 300+ controls

References available

references/saq-selection.md — SAQ A vs SAQ A-EP vs SAQ D decision tree, control counts, scope criteria

references/cardholder-data.md — what to store vs what to forbid, tokenization schema, webhook security patterns

references/network-segmentation.md — CDE boundary design, firewall rules, segmentation testing

PCI DSS Compliance

When to use

Implementing payment card processing
Reducing PCI scope with hosted fields / Elements
Reviewing what data can/cannot be stored
Designing network segmentation for CDE
Choosing SAQ level for annual assessment

Core principles

Never store raw card data — full PAN, CVV, magnetic stripe data must never touch your servers
Reduce scope, don't solve scope — use Stripe Elements / Braintree Hosted Fields to push scope to the processor
Tokenize, never transmit — use processor tokens (pm_xxx, tok_xxx); your app never sees raw card numbers
CVV must never be stored — not even transiently in logs; PCI Req 3.3 is absolute
SAQ A is achievable for most SaaS — if you use hosted card collection, you avoid SAQ D's 300+ controls

References available

references/saq-selection.md — SAQ A vs SAQ A-EP vs SAQ D decision tree, control counts, scope criteria
references/cardholder-data.md — what to store vs what to forbid, tokenization schema, webhook security patterns
references/network-segmentation.md — CDE boundary design, firewall rules, segmentation testing