{"id":2926,"date":"2026-04-12T23:35:48","date_gmt":"2026-04-12T23:35:48","guid":{"rendered":"https:\/\/aiopsschool.com\/blog\/?p=2926"},"modified":"2026-04-12T23:35:48","modified_gmt":"2026-04-12T23:35:48","slug":"how-to-build-an-application-using-claude-and-codex","status":"publish","type":"post","link":"https:\/\/aiopsschool.com\/blog\/how-to-build-an-application-using-claude-and-codex\/","title":{"rendered":"How to Build an Application Using Claude and Codex"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">What you are really building<\/h2>\n\n\n\n<p>You are not just building an app.<\/p>\n\n\n\n<p>You are building a <strong>repeatable engineering system<\/strong> where:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>requirements are clarified before code<\/li>\n\n\n\n<li>architecture is documented before implementation<\/li>\n\n\n\n<li>agents work from written contracts instead of fuzzy memory<\/li>\n\n\n\n<li>implementation is done in slices<\/li>\n\n\n\n<li>every slice is tested and reviewed<\/li>\n\n\n\n<li>deployment is a controlled release, not a gamble<\/li>\n<\/ul>\n\n\n\n<p>This tutorial gives you that system.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 1 \u2014 The right mental model<\/h1>\n\n\n\n<h2 class=\"wp-block-heading\">Why most AI-assisted app builds fail<\/h2>\n\n\n\n<p>Most teams fail because they do one of these:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>ask one agent to \u201cbuild everything\u201d<\/li>\n\n\n\n<li>skip requirements and jump to code<\/li>\n\n\n\n<li>let the agent modify too many services at once<\/li>\n\n\n\n<li>don\u2019t define what \u201cdone\u201d means<\/li>\n\n\n\n<li>don\u2019t force tests, validation, linting, and review<\/li>\n\n\n\n<li>deploy without a staging gate<\/li>\n\n\n\n<li>assume \u201ccode generated\u201d means \u201cproduction ready\u201d<\/li>\n<\/ul>\n\n\n\n<p>That creates fake speed.<\/p>\n\n\n\n<p>Real speed comes from this sequence:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>define<\/li>\n\n\n\n<li>constrain<\/li>\n\n\n\n<li>implement<\/li>\n\n\n\n<li>verify<\/li>\n\n\n\n<li>deploy safely<\/li>\n\n\n\n<li>harden<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 2 \u2014 Divide responsibilities between Claude and Codex<\/h1>\n\n\n\n<h2 class=\"wp-block-heading\">Use Claude for these jobs<\/h2>\n\n\n\n<p>Use Claude when you need:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>idea clarification<\/li>\n\n\n\n<li>product requirement discovery<\/li>\n\n\n\n<li>architecture planning<\/li>\n\n\n\n<li>user flow and admin flow design<\/li>\n\n\n\n<li>repo audit and codebase understanding<\/li>\n\n\n\n<li>gap analysis<\/li>\n\n\n\n<li>\u201cwhat is missing?\u201d<\/li>\n\n\n\n<li>writing <code>CLAUDE.md<\/code><\/li>\n\n\n\n<li>writing <code>SPEC.md<\/code><\/li>\n\n\n\n<li>reviewing whether a feature is actually complete<\/li>\n\n\n\n<li>finding what is broken, risky, missing, or inconsistent<\/li>\n<\/ul>\n\n\n\n<p>Claude Code is explicitly built around an agentic loop of gathering context, taking action, and verifying results, and it reads <code>CLAUDE.md<\/code> at the start of sessions as persistent project guidance. (<a href=\"https:\/\/code.claude.com\/docs\/en\/how-claude-code-works\">Claude<\/a>)<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Use Codex for these jobs<\/h2>\n\n\n\n<p>Use Codex when you need:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>implementing a clearly-scoped slice<\/li>\n\n\n\n<li>editing multiple files safely<\/li>\n\n\n\n<li>generating tests<\/li>\n\n\n\n<li>running lint\/typecheck\/test commands<\/li>\n\n\n\n<li>validating acceptance criteria<\/li>\n\n\n\n<li>reviewing diffs<\/li>\n\n\n\n<li>repeating a stable workflow with consistency<\/li>\n<\/ul>\n\n\n\n<p>Official Codex guidance emphasizes durable repo instructions in <code>AGENTS.md<\/code>, giving verification steps, running lint and pre-commit checks, and breaking complex work into smaller focused tasks. (<a href=\"https:\/\/developers.openai.com\/codex\/learn\/best-practices\">OpenAI Developers<\/a>)<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">The simplest split<\/h2>\n\n\n\n<p>Use this rule:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Claude decides what should happen<\/strong><\/li>\n\n\n\n<li><strong>Codex makes it happen<\/strong><\/li>\n\n\n\n<li><strong>Claude checks whether it happened correctly<\/strong><\/li>\n<\/ul>\n\n\n\n<p>That is the cleanest operating model.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 3 \u2014 The file system of control<\/h1>\n\n\n\n<p>For a serious project, do not rely only on chat history.<\/p>\n\n\n\n<p>Create these files in the repository root:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Myhospital\/\n  CLAUDE.md\n  AGENTS.md\n  SPEC.md\n  RELEASE_READINESS.md\n  svc1\/\n    CLAUDE.md\n  svc2\/\n    CLAUDE.md\n  svc3\/\n    CLAUDE.md\n  svc4\/\n    CLAUDE.md\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">What each file does<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\"><code>SPEC.md<\/code><\/h3>\n\n\n\n<p>This is the <strong>contract<\/strong>.<\/p>\n\n\n\n<p>It defines:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>what is being built<\/li>\n\n\n\n<li>why it matters<\/li>\n\n\n\n<li>who uses it<\/li>\n\n\n\n<li>what flows must work<\/li>\n\n\n\n<li>acceptance criteria<\/li>\n\n\n\n<li>test plan<\/li>\n\n\n\n<li>rollout plan<\/li>\n\n\n\n<li>rollback plan<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\"><code>CLAUDE.md<\/code><\/h3>\n\n\n\n<p>This is Claude\u2019s <strong>persistent repo memory that you write<\/strong>.<\/p>\n\n\n\n<p>Official Claude Code docs say <code>CLAUDE.md<\/code> is loaded at the start of every session and should contain things Claude cannot infer on its own, such as bash commands, code style, workflow rules, architecture decisions, and review expectations. They also recommend keeping it concise and using more specific files deeper in the directory tree when needed. (<a href=\"https:\/\/code.claude.com\/docs\/en\/best-practices\">Claude<\/a>)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><code>AGENTS.md<\/code><\/h3>\n\n\n\n<p>This is Codex\u2019s <strong>durable repo guide<\/strong>.<\/p>\n\n\n\n<p>OpenAI\u2019s Codex docs recommend using <code>AGENTS.md<\/code> as the place to encode repo layout, run instructions, build\/test\/lint commands, engineering conventions, constraints, and what \u201cdone\u201d means. (<a href=\"https:\/\/developers.openai.com\/codex\/learn\/best-practices\">OpenAI Developers<\/a>)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><code>RELEASE_READINESS.md<\/code><\/h3>\n\n\n\n<p>This is the <strong>truth document<\/strong> before deployment.<\/p>\n\n\n\n<p>It states:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>what works<\/li>\n\n\n\n<li>what does not work<\/li>\n\n\n\n<li>what is partial<\/li>\n\n\n\n<li>what was tested<\/li>\n\n\n\n<li>remaining risks<\/li>\n\n\n\n<li>release blockers<\/li>\n<\/ul>\n\n\n\n<p>This file is not mandated by the vendors. It is a high-value engineering practice.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 4 \u2014 From idea initiation to a real requirement set<\/h1>\n\n\n\n<p>This is where your original notes are already strong.<\/p>\n\n\n\n<p>You wrote:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Authentication<\/li>\n\n\n\n<li>Authorisation<\/li>\n\n\n\n<li>User Flow<\/li>\n\n\n\n<li>Admin Flow<\/li>\n\n\n\n<li>UX Spec<\/li>\n\n\n\n<li>Search \/ Filter \/ Pagination<\/li>\n\n\n\n<li>Validation<\/li>\n\n\n\n<li>Feature 1<\/li>\n\n\n\n<li>Feature 2<\/li>\n\n\n\n<li>Feature 3<\/li>\n<\/ul>\n\n\n\n<p>That is exactly the right backbone.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Step 1: Turn the idea into a requirement brief<\/h2>\n\n\n\n<p>Before any code, answer these:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Product<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What problem are we solving?<\/li>\n\n\n\n<li>Who is the primary user?<\/li>\n\n\n\n<li>What outcome should improve?<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Business<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What does success look like?<\/li>\n\n\n\n<li>What is MVP?<\/li>\n\n\n\n<li>What is explicitly out of scope?<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>How do users authenticate?<\/li>\n\n\n\n<li>How are permissions enforced?<\/li>\n\n\n\n<li>What data is sensitive?<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">UX<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What is the primary user journey?<\/li>\n\n\n\n<li>What is the admin journey?<\/li>\n\n\n\n<li>What are the loading, empty, validation, and error states?<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Data<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What entities exist?<\/li>\n\n\n\n<li>What relationships exist?<\/li>\n\n\n\n<li>What changes the database?<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Where will this run?<\/li>\n\n\n\n<li>What environments exist?<\/li>\n\n\n\n<li>What does rollback look like?<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Step 2: Ask Claude to turn the rough idea into a structured brief<\/h2>\n\n\n\n<p>Prompt:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>I want to build &#91;APP NAME].\n\nTurn this into a complete product brief.\n\nInclude:\n1. problem statement\n2. user personas\n3. user flow\n4. admin flow\n5. authentication model\n6. authorization model\n7. UX requirements\n8. search\/filter\/pagination needs\n9. validation rules\n10. feature list grouped into MVP \/ v2 \/ later\n11. non-functional requirements\n12. security concerns\n13. deployment assumptions\n14. open questions\n\nDo not write code yet.\nBe strict and identify what is missing.\n<\/code><\/pre>\n\n\n\n<p>This is discovery, not implementation.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 5 \u2014 If the project already exists, audit the repository first<\/h1>\n\n\n\n<p>Your note said:<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p>CLAUDE &#8211; READ my all of code without missing each file<\/p>\n<\/blockquote>\n\n\n\n<p>That is exactly the right instinct.<\/p>\n\n\n\n<p>But make it systematic.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">The correct repo-audit method<\/h2>\n\n\n\n<p>Do not simply say \u201cread the codebase.\u201d<\/p>\n\n\n\n<p>Instead:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>generate a tracked file list<\/li>\n\n\n\n<li>exclude generated\/build\/vendor files<\/li>\n\n\n\n<li>ask Claude to reconcile its audit against the file list<\/li>\n\n\n\n<li>force a summary of:\n<ul class=\"wp-block-list\">\n<li>working features<\/li>\n\n\n\n<li>broken features<\/li>\n\n\n\n<li>unknown features<\/li>\n\n\n\n<li>missing tests<\/li>\n\n\n\n<li>missing validation<\/li>\n\n\n\n<li>missing lint\/type rules<\/li>\n\n\n\n<li>service ownership confusion<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n<p>Claude Code is explicitly designed to search files, understand codebases, and follow project instructions from <code>CLAUDE.md<\/code>; Claude docs also recommend using concise persistent instructions and path-specific guidance where necessary. (<a href=\"https:\/\/code.claude.com\/docs\/en\/overview\">Claude<\/a>)<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Strong audit prompt for Claude<\/h2>\n\n\n\n<pre class=\"wp-block-code\"><code>Audit this repository completely.\n\nRules:\n- Start from the tracked source-file inventory.\n- Ignore generated\/build\/vendor files unless referenced by source code.\n- Account for every important source file.\n- Produce:\n\n1. top-level architecture summary\n2. directory layout\n3. service-by-service responsibility map\n4. feature inventory\n5. which features appear working\n6. which features appear broken\n7. which features are unknown or unverified\n8. missing test coverage\n9. missing validation\n10. missing lint\/type enforcement\n11. security risks\n12. API or schema mismatches\n13. priority-ranked recommendations\n\nAt the end include:\n- total reviewed files\n- excluded files\n- not reviewed files\n- confidence level by service\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 6 \u2014 Write <code>CLAUDE.md<\/code> the right way<\/h1>\n\n\n\n<p>Claude\u2019s official docs say <code>CLAUDE.md<\/code> should contain instructions that matter every session, stay concise, and be used for rules Claude cannot infer from the code alone. They also support placing <code>CLAUDE.md<\/code> files at multiple levels, where more specific local guidance takes precedence. (<a href=\"https:\/\/code.claude.com\/docs\/en\/best-practices\">Claude<\/a>)<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">What belongs in <code>CLAUDE.md<\/code><\/h2>\n\n\n\n<p>Put in:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>repo purpose<\/li>\n\n\n\n<li>service boundaries<\/li>\n\n\n\n<li>coding conventions<\/li>\n\n\n\n<li>commands to run<\/li>\n\n\n\n<li>validation expectations<\/li>\n\n\n\n<li>test expectations<\/li>\n\n\n\n<li>review checklist<\/li>\n\n\n\n<li>\u201cdo not\u201d rules<\/li>\n\n\n\n<li>definition of done<\/li>\n<\/ul>\n\n\n\n<p>Do not put in:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>giant architecture essays<\/li>\n\n\n\n<li>temporary ticket notes<\/li>\n\n\n\n<li>long one-off procedures<\/li>\n\n\n\n<li>duplicated information from README unless it changes behavior<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Root <code>CLAUDE.md<\/code> template<\/h2>\n\n\n\n<pre class=\"wp-block-code\"><code># Project: MyHospital\n\n## Purpose\nMulti-service hospital platform.\n\n## Repo layout\n- svc1: auth and identity\n- svc2: patient and appointment flows\n- svc3: billing and payments\n- svc4: admin, analytics, reporting\n\n## Global rules\n- Do not change public contracts without updating SPEC.md first.\n- Prefer small, reviewable changes.\n- Preserve backward compatibility unless SPEC.md explicitly allows breaking change.\n- Every code change must include validation, tests, and lint\/type correctness.\n- Do not bypass security checks for convenience.\n\n## Commands\n- install: &#91;command]\n- dev: &#91;command]\n- test: &#91;command]\n- lint: &#91;command]\n- typecheck: &#91;command]\n- integration-test: &#91;command]\n\n## Security rules\n- All protected endpoints require server-side authorization checks.\n- Never trust client-provided roles.\n- Validate all input at the request boundary.\n- Sensitive data must not be logged.\n\n## Output format for implementation tasks\nFor each task, report:\n1. files changed\n2. what changed\n3. tests added or updated\n4. risk introduced\n5. follow-up work\n\n## Definition of done\nA task is done only if:\n- implementation is complete\n- validation is enforced\n- tests pass\n- lint\/typecheck pass\n- affected user\/admin flows still work\n- SPEC.md remains accurate\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">Service-level <code>CLAUDE.md<\/code><\/h2>\n\n\n\n<p>For <code>svc1\/CLAUDE.md<\/code>:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># svc1: auth and identity\n\n## Responsibility\nAuthentication, authorization, session handling, roles, permissions.\n\n## Must not break\n- login\n- logout\n- session renewal\n- password reset\n- role enforcement\n- unauthorized access handling\n\n## Required tests\n- auth success\n- auth failure\n- invalid credentials\n- expired token\n- insufficient permissions\n- session timeout behavior\n\n## Required validation\n- email\n- password policy\n- token format\n- permission checks\n<\/code><\/pre>\n\n\n\n<p>For <code>svc2\/CLAUDE.md<\/code>:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># svc2: patient and appointment workflows\n\n## Responsibility\nPatient search, appointment booking, rescheduling, cancellation, provider assignment.\n\n## Must not break\n- patient search\n- appointment creation\n- reschedule flow\n- cancellation flow\n- pagination and filtering\n- validation feedback\n\n## Required validations\n- required fields\n- date\/time validity\n- provider availability\n- duplicate booking prevention\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 7 \u2014 Write <code>AGENTS.md<\/code> for Codex<\/h1>\n\n\n\n<p>OpenAI\u2019s docs position <code>AGENTS.md<\/code> as the durable place for Codex repo instructions, including repo layout, commands, constraints, and what \u201cdone\u201d means. They also note that <code>\/init<\/code> can scaffold a starter <code>AGENTS.md<\/code>, but that you should refine it to match real team workflows. (<a href=\"https:\/\/developers.openai.com\/codex\/learn\/best-practices\">OpenAI Developers<\/a>)<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><code>AGENTS.md<\/code> template<\/h2>\n\n\n\n<pre class=\"wp-block-code\"><code># AGENTS.md\n\n## Repo overview\nMyHospital is a multi-service application with service boundaries that must be preserved.\n\n## Services\n- svc1: auth and authorization\n- svc2: appointments and patient flows\n- svc3: billing and invoicing\n- svc4: admin dashboards and reporting\n\n## Commands\n- install: &#91;command]\n- dev: &#91;command]\n- unit-tests: &#91;command]\n- integration-tests: &#91;command]\n- lint: &#91;command]\n- typecheck: &#91;command]\n\n## Engineering conventions\n- Prefer minimal diffs.\n- Reuse existing patterns before introducing new abstractions.\n- Do not rename files or functions unless necessary.\n- Keep API changes backward compatible unless SPEC.md says otherwise.\n\n## Constraints\n- Do not change infra or deployment manifests unless task explicitly asks.\n- Do not touch unrelated services.\n- Do not skip tests.\n- Do not leave TODOs in completed work unless listed in follow-up.\n\n## Validation rules\n- Implement request validation and business-rule validation.\n- Add negative test cases for invalid input and permission failures.\n\n## Done means\n- code compiles\n- tests pass\n- lint\/typecheck pass\n- changed behavior is verified\n- risk is stated clearly\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 8 \u2014 Create <code>SPEC.md<\/code> before you write code<\/h1>\n\n\n\n<p>This is the center of the whole workflow.<\/p>\n\n\n\n<p>If <code>SPEC.md<\/code> is weak, the whole build will drift.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">What <code>SPEC.md<\/code> must contain<\/h2>\n\n\n\n<pre class=\"wp-block-code\"><code># SPEC: &#91;Feature Name]\n\n## Objective\nWhat are we building and why?\n\n## Scope\nIncluded:\nExcluded:\n\n## Users\n- user\n- admin\n- support\/internal ops\n\n## Functional requirements\n1. Authentication\n2. Authorization\n3. User flow\n4. Admin flow\n5. Search\/filter\/pagination\n6. Validation\n7. Feature 1\n8. Feature 2\n9. Feature 3\n\n## UX requirements\n- loading states\n- empty states\n- error states\n- unauthorized states\n- form validation states\n\n## Data model impact\n- tables\n- fields\n- migrations\n- compatibility concerns\n\n## API\/contracts\n- endpoints\n- request schema\n- response schema\n- failure modes\n\n## Security\n- role rules\n- audit logging\n- sensitive data handling\n\n## Test plan\n- unit\n- integration\n- end-to-end\n- negative cases\n- regression cases\n\n## Rollout plan\n- dev\n- staging\n- production\n\n## Rollback plan\n- revert method\n- migration reversal or mitigation\n- feature flag fallback\n\n## Definition of done\n- implementation complete\n- tests passing\n- lint\/typecheck passing\n- staging validated\n- docs updated\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 9 \u2014 The approval gate: \u201cClaude yes\/no\u201d<\/h1>\n\n\n\n<p>This part from your notes is gold.<\/p>\n\n\n\n<p>After <code>SPEC.md<\/code> is written, stop.<\/p>\n\n\n\n<p>Do <strong>not<\/strong> code yet.<\/p>\n\n\n\n<p>Ask Claude for a hard gate.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Prompt<\/h2>\n\n\n\n<pre class=\"wp-block-code\"><code>Review SPEC.md and repository context.\n\nAnswer only in this format:\n\nREADY: yes\/no\n\nIf no, list only blockers.\n\nCheck for:\n- missing requirements\n- missing edge cases\n- missing validation rules\n- missing security rules\n- missing error states\n- missing test cases\n- unclear service ownership\n- missing deployment or rollback concerns\n<\/code><\/pre>\n\n\n\n<p>If Claude says <strong>READY: no<\/strong>, fix the blockers first.<\/p>\n\n\n\n<p>That one step prevents a huge amount of bad implementation work.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 10 \u2014 Break implementation into slices<\/h1>\n\n\n\n<p>This is where Codex becomes powerful.<\/p>\n\n\n\n<p>OpenAI\u2019s prompting guidance says Codex performs better when tasks are small, focused, and verifiable, and when prompts include reproduction steps, validation steps, and lint\/pre-commit checks. (<a href=\"https:\/\/developers.openai.com\/codex\/prompting\">OpenAI Developers<\/a>)<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Never do this<\/h2>\n\n\n\n<pre class=\"wp-block-code\"><code>Build the whole MyHospital app end to end.\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">Always do this instead<\/h2>\n\n\n\n<p>Break the work into slices like:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>auth foundation<\/li>\n\n\n\n<li>permission model<\/li>\n\n\n\n<li>appointment data model<\/li>\n\n\n\n<li>appointment search\/filter\/pagination<\/li>\n\n\n\n<li>booking UX<\/li>\n\n\n\n<li>admin approval UX<\/li>\n\n\n\n<li>billing integration<\/li>\n\n\n\n<li>tests<\/li>\n\n\n\n<li>observability and release prep<\/li>\n<\/ol>\n\n\n\n<p>Then implement one slice at a time.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Example slice prompt for Codex<\/h2>\n\n\n\n<pre class=\"wp-block-code\"><code>Implement SPEC section: Appointment Search in svc2.\n\nScope:\n- touch only svc2 and shared contracts if needed\n- do not modify svc1 auth logic\n- do not modify billing\n- preserve existing API style and patterns\n\nRequirements:\n- search by patient name, doctor, status, date range\n- pagination\n- sorting\n- input validation\n- unauthorized access checks\n- empty state handling\n- error handling\n\nRequired verification:\n- add or update unit tests\n- add integration tests for search and pagination\n- run lint\n- run typecheck\n- run affected test suites\n\nFinal output must include:\n1. files changed\n2. commands run\n3. test results\n4. known risks\n5. follow-up items\n<\/code><\/pre>\n\n\n\n<p>That is the level of prompt quality that makes Codex reliable.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 11 \u2014 The right implementation loop<\/h1>\n\n\n\n<p>Here is the exact loop you should run.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Loop A \u2014 Claude prepares the work<\/h2>\n\n\n\n<p>Claude:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>understands the repo<\/li>\n\n\n\n<li>maps the target service<\/li>\n\n\n\n<li>drafts or refines the spec<\/li>\n\n\n\n<li>identifies risks and missing items<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Loop B \u2014 Codex implements the slice<\/h2>\n\n\n\n<p>Codex:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>edits the right files<\/li>\n\n\n\n<li>adds tests<\/li>\n\n\n\n<li>runs commands<\/li>\n\n\n\n<li>reports results<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Loop C \u2014 Claude reviews the slice<\/h2>\n\n\n\n<p>Claude:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>compares implementation against <code>SPEC.md<\/code><\/li>\n\n\n\n<li>checks whether validation is real<\/li>\n\n\n\n<li>checks whether user and admin flows still work<\/li>\n\n\n\n<li>checks for missing edge cases<\/li>\n\n\n\n<li>checks for architecture drift<\/li>\n<\/ul>\n\n\n\n<p>Repeat until the release is complete.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 12 \u2014 What \u201cmissing\u201d really means<\/h1>\n\n\n\n<p>You wrote:<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p>What is missing?<br>test cases<br>validation<br>lining<br>which feature is working<br>which feature is not<\/p>\n<\/blockquote>\n\n\n\n<p>I assume \u201clining\u201d means <strong>linting<\/strong>.<\/p>\n\n\n\n<p>This should become a standing checklist.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">The Production Readiness Checklist<\/h2>\n\n\n\n<p>For every feature, always ask:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1. Is the feature functionally implemented?<\/h3>\n\n\n\n<p>Not \u201cdid code change?\u201d<br>But \u201ccan the user complete the flow?\u201d<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">2. Is validation complete?<\/h3>\n\n\n\n<p>At least two levels:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>request or schema validation<\/li>\n\n\n\n<li>business-rule validation<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3. Are authorization checks enforced server-side?<\/h3>\n\n\n\n<p>Not only hidden in the UI.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">4. Are negative cases tested?<\/h3>\n\n\n\n<p>Examples:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>invalid input<\/li>\n\n\n\n<li>expired token<\/li>\n\n\n\n<li>missing permissions<\/li>\n\n\n\n<li>duplicate operations<\/li>\n\n\n\n<li>empty search results<\/li>\n\n\n\n<li>invalid pagination params<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5. Are lint and type checks green?<\/h3>\n\n\n\n<p>This is the minimum quality floor.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">6. Is the status of the feature known?<\/h3>\n\n\n\n<p>Each feature must be labeled:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>working<\/li>\n\n\n\n<li>partial<\/li>\n\n\n\n<li>broken<\/li>\n\n\n\n<li>unverified<\/li>\n<\/ul>\n\n\n\n<p>That is how adults ship software.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 13 \u2014 Create <code>RELEASE_READINESS.md<\/code><\/h1>\n\n\n\n<p>Use this before staging and before production.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># RELEASE_READINESS\n\n## Release name<\/code><\/pre>\n\n\n<p>[release name]<\/p>\n\n\n\n<p>## Working &#8211; feature A &#8211; feature B &#8211; feature C ## Partial &#8211; feature D: works except [case] ## Broken &#8211; feature E: blocked by [reason] ## Unverified &#8211; feature F ## Validation status &#8211; request validation: complete \/ partial \/ missing &#8211; business validation: complete \/ partial \/ missing ## Test status &#8211; unit: [status] &#8211; integration: [status] &#8211; e2e: [status] ## Quality checks &#8211; lint: pass\/fail &#8211; typecheck: pass\/fail &#8211; security review: done\/pending ## Known risks &#8211; high &#8211; medium &#8211; low ## Deployment blockers &#8211; [list]<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 14 \u2014 Testing strategy that actually works<\/h1>\n\n\n\n<p>Do not wait until the end for testing.<\/p>\n\n\n\n<p>Testing should exist at every layer.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Unit tests<\/h2>\n\n\n\n<p>Use for:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>pure logic<\/li>\n\n\n\n<li>validators<\/li>\n\n\n\n<li>transformers<\/li>\n\n\n\n<li>helpers<\/li>\n\n\n\n<li>permission rules<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Integration tests<\/h2>\n\n\n\n<p>Use for:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>API routes<\/li>\n\n\n\n<li>DB interactions<\/li>\n\n\n\n<li>service contracts<\/li>\n\n\n\n<li>auth middleware<\/li>\n\n\n\n<li>pagination and filtering behavior<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">End-to-end tests<\/h2>\n\n\n\n<p>Use for:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>login flow<\/li>\n\n\n\n<li>admin approval flow<\/li>\n\n\n\n<li>key user journey<\/li>\n\n\n\n<li>one or two critical revenue or compliance flows<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Negative tests<\/h2>\n\n\n\n<p>These are mandatory:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>malformed requests<\/li>\n\n\n\n<li>unauthorized access<\/li>\n\n\n\n<li>forbidden actions<\/li>\n\n\n\n<li>invalid filters<\/li>\n\n\n\n<li>missing required fields<\/li>\n\n\n\n<li>duplicate submissions<\/li>\n\n\n\n<li>bad state transitions<\/li>\n<\/ul>\n\n\n\n<p>Official Codex guidance specifically recommends asking it to write or update tests, run relevant checks, and review the work rather than stopping at code generation. (<a href=\"https:\/\/developers.openai.com\/codex\/learn\/best-practices\">OpenAI Developers<\/a>)<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 15 \u2014 The review phase: Claude as auditor<\/h1>\n\n\n\n<p>Once Codex finishes a slice, ask Claude to review it.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Prompt<\/h2>\n\n\n\n<pre class=\"wp-block-code\"><code>Review the implementation against SPEC.md.\n\nClassify findings as:\n- blocker\n- major\n- minor\n- follow-up\n\nCheck:\n- feature completeness\n- missing edge cases\n- missing validation\n- missing auth\/authz checks\n- UX-state coverage\n- pagination\/search\/filter correctness\n- schema\/API mismatches\n- regression risk\n- docs drift\n<\/code><\/pre>\n\n\n\n<p>This is where Claude shines.<\/p>\n\n\n\n<p>Claude is especially strong at asking:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>\u201cDid you really cover the whole flow?\u201d<\/li>\n\n\n\n<li>\u201cDoes this contradict the spec?\u201d<\/li>\n\n\n\n<li>\u201cIs this secure?\u201d<\/li>\n\n\n\n<li>\u201cWhat did we forget?\u201d<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 16 \u2014 Staging before production<\/h1>\n\n\n\n<p>Do not let AI-generated confidence replace release discipline.<\/p>\n\n\n\n<p>Before production:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>deploy to staging<\/li>\n\n\n\n<li>run smoke tests<\/li>\n\n\n\n<li>verify login\/authz<\/li>\n\n\n\n<li>verify primary user flow<\/li>\n\n\n\n<li>verify admin flow<\/li>\n\n\n\n<li>verify search\/filter\/pagination with realistic data<\/li>\n\n\n\n<li>verify migration compatibility<\/li>\n\n\n\n<li>verify logs and alerts<\/li>\n\n\n\n<li>verify rollback<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">Staging checklist<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Does login still work?<\/li>\n\n\n\n<li>Does role enforcement still work?<\/li>\n\n\n\n<li>Are old records still readable?<\/li>\n\n\n\n<li>Does pagination behave at scale?<\/li>\n\n\n\n<li>Do validation messages make sense?<\/li>\n\n\n\n<li>Are empty states and error states usable?<\/li>\n\n\n\n<li>Do audit logs contain what you need?<\/li>\n\n\n\n<li>Is performance acceptable?<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 17 \u2014 Production deployment<\/h1>\n\n\n\n<p>Production should be boring.<\/p>\n\n\n\n<p>If it feels exciting, the process is wrong.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Production release sequence<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li>freeze the release branch<\/li>\n\n\n\n<li>confirm CI is green<\/li>\n\n\n\n<li>confirm migrations<\/li>\n\n\n\n<li>confirm environment variables<\/li>\n\n\n\n<li>deploy lowest-risk components first if possible<\/li>\n\n\n\n<li>run health checks<\/li>\n\n\n\n<li>smoke test critical journeys<\/li>\n\n\n\n<li>monitor logs, errors, metrics<\/li>\n\n\n\n<li>keep rollback ready<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">The production questions you must answer in writing<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What exactly changed?<\/li>\n\n\n\n<li>What can fail?<\/li>\n\n\n\n<li>How will we detect failure?<\/li>\n\n\n\n<li>How fast can we rollback?<\/li>\n\n\n\n<li>Does rollback require DB mitigation?<\/li>\n\n\n\n<li>Which flows must be tested immediately after deploy?<\/li>\n<\/ul>\n\n\n\n<p>That belongs either in <code>SPEC.md<\/code> or your deployment runbook.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 18 \u2014 Post-production hardening<\/h1>\n\n\n\n<p>A release is not done when it reaches production.<\/p>\n\n\n\n<p>It is done when the first production learning cycle is complete.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">After deploy, ask Claude:<\/h2>\n\n\n\n<pre class=\"wp-block-code\"><code>We deployed &#91;release name].\n\nAnalyze:\n- likely failure modes\n- weak validation areas\n- missing monitors\n- missing alerts\n- rollback risks\n- assumptions that were not actually verified\n\nProduce a hardening backlog ranked by risk.\n<\/code><\/pre>\n\n\n\n<p>This turns production into learning, not panic.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 19 \u2014 Your 10-hour operating model<\/h1>\n\n\n\n<p>You wrote:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>1 PM --&gt; 11 PM\nEffective - 2 Hours\n30 mins Step 1 Requirement\n<\/code><\/pre>\n\n\n\n<p>That can become a superb delivery cadence.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">A serious 10-hour build day<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">1:00 PM \u2013 1:30 PM<\/h3>\n\n\n\n<p>Requirements and scope lock<\/p>\n\n\n\n<p>Output:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>feature brief<\/li>\n\n\n\n<li>user flow<\/li>\n\n\n\n<li>admin flow<\/li>\n\n\n\n<li>auth\/authz rules<\/li>\n\n\n\n<li>search\/filter\/pagination rules<\/li>\n\n\n\n<li>validation rules<\/li>\n\n\n\n<li>MVP scope<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">1:30 PM \u2013 2:15 PM<\/h3>\n\n\n\n<p>Claude repo audit or architecture design<\/p>\n\n\n\n<p>Output:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>repo\/service map<\/li>\n\n\n\n<li>risk map<\/li>\n\n\n\n<li>identified gaps<\/li>\n\n\n\n<li>what already exists<\/li>\n\n\n\n<li>what must not break<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2:15 PM \u2013 3:00 PM<\/h3>\n\n\n\n<p>Write control docs<\/p>\n\n\n\n<p>Output:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>CLAUDE.md<\/code><\/li>\n\n\n\n<li><code>AGENTS.md<\/code><\/li>\n\n\n\n<li><code>SPEC.md<\/code><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3:00 PM \u2013 3:15 PM<\/h3>\n\n\n\n<p>Claude readiness gate<\/p>\n\n\n\n<p>Output:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>READY: yes\/no<\/code><\/li>\n\n\n\n<li>blocker list if no<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3:15 PM \u2013 6:00 PM<\/h3>\n\n\n\n<p>Codex implements slices 1\u20133<\/p>\n\n\n\n<p>Examples:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>auth improvements<\/li>\n\n\n\n<li>data model<\/li>\n\n\n\n<li>first API or first UI flow<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6:00 PM \u2013 7:00 PM<\/h3>\n\n\n\n<p>Claude review and gap fixing<\/p>\n\n\n\n<p>Output:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>missing tests<\/li>\n\n\n\n<li>missing validation<\/li>\n\n\n\n<li>broken user\/admin flows<\/li>\n\n\n\n<li>major risks<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7:00 PM \u2013 9:00 PM<\/h3>\n\n\n\n<p>Codex implements slices 4\u20136<\/p>\n\n\n\n<p>Examples:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>pagination\/filtering<\/li>\n\n\n\n<li>admin flow<\/li>\n\n\n\n<li>edge-case handling<\/li>\n\n\n\n<li>tests and lint\/type cleanup<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9:00 PM \u2013 10:00 PM<\/h3>\n\n\n\n<p>Staging prep and release-readiness report<\/p>\n\n\n\n<p>Output:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>RELEASE_READINESS.md<\/code><\/li>\n\n\n\n<li>known risks<\/li>\n\n\n\n<li>blockers<\/li>\n\n\n\n<li>staging checklist<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10:00 PM \u2013 11:00 PM<\/h3>\n\n\n\n<p>Staging validation and production decision<\/p>\n\n\n\n<p>Output:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>go \/ no-go<\/li>\n\n\n\n<li>rollback plan<\/li>\n\n\n\n<li>post-deploy watchlist<\/li>\n<\/ul>\n\n\n\n<p>Your \u201ceffective 2 hours\u201d are the decisions:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>scope<\/li>\n\n\n\n<li>tradeoffs<\/li>\n\n\n\n<li>final review<\/li>\n\n\n\n<li>go\/no-go<\/li>\n<\/ul>\n\n\n\n<p>That is exactly where humans should spend time.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 20 \u2014 The single biggest mistake to avoid<\/h1>\n\n\n\n<p>Do <strong>not<\/strong> run Claude and Codex live on the same files at the same time without isolation.<\/p>\n\n\n\n<p>Codex guidance explicitly warns against running live threads on the same files without using git worktrees. (<a href=\"https:\/\/developers.openai.com\/codex\/learn\/best-practices\">OpenAI Developers<\/a>)<\/p>\n\n\n\n<p>So use one of these models:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Safe model A<\/h3>\n\n\n\n<p>Claude plans, Codex edits, Claude reviews after<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Safe model B<\/h3>\n\n\n\n<p>Claude works in one branch\/worktree, Codex in another<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Safe model C<\/h3>\n\n\n\n<p>Claude only reads\/reviews, Codex only writes<\/p>\n\n\n\n<p>This one rule will save you a lot of pain.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 21 \u2014 The best prompt library<\/h1>\n\n\n\n<h2 class=\"wp-block-heading\">Prompt 1 \u2014 Claude requirement discovery<\/h2>\n\n\n\n<pre class=\"wp-block-code\"><code>You are the product architect for this application.\n\nTurn my rough idea into a production-grade feature brief.\nBe strict.\nDo not write code.\n\nInclude:\n- problem\n- users\n- user flow\n- admin flow\n- auth\/authz\n- UX states\n- validation\n- search\/filter\/pagination\n- API assumptions\n- data model assumptions\n- edge cases\n- security concerns\n- rollout and rollback concerns\n- what is missing\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">Prompt 2 \u2014 Claude repo audit<\/h2>\n\n\n\n<pre class=\"wp-block-code\"><code>Audit this repository completely.\n\nI want:\n- architecture summary\n- directory and service map\n- feature inventory\n- working vs broken vs unverified features\n- missing test cases\n- missing validation\n- lint\/type issues\n- risky modules\n- service ownership confusion\n- recommended next actions\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">Prompt 3 \u2014 Claude writes <code>SPEC.md<\/code><\/h2>\n\n\n\n<pre class=\"wp-block-code\"><code>Write SPEC.md for this feature.\n\nUse these sections:\n- objective\n- scope\n- users\n- functional requirements\n- UX requirements\n- validation\n- security\n- API\/contracts\n- data model impact\n- test plan\n- rollout plan\n- rollback plan\n- definition of done\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">Prompt 4 \u2014 Claude readiness gate<\/h2>\n\n\n\n<pre class=\"wp-block-code\"><code>Review SPEC.md and answer only:\n\nREADY: yes\/no\n\nIf no, list blockers only.\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">Prompt 5 \u2014 Codex implementation prompt<\/h2>\n\n\n\n<pre class=\"wp-block-code\"><code>Implement the approved SPEC section for &#91;feature].\n\nScope:\n- allowed directories: &#91;...]\n- forbidden directories: &#91;...]\n\nRequirements:\n- &#91;...]\n- &#91;...]\n- &#91;...]\n\nVerification:\n- add\/update tests\n- run lint\n- run typecheck\n- run affected tests\n\nFinal report:\n1. files changed\n2. commands run\n3. test results\n4. known risks\n5. follow-up items\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">Prompt 6 \u2014 Claude review prompt<\/h2>\n\n\n\n<pre class=\"wp-block-code\"><code>Review this implementation against SPEC.md.\n\nClassify issues as:\n- blocker\n- major\n- minor\n- follow-up\n\nCheck:\n- completeness\n- validation\n- auth\/authz\n- search\/filter\/pagination\n- user flow\n- admin flow\n- regression risk\n- docs drift\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 22 \u2014 How this applies specifically to <code>Myhospital<\/code><\/h1>\n\n\n\n<p>Your directory layout example was:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Myhospital\n  svc1\n  svc2\n  svc2\n  svc3\n<\/code><\/pre>\n\n\n\n<p>I assume one <code>svc2<\/code> is a typo. A better normalized version:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Myhospital\/\n  svc1-auth\/\n  svc2-patients\/\n  svc3-appointments\/\n  svc4-billing\/\n  svc5-admin\/\n<\/code><\/pre>\n\n\n\n<p>If renaming is not possible, keep the existing names but define ownership clearly in docs.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">A clean ownership model<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\"><code>svc1<\/code><\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>authentication<\/li>\n\n\n\n<li>authorization<\/li>\n\n\n\n<li>sessions<\/li>\n\n\n\n<li>roles<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\"><code>svc2<\/code><\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>patient records<\/li>\n\n\n\n<li>patient search<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\"><code>svc3<\/code><\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>appointments<\/li>\n\n\n\n<li>schedules<\/li>\n\n\n\n<li>rescheduling<\/li>\n\n\n\n<li>cancellation<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\"><code>svc4<\/code><\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>billing<\/li>\n\n\n\n<li>invoices<\/li>\n\n\n\n<li>payments<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\"><code>svc5<\/code><\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>admin dashboards<\/li>\n\n\n\n<li>reports<\/li>\n\n\n\n<li>audit tools<\/li>\n<\/ul>\n\n\n\n<p>Now every feature can be mapped clearly.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 23 \u2014 The golden rules for production-grade AI development<\/h1>\n\n\n\n<p>Here are the rules I would insist on for any serious team:<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Rule 1<\/h2>\n\n\n\n<p>No implementation before <code>SPEC.md<\/code>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Rule 2<\/h2>\n\n\n\n<p>No \u201cdone\u201d without tests, validation, lint, and type checks.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Rule 3<\/h2>\n\n\n\n<p>No production deploy without a rollback plan.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Rule 4<\/h2>\n\n\n\n<p>No large prompts for large features.<br>Split into slices.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Rule 5<\/h2>\n\n\n\n<p>Claude reviews Codex output before acceptance.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Rule 6<\/h2>\n\n\n\n<p>Every feature must be labeled:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>working<\/li>\n\n\n\n<li>partial<\/li>\n\n\n\n<li>broken<\/li>\n\n\n\n<li>unverified<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Rule 7<\/h2>\n\n\n\n<p>Never trust UI-only validation or UI-only permissions.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Rule 8<\/h2>\n\n\n\n<p>Use persistent repo instructions.<br>Claude docs recommend <code>CLAUDE.md<\/code>; Codex docs recommend <code>AGENTS.md<\/code>. (<a href=\"https:\/\/code.claude.com\/docs\/en\/best-practices\">Claude<\/a>)<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Rule 9<\/h2>\n\n\n\n<p>Keep those instruction files concise and practical.<br>Both Claude and Codex docs emphasize that durable guidance should stay short, specific, and based on real repeated friction rather than vague rule dumps. (<a href=\"https:\/\/code.claude.com\/docs\/en\/best-practices\">Claude<\/a>)<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Rule 10<\/h2>\n\n\n\n<p>Don\u2019t automate a workflow until it works manually.<br>Codex best practices explicitly recommend turning repeated stable work into skills first and automating only once the process is predictable. (<a href=\"https:\/\/developers.openai.com\/codex\/learn\/best-practices\">OpenAI Developers<\/a>)<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Final takeaway<\/h1>\n\n\n\n<p>The best way to build applications with Claude and Codex is not:<\/p>\n\n\n\n<p>\u201cAsk both to build the app.\u201d<\/p>\n\n\n\n<p>It is:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Claude turns ambiguity into a clear plan<\/strong><\/li>\n\n\n\n<li><strong>Claude audits the codebase and identifies gaps<\/strong><\/li>\n\n\n\n<li><strong>You write durable repo guidance<\/strong><\/li>\n\n\n\n<li><strong>You lock the feature contract in <code>SPEC.md<\/code><\/strong><\/li>\n\n\n\n<li><strong>Claude gives a strict readiness gate<\/strong><\/li>\n\n\n\n<li><strong>Codex implements one approved slice at a time<\/strong><\/li>\n\n\n\n<li><strong>Codex runs tests, lint, and validation<\/strong><\/li>\n\n\n\n<li><strong>Claude audits the implementation<\/strong><\/li>\n\n\n\n<li><strong>You produce a release-readiness report<\/strong><\/li>\n\n\n\n<li><strong>You deploy through staging to production with rollback ready<\/strong><\/li>\n\n\n\n<li><strong>Claude creates the hardening backlog after release<\/strong><\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"<p>What you are really building You are not just building an app. You are building a repeatable engineering system where: [&hellip;]<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-2926","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/aiopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/2926","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/aiopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/aiopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/aiopsschool.com\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/aiopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=2926"}],"version-history":[{"count":1,"href":"https:\/\/aiopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/2926\/revisions"}],"predecessor-version":[{"id":2927,"href":"https:\/\/aiopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/2926\/revisions\/2927"}],"wp:attachment":[{"href":"https:\/\/aiopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=2926"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/aiopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=2926"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/aiopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=2926"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}