A structured pre-release audit pipeline for software products — built from reusable AI agent prompts.
By Jason Fields — @fasonista
Cognitive modes and gstack lineage inspired by Garry Tan's gstack.
Product Deploy Agents is a 7-file framework for running a rigorous, multi-perspective pre-release audit on any software product before it ships. Each file defines an AI agent with a distinct professional identity, cognitive methodology, and audit scope. Together they cover the full release surface: user experience, architecture, quality assurance, product strategy, compliance, and release execution.
The pipeline is designed to be run with AI tools that support agentic workflows — Claude Cowork, Claude Code, or any multi-agent orchestration setup. But the prompts are plain Markdown. You can read them, adapt them, and apply them manually if you prefer.
The agents are completely generic. They contain no product-specific knowledge. All project context lives in two files you populate for each new product: agent0-product-context.md and app-context.md. Swap those out and the entire pipeline works for a different product.
Most pre-release checklists are flat. They ask: did you test the happy path? Is the build signed? Did you check the App Store screenshots? These are necessary but not sufficient. What they miss is the adversarial layer — the race conditions, the state machine edge cases, the regulatory line someone crossed without realizing it, the UX detail that signals "assembled rather than designed" to users who can't articulate why they stopped trusting the app.
This pipeline applies seven distinct professional lenses to a codebase before release. Each agent has a different threat model, a different set of references, and a different definition of "done." The failure modes they catch don't overlap much — which is the point.
STAGE 0 — Foundation (read by all agents before any audit):
Agent 0: Product Context
STAGE 1 — Parallel (no dependencies between agents):
Agent 1: UX & Design Auditor
Agent 2: Full Stack Developer
Agent 3: QA & Testing Auditor
STAGE 2 — Sequential (reads Stage 1 output):
Agent 4: Product & Business Manager
Agent 5: Compliance & Claims Reviewer
STAGE 3 — Sequential (reads all prior output):
Agent 6: App Store & Release Manager
Agents 1, 2, and 3 run in parallel against the codebase. Agents 4 and 5 read their output before forming opinions. Agent 6 reads everything, produces the final release verdict, and generates a plain-English document for any required expert review (clinical lead, legal, security).
Not an auditing agent. A structured intake template that every other agent reads before touching the codebase. It establishes who the product is for, what the primary user flows are, what data architecture is in play, what "working correctly" means for this specific user, and which compliance framework applies.
For each new project: populate this template from your app-context.md and product spec. The agent files themselves never change.
Cognitive mode: Senior designer and visual QA engineer — Swiss grid rationalist, Frog Design provocateur, Apple platform purist.
This agent has strong aesthetic convictions rooted in the design canon: Dieter Rams' principle that restraint is precision not timidity, the Bauhaus insistence that form and function are the same thing stated differently, Jony Ive's attention to the details users don't consciously notice, Frog Design's requirement that a product has a coherent personality across every surface and state.
It catches what checklists miss: the generic card layout that could belong to any app, the animation running at linear timing because nobody thought about it, the empty state that's just whitespace where content should be, the icon family where some icons feel heavier than others. These are signals that a product was assembled rather than designed.
It audits: primary flow choreography, multi-surface visual consistency, the full state matrix (loading / loaded / empty / error / offline / first-time / edge input), feedback and communication quality, accessibility, contemporary platform standards, and visual regression across changed files.
Key principles: subtraction as craft, type as architecture, color with restraint, motion as communication, spatial consistency, platform fluency, parallax and depth as hierarchy.
Cognitive mode: Senior engineering manager in the "boring technology" school.
This agent's intellectual formation: Dan McKinley's "Choose Boring Technology" (novelty has a carrying cost; most systems fail at the seams between components), Kelsey Hightower (the best infrastructure is what you don't have to think about), the Google SRE book (reliability is an engineering discipline, not a prayer), Rich Hickey (complexity is the enemy — things braided together when they should be separate).
It draws boxes and arrows before reading code, because architecture should be legible at that level of abstraction. It finds the edge where two subsystems disagree about state — the race condition that lives not in any single component but in the space between them.
It audits: primary flow state machines with full invariant verification, data persistence and recovery across all layers, multi-surface communication architecture, authentication and token management sequencing, race conditions, error handling completeness, and API contract integrity.
Mandatory output: ASCII architecture diagrams for the primary flow state machine, data persistence flow, cross-surface communication, and token refresh coordination.
Key principles: explicit over implicit, the boring solution wins, failure modes as first-class citizens, state machines not flags, data has gravity, the two-way door test.
Cognitive mode: Paranoid staff engineer in the tradition of chaos engineering and adversarial security.
This agent's formation: Netflix chaos engineering (systems fail in production in ways they never fail in testing; the only honest preparation is deliberate failure under controlled conditions), Bruce Schneier (attackers think in systems while defenders think in components — that asymmetry is why defenders lose), the blameless postmortem tradition (most failures are system failures, not individual ones).
It assumes every async operation will race, every timer will fire at the worst possible moment, every network call will fail in a way nobody anticipated, and every background transition will happen during the two seconds when the state machine is between valid states.
It audits across six adversarial categories: data loss scenarios (action × adverse condition × timing), cross-surface connectivity edge cases, authentication edge cases, state corruption scenarios, offline queue integrity, and regression surface against the full fix history.
Key principle: silent failure is the worst failure. A crash is honest. A silent failure lets users believe everything is fine while their data disappears.
Cognitive mode: Founder-mode product leader with strong convictions about what separates products that matter from products that are merely functional.
This agent's formation: Jobs (the most important decisions are what to say no to; focus is a discipline not a strategy), Bezos (one-way vs two-way doors; scrutinize irreversible decisions with everything you have), Horowitz (wartime and peacetime CEOs are different creatures; know which mode you're in), Chesky's 10-star framework (start with the version that would make someone cry with joy — not to ship it, but to know what direction "better" points), Collison (irrationally impatient about what's possible, rationally patient about what it takes).
It reads Stage 1 output before forming opinions. It doesn't re-audit code — it evaluates decisions.
It evaluates: release story coherence, trust calculus against the primary user persona, conversion and retention impact, competitive positioning on the dimensions that matter to this user, enterprise or institutional readiness, risk stack ranked by user impact, and roadmap alignment.
Key principle: trust is built slowly and lost quickly. Users don't churn because of individual bugs — they churn when they stop trusting the product.
Cognitive mode: Discerning regulatory reviewer who reads every claim the way a regulator will — not charitably, not adversarially, but literally.
This agent has internalized three simultaneous perspectives: the relevant regulator for this product's domain, the platform's app review team looking for misleading claims, and the plaintiff's attorney who will read the privacy policy against the deposition transcript in three years.
Its formation: information security threat modeling (the threat model must precede the defense), Daniel Solove's privacy law scholarship (privacy violations are about loss of control and broken expectations, not just data theft), and the principle that the line between acceptable and non-compliant is almost never about what the technology does — it's about what you claim it does.
This agent is parameterized by compliance class — read from Agent 0. The scope scales entirely to the product at hand. A simple consumer app gets App Store guidelines and basic privacy policy alignment. A health/wellness product gets FDA General Wellness + HealthKit audit (example: the line between "supports stress awareness" and "treats anxiety disorder" is a regulatory line, not a semantic one). A financial product gets GDPR/CCPA/PCI. An enterprise B2B product gets SOC 2 and data processing agreement review. For a product with no regulated data, this agent reduces to a quick copy and permissions check.
It audits: sensitive data flow across all surfaces and layers, at-rest and in-transit encryption verification, access control, data retention and deletion, privacy policy alignment claim by claim, platform permission justification, and all user-facing copy against applicable regulatory lines.
Key principle: the cost of staying on the safe side of a regulatory line is almost always near-zero. The cost of crossing it is orders of magnitude higher. When in doubt, rewrite toward caution.
Hard gate: if Agent 5 is CONDITIONAL or BLOCKED and expert sign-off has not been received, Agent 6 cannot issue a GO verdict.
Cognitive mode: Release engineer in the Site Reliability Engineering tradition.
This agent's formation: the Google SRE book (reliability is a feature that must be designed and measured; "zero risk" is not a goal, it's a constraint), error budget thinking (the question is not "is this safe?" but "is the risk within budget and have we been explicit about accepting it?"), the blameless postmortem tradition (production failures are system failures), Charity Majors and the observability movement (you cannot reason about production systems from first principles — instrumentation must be designed before you need it).
It is the last agent in the pipeline before real users see the build. It doesn't debate what should have been built. Its job is surgical: verify the build is what it claims to be, verify all gates have been passed, verify the rollout plan is sound, and verify the rollback path is clear.
It executes: full build configuration verification across all platforms, TestFlight and App Store metadata drafting, phased rollout plan with platform-specific monitoring, severity-based rollback plan with data impact analysis, complete pre-submission checklist, post-release monitoring plan, and generation of a plain-English expert review document for any required sign-off.
Key principle: boring releases are successful releases. Excitement at launch is a warning sign. The checklist is institutional memory — every item exists because someone forgot it once.
product-deploy-agents/
├── README.md
├── LICENSE
├── DEPLOY_READINESS_COWORK_PROMPT.md ← Master pipeline prompt
├── agent0-product-context.md ← Intake template (populate per project)
├── agent1-ux-design.md
├── agent2-fullstack-dev.md
├── agent3-qa-audit.md
├── agent4-product-business.md
├── agent5-compliance-claims.md
└── agent6-appstore-release.md
git clone https://github.com/fasonista71/product-deploy-agentsFor each product, create two files outside this repo (in your project's own folder):
agent0-product-context.md— populate from the intake template. Defines your user persona, primary flows, data architecture, device surfaces, auth model, known risks, and compliance class.app-context.md— your project's technical reference: build config, endpoints, architecture rules, compliance status, critical invariants.
These two files are the only things that change between projects. The agent files never change.
The pipeline is designed for AI agentic workflows. Point your tool at the agent files and your context files.
With Claude Cowork or Claude Code:
- Add all agent
.mdfiles and your context files to the project - Use
DEPLOY_READINESS_COWORK_PROMPT.mdas the orchestration prompt - Stage 1 agents (1, 2, 3) can run in parallel
- Stage 2 agents (4, 5) read Stage 1 output before running
- Agent 6 reads all prior output and produces the final verdict
Manually:
- Read each agent file and apply its audit scope to your codebase
- Write findings to
deploy-readiness/output/agent[N]-[name].md - Agent 6 synthesizes all findings into a release verdict
| Condition | Outcome |
|---|---|
| Agent 3 has unresolved P0 | All agents hold — no GO |
| Agent 5 is BLOCKED | Agent 6 issues BLOCKED |
| Agent 5 is CONDITIONAL | Agent 6 issues CONDITIONAL until expert confirms |
| Expert sign-off pending | Agent 6 holds GO |
The expert review gate is absolute. Agent 6 does not issue GO while compliance is unresolved.
The agents are the methodology. You bring the context:
| You provide | Where it goes |
|---|---|
| Who the product is for | agent0-product-context.md → Product Identity |
| What the primary flows are | agent0-product-context.md → Core User Flows |
| What "working correctly" means | agent0-product-context.md → Working Correctly |
| Build config, endpoints, auth | app-context.md |
| Architecture rules and known risks | app-context.md |
| Compliance class | agent0-product-context.md → Regulatory Class |
| User-facing copy inventory | Referenced by Agent 5 |
| Fix history and regression surface | Referenced by Agents 2, 3, 6 |
Agent 5 is parameterized. Scope it to what actually applies:
| Product type | Agent 5 scope |
|---|---|
| Health / wellness (HealthKit, FDA) | Sections A + B + C |
| Consumer app with PII | Sections B + C |
| Simple consumer app, no sensitive data | Section C only |
| Financial product | Sections B + C + D |
| No compliance requirement | Drop Agent 5 entirely |
The cognitive mode labels and gstack lineage tags in each agent prompt (/plan-design-review, /plan-eng-review, /qa, /plan-ceo-review, /review, /ship) are inspired by and adapted from Garry Tan's gstack — a framework for applying distinct cognitive modes to different types of work. If this pipeline resonates with you, gstack is worth reading in full.
Issues and pull requests welcome. If you adapt this pipeline for a new domain (fintech, edtech, enterprise SaaS) and want to share the additions, open a PR.
Attribution required per CC BY 4.0 terms.
© 2026 Jason Fields — jasonpfields.com — @fasonista
Licensed under Creative Commons Attribution 4.0 International (CC BY 4.0).
You are free to share and adapt this material for any purpose, including commercially, as long as you give appropriate credit.
