Codex skills that
finish the job.

Codex maps your monolith's real dependency graph and git co-change, drafts a module map with public APIs, allowed dependencies and table ownership, baselines existing violations so CI fails only on new ones, removes violations seam by seam in small PRs, optionally extracts a first service behind a flag, and reports coupling before and after.

You end up with

• Module map and ADR: owners, public APIs, allowed dependencies and a table-ownership matrix
• CI boundary check with a shrinking baseline (native tool or bundled checker)
• Seam-by-seam PRs that remove cycles and private imports without behaviour changes
• Optional first service behind a facade with an in-process rollback flag
• Before/after report: cross-module edges, cycles, violations, instability per module

Proof

modgraph compare output on the same module map for the baseline and final commits, the CI run that failed on a deliberate violation, and a seam log with violation counts and PR links.

Try

• $monolith-to-modules-extraction Our Django monolith is a big ball of mud; turn it into enforced modules
• $monolith-to-modules-extraction Measure coupling in this TypeScript monorepo and add boundary checks to CI without breaking everyone
• $monolith-to-modules-extraction We want to extract billing into a service; get the module clean first and plan the extraction

Codex pins down which ceiling you are actually hitting, fits a growth model to your size history, works through cheaper alternatives (tuning, pooling, replicas, archiving, partitioning, functional split), scores candidate shard keys against your real pg_stat_statements or performance_schema workload, inventories every cross-shard query and transaction, and writes a decision document: do not shard, prepare, or shard.

You end up with

• A growth projection with both linear and exponential fits, R-squared and crossing dates for your real limits
• An alternatives table with a verdict and evidence for each cheaper option
• A shard-key scorecard weighted by calls and execution time, plus skew numbers per candidate
• A cross-shard query and transaction inventory with a resolution per item
• A decision document with triggers to revisit and no-regret preparation work

Proof

Scorecard and growth-model output generated from your exported workload and size history, saved alongside the skew query results and a hand-reviewed sample of classified statements.

Try

• $database-sharding-readiness Our Postgres primary is at 6 TB and growing. Do we need to shard, and on what key?
• $database-sharding-readiness Evaluate account_id vs user_id as a shard key using our real query workload
• $database-sharding-readiness Should we move to Citus or Vitess, or can we hold off?

Codex runs a read-only preflight (replica identity, extensions, collations, reg* types, large objects), picks logical replication or pg_upgrade --link with you, rehearses the full cutover on a clone with a write probe running, writes a PgBouncer cutover runbook with abort rules and reverse-replication rollback, executes it with your confirmation, then verifies no acknowledged write was lost.

You end up with

• Preflight report per database with blockers, warnings and the fix for each
• Rehearsed cutover runbook with owners, expected outputs, abort criteria and a tested rollback
• Measured write pause from a probe that writes through your pooler during the cutover
• Lost-write check: every acknowledged probe write confirmed present on the new cluster
• Cutover evidence report with before/after query timings and the rollback retirement record

Proof

Probe log analysis showing the longest gap between committed writes in rehearsal and production, a verify run listing zero missing acknowledged writes, and before/after top-query timings from pg_stat_statements.

Try

• $zero-downtime-postgres-major-upgrade Plan our Postgres 13 to 17 upgrade with a write pause under 10 seconds
• $zero-downtime-postgres-major-upgrade We are on RDS Postgres 12; rehearse a blue/green major upgrade and give me the cutover runbook
• $zero-downtime-postgres-major-upgrade Check whether our database can use logical replication for a major version upgrade

Codex measures JS vs TS coverage, builds the import graph and orders files into leaf-first rename waves (cycles converted together), sets up a mixed allowJs toolchain with tsc in CI, bridges slow-moving files with JSDoc, renames and types each wave in separate commits, resolves types for untyped dependencies, enforces an any and suppression budget that only goes down, and reports coverage per wave.

You end up with

• Import-graph wave plan with cycle groups and generated git mv scripts per wave
• Mixed JS/TS toolchain with tsc --noEmit in CI and no change to build output
• Rename-then-type PRs per wave, with dependency types resolved honestly
• Explicit-any and suppression budget enforced in CI and lowered after each wave
• Coverage-of-types report per wave and a final tsconfig with noImplicitAny on

Proof

Per-wave coverage snapshots from the bundled script (files and lines in TS, explicit any, suppressions), the budget history, and the CI run that failed on a deliberate type error.

Try

• $javascript-to-typescript-migration Migrate our Express API from JavaScript to TypeScript without freezing features
• $javascript-to-typescript-migration Where should we start converting this React app to TypeScript?
• $javascript-to-typescript-migration Set up an any-budget and coverage report for our TS migration

Codex inventories every Pages Router route with its render mode and migration risks, captures a baseline parity snapshot of production, builds root layout and providers, then migrates one route per PR using a data-fetching and metadata translation table, decides the client/server boundary and caching per route, and proves each route with an HTTP and SEO parity report.

You end up with

• Route tracker with render mode, fallback, revalidate and effort score per page
• Root layout, providers and metadataBase set up without moving any route
• One PR per route with explicit caching and client/server boundary decisions
• Per-route parity reports: status, redirects, canonical, robots, hreflang, title, JSON-LD
• Final full-site parity run and sitemap URL-set comparison

Proof

route_parity.py reports per route comparing production with the preview deployment (default and Googlebot user agents), a self-parity baseline proving the check is stable, and the sitemap URL-set diff.

Try

• $nextjs-app-router-migration Migrate our Next.js pages/ directory to the App Router without losing SEO
• $nextjs-app-router-migration How do we translate getServerSideProps and getStaticPaths for this route?
• $nextjs-app-router-migration Check that our App Router preview serves the same status codes and canonicals as production

Codex finds how your API is versioned, writes a versioning policy, measures who still calls the old version from 30+ days of access logs, ships RFC 9745 Deprecation and RFC 8594 Sunset headers with tests, drafts the migration guide and consumer emails, runs flag-gated brownouts, and switches off only when measured traffic is under an agreed threshold.

You end up with

• A written versioning policy with explicit breaking-change rules, support window and notice period
• A per-consumer CSV of old-version traffic with owners, last-seen dates and top endpoints
• Deprecation, Sunset and Link headers in production code, enforced by tests and marked in OpenAPI
• Migration guide, changelog entry and personalised announcement drafts for each top consumer
• A brownout calendar behind a kill-switch flag and a filled retirement report

Proof

Baseline vs latest consumer traffic tables from the same log query, curl output showing live headers, brownout logs with consumers discovered, and the switch-off threshold next to the measured value.

Try

• $api-versioning-deprecation-program We need to retire API v1 by the end of the year. Who is still using it and what is the plan?
• $api-versioning-deprecation-program Add Deprecation and Sunset headers to our old endpoints and write the migration guide
• $api-versioning-deprecation-program Set up brownouts for v1 and track which customers have migrated

Codex inventories every legacy React pattern per file, writes render-parity RTL tests against the current class components, runs the official codemods per batch, converts the rest by hand in risk-ordered batches using a pattern catalog, removes Enzyme, adds a CI ratchet and lint rules, and reports the burn-down with PR links per batch.

You end up with

• Per-file inventory of class components, legacy context, string refs, findDOMNode, Enzyme and more
• Render-parity RTL tests written before each conversion and passing unchanged after it
• Risk-ordered conversion batches: codemod output and hand edits in separate commits
• Enzyme removed, CI ratchet and ESLint rules so legacy patterns cannot return
• Burn-down report with codemod versions, batch PRs and the remaining exceptions

Proof

Burn-down table from the bundled scanner at the start and end commits, parity snapshot tests committed before each conversion, and test counts before and after from the runner summary.

Try

• $legacy-react-modernization Get rid of class components and Enzyme in our React app without a feature freeze
• $legacy-react-modernization What blocks us from upgrading to React 19, and can you clear it batch by batch?
• $legacy-react-modernization Migrate our Enzyme tests to React Testing Library with proof nothing changed

Codex sizes every strict-family flag, adds a strict tsconfig checked in CI against a committed baseline so only new errors fail, locks directories as they reach zero, fixes errors in small PRs using a catalog of correct fixes per TS error code, tracks any/non-null/ts-ignore counts so fixes are real, charts the burn-down, and flips your main tsconfig at the end.

You end up with

• Per-flag error sizing and a staged plan for strict and noUncheckedIndexedAccess
• CI ratchet that fails only on new errors and on errors in locked directories
• Small fix PRs that lower a committed baseline, guided by a fix-pattern catalog
• Burn-down CSV and SVG chart, by TS code and by directory
• Main tsconfig flipped to strict with tsc --noEmit passing in CI

Proof

Burn-down from the first baseline to zero produced by the bundled ratchet script, escape-hatch counts (any, non-null assertions, ts-ignore) before and after, and the CI run that failed on a deliberate regression.

Try

• $typescript-strict-rollout Turn on strict mode in our TypeScript monorepo without blocking everyone
• $typescript-strict-rollout We have 4,000 strictNullChecks errors; set up a baseline and burn them down
• $typescript-strict-rollout Add noUncheckedIndexedAccess with a ratchet and a burn-down chart

Codex audits your lockfile and the target interpreter's resolution, harvests every deprecation warning from your test suite, plans waves (dual-support libs, interpreter, then one framework major each with its official upgrade tool), executes each wave with a CI matrix and shims, turns warnings into errors with a justified ignore list, and logs evidence per wave.

You end up with

• Audit of direct dependencies, target-interpreter resolution and known vulnerabilities
• Grouped deprecation-warning harvest per wave, with a diff that flags new breakages
• Wave plan and per-wave PRs for interpreter, Django, Pydantic v2 and SQLAlchemy 2.0
• pytest filterwarnings set to error, with each remaining third-party ignore justified
• Evidence log: commit, CI run, test counts and warning counts for every wave

Proof

Per-wave evidence log with commit SHAs, CI run links, test pass counts and harvested warning counts falling from the baseline, plus the final filterwarnings=error config passing in CI.

Try

• $python-dependency-upgrade-program Upgrade our service from Python 3.9 to 3.13 and Pydantic v1 to v2 without breaking prod
• $python-dependency-upgrade-program Plan our Django 4.2 to 5.2 upgrade in waves with evidence for each step
• $python-dependency-upgrade-program Harvest all deprecation warnings in our tests and turn them into errors

Codex scans every codebase for flag references, joins them with your provider export, scores staleness from age, served variation, last evaluation and code usage, removes dead branches flag by flag with tests, cleans up the provider in the safe order (code, then archive, then delete), and adds a CI guardrail requiring owner, type and expiry for every flag.

You end up with

• Flag inventory joining code references and provider metadata, scored and classified
• Per-flag removal PRs that keep the confirmed branch and delete its dead code and tests
• Provider cleanup done in the safe order with archive and delete dates recorded
• List of flags used in code but unknown to the provider, with what production served
• CI guardrail: registry with owner, type and expiry; expired temporary flags fail the build

Proof

Inventory counts by action before and after from the bundled scorer, a per-flag table with PR, deploy, reference count and archive date, and the CI run that failed on an unregistered flag.

Try

• $feature-flag-cleanup-program We have 400 LaunchDarkly flags; find the stale ones and remove them safely
• $feature-flag-cleanup-program Clean up our Unleash release flags and add a rule that every flag has an owner and expiry
• $feature-flag-cleanup-program Which feature flags are fully rolled out and safe to delete from code?

