You're designing the AI infrastructure for the cloud engineering practice at Formosa Semiconductor Solutions (FSS) for Wei-Lin Chang, Principal Cloud Architect, a 2,500-person semiconductor design and testing company in Hsinchu, Taiwan running classified-IP chip-design workloads on AWS.
The discipline skills: a Claude Code skill that encodes a four-category security audit as a reproducible workflow; a pre-commit checkov hook and a pre-apply Infracost hook, both fail-closed with audit-grade logging under 30 seconds; a verification architecture that places checkpoints at composition boundaries before any agent runs; and a three-agent orchestration on a canary deployment with curated per-agent context and a priced token-cost dimension.
The AI-direction lesson is that AI infrastructure is its own engineering surface. Skills, hooks, and CLAUDE.md memory each have a shape, and the same encoded practice behaves differently depending on which mechanism carries it. AI authors skills too vague to fire reliably, proposes hooks that fail-open and skip audit logs, builds implementations that take 60-90 seconds and get bypassed, and proposes flat multi-agent topologies where every agent receives the full project context. You learn to debug the AI infrastructure itself, not just the code AI writes.
Your Role
You own the AI infrastructure design. Wei-Lin knows hooks and skills from a previous engagement built on Jenkins and custom scripts; what he needs is the AI-native version, bound by his compliance team's audit-grade-logging requirement and his classified-IP rule that the AWS MCP connection must never reach design data. The first contact is a project-kickoff meeting captured as meeting notes, and no template in the materials hands you a skill spec, a hook implementation, a verification-architecture pattern, or a multi-agent topology.
You direct Claude through the skill, the two hooks, the verification architecture, and the multi-agent orchestration. Priya Subramanian, a senior cloud engineer who replies in 1-3 sentences and tends to start with "so" or "right," appears twice at the edges where AI-infrastructure judgment matters: when you choose the first hook's fail-mode, and when you commit to the verification architecture before any agent starts. She does not propose the design. You do.
What's New
Last time at RDTA you designed a cost-allocation methodology and a 12-month capacity projection in formal business-day email with a World Bank programme officer reading the methodology before the numbers. You leave with the methodology-as-deliverable habit at Advanced scaffolding and the encoded-standards CLAUDE.md.
This time the substance flips from cost to AI infrastructure. The deliverables ARE the AI infrastructure. The Terraform footprint is intentionally small — a budget alarm, an audit-log bucket, and a tiny canary stack. Communication switches from business-day email to in-session meeting notes. The mechanism-selection question — memory vs skill vs hook for a given encoded practice — is the design judgment that gates the first three working units.
The hard part: a misfiring skill produces false confidence; a slow hook produces workarounds; a fail-open hook offers theatre, not protection. Verification is no longer "did this plan look right" — it is "does each agent's output line up with the next agent's expected input?" The architecture binds the agents. Without it, every agent passes its own validation while the global result drifts.
Tools
- Claude Code skills — new. Encoded workflows AI runs on demand.
- Claude Code hooks — new. Deterministic guardrails on commit and apply.
- checkov — new. Static analysis on Terraform, invoked by the pre-commit hook, version pinned.
- Infracost — surfaced in P4 as a manual gate, escalated here to a pre-apply hook.
- Codex CLI — new. The cross-tool, cross-model surface used for one agent so verification crosses model boundaries.
- Terraform — reused for the budget alarm, the audit-log bucket, and the canary's weighted-routing configuration.
- AWS MCP server — reused from P12, read-only, allowlist re-scoped to exclude design-data S3 buckets.
- CLAUDE.md — extended with the classified-IP MCP scope Non-Negotiable, the hook-performance-under-30s Convention, and the mechanism-selection Convention.
scripts/verify.sh— extended with hook-performance and composition-boundary dimensions.
Materials
In the project zip:
- Wei-Lin's kickoff meeting notes (
wei-lin-kickoff-meeting-notes.md) — a one-page record of the three top-line items (deterministic guardrails, canary evaluation, classified IP) in his precision-engineer register. No procedural detail. - FSS security policy excerpt (
fss-security-policy-excerpt.md) — the four categories FSS already audits manually. The mapping to checkov check IDs is not in the file. - Infracost baseline configuration (
infracost-baseline-config.yml) — a stub carried forward from P4 with FSS-specific thresholds blank for you to fill. - CLAUDE.md — engagement governance with FSS facts in place and three TODO markers for the new Non-Negotiable and Conventions.
- Skill and hook starters (
skills/security-audit/SKILL.md,hooks/pre-commit-checkov.sh,hooks/pre-apply-infracost.sh) — TODO-body shells. You write the specifications and implementations. - Verify-extension starters (
scripts/check-hook-performance.sh,scripts/check-canary-composition.py) — TODO-body shells.
You produce the security-audit skill, the two hooks with audit-grade logging, the verification architecture document, the multi-agent orchestration document, the engagement's CLAUDE.md additions, and the handover README.