# Privacy Computing Engineer > Privacy Computing Engineer - Skill: `haibarakiku/privacy-computing-engineer` (Agent Skill, multi-file: 14 files) - Install (CLI): `npx skillmds@latest add haibarakiku/privacy-computing-engineer` - Raw SKILL.md: https://api.skillmd.com/api/skills/haibarakiku/privacy-computing-engineer/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: Haibarakiku (https://skillmd.com/u/haibarakiku) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/haibarakiku/privacy-computing-engineer --- # Privacy Computing Engineer --- ## § 1 · System Prompt ``` [Code block moved to code-block-1.md] ``` --- ## § 10 · Common Pitfalls ### Anti-Pattern 1 — Centralized Aggregation Server in "Federated" Learning → Full code examples: [references/code-block-2.md](references/code-block-2.md) --- ### Anti-Pattern 2 — DP Epsilon Misreporting → Full code examples: [references/code-block-2.md](references/code-block-2.md) --- ### Anti-Pattern 3 — SGX Enclave Without Remote Attestation → Full code examples: [references/code-block-2.md](references/code-block-2.md) --- ### Anti-Pattern 4 — SMPC with Malicious Majority Assumption Ignored → Full code examples: [references/code-block-2.md](references/code-block-2.md) --- ### Anti-Pattern 5 — Homomorphic Encryption Without Noise Budget Management → Full code examples: [references/code-block-2.md](references/code-block-2.md) --- ## § 11 · Integration with Other Skills **Privacy Computing Engineer + Secure Code Reviewer** Combine for end-to-end privacy-preserving system audits. The Secure Code Reviewer examines enclave code for memory safety (buffer overflows in untrusted memory interfaces) and cryptographic misuse; the Privacy Computing Engineer validates the privacy protocol composition, DP accounting, and attestation flow. The natural handoff point is the enclave/host interface boundary. **Privacy Computing Engineer + ML Engineer** Collaborate on production federated learning deployments. The ML Engineer owns model architecture, convergence, and evaluation metrics; the Privacy Computing Engineer owns DP calibration (noise multiplier, clipping norm, sampling rate), secure aggregation protocol, and regulatory documentation. Critical integration point: the ML Engineer must accept accuracy degradation from DP noise as a deliberate privacy-accuracy tradeoff, not a bug to fix. **Privacy Computing Engineer + Compliance Auditor** Joint DPIA production for high-risk processing activities. The Compliance Auditor maps business processing purposes to legal bases and Art. 35 risk criteria; the Privacy Computing Engineer translates technical countermeasures into evidence artifacts (DP accountant logs, attestation verification records, SMPC protocol proofs) that satisfy supervisory authority inquiry standards under GDPR and PIPL. --- ## § 12 · Scope & Limitations **Use this skill when:** - Designing cross-organizational data collaboration where raw data cannot be shared (healthcare consortia, financial industry benchmarking, government statistics pooling). - Implementing ML training pipelines on sensitive data requiring formal privacy guarantees rather than access controls alone. - Deploying computation on cloud infrastructure that must not trust the cloud provider (confidential computing use cases requiring TEE). - Producing regulatory evidence for GDPR Art. 25, DPIA, or EU AI Act conformity assessments for high-risk AI systems. **Do NOT use this skill when:** - Data can be legally shared under existing agreements and the threat model does not require cryptographic guarantees — standard encryption at rest and in transit suffices; do not add HE or SMPC overhead unnecessarily. - The performance budget makes cryptographic privacy computationally infeasible and no optimization path exists — acknowledge the constraint and recommend synthetic data generation or data minimization instead. - The regulatory requirement is contractual or policy-based (NDA, DPA) rather than requiring technical enforcement — legal instruments may be sufficient; cryptographic controls would be engineering overkill. - Real-time low-latency inference (< 10ms) is required and HE/SMPC overhead cannot meet the SLA — TEE may be the only viable path; if TEE trust model is rejected, escalate to architecture review before proceeding. --- ## § 14 · Quality Verification → See references/standards.md §7.10 for full checklist --- ## References Detailed content: - [## § 2 · What This Skill Does](./references/2-what-this-skill-does.md) - [## § 3 · Risk Disclaimer](./references/3-risk-disclaimer.md) - [## § 4 · Core Philosophy](./references/4-core-philosophy.md) - [## § 6 · Professional Toolkit](./references/6-professional-toolkit.md) - [## § 7 · Standards & Reference](./references/7-standards-reference.md) - [## § 8 · Workflow](./references/8-workflow.md) - [## § 9 · Scenario Examples](./references/9-scenario-examples.md) - [## § 20 · Case Studies](./references/20-case-studies.md) ## Examples ### Example 1: Standard Scenario Input: Design and implement a privacy computing engineer solution for a production system Output: Requirements Analysis → Architecture Design → Implementation → Testing → Deployment → Monitoring Key considerations for privacy-computing-engineer: - Scalability requirements - Performance benchmarks - Error handling and recovery - Security considerations ### Example 2: Edge Case Input: Optimize existing privacy computing engineer implementation to improve performance by 40% Output: Current State Analysis: - Profiling results identifying bottlenecks - Baseline metrics documented Optimization Plan: 1. Algorithm improvement 2. Caching strategy 3. Parallelization Expected improvement: 40-60% performance gain ## Workflow ### Phase 1: Requirements - Gather functional and non-functional requirements - Clarify acceptance criteria - Document technical constraints **Done:** Requirements doc approved, team alignment achieved **Fail:** Ambiguous requirements, scope creep, missing constraints ### Phase 2: Design - Create system architecture and design docs - Review with stakeholders - Finalize technical approach **Done:** Design approved, technical decisions documented **Fail:** Design flaws, stakeholder objections, technical blockers ### Phase 3: Implementation - Write code following standards - Perform code review - Write unit tests **Done:** Code complete, reviewed, tests passing **Fail:** Code review failures, test failures, standard violations ### Phase 4: Testing & Deploy - Execute integration and system testing - Deploy to staging environment - Deploy to production with monitoring **Done:** All tests passing, successful deployment, monitoring active **Fail:** Test failures, deployment issues, production incidents