Codex analyses your FOCUS or CUR export with a bundled script, drills into the spend that matters, finds idle and oversized resources from real utilisation, sizes Savings Plans or CUDs from hourly usage, fixes storage lifecycle and data-transfer waste through your IaC, and keeps a savings ledger with risk, rollback and owner per change, checked against the next bill.

You end up with

• A spend breakdown by month, service, resource, SKU and waste category from your own export
• A savings ledger: current cost, estimated saving with basis, risk, rollback and owner per change
• Commitment sizing from hourly usage with utilisation and coverage at each level
• IaC pull requests for approved changes, applied safely with plans shown first
• A report comparing realised savings from billing data with the estimates

Proof

Baseline and post-change breakdowns from the same export script, per-change daily cost before vs after from billing data, and the commitment sweep table used for the purchase decision.

Try

• $cloud-cost-reduction-audit Our AWS bill went up 30% this quarter. Find out why and cut it.
• $cloud-cost-reduction-audit Should we buy Savings Plans, and how much? Here is our CUR export.
• $cloud-cost-reduction-audit Audit our GCP spend and give finance a savings plan with risks

Codex pulls your CrUX and RUM field data per page template, attributes each failing metric to the sub-part that is slow (TTFB, load delay, render delay, input delay, processing, layout shift source), ships fixes in order of field impact with Lighthouse and trace verification for each, then runs a dated 28-day follow-up until the field p75 numbers are in.

You end up with

• A baseline table of p75 LCP, INP and CLS per template and form factor from CrUX and RUM
• A ranked attribution list naming the slow sub-part for every failing cell, with evidence
• Small, verified fixes with lab before/after medians and saved traces for each
• A web-vitals attribution RUM snippet and queries if the site had no RUM
• A 28-day field follow-up plan and a report with before/after field numbers

Proof

CrUX tables from the same script before and after (with collection periods), RUM p75 by template for matched 7-day windows, and median-of-n Lighthouse runs plus traces for every fix.

Try

• $web-vitals-rescue Search Console says our product pages have poor LCP on mobile. Fix it.
• $web-vitals-rescue Our INP is 450 ms at p75. Find out why and get it under 200.
• $web-vitals-rescue Get our Core Web Vitals passing before the redesign launch and prove it

Codex measures the tail from histogram metrics, decomposes it by route and shape, samples traces of the slow requests specifically, works a lock/GC/pool/N+1/fan-out/retry/throttling checklist against that evidence, builds an open-model k6 profile that reproduces the tail, then ships one fix at a time with before/after percentile tables from identical runs and confirms in production.

You end up with

• A tail decomposition showing which routes and which latency mode produce requests above p99
• A slow-trace tally naming the dominant mechanism with two independent signals each
• A reproducible open-model k6 load profile with measured run-to-run noise
• Fixes shipped one at a time, each with a percentile comparison and bootstrap confidence interval
• A report with production p99 before and after over matched windows

Proof

Before/after p50/p90/p99/p99.9 tables per route from identical k6 runs with bootstrap confidence intervals, baseline-vs-baseline noise, and production histogram queries over matched windows.

Try

• $backend-p99-latency-hunt Our checkout p99 is 1.8 s but p50 is 80 ms. Find out why and fix it.
• $backend-p99-latency-hunt Latency SLO keeps burning during peak hours. Hunt down the tail.
• $backend-p99-latency-hunt Build a load test that reproduces our p99 spikes and prove the fix works

Codex pulls run history from the GitHub Actions or GitLab API, computes wall-clock, queue and runner-minute percentiles and the critical path, then applies cancellation of superseded runs, dependency and build caches, BuildKit layer reuse, timing-based test sharding and PR-only impact-based selection one change at a time, and closes with a before/after median and p90 report from comparable runs.

You end up with

• A baseline of wall-clock, queue time and runner minutes per run, with the critical path identified
• Workflow changes as separate commits, each measured cold and warm with test counts verified
• Sharding and selection set up without breaking required checks
• A before/after median and p90 table from the same script over 20+ comparable runs

Proof

Before/after median and p90 wall-clock, queue and runner minutes from the same history script over matched successful runs, with per-job deltas, flaky-rate comparison and test counts.

Try

• $ci-pipeline-speedup Our PR checks take 35 minutes. Make them faster and show me the numbers.
• $ci-pipeline-speedup We are burning GitHub Actions minutes. Find the waste and fix it.
• $ci-pipeline-speedup Shard our test suite and add caching to the GitLab pipeline

Codex builds a per-feature token and cost ledger from your request logs (OpenAI, Anthropic and Gemini usage shapes, cached tokens handled correctly), freezes a quality baseline per feature, then applies prompt caching, context trimming, output limits, model routing or cascades and batch APIs one at a time, each behind a flag and an eval gate, and measures cost per call in production after rollout.

You end up with

• A per-feature ledger of calls, cost per call, token profile and cache-read ratio, reconciled with the invoice
• Frozen eval baselines with agreed quality tolerances for the features that drive spend
• Cost changes shipped behind flags, each with a saved pass/fail gate result and flipped cases reviewed
• A before/after cost-per-call table from production logs at constant volume

Proof

Ledger output before and after from the same script and window length, plus eval-gate files showing mean and per-slice quality differences with bootstrap confidence intervals for every shipped change.

Try

• $llm-token-cost-reduction Our OpenAI bill doubled. Which features cost the most and how do we cut it safely?
• $llm-token-cost-reduction Add prompt caching to our Claude calls and prove quality did not drop
• $llm-token-cost-reduction Can we route simple requests to a smaller model? Set up an eval gate first.

Codex defines TTID and TTFD for your app, builds a repeatable launch harness on a reference device, traces cold start with Perfetto, Instruments or the Hermes profiler, plans deferred initialization, applies Android baseline profiles, trims the JS bundle and launch assets one commit at a time, and compares medians with bootstrap confidence intervals.

You end up with

• Written TTID/TTFD definitions plus app instrumentation for full display
• Per-phase startup breakdown backed by saved trace files
• Baseline and startup profile generator committed for Android
• Deferred-init changes, each with its own measured effect and behaviour check
• Before/after report with medians, p90 and 95% CIs from 15+ runs per build

Proof

Raw per-run JSON files from identical launch harness runs on a named device, a compare table with bootstrap confidence intervals for the median change, and before/after trace files.

Try

• $mobile-app-startup-speedup Our Android app takes 3 seconds to open on mid-range phones. Find out why and fix it.
• $mobile-app-startup-speedup Set up baseline profiles and prove they improve cold start.
• $mobile-app-startup-speedup Measure and reduce React Native startup time; we added five SDKs this year.

Codex ranks statements by total time from pg_stat_statements, captures EXPLAIN (ANALYZE, BUFFERS) plans and flags the costly nodes, chooses between statistics fixes, rewrites and indexes, checks each index's write cost with pgbench, ships indexes as CONCURRENTLY migrations one at a time, re-measures, and installs a weekly top-N regression check.

You end up with

• Ranked top-25 statement baseline saved as a JSON snapshot with window length and code paths
• Before/after EXPLAIN plans with flagged root causes for every changed statement
• Index migrations built CONCURRENTLY, each with a measured write-cost check
• Weekly snapshot-and-compare job that fails on regressions or new top-N entrants
• Filled evidence report with before/after per-statement numbers and rollbacks

Proof

Before/after pg_stat_statements snapshots compared by queryid, before/after plan JSON with buffer counts, pgbench runs with and without each new index, and migration file:line references.

Try

• $postgres-slow-query-program Our Postgres CPU is pinned at 90%. Find which queries cause it and fix the worst ones safely.
• $postgres-slow-query-program Set up a weekly check that tells us when a query regresses or a new one enters the top 20.
• $postgres-slow-query-program Which indexes should we add to the orders table, and what will they cost our inserts?

Codex measures gzip and brotli bytes per route from your build manifest, finds the heaviest modules with a bundle analyzer, then swaps heavy dependencies, removes tree-shaking blockers, adds lazy routes and widget splits one commit at a time, re-measuring after each, and wires per-route size budgets into CI that fail the build on growth.

You end up with

• Per-route gzip/brotli snapshot of the production build before and after
• One commit per change, each with its measured KB saving and passing tests
• Dependency swaps done through adapters with characterisation tests
• Per-route budget file and a CI step proven to fail on growth
• Filled report with the per-route before/after table and reverted experiments

Proof

Two bundle_report.mjs snapshots of the same production build command, a per-route markdown diff, analyzer treemaps before and after, and a CI run that fails when a route exceeds its budget.

Try

• $bundle-size-diet Our landing page ships 900 KB of JavaScript. Cut it down and show me per-route numbers.
• $bundle-size-diet Replace moment and lodash where it actually saves bytes, without changing date output.
• $bundle-size-diet Add bundle size budgets to CI so a route that grows fails the build.

Codex audits each Dockerfile, measures the current image (size, layers, cold and warm build time, CVEs by severity), rebuilds it as a multi-stage build on a minimal or distroless base with correct layer order, BuildKit cache and secret mounts and a non-root user, smoke-tests it, generates an SBOM, scans it, exports the build cache in CI, and reports the before/after numbers.

You end up with

• Multi-stage Dockerfiles on minimal or distroless bases, pinned by digest, running as non-root
• BuildKit cache and secret mounts plus a .dockerignore, so source changes rebuild only what changed
• An SBOM and scan file per image, with remaining critical/high CVEs triaged
• A before/after table of size, layers, cold/warm build time and CVE counts from the same machine

Proof

Before/after rows from the same measurement script on the same machine (size, layers, cold, warm and code-change rebuild times, CVEs by severity), audit outputs, smoke-test output and SBOM files.

Try

• $container-build-overhaul Our API image is 1.4 GB and takes 9 minutes to build. Fix it.
• $container-build-overhaul Move our images to distroless, run as non-root, and show the CVE difference
• $container-build-overhaul Add an SBOM and vulnerability scan to our container builds

Codex scopes the system and Trust Services Criteria with you, maps each criterion to concrete controls in code, cloud, identity and process, runs read-only collectors for GitHub, AWS and GCP with checksummed output, builds the change-management population from git and PR history, triages a gap register, fixes approved engineering gaps, drafts policy skeletons and sets a Type II evidence calendar. Engineering evidence only: not legal advice or an audit opinion.

You end up with

• Agreed system boundary and a control matrix mapping every in-scope criterion to an owner
• Timestamped, checksummed evidence exports from GitHub, AWS and GCP
• Change-management population with flagged exceptions and an auditor-style sample
• Severity-ranked gap register with remediation re-tested against fresh evidence
• Policy skeletons and a Type II operating calendar for control owners

Proof

Evidence files with UTC timestamps and a SHA-256 manifest, the PR population CSV with exceptions, before/after exports for each remediated gap, and a readiness report where every 'ready' row cites a file.

Try

• $soc2-readiness-evidence-pack A customer wants our SOC 2 Type II. Get us ready: map controls, collect evidence, find the gaps.
• $soc2-readiness-evidence-pack Build the change-management evidence for the last six months from our GitHub repos.
• $soc2-readiness-evidence-pack Our audit window starts in 60 days. What is missing and what should engineering fix first?

Codex inventories data stores, scans schemas and ORM models for personal data with file:line evidence, finds processors from SDKs and API calls, drafts Article 30 records with legal fields left for counsel, then builds DSAR export and erasure driven by one subject map, with retention exceptions, processor propagation, a deletion ledger for backups and tests proving coverage. Not legal advice.

You end up with

• Personal-data map by table and column with categories and file:line sources
• Processor list with the fields each vendor receives and the code that sends them
• Record-of-processing draft with engineering facts filled and legal decisions flagged
• DSAR export and erasure modules driven by one approved subject map
• Tests and before/after SQL proving exports are complete and erasure leaves nothing behind

Proof

pii-columns.csv and processors.csv with file:line evidence, the approved subject map, CI tests seeding a subject in every table, and verify.sql output before and after erasure on staging.

Try

• $gdpr-data-map-and-dsar We got our first GDPR deletion request. Build a proper export and erasure flow we can trust.
• $gdpr-data-map-and-dsar Map where personal data lives in our codebase and which vendors we send it to.
• $gdpr-data-map-and-dsar Draft our record of processing from the actual schemas for our DPO to review.

Codex scans the code for ePHI fields, ePHI in logs and third-party SDKs, draws a data-flow map with file:line evidence, assesses each 164.312 standard (access control, audit, integrity, authentication, transmission), builds a vendor and BAA inventory, ranks gaps, fixes the top ones with tests, and re-runs the same checks so you get a before/after evidence report. Engineering evidence, not legal advice.

You end up with

• Confirmed ePHI field list and a Mermaid data-flow map where every edge cites file:line evidence
• 164.312 control table with status, evidence and decision records for addressable specifications
• Vendor inventory from code: who can receive ePHI and which BAAs you still need to confirm
• Prioritized gap list with code fixes (audit events, session timeouts, log scrubbing) and tests
• Before/after report with scanner deltas and questions for your compliance owner

Proof

Before/after counts from the same scanner run (ePHI in log and tracker calls, unreviewed vendors), a control table citing file:line and command output per row, and tests that fail before and pass after each fix.

Try

• $hipaa-safeguards-review Review our app against the HIPAA technical safeguards and tell me where PHI goes
• $hipaa-safeguards-review Which of our vendors need a BAA based on what the code actually sends them?
• $hipaa-safeguards-review We're a business associate for a clinic network. Find and fix the gaps in audit logging and session handling.

Codex scopes the application, builds the ASVS 4.0.3 L1+L2 checklist, scans the code with per-requirement patterns for leads, verifies each requirement through code, config, cross-user tests and live requests to staging, records file:line or test evidence, writes severity-ranked findings with fixes, applies approved fixes with tests, and scores coverage and pass rate per chapter.

You end up with

• Requirement-level CSV with status and evidence for every ASVS L1 and L2 item in scope
• Severity-ranked findings with exploit scenario, location and specific fix
• Cross-user access control tests added to the suite
• Approved fixes, each proven by a test that failed before and passes after
• Scored report: coverage and pass rate per chapter, unverified items listed

Proof

audit.csv with file:line, test name or captured response for each pass and fail, the scan output, and a score table computed from that CSV where unverified items never count as passing.

Try

• $owasp-asvs-l2-audit A customer asked if we meet OWASP ASVS Level 2. Audit our app and show the evidence.
• $owasp-asvs-l2-audit Run an ASVS L2 review on the API before our pen test and fix the cheap findings first.
• $owasp-asvs-l2-audit Check our session, cookie and access control handling against ASVS and score it.

Codex traces your payment flow, scans code, logs, error-tracker exports and database samples for Luhn-valid card numbers (masked, never printed in full), builds a scope inventory, moves card capture to your provider's hosted fields or redirect, removes PAN from logs, trackers and tables under an approved purge plan, protects the payment page, tests segmentation, and documents evidence per SAQ eligibility criterion. Not a QSA assessment.

You end up with

• Scope inventory of CDE and connected systems, before and after, with evidence per system
• Masked PAN scan results for repo, logs, trackers and database samples, with before/after deltas
• Checkout moved to provider hosted fields or redirect, raw card routes deleted and tested
• Payment page script inventory and CSP, plus segmentation test output where scope remains
• Evidence table mapped to your target SAQ's eligibility criteria for the acquirer

Proof

Before/after counts from the same Luhn-validating scanner per location, a provider test-mode checkout capture showing no PAN reaching your origin, SQL counts for card-shaped columns, and saved segmentation scan output.

Try

• $pci-dss-scope-reduction Get us from SAQ D to SAQ A: find everywhere card numbers touch our systems and remove them
• $pci-dss-scope-reduction Scan our logs and Sentry exports for credit card numbers and fix whatever is leaking them
• $pci-dss-scope-reduction We still have a card_number column from 2019. Plan the migration to Stripe tokens and the purge.

Codex inventories every route, resolver and handler with its guard, builds a role-by-endpoint access matrix for your owner to approve, validates it against the code, generates tests from the matrix that expose broken object level authorization and tenant isolation bugs, fixes them by centralizing policy and default scoping, and proves it with the same tests failing before and passing after.

You end up with

• Route and resolver inventory with the guard protecting each one, unknowns resolved by reading code
• Approved access matrix (allow / own / tenant / deny per role) kept in the repo as a contract
• Matrix-derived authz tests for IDOR/BOLA, cross-tenant access and mass assignment
• Central policy module, default tenant scoping and a deny-by-default guard test in CI
• Report with findings by severity and before/after counts from the same scripts

Proof

Every finding has a test that fails on the pre-fix commit and passes after; before/after counts of unguarded routes, undecided matrix cells and failing authz tests from the same inventory and matrix checks.

Try

• $authz-model-audit Audit our API for IDOR and make sure tenant A can never read tenant B's data
• $authz-model-audit Build a permission matrix for every route and tell me which ones have no auth
• $authz-model-audit We got a bug bounty report for one invoice leak. Find the siblings and fix the pattern.

Codex exports your AWS, GCP or Azure identities and policies, labels every principal and permission used or unused from the provider's access data, flags admin/wildcard grants, privilege-escalation combos and risky trust policies, generates scoped replacement policies from actual activity, plans elimination of long-lived keys in favor of short-lived roles and workload identity, and stages every change behind a tested break-glass path with recorded rollback.

You end up with

• Inventory and labeled findings for every identity, role and policy in scope
• Scoped replacement policies generated from real activity, with an explicit escalation deny
• Long-lived key elimination plan with migration targets and dated deactivation
• MFA/SSO enforcement changes and a tested break-glass role with rollback per change
• Before/after counts of admin, escalation, unused and keyless findings from the same analyzer

Proof

Before/after findings counts from the same analyzer run on fresh exports: admin/wildcard principals, privilege-escalation combos, long-lived keys, no-MFA users and unused principals, each change with its revert command.

Try

• $cloud-iam-least-privilege Tighten our AWS IAM: find admin roles and unused keys and give me scoped policies
• $cloud-iam-least-privilege Who in our GCP org has owner or editor, and what can we safely remove?
• $cloud-iam-least-privilege Get rid of long-lived access keys and move our workloads to short-lived roles

Codex threat-models your LLM app against the OWASP LLM Top 10, builds a labeled attack corpus for direct and indirect prompt injection, system-prompt and data exfiltration, tool misuse, jailbreaks and excessive agency, runs a harness that replays every attack against your real endpoint with an explicit success check per attack, triages findings with reproducible transcripts, implements layered mitigations, and re-runs the corpus to show the before/after attack success rate.

You end up with

• Threat model with trust boundaries and a per-risk applicability table for your app
• Versioned, labeled attack corpus (JSONL) specialized to your prompts, tools and retrieval
• Harness that replays attacks against your endpoint and scores each with a written oracle
• Findings with severity, minimal reproductions and before/after transcripts
• Implemented or specified mitigations and a CI regression gate from the same corpus

Proof

Before/after attack success rate overall and per OWASP category from identical harness runs, each fixed attack shown succeeding then blocked, and control-case pass rate proving mitigations did not break normal use.

Try

• $llm-app-red-team Red-team our support agent for prompt injection and make sure a poisoned doc can't trigger its tools
• $llm-app-red-team Can users get our chatbot to leak its system prompt or our API key? Test it and fix it.
• $llm-app-red-team Build an attack corpus for our RAG app and wire the harness into CI as a regression gate

Codex baselines the repo with OpenSSF Scorecard and a workflow audit, pins every action to a commit SHA with Dependabot updates, sets least-privilege tokens, fixes script injection, replaces stored cloud keys with OIDC, enforces lockfile installs and dependency review, adds signed provenance, cosign signatures and SBOM attestations, protects workflow files, then reruns Scorecard and every verification command.

You end up with

• Every third-party action pinned to a SHA, with Dependabot keeping pins current
• Least-privilege permissions and no script-injection patterns in workflows
• Cloud deploys on OIDC with stored long-lived keys removed
• Release artifacts and images with provenance anyone can verify in one command
• Scorecard before/after table and an honest SLSA level claim per artifact

Proof

Scorecard JSON before and after with a per-check diff, pin_actions.py --check passing, gh attestation and cosign verify output for each artifact, and failing runs proving dependency review and lockfile checks block.

Try

• $supply-chain-hardening Pin all our GitHub Actions to SHAs and lock down workflow permissions.
• $supply-chain-hardening Get our release pipeline to SLSA Level 2 with signed container images.
• $supply-chain-hardening Replace the AWS keys in our GitHub secrets with OIDC and prove deploys still work.

Codex triages the leak and its severity, maps what the credential can reach, finds every copy across all git refs, reflogs and build output without printing the secret, rotates and revokes in the safe order with provider-specific steps, reviews provider logs over the exposure window for abuse and persistence, rewrites history with git filter-repo when warranted, installs pre-commit and push-protection scanning, and writes the incident timeline.

You end up with

• Revoked credential with proof the old value is rejected and the new one works
• Every exposure location with its first-exposure time, found by fingerprint
• Abuse-window log review across provider logs with coverage limits stated
• Verified history rewrite in a mirror clone, or a recorded decision not to
• Pre-commit and push-protection controls proven to block a test secret

Proof

A UTC incident timeline, the provider error showing the old credential rejected, find_exposure.py output before and after cleanup, saved log query results for the full window, and captured blocked commit and push outputs.

Try

• $secrets-leak-response I just pushed our AWS access key to GitHub. Walk me through fixing it properly.
• $secrets-leak-response GitHub secret scanning flagged a Stripe live key in an old commit. Handle it end to end.
• $secrets-leak-response Our database password showed up in CI logs. Rotate it and check whether anyone used it.

Codex inventories your stateful systems, agrees RPO/RTO targets with each owner, checks every backup for off-account copies, PITR and key availability, restores each one into an isolated target and validates the data, scripts the restore path, runs a timed game-day with a live event log, measures RPO/RTO against target, fixes the gaps and re-tests. You end with a signed-off drill report.

You end up with

• RPO/RTO targets per system, signed off by each owner
• Validated restores of every tier 0/1 datastore with timings and per-table data-loss windows
• Restore scripts and runbooks executed by an engineer other than the author
• Game-day timeline with measured RTO/RPO vs target and the phase that dominated
• Findings list with fixes, owners and re-test evidence

Proof

A drill log with timestamps for detect, declare, restore, validate and cutover; restore_check output comparing row counts and newest rows; and a measured-vs-target RPO/RTO table per system.

Try

• $disaster-recovery-drill Run a DR drill for our Postgres and S3 data and tell me our real RPO and RTO
• $disaster-recovery-drill We have RDS snapshots but nobody has ever restored one. Prove they work and script the restore
• $disaster-recovery-drill Plan and run a game-day for a bad migration that corrupts the orders table

Codex maps region-pinned dependencies from Terraform state plus the hidden ones (identity, secrets, KMS, images, CI/CD, third parties), measures replication lag and documents data-loss, conflict and fencing behaviour per datastore, verifies the DNS or traffic-manager path and secondary capacity, then runs a staged failover rehearsal with an external probe that measures downtime and failover time, through failback.

You end up with

• Dependency map with every region-pinned resource, its owner and a fix or accepted gap
• Measured replication lag (average, max, at peak) and RPO-on-failover per datastore
• Verified traffic failover path, health check design and secondary capacity vs peak
• Staged rehearsal plan with go/no-go checks, abort criteria and rollback steps
• Probe-measured failover and failback time, downtime and marker-write data loss

Proof

failover_probe.py summaries for failover and failback (availability, longest failure window, region flip time, initiated-to-serving time), CloudWatch or SQL lag measurements, and region_inventory.py output.

Try

• $multi-region-failover-readiness Can we survive a us-east-1 outage? Map what is pinned there and plan a failover rehearsal
• $multi-region-failover-readiness Measure our Aurora global database lag and rehearse a switchover to us-west-2 in staging
• $multi-region-failover-readiness We claim warm-standby DR to customers. Prove it with a timed failover and failback

Codex renders your charts or overlays, scores every workload with a bundled scanner plus kube-score, Polaris, Kyverno and pluto, sizes requests and limits from real Prometheus usage, fixes probes, PDBs, topology spread, HPA, security context, NetworkPolicies and secrets in the manifests, clears deprecated APIs for your next upgrade, runs a drain test in staging, and rescans. You get a scored before/after readiness report.

You end up with

• Per-workload readiness scores before and after from the same scanner and flags
• Requests and limits set from 1-2 weeks of measured usage, with confidence labels
• Probes, PDBs, zone spread, HPA and graceful shutdown fixed in charts or overlays
• Restricted pod security, default-deny NetworkPolicies and no plaintext secrets
• Zero removed APIs for the next Kubernetes minor version, plus a drain test result

Proof

Before/after scanner and Polaris scores, kube-score and Kyverno outputs, a rightsizing table from Prometheus data, pluto output for the target version, and a staging drain test with request error counts.

Try

• $k8s-production-readiness Is our shop namespace ready for production on Kubernetes? Score it and fix the gaps
• $k8s-production-readiness Right-size requests and limits for these deployments from the last two weeks of Prometheus data
• $k8s-production-readiness We upgrade to the next Kubernetes version next month. Review our workloads and charts first

Codex builds a traffic model from your access logs, writes k6 (or Locust) scenarios that replay the real request mix at open-model arrival rates, runs repeated step tests to find the knee of the latency curve, names the first bottleneck with metrics and a confirming re-run, agrees a headroom policy, and produces a dated capacity forecast with instance counts for low and high growth cases.

You end up with

• Traffic model with request mix, peak-minute RPS and a reusable mix file
• Arrival-rate k6 step scenario tagged per endpoint, with SLO thresholds
• Load curve from two runs with knee, sustainable RPS and generator health
• First bottleneck named from metrics at the knee and confirmed by a re-run
• Dated forecast: when peak hits usable capacity and instances needed at +3/+6/+12 months

Proof

Two step-test runs with per-step achieved RPS, p95/p99, errors and dropped iterations from identical k6 scenarios; metric evidence at the knee step; and a forecast table with stated growth assumptions.

Try

• $capacity-plan-from-load-tests How much traffic can our API handle before p95 goes over 300 ms? Build a capacity plan
• $capacity-plan-from-load-tests We have a launch in six weeks. Load test with our real traffic mix and tell me what breaks first
• $capacity-plan-from-load-tests Turn our nginx logs into a k6 scenario and forecast when we need more instances

Codex normalizes incident data from PagerDuty, Opsgenie, Jira or a spreadsheet into one schema, classifies each incident by contributing factor with a reviewable rule, computes MTTD and MTTR by factor, service and severity as distributions (median and p90, not just the mean), surfaces repeat-offender services and recurring factors, and turns the patterns into a prioritized reliability roadmap where every item ties to the incidents it addresses with impact ranges labeled as estimates.

You end up with

• One normalized, validated incident dataset from your mixed sources
• Each incident classified by contributing factor, auto-proposals reviewed and corrected
• MTTD/MTTR by factor, service and severity as distributions, with a monthly trend and low-n flags
• Ranked systemic patterns, each citing the specific incident ids behind it
• A reliability roadmap with effort, owner, leading indicator and labeled impact estimates

Proof

Every metric is computed from your incident records (reproducible from the attached dataset and metrics.json), distributions not skewed means, patterns cite incident ids, and roadmap impact is a range with its basis shown, never a promised reduction.

Try

• $incident-trend-analysis Analyze our last 12 months of incidents and tell me what keeps breaking
• $incident-trend-analysis Compute MTTR by cause and find our repeat-offender services
• $incident-trend-analysis Mine our postmortems for systemic fixes and give me a prioritized reliability roadmap

Codex maps one critical request path, stands up an OpenTelemetry Collector with memory limits, batching, redaction and noise filters, instruments each service hop by hop with W3C context propagation (HTTP, gRPC, queues, DB), adds RED metrics and JSON logs carrying trace ids, sets sampling and cost controls from measured volume, builds three starter dashboards, and verifies with a trace checker that one request is a single connected trace with correlated logs.

You end up with

• Every in-scope service emitting traces, RED metrics and trace-correlated JSON logs via OTLP
• A versioned collector config with tail sampling topology, redaction and noise filters
• Service RED, endpoint drill-down and telemetry pipeline health dashboards
• trace_walk.py output proving one request crosses every hop as one connected trace
• Sampling decision with estimated vs measured span and log volumes, plus overhead numbers

Proof

trace_walk.py output on a real request: span tree across every service, one root, no orphans, propagation checks and log lines per service with the same trace id, plus measured collector throughput.

Try

• $observability-from-zero We have no tracing. Set up OpenTelemetry across our Node and Python services and prove it works
• $observability-from-zero Our traces break into pieces between the API and the queue worker. Fix propagation end to end
• $observability-from-zero Add RED metrics, trace-correlated logs and starter Grafana dashboards with an OTel collector

Codex inventories your runbooks and ranks them by page frequency and risk, converts the high-value ones into automations built on a shared safety backbone (dry-run by default, idempotency, pre-flight checks, confirmation gates for destructive steps, and a JSON audit log), tests each against a fixture or staging, links it from the alert that triggers it, and tracks the toil hours removed with measured and estimated figures kept separate.

You end up with

• Ranked runbook inventory scored by value (frequency x manual minutes) and risk
• Converted automations that default to dry-run, are idempotent, and gate destructive steps
• A reusable safety library (dry-run, confirm, audit log) and a self-test proving its gates
• Each automation linked from its alert, with optional guarded auto-remediation
• A toil-reduction ledger separating measured savings from labeled estimates

Proof

A dry-run plan and an idempotency proof (second run is a no-op in the audit log) for each automation, the library self-test passing its five gates, and a toil ledger with measured hours from page data distinct from estimates.

Try

• $runbook-automation-program Automate our top on-call runbooks and show me the toil hours it saves
• $runbook-automation-program Turn this wiki runbook into an idempotent script with a dry-run and confirmation gates
• $runbook-automation-program We restart the same service by hand every week. Codify it and link it from the alert.

Codex picks SLIs from each service's user journeys, measures a 30-day baseline from your existing metrics so objectives are grounded, sets objectives and error budgets, generates multi-window multi-burn-rate alerts for Prometheus or Datadog from a small spec, drafts an error-budget policy and a review cadence, runs new alerts alongside the old ones during a soak, and leaves config in the repo so you extend it service by service.

You end up with

• Written SLI specifications tied to user journeys for each pilot service
• Measured 30-day baselines with the exact queries, and objectives chosen from them
• Multi-window multi-burn-rate alert rules (Prometheus YAML and Datadog JSON) in the repo
• A drafted error-budget policy with states, actions and a named decider, sent for adoption
• A review cadence and a report that lets the team onboard the next services

Proof

Per-service baseline vs chosen objective with the queries used, generated burn-rate rules reviewed against real metric names and backtested, and a soak comparing new SLO alerts against the alerts they replace.

Try

• $slo-program-launch Set up SLOs for our checkout and search services with burn-rate alerts
• $slo-program-launch Our CPU alerts page constantly but users don't notice. Replace them with SLO-based alerting.
• $slo-program-launch Measure our API's real availability over 30 days and propose an objective and error budget

Codex exports 4-8 weeks of page history, helps you label actionability, scores every alert for self-resolution, flapping and co-firing duplicates, then replaces cause-based pages with symptom and SLO burn-rate alerts, fixes routing, grouping and inhibition with tested Alertmanager config, keeps a recall check for every real incident, and compares pages per week after an equal window.

You end up with

• Ranked noise table of every paging alert with an outcome and a PR for each
• Multiwindow SLO burn-rate alerts with promtool unit tests replaying real incidents
• Routing, grouping and inhibition config verified with amtool test cases
• Recall table showing each real incident still has a detecting page
• Pages/week and off-hours pages/week before vs after over equal windows

Proof

alert_noise_score.py compare output for equal-length before/after windows (pages/week, off-hours pages/week, actionable %), promtool and amtool test output, and a recall table for every real incident.

Try

• $on-call-noise-reduction We get paged 40 times a week and most are nothing. Cut the noise and show me the numbers
• $on-call-noise-reduction Replace our CPU and pod-restart pages with SLO burn-rate alerts and fix Alertmanager grouping
• $on-call-noise-reduction Score our PagerDuty incidents from the last two months for actionability and flapping

Codex frames the hypothesis, freezes an eval set, measures the best prompting baseline, records each data source's approval in an inventory, runs a dedup/PII-scrub/quality/contamination pipeline with grouped splits and a manifest, has you inspect samples, launches the fine-tune, compares it to the baseline with paired bootstrap intervals, and writes a go/no-go decision record.

You end up with

• A frozen eval set and prompting baseline scores with cost and latency
• A data inventory with approval status, owner and PII mode per source
• Train/val JSONL with a manifest counting every dropped record by reason
• A paired baseline-vs-fine-tune comparison with slice checks and a signed go/no-go record

Proof

compare_eval.py output on the same frozen eval set (mean scores, bootstrap CI, win/loss, per-slice deltas, verdict) plus the dataset manifest with drop counts, PII matches, split hashes and empty group leaks.

Try

• $fine-tuning-data-pipeline Should we fine-tune a small model on our support tickets instead of using GPT with a long prompt? Build the pipeline and decide.
• $fine-tuning-data-pipeline Turn these chat logs into a clean fine-tuning dataset with PII removed and proper splits.
• $fine-tuning-data-pipeline We fine-tuned once and it got worse. Redo it properly with a baseline and a go/no-go.

Codex defines testable quality dimensions with the owner, builds a stratified golden dataset from scrubbed production traffic, writes a labeling guide and measures human agreement, implements code graders and LLM judges calibrated against human labels, adds a runner that records metrics, latency, tokens and cost per case, and wires a paired regression gate into CI, proven by catching a deliberate regression.

You end up with

• Versioned dev and holdout golden sets from real traffic, stratified by slice
• Labeling guide with measured human-human agreement per criterion
• Judges calibrated against human labels: kappa, failure sensitivity, corrected pass rate
• Runner writing per-case JSONL with metrics, latency, tokens and cost, ready for dashboards
• CI regression gate with paired CIs, critical-metric flips, latency and cost limits

Proof

judge_calibration.py output per judge, a baseline run summary with cost and latency, and regression_gate.py output showing the gate failing on a deliberate regression and passing on a no-op change.

Try

• $llm-eval-harness Build an eval harness for our support bot from last month's conversations and gate PRs on it
• $llm-eval-harness Our LLM judge says the new prompt is better. Check the judge against human labels first
• $llm-eval-harness Extend our small eval script into a CI regression gate with cost and latency tracking

Codex collects real failing queries, triages them into a retrieval/generation/corpus failure taxonomy, labels relevance and reference answers, measures retrieval (recall@k, MRR, nDCG) separately from generation (correctness, faithfulness, refusals, citations), runs one-variable experiments on chunking, hybrid search, reranking, query handling and prompts, and compares baseline vs final on a held-out set.

You end up with

• Failure taxonomy with counts and a retrieval-vs-generation attribution matrix
• Relevance labels (qrels) and reference answers for dev and holdout query sets
• Experiment log: chunking, hybrid BM25+vector, reranking, query rewriting, context and prompt
• Citation checks for phantom ids, unverified quotes and weakly supported sentences
• Before/after holdout table with paired CIs, latency and cost per query

Proof

retrieval_metrics.py paired before/after on a held-out query set, citation_check.py results, an oracle-context run bounding retrieval gains, and failure-taxonomy counts before and after.

Try

• $rag-quality-overhaul Our docs chatbot gives wrong answers. Figure out whether it's retrieval or the prompt and fix it
• $rag-quality-overhaul Measure recall@5 and MRR for our RAG, then try hybrid search and a reranker
• $rag-quality-overhaul Our answers cite sources that don't say what the answer claims. Add citation checks and fix it

Codex maps the agent loop and tools, adds a normalized trace recorder, freezes a task suite with state-based success checks, runs a k-trial baseline, labels every failure (loops, wrong tool, bad args, premature stop, budget, unrecovered errors), hardens tool schemas and adds step budgets and recovery, then re-runs the same suite and writes a before/after report.

You end up with

• A frozen task suite with state-based success checks and a k-trial runner
• Failure-mode counts for every failed baseline run, with hand-reviewed traces
• Hardened tool schemas, typed tool errors, repeat detection and graceful step budgets
• Before/after success rate with 95% intervals, pass^k, tokens per success and holdout result

Proof

Before/after table from suite_compare.py on identical tasks, model and trial counts: success rate with Wilson intervals, pass^k, per-task regressions, plus failure-mode counts from trace_classify.py and a holdout run.

Try

• $agent-reliability-program Our support agent loops and sometimes says it refunded orders it didn't. Make it reliable and show me the numbers.
• $agent-reliability-program Build a task suite for our coding agent and measure its success rate before and after hardening the tools.
• $agent-reliability-program Why does this LangGraph agent give up early? Classify the failures and fix the top ones.

Codex maps the request path and agrees a failure policy per layer, writes block and near-miss allow cases first, implements input limits and classification, PII and secret filtering, retrieved-content screening, a tool-call allowlist with authorization and confirmation, schema validation with one repair, groundedness checks and fallbacks, then proves them with a labeled eval, measures added latency and plans a shadow rollout.

You end up with

• An approved guardrail map with implementation file:line and failure policy per layer
• A labeled case set with block cases per layer and a sized allow set
• Eval results over three runs: recall per layer, false-positive rate, guard latency
• Before/after endpoint latency and cost, plus a shadow-mode rollout plan

Proof

guardrail_eval.py output from three runs showing every block case caught by its own layer and the false-positive rate on the allow set, plus measured p95 latency with guards off and on.

Try

• $llm-guardrails-production Add guardrails to our support bot: no PII leaks, no prompt injection, and only allowed tools. Prove they work.
• $llm-guardrails-production Our RAG assistant made up a price. Add groundedness checks and output validation with tests.
• $llm-guardrails-production Harden the agent's tool calls so it can't refund other customers' orders.

Codex profiles the corpus, designs a strict nullable schema with evidence quotes, builds a labeled dev/test gold set with human agreement, extracts with structured outputs, handles long documents with per-field merge rules, verifies evidence and validators to set abstain thresholds, routes doubtful fields to review, measures field-level accuracy on the held-out split, and pilots to get real cost per document.

You end up with

• A versioned extraction schema with null semantics and per-field evidence
• Dev/test gold sets with per-field human agreement as the accuracy ceiling
• Field-level accuracy, abstain and hallucination counts on the held-out test split
• Evidence and validator checks feeding a review queue with projected workload
• Measured cost per document from a pilot, plus an idempotent full-run plan

Proof

score_extraction.py output on the untouched test split (per-field accuracy, coverage, hallucinations, threshold sweep, cost per document) plus evidence_check.py review-queue counts by reason.

Try

• $structured-extraction-at-scale Extract parties, dates and renewal terms from our 40,000 contracts into a table, and tell me how accurate it is.
• $structured-extraction-at-scale Our invoice extraction gets totals wrong sometimes. Measure field accuracy and add a review queue for low-confidence values.
• $structured-extraction-at-scale What would it cost per document to extract these fields from our filings, and how many need human review?

Codex maps the voice pipeline, instruments every stage boundary on one clock, measures end-of-speech to agent-audio latency from loopback recordings of a fixed script set, sets a p95 budget per stage, makes every link stream, tunes endpointing while tracking early cut-ins, fixes barge-in and history truncation, and re-measures twice to report before/after percentiles.

You end up with

• Per-turn stage events (endpointing, ASR, LLM TTFT, first sentence, TTS first byte, playout)
• Ear-level latency percentiles from loopback recordings, not just server logs
• A per-stage p95 budget with pass/fail and the stages driving the slow tail
• Streaming, endpointing and barge-in fixes with cut-in rate and stop time tracked

Proof

Before/after p50/p90/p95 end-of-speech to agent-audio latency from measure_m2e.py on the same scripted conversation set (two final runs), plus latency_breakdown.py stage tables against the budget.

Try

• $voice-agent-latency-budget Our phone agent pauses too long before answering. Measure where the time goes and get p95 under our target.
• $voice-agent-latency-budget The voice bot keeps talking after customers interrupt it. Fix barge-in and show me the stop times.
• $voice-agent-latency-budget Set up proper latency measurement for our LiveKit voice agent and tune endpointing without cutting people off.

Codex inventories every LLM call site and parameter, diffs capabilities and API shapes against the target model, writes parity thresholds before any results, adds a routing seam with per-model prompt variants, runs paired offline evals and async shadow traffic, compares quality, errors, p95 latency and cost per call site, then rolls out in sticky flag stages with guard metrics and a timed kill-switch drill.

You end up with

• A call-site inventory with model ids, parameters, output contracts and volumes
• Per-call-site API diff tables and a pre-registered thresholds file
• Offline and shadow parity reports: agreement, score CI, errors, p95 latency, cost per 1k
• A staged rollout log with guard metrics and a measured kill-switch drill

Proof

shadow_compare.py reports per call site on offline and shadow pairs against thresholds committed before testing, plus the rollout log with guard metrics and the kill-switch drill timing.

Try

• $model-migration-playbook Our model is being deprecated next quarter. Migrate every call site to the replacement without regressions.
• $model-migration-playbook We want to move our classification calls to a cheaper model. Prove it's as good before switching.
• $model-migration-playbook Migrate us from Chat Completions to the Responses API with shadow testing and a rollback switch.

Codex finds every prompt in the codebase, migrates each verbatim into a versioned registry with an equivalence check, writes fixture cases with schema, contains, regex and pinned model-graded assertions, records a multi-sample baseline, wires a stdlib runner and diff report into pull-request CI, then proves the gate by breaking a prompt on purpose and showing the failing run.

You end up with

• A prompts/ registry with version, model, params, owner and changelog per prompt
• Fixture cases per prompt covering branches, past incidents and adversarial inputs
• A CI workflow that runs the suite and posts a base-vs-head diff on every prompt PR
• A committed baseline plus a model-change rehearsal diff for future upgrades

Proof

Baseline results file, a CI run that failed on a deliberately broken prompt and passed after revert, and diff_report.py output listing newly failing cases with assertion details and output diffs.

Try

• $prompt-regression-suite Put all our prompts under version control with tests and run them in CI.
• $prompt-regression-suite We changed the summarizer prompt and support tickets went up. Set up regression tests so this can't happen again.
• $prompt-regression-suite Show me what changes across our prompts if we switch to a newer model.

Codex reconciles your checkout analytics with real orders, measures step conversion by device, walks the flow against a form and payment UX checklist, buckets payment failures by decline code, measures mobile performance of each checkout page, checks price clarity and trust cues, then ranks every fix and writes sized A/B test plans for the top ones.

You end up with

• Reconciled step funnel by device with instrumentation defects listed by file and line
• Payment failure breakdown by decline code with a remedy per recoverable bucket
• UX, trust and price-clarity checklist results with screenshot or code evidence
• Lab and field performance table for each checkout page on mobile
• Ranked fix list plus A/B test plans with sample size and duration

Proof

Funnel and decline tables generated by the bundled script from your exports, a daily analytics-vs-orders reconciliation, median-of-three Lighthouse runs per page, and before/after evidence for each bug fixed during the audit.

Try

• $checkout-conversion-audit Audit our checkout - mobile converts far worse than desktop and I want to know why
• $checkout-conversion-audit Payment declines went up last month; break them down and tell me what we can recover
• $checkout-conversion-audit Give me a ranked list of checkout fixes and A/B tests with sample sizes

Codex writes funnel step definitions with you, audits event data and identity stitching, builds ordered funnels with conversion windows in SQL or from an export, cuts mature cohorts and segments, validates the activation definition against later payment, ranks drop-offs by users and estimated revenue at stake, gathers qualitative evidence for the top leaks, and delivers a sized experiment backlog.

You end up with

• Written funnel definitions and a data-quality audit with exclusions
• Mature-cohort funnel, cohort trend and segment tables from your own events
• An activation definition validated against later conversion to paid
• Drop-offs ranked by users and estimated revenue at stake, with qualitative evidence
• An experiment backlog with baseline, MDE, users per arm and days to run

Proof

Funnel and segment tables from the exact SQL or funnel_from_events.py command, reconciled against billing, plus sample_size.py output for every backlog item and the activation validation table.

Try

• $plg-funnel-diagnostic Our signups don't convert to paid. Diagnose the funnel from our Snowflake events and tell me what to test first.
• $plg-funnel-diagnostic Validate our activation metric and rank where we lose users between signup and paid.
• $plg-funnel-diagnostic Here's an events export. Build the visit-to-paid funnel by channel and size experiments for the biggest drop.

Codex frames the pricing decision and guardrails, runs willingness-to-pay research with a Van Westendorp survey and analysis, picks a fair experiment design (packaging tests, honour-the-lowest-price randomisation, market splits or cohorts), sizes and implements it with sticky assignment and new billing prices, models grandfathering options on your customer base, and ends with a decision readout.

You end up with

• Pricing brief with primary metric, guardrails and sign-off
• Van Westendorp survey, analysed acceptable price ranges by segment, and candidate price points
• Pre-registered experiment design with fairness policy, sample size and implementation checklist
• Grandfathering plan with MRR scenarios, notice timeline and customer communication drafts
• Decision readout: revenue per visitor, conversion, retention and refunds with intervals

Proof

Survey analysis and experiment readout produced by the bundled script on your data: SRM check, per-arm revenue per visitor with bootstrap intervals, guardrail metrics, and MRR scenarios for each grandfathering option.

Try

• $pricing-experiment-program We think Pro is underpriced at $29 - design a safe test and tell us what to charge
• $pricing-experiment-program Run a Van Westendorp survey for our new Team plan and analyse it by company size
• $pricing-experiment-program We're raising prices - model grandfathering options and draft the customer emails

Codex pulls daily Search Console data by page and query, finds the break date, sizes the loss by page group and brand vs non-brand, separates algorithm, technical, migration, tracking and seasonal causes by their data signatures, confirms them with URL Inspection, redirect, robots and log checks, then ships fixes in order of recoverable clicks and tracks affected groups against a control weekly.

You end up with

• Drop sizing: clicks lost per week, break date, affected page groups and queries
• Cause analysis with evidence for and against each hypothesis and a verdict
• Crawl, index and redirect check results for the lost URLs, before and after fixes
• Recovery plan ordered by recoverable clicks with owners and ship dates
• Weekly tracking table of affected groups vs control vs pre-drop baseline

Proof

Script output from your Search Console data classifying every lost page (vanished, rank loss, demand, CTR loss), URL Inspection and live-fetch results saved before and after each fix, and a weekly recovery table against a fixed baseline.

Try

• $seo-traffic-recovery Our organic traffic dropped 40% in September - find out why and build a recovery plan
• $seo-traffic-recovery We migrated to a new URL structure and lost rankings; audit the migration and fix it
• $seo-traffic-recovery Was our traffic drop the core update, seasonality or something we broke?

Codex inventories your events, builds a censoring-safe signup cohort from the warehouse or analytics export, scans every behaviour and frequency threshold for retention lift, adjusts for general activity, channel and plan, checks stability on a second cohort, picks one activation definition, then writes an onboarding brief and a powered validation experiment.

You end up with

• A written activation definition (behaviour, threshold, window) with owner and review date
• Candidate scan with crude and confounder-adjusted retention lift across two cohorts
• Confounder checklist per shortlisted behaviour, with rejected options and reasons
• Onboarding redesign brief tied to the measured signup-to-aha funnel
• Pre-registered A/B or holdout design with sample size and duration

Proof

Scan output from the bundled script on your own cohort: per-behaviour lift, Mantel-Haenszel adjusted lift, coverage and overlap, repeated on a second cohort, plus the exact queries and commands that produced every number.

Try

• $aha-moment-discovery Find our aha moment from the events in BigQuery and tell me what activation should mean
• $aha-moment-discovery Which first-week actions predict that a workspace is still active in week 5?
• $aha-moment-discovery We are redesigning onboarding - figure out what behaviour it should push new users toward

Codex builds a versioned buyer-language query set, samples each AI engine repeatedly, scores brand mentions, citations, prominence and share of voice against your competitors, maps which sources the answers cite, checks crawler access, bot blocking, llms.txt and server-rendered facts, ships content and structured-data fixes for the gap queries, then re-samples and compares against the baseline.

You end up with

• Versioned query set (30-80 buyer-language prompts) with stages and priorities
• Baseline snapshot: mention, citation and share-of-voice rates per engine and competitor
• Citation-source map and gap list of queries where competitors appear and you do not
• Crawler access, WAF and raw-HTML check per AI agent with owner decisions recorded
• Shipped fixes tied to gap queries and a follow-up snapshot comparison

Proof

Two scored snapshots on the same query set and engines (at least 3 sampled answers per query per engine), the raw answer files, and a comparison table showing change per entity, engine and targeted gap query.

Try

• $ai-search-visibility Why doesn't ChatGPT or Perplexity recommend us for feature flags? Measure it and fix it
• $ai-search-visibility Set up AI search visibility tracking against our three main competitors
• $ai-search-visibility Check whether AI crawlers can read our docs and pricing pages

Codex writes churn definitions finance will sign, builds monthly logo and revenue churn, GRR/NRR and cohort retention from billing data, separates voluntary from involuntary churn, analyses stated reasons and pre-churn behaviour, fixes failed-payment recovery (retries, card updates, dunning), and ships an honest cancel flow with reason-matched offers measured against a randomised holdout.

You end up with

• Signed-off churn definitions and SQL that produces logo churn, GRR and NRR monthly
• Cohort retention table and churn split by plan, tenure, and voluntary vs involuntary
• Ranked churn reasons combining survey answers with observed pre-churn behaviour
• Failed-payment recovery fixes with a before/after recovery-rate table
• Cancel flow with reason-matched save offers and a 30/60/90-day holdout readout

Proof

Monthly churn and cohort tables from the bundled script reconciled against your billing dashboard, failed-payment recovery before and after the fixes, and a holdout readout showing retained-customer difference at 30, 60 and 90 days with intervals.

Try

• $churn-analysis-save-flows What is our real churn rate? Split it into voluntary and involuntary and show cohorts
• $churn-analysis-save-flows Build a cancellation flow with save offers and measure it properly with a holdout
• $churn-analysis-save-flows Failed payments are killing us - fix our dunning and show the recovery rate

Codex turns your product questions into a versioned tracking plan, audits existing events, defines naming rules and a typed properties dictionary, generates a typed TypeScript tracker with vendor transports, migrates call sites flow by flow with dual-writes for renamed events, validates staging captures against the plan, and adds CI checks and a governance doc for future changes.

You end up with

• Versioned tracking-plan.json where every event has a question, owner, trigger and typed properties
• Generated TypeScript tracker that turns unknown events or bad properties into compile errors
• Call sites migrated per flow with tests, and a dual-write plan for renamed events
• Staging QA validation report with zero failures and full coverage of active events
• CI checks for plan lint, breaking changes and stale generated code, plus GOVERNANCE.md

Proof

Before/after audit counts (event names, naming styles, raw vendor calls), the passing validate output on a staging capture with coverage of all active events, and CI runs of lint and plan diff.

Try

• $product-analytics-rollout Our event names are a mess - design a tracking plan and implement typed analytics
• $product-analytics-rollout Set up product analytics with PostHog and validate the events in staging before launch
• $product-analytics-rollout We're moving from Mixpanel to Amplitude; migrate our tracking without breaking dashboards

Codex sets the launch goal and baseline, builds a T-14 to T+7 calendar with owners, drafts and checks every asset (changelog, quickstart, demo, cards, Product Hunt listing, Show HN, X thread, email), load-tests and hardens the signup path with alerts and an incident plan, runs the reply rota within each venue's rules, and ends with a readout of signups and activation by source.

You end up with

• Launch calendar from T-14 to T+7 with owners, venues by day and a reply rota
• Reviewed launch assets plus a preflight report on every linked URL and social card
• Load test results, hardening checklist, launch-day alerts and an incident plan with roles
• Venue posts drafted to Product Hunt, Hacker News and X norms, with prepared answers
• Post-launch readout: signups, activation and paid by source vs baseline, plus the retro

Proof

Preflight output for every launch URL, load-test numbers at target load, the launch-day log, and a readout from the bundled script comparing launch and after windows with the pre-launch baseline by source.

Try

• $launch-week-playbook We're launching our CLI on Product Hunt and Hacker News in two weeks - plan the whole week
• $launch-week-playbook Make sure our signup flow survives launch day traffic and set up monitoring
• $launch-week-playbook Our launch was last week - put together the readout by traffic source

Codex inventories your Postgres or MySQL tables, prepares logical replication or binlog safely, deploys Debezium (or works with a managed tool), lands a raw changelog and merged current-state tables with ordering guards and delete handling, defines schema evolution rules, hands off from backfill to streaming without gaps, monitors lag end to end and reconciles source and target with bucketed checksums.

You end up with

• Source prepared for CDC with WAL/binlog retention caps and slot monitoring in place
• Debezium connector config, raw changelog tables and idempotent merge jobs per table
• Written schema evolution policy rehearsed on staging
• Heartbeat-based end-to-end latency, lag and connector alerts that were test-fired
• Bucketed row-count and checksum reconciliation with drill-down to individual keys

Proof

Reconciliation output showing matching bucket counts and checksums per table, p50/p95 heartbeat latency over 24h, alert firings from staged failures, and replay and failover drill results.

Try

• $cdc-pipeline-build Replace our nightly Postgres dumps with Debezium CDC into Snowflake, including deletes.
• $cdc-pipeline-build Our CDC pipeline to BigQuery has duplicate and missing rows. Fix the ordering and prove the tables match.
• $cdc-pipeline-build Set up MySQL binlog CDC into Databricks Delta with lag monitoring and a backfill plan for a 2 TB table.

Codex audits your manifest for layer and lineage violations, writes staging/intermediate/marts conventions, refactors in lineage order with row-level equivalence checks, adds PK tests, unit tests and enforced contracts on key marts, fixes incremental models, wires slim CI with state:modified and defer, then reports run time and warehouse cost before and after.

You end up with

• Audit of every model's layer, violations, missing tests and slowest models, before and after
• Written layer conventions and a lineage-ordered refactor plan in small reversible PRs
• Equivalence-checked refactors, PK tests, unit tests and enforced contracts on public marts
• Corrected incremental models and a slim CI job that builds only state:modified+
• Evidence report with identical-command run time and cost comparison

Proof

Before/after audit counts from the manifest, a per-model timing diff from run_results.json for the same command and target, cost from query history for tagged runs, and audit_helper equivalence results per refactored model.

Try

• $dbt-project-overhaul Our dbt project has 600 models and marts read raw sources directly. Clean it up without breaking dashboards.
• $dbt-project-overhaul dbt runs take 3 hours and CI rebuilds everything. Set up slim CI and fix our slow incremental models.
• $dbt-project-overhaul Add tests and contracts to our key dbt marts and prove the refactor didn't change any numbers.

Codex decomposes your warehouse bill from usage views into compute, idle, serverless and storage, ranks costly query patterns, users and pipelines, plans changes like auto-suspend, sizing, partitioning and refresh schedules, applies them one scope at a time with rollbacks, and verifies each one in a savings ledger against daily metering or billing data.

You end up with

• Spend breakdown reconciled to your invoice, with idle cost per warehouse or reservation
• Ranked list of the most expensive query patterns, users and pipelines with owners and levers
• Applied changes with rollback commands and side-effect checks on failures and latency
• Savings ledger with before/after daily cost per scope and a noise check per change
• Guardrails (resource monitors, byte limits, cluster policies) and a monthly review routine

Proof

A savings ledger where each change shows mean daily cost of its scope before and after, from metering or billing exports over equal windows, with noise and confound flags, plus failure and latency checks.

Try

• $warehouse-cost-optimization Our Snowflake bill doubled in six months. Find out why and cut it without breaking dashboards.
• $warehouse-cost-optimization Rank our most expensive BigQuery queries and users, then fix the worst ones and prove the savings.
• $warehouse-cost-optimization Set up a savings ledger for our Databricks SQL warehouses and verify each change against billing.

Codex picks the first datasets from your incident history, drafts versioned contracts with owners, schema and semantic rules and freshness/volume service levels, adds breaking-change detection to producer CI, builds warehouse checks from the same contract, routes failures to the producer on-call with a runbook and circuit breaker, and proves every check fires.

You end up with

• Versioned contract files for your highest-risk datasets, approved by producer and consumer owners
• Producer CI check that fails breaking changes lacking a major version bump
• Warehouse schema, semantic, freshness and volume checks generated from each contract
• Alert routing, per-contract runbooks and a circuit breaker for downstream builds
• Evidence report with failing and passing CI runs and controlled check firings

Proof

Linked CI runs where a breaking contract change failed and an additive one passed, logs of each warehouse check firing on a deliberately bad dev load, and a week of check results with false-positive counts.

Try

• $data-quality-contracts The app team keeps renaming columns and our finance dashboards break. Set up data contracts.
• $data-quality-contracts Add freshness and volume monitors to our raw orders tables and page the owning team when they fail.
• $data-quality-contracts Make the checkout service's CI fail when someone makes a breaking change to the orders schema.

Codex frames the decision and horizon, audits your history, scores naive and seasonal baselines on rolling-origin folds, backtests ETS/ARIMA, Prophet and LightGBM on the identical folds, checks interval coverage, picks the model by evidence, then ships a scheduled pipeline with versioned forecasts, publish checks, retraining and accuracy monitoring with alerts.

You end up with

• Framing doc with horizon, granularity, data latency and the planning quantile
• Baseline and model comparison on identical backtest folds, per series and per fold
• Calibrated prediction intervals with measured coverage
• Scheduled pipeline writing versioned forecasts with model version and cutoff
• Accuracy monitor at the decision lead time that alerts on breaches

Proof

A comparison table of every model and baseline on the same rolling-origin folds (MASE, WAPE, bias, interval coverage), the fold definitions file, shadow-period accuracy vs the old forecast, and monitor output.

Try

• $forecasting-pipeline Forecast daily support tickets 8 weeks ahead per team so we can plan staffing, with intervals.
• $forecasting-pipeline Our revenue forecast is a spreadsheet and always wrong. Build a backtested pipeline that retrains monthly.
• $forecasting-pipeline Compare ETS, Prophet and LightGBM for our SKU demand forecast against baselines and ship the winner.

Codex inventories metric definitions across SQL, LookML, Tableau and dbt, surfaces conflicting versions with reproduced numbers, writes definitions and decision records for owners to approve, implements them in MetricFlow or Cube, tests them with config validation, key tests and reconciliation against legacy numbers, and publishes a metrics catalog.

You end up with

• Metric inventory with every conflicting definition located to file and line
• Owner-approved definitions and decision records explaining each resolved conflict
• Semantic layer implementation in dbt MetricFlow or Cube for your top metrics
• Reconciliation checks proving new numbers match approved legacy numbers by dimension
• A metrics catalog with owner, formula, grain, timezone, allowed dimensions and status

Proof

Scanner output of conflicting definitions, decision records with owner approval links, passing semantic-layer validation in CI, and reconciliation tables of legacy vs new values by period and dimension.

Try

• $metrics-layer-design Finance and product dashboards show different revenue. Find every definition and set up one source of truth.
• $metrics-layer-design Set up the dbt Semantic Layer for our top 15 metrics and prove the numbers match our current reports.
• $metrics-layer-design Build a Cube data model for our KPIs and write a metrics catalog people can actually use.

Codex scans every schema by column name, samples content with validated detectors (Luhn, IBAN, SSN rules, emails, tokens), builds a reviewed PII register, applies tags and masking or tokenization policies in Snowflake, BigQuery, Databricks or Postgres, scrubs logs at the source, builds masked dev copies, and reports protection coverage. Engineering evidence, not legal advice.

You end up with

• PII register across databases, warehouse and logs with type, sensitivity and owner
• Native tags plus masking, tokenization and row policies with role tests
• Log redaction at the source with a CI test that proves it
• Repeatable masked dev/staging copy job verified by a clean rescan
• Coverage report and CI check that fails on unprotected high-sensitivity columns

Proof

Name and content scan outputs with masked examples only, role tests showing masked vs clear counts per policy, a clean scan of the dev copy, and a coverage report of classified vs protected columns.

Try

• $pii-discovery-and-masking Find all the PII in our Snowflake account and mask it for analysts, but keep emails joinable.
• $pii-discovery-and-masking Our logs have customer emails and tokens in them. Find where and stop it at the source.
• $pii-discovery-and-masking Give developers a masked staging copy of production Postgres and prove there is no PII left.

Codex turns company goals into a validated KPI tree, writes definitions with owners and targets, implements tested SQL per KPI, lays out one screen with value, change, target status and freshness on every tile, generates freshness checks from the spec, sets up a weekly review with a pre-filled agenda, and measures adoption from BI usage logs.

You end up with

• KPI tree linking every tier-1 metric to a company goal, validated by script
• Definitions, owners, targets and tested SQL for each KPI
• One-screen dashboard layout with chart choices and freshness indicators on every tile
• Weekly review ritual with an auto-generated agenda sorted by off-track KPIs
• Adoption numbers from BI usage logs after launch

Proof

KPI spec validation output, SQL test results and finance reconciliation for closed periods, a freshness badge shown turning stale on an old table, the first generated review doc, and weekly viewer counts from BI logs.

Try

• $executive-kpi-dashboard Build our leadership KPI dashboard from our FY27 goals, with owners and targets for each metric.
• $executive-kpi-dashboard Our exec dashboard has 40 charts nobody trusts. Cut it to a one-screen scorecard with freshness indicators.
• $executive-kpi-dashboard Set up a weekly business review ritual around our KPI dashboard with an auto-generated agenda.

Codex pins the commit, builds a fact sheet from the code and git history, maps the architecture, measures quality and tests, triages secrets, SAST and dependency scans, reviews licenses, bus factor, delivery and scalability risks, runs a structured interview, and rates nine areas against a fixed rubric. A checker refuses any finding whose evidence does not resolve.

You end up with

• Executive summary with a red/amber/green rating for nine areas and the top risks
• Architecture overview with a C4 container diagram and data-store map
• Triaged security, dependency and license findings, with secrets redacted and counsel questions listed
• Team and bus-factor analysis from git history, reported in aggregate
• Remediation list with effort ranges labeled as estimates and their basis

Proof

Every finding cites file:line at a pinned commit, a saved scan artifact or an interview note, and the bundled findings_check.py must exit 0 (all evidence resolves) before the report ships.

Try

• $codebase-due-diligence-report We're acquiring this company. Do technical due diligence on their repos and give me a red/amber/green report.
• $codebase-due-diligence-report Assess this vendor's codebase before we sign: security, maintainability, key-person risk.
• $codebase-due-diligence-report What are the biggest technical risks in this repository for an investor? Back each one with evidence.

Codex inventories each repository, picks pnpm workspaces, Turborepo, Nx or Bazel from a decision table, rehearses a history-preserving import with prefixed tags, unifies dependency versions, wires affected-only CI, caching and CODEOWNERS, then runs a confirmed cutover checklist. You get a monorepo where git log and blame still work, plus a verified report.

You end up with

• Monorepo with each source repo under its own path, full commit history and prefixed tags
• Unified dependencies with one lockfile per ecosystem and a list of justified exceptions
• Affected-only CI with task caching, an aggregate required check and a full build on main
• CODEOWNERS and import-boundary rules generated from the repo inventory
• Cutover checklist with rollback plan, completed and dated

Proof

Per-repo commit, file and tag counts from the import script's verify step, build/test parity per package, and CI task selection plus wall-clock for three representative changes, old setup vs new.

Try

• $monorepo-migration Merge our api, web and shared-ui repos into a pnpm + Turborepo monorepo without losing history.
• $monorepo-migration Should we use Nx, Turborepo or Bazel for our monorepo? Then do the migration.
• $monorepo-migration Plan and run the cutover from five repos to one monorepo with affected-only CI.

Codex inventories what the legacy system really does from code, traffic and jobs, hunts hidden behaviour such as triggers, cron jobs, file drops and customer special cases, writes three competent options, models cost and schedule for each with Monte Carlo from team estimates, rates strangler seams, and records the decision as an ADR with a first-slice plan.

You end up with

• Capability inventory traced to code and production usage, with unused capabilities flagged for deletion
• Hidden behaviour register with evidence and how each option handles it
• P50/P80/P95 effort, schedule and cost per option from the team's three-point estimates
• Seam map with rollback and parity proof per slice, plus a ready first slice
• Decision record (MADR) with revisit triggers and named approvers

Proof

Inventory rows link to file:line and traffic counts, the option model is reproducible from saved inputs and seed, and the weighted criteria table names who scored it before the decision was taken.

Try

• $legacy-rewrite-decision Should we rewrite our old PHP billing system or refactor it? Give me an evidence-based recommendation.
• $legacy-rewrite-decision Plan a strangler-fig migration off our legacy monolith and show the cost range versus a rewrite.
• $legacy-rewrite-decision Find everything this legacy app does, including the hidden stuff, before we decide to replace it.

Codex pulls JUnit results from your CI history, finds tests that pass and fail on the same commit, quarantines them with owners and expiry, fixes root causes one PR at a time with rerun-loop proof, ranks slow tests by total time paid, aims new tests at churn x complexity x uncovered files, and re-measures over an equal window.

You end up with

• Flaky and broken test inventory built from CI history and same-commit rerun evidence
• Quarantine file, CI enforcement check and non-blocking quarantine job with owners and expiry
• Root-cause fixes per flaky test, each with a before/after rerun loop in its PR
• Risk-ranked list of files to test next, with new tests merged for the top targets
• Trust scorecard: flake rate, rerun rate, suite duration and escaped bugs before and after

Proof

Before/after scorecard from the same CI workflow over equal windows, produced by the bundled flake_report.py, plus per-test rerun loops (failures out of n runs) linked from each fix PR.

Try

• $test-suite-rescue Our CI is flaky and everyone just reruns it. Find the flaky tests and fix them.
• $test-suite-rescue The test suite takes 35 minutes and still misses bugs. Rescue it and show me before/after numbers.
• $test-suite-rescue Set up a quarantine process for flaky tests with owners and expiry dates.

Codex mines git for hotspots (churn x complexity, fix density, author spread), gathers debt from CI, incidents and dependencies, writes each item with evidence and estimated interest ranges, validates the ledger, ranks it by cost of delay over effort into a roadmap that fits your capacity, and drafts a one-page leadership brief.

You end up with

• Hotspot table by file and area from your git history, each top file with a human diagnosis
• Validated debt ledger: owner, evidence, interest and effort ranges with a written basis per item
• CD3-ranked roadmap fitted to one or two capacity levels, deadline items pulled forward
• One-page leadership brief asking for a specific funding decision
• Tracking plan so the same commands show progress next quarter

Proof

Every number traces to a command: hotspots.py output at a named commit, gh PR timing queries, incident links, and ledger.py validation; estimates are labeled as ranges with their basis and a sensitivity check.

Try

• $tech-debt-ledger Build a tech debt ledger for this repo and a roadmap we can pitch to the CTO.
• $tech-debt-ledger Where is our code rotting? Rank the hotspots and estimate what they cost us.
• $tech-debt-ledger We have 30 engineer-days a quarter for debt. What should we spend it on and why?

Codex builds one inventory from all your lockfiles, checks OSV advisories, release history, deprecation, maintainer count, Scorecard, license class against how you ship, look-alike names and transitive bloat, then walks each risky package through a replace / upgrade / pin / vendor / keep rubric, executes the safe fixes in small PRs, and adds CI guardrails.

You end up with

• Single dependency inventory across npm, pnpm, PyPI, Go and Cargo lockfiles, tied to a commit
• Risk table per package: advisories, last release, maintainers, license class, closure size
• Decision per risky dependency with owner, ticket and evidence links
• License appendix written as precise questions for your counsel
• CI guardrails: vulnerability scan, update bot policy, license check, new-dependency checklist

Proof

Flag counts before and after remediation from identical runs of the bundled dep_risk.py against a named commit, with registry and OSV sources and dates, plus merged PRs with test results.

Try

• $dependency-risk-audit Audit our dependencies for abandoned packages, license problems and anything suspicious.
• $dependency-risk-audit A customer asked how we manage third-party component risk. Run a dependency risk audit and give me the evidence.
• $dependency-risk-audit Which of our npm and Python dependencies should we replace, pin or vendor?

Codex inventories existing docs, measures your real conventions from code and git history, verifies the setup steps on a clean environment, writes setup, architecture, conventions, testing, workflow, release, on-call and glossary pages with owners and review dates, and installs a CI check that fails when pages reference paths, scripts or env vars that no longer exist.

You end up with

• Handbook pages in your repo, each with an owner, review date and cited sources
• Setup page verified on a clean environment with measured clone-to-green-tests time
• Conventions page stating measured practice with evidence, aspirations clearly labeled
• Staleness checker in CI for broken paths, missing scripts and env vars, plus weekly drift report
• List of gaps between documented and actual process, handed to owners

Proof

A clean-environment setup run log, convention shares measured by the bundled extractor, and the checker's exit 0 on the final handbook plus a deliberate-break run that fails and names the page.

Try

• $engineering-handbook-generator Generate an engineering handbook for this repo that new hires can actually follow.
• $engineering-handbook-generator Our onboarding docs are out of date. Rebuild them from the code and add a check so they stay current.
• $engineering-handbook-generator Document our real coding conventions and release process, with evidence.

Codex mines git history, manifests and PRs for decision points (datastore and framework choices, replacements, infrastructure and tooling adoptions, restructures), selects the ones that shape the system, reconstructs each from commits, PRs and short interviews, writes MADR records marked as retroactive with sources labeled, and installs a small process for new ADRs.

You end up with

• Candidate list of decisions found in history, grouped, with reasons for what was kept or dropped
• 10-25 MADR-format ADRs with original dates, evidence lists and labeled sources
• Supersession links between replaced and replacing decisions
• ADR process: numbering script, generated index, PR template prompt, CODEOWNERS entry
• Open-questions list for decisions whose rationale could not be recovered

Proof

Each ADR cites the commits, PRs or documents it was reconstructed from, with claims labeled as evidence, recollection or inferred; the report maps every mined candidate to an ADR or a reason for dropping it.

Try

• $adr-backfill Nobody remembers why we chose MongoDB and Kafka. Backfill ADRs for our main architecture decisions.
• $adr-backfill Mine our git history for architecture decisions and write them up in MADR format.
• $adr-backfill Set up an ADR process for this repo and document the decisions we've already made.

Codex scopes the product and a WCAG-EM style sample, runs axe-core scans, guides keyboard, zoom, visual and screen reader testing for all 55 WCAG 2.2 A/AA criteria, records evidence per criterion, applies VPAT 2.5 conformance terms by strict rules, validates the worksheet, renders the report tables, and builds a remediation roadmap. Engineering artifact, not legal advice or certification.

You end up with

• Findings worksheet covering all 55 WCAG 2.2 A/AA criteria with method, evidence, tester and date
• WCAG report tables in VPAT 2.5 structure, validated for allowed terms and required remarks
• Evidence pack with scope, sample, environment matrix, issues and screen reader notes
• Remediation roadmap grouping issues by root cause, owner and target release
• Guidance for 508 and EN 301 549 chapters when the buyer needs those editions

Proof

Evidence pack linking every conformance level to a tester, date, method and sample, axe-core result files, issue records with AT output, and acr_builder.py build --check passing with zero errors.

Try

• $vpat-acr-builder A state agency wants a VPAT for our web app. Test it against WCAG 2.2 AA and build the ACR.
• $vpat-acr-builder Our VPAT is three years old and says 'Supports' everywhere. Redo it honestly with evidence.
• $vpat-acr-builder We need an INT edition ACR covering 508 and EN 301 549 for our SaaS and iOS app.

Codex measures drift between your OpenAPI spec and the routes your code serves, runs a contract test against a disposable instance, fixes the spec, builds an error catalog from real error paths, writes a quickstart and times it, regenerates the reference, and wires CI so every marked code sample runs. You end with docs that are checked on every change.

You end up with

• OpenAPI spec reconciled with the implementation, with drift measured before and after by script
• Contract test (Schemathesis or Prism proxy) running in CI against a disposable instance
• Error catalog built from the code's real error paths, each with a captured example response
• Quickstart timed in a clean environment, targeting a first successful call in under five minutes
• Every marked docs code sample executed in CI with JUnit output

Proof

Evidence report with before/after drift counts from spec_route_diff.py, contract-test failures by check from JUnit output, examples passing in CI, and timed quickstart runs in a clean container.

Try

• $api-docs-overhaul Our API docs are out of date and customers say the examples fail. Overhaul them.
• $api-docs-overhaul Check our openapi.yaml against what the Express app actually serves and fix the drift.
• $api-docs-overhaul Write a quickstart for our API that gets someone to a first call in five minutes, and test it in CI.

Codex defines the first call, instruments and baselines time to first call, structures the portal around it, designs safe self-serve API keys with test and live separation, generates SDKs from your OpenAPI spec with sandbox smoke tests in CI, specifies an isolated sandbox, sets up status and changelog pages, and measures TTFC and activation again after launch.

You end up with

• Portal information architecture with a CI-tested quickstart one click from every page
• API key lifecycle design: prefixed test/live keys, hashed storage, rotation, revocation, leak response
• SDKs generated from the spec with pinned generator versions and sandbox smoke tests
• Sandbox design with isolation test, seed data, failure triggers and test-mode third parties
• TTFC and activation funnel measured before and after launch from real events

Proof

Report with before/after median and P90 time to first call and activation from ttfc.py on your event data (or timed clean walkthroughs when no data exists), plus a launch checklist with CI jobs and test evidence.

Try

• $developer-portal-launch We're opening our API to partners. Plan and build the developer portal, keys, sandbox and SDKs.
• $developer-portal-launch Measure how long it takes a new developer to make their first API call and cut it down.
• $developer-portal-launch Generate TypeScript and Python SDKs from our OpenAPI spec and test them against the sandbox in CI.

Codex extracts the questions from the buyer's spreadsheet, builds or refreshes an answer library from your policies, infrastructure code and attestations, matches each question to library entries, drafts answers with citations, routes unknowns to named owners instead of guessing, and writes approved answers back into the buyer's own file with an evidence index.

You end up with

• Answered copy of the buyer's questionnaire in its original format, original file untouched
• Reusable answer library with question variants, evidence citations, owners and review dates
• Open-items list routed to owners for every question the evidence cannot support
• Internal gap list of controls found missing or partial while mining code and config
• Evidence index mapping every answer to the policy section or file:line behind it

Proof

Report with coverage counts (DRAFT/REVIEW/UNKNOWN to approved), a spot-check log against cited evidence, a contradiction scan, owner approvals per domain, and a round-trip diff showing the buyer's questions are unchanged.

Try

• $security-questionnaire-responder A prospect sent a SIG Lite spreadsheet. Draft answers from our policies and Terraform, and flag anything we can't back up.
• $security-questionnaire-responder Fill out this CAIQ v4 for our SaaS product and build an answer library we can reuse.
• $security-questionnaire-responder We keep getting custom security questionnaires. Turn our last five into a library with evidence.

Codex inventories the SDKs, permissions and required-reason APIs in your release build, drafts App Store privacy labels, the iOS privacy manifest and Play Data safety from one table, pre-checks the build against common rejection reasons with evidence, validates metadata and screenshots against store limits, plans a phased release and staged rollout with halt criteria, and keeps a rejection-response playbook ready.

You end up with

• SDK and permission inventory scanned from the source and the release build
• App Privacy answers, PrivacyInfo.xcprivacy and Play Data safety drafted from one inventory
• Review pre-check with pass/fail evidence for the most common rejection reasons
• Metadata and screenshots validated against store limits by script
• Phased release and staged rollout plan with halt criteria and a rejection playbook

Proof

Report with the build inventory, owner-confirmed privacy declarations, a pre-check table with screenshots or recordings per item, store_assets_check.py passing, review outcome per store, and rollout steps with metric readings.

Try

• $app-store-launch-kit We're submitting our React Native app to both stores for the first time. Get us through review.
• $app-store-launch-kit Apple rejected us under 5.1.1. Figure out why and redo our privacy labels from the actual SDKs.
• $app-store-launch-kit Set up a phased release for our iOS update and a 5% staged rollout on Play with halt criteria.

Codex runs structured discovery, writes verifiable scope and explicit non-goals, compares two or three architecture options, builds a work breakdown with three-point estimates, rolls them up with PERT and a seeded Monte Carlo simulation including a risk register, and drafts the proposal with assumptions, risks and P50/P80/P90 ranges traceable to every task.

You end up with

• Discovery question list tagged by what each answer changes in the estimate
• Scope written as verifiable outcomes, with non-goals and an assumptions list
• Architecture options comparison with a reasoned recommendation and diagram
• Work breakdown with three-point estimates and P50/P80/P90 effort and cost ranges
• Risk register with probabilities, impact ranges, basis and owners

Proof

Appendix with the full WBS, the exact estimate.py command (seed, runs, correlation) and its output, so anyone can rerun the simulation and get the same P50/P80/P90 figures.

Try

• $technical-proposal-and-estimate Write a proposal and estimate for this RFP. We're three engineers and bill time and materials.
• $technical-proposal-and-estimate The client wants a fixed price for migrating their Rails app to our platform. Give me an honest range.
• $technical-proposal-and-estimate Sanity-check this estimate spreadsheet before I send it and tell me what's missing.

Codex measures how your commits and PRs are written today, configures categories and label mappings, generates developer, customer and JSON notes from conventional commits and PR labels, replays two past releases to tune the rules, adds PR checks so every user-visible change carries a release note, and wires publishing to CHANGELOG.md, GitHub Releases, docs and in-app.

You end up with

• Developer changelog, customer release notes and an in-app JSON feed from one command
• Breaking changes called out with what users must do, flagged when the migration note is missing
• PR title lint and a release-note presence check proposed as required CI checks
• Tag-triggered workflow that creates a draft GitHub Release for human review

Proof

Report replaying two past releases: items in the published notes vs generated, misses, noise and flags, with the rule change that fixed each miss, plus per-category counts for the current release.

Try

• $release-notes-pipeline Automate our release notes: a changelog for developers and plain-language notes for customers.
• $release-notes-pipeline Our changelog is a commit dump. Set up a pipeline with breaking-change callouts and a what's new feed.
• $release-notes-pipeline Add a CI check so every PR either has a release note or a skip-changelog label.