القائمة
Define and validate what ready-to-ship means beyond tests passing. Use when a repo needs release checklists, smoke tests, rollback plans, changelog/versioning guidance, deployment verification, or scripts/smoke-test.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Diagnose failed or unreliable agent workflows by classifying bad assumptions, missing observations, tool misuse, wrapper failures, hidden repair loops, incomplete validation, handoff gaps, and repeated failure patterns. Use after a failed harness run, flaky agent output, or confusing validation loop.
Review agent-generated changes against project rules. Use when asked for a review, before opening a PR, after large Codex edits, or when checking diffs for correctness, security, architecture, tests, docs drift, dependencies, migrations, and release risk.
Generate or maintain a minimal high-signal AGENTS.md for coding agents. Use whenever a repo needs agent instructions, an existing AGENTS.md is too long or vague, or project docs/scripts need a concise routing map for Codex.
Define and mechanically enforce architecture boundaries for a repo. Use when a project needs allowed dependency rules, forbidden imports, layer documentation, dependency maps, circular dependency checks, or protection against agent-created architectural drift.
Scaffold a new TypeScript web, mobile, API, or full-stack project with Better-T-Stack, then harden it with the Pax Fullstack Harness. Use whenever the user wants a new TypeScript app scaffold, mentions Better-T-Stack, asks for a modern type-safe stack, or wants Codex to start a repo that is agent-ready from day one.
Use guided Chrome DevTools MCP setup and workflows for browser runtime debugging. Use when a web app needs console, network, DOM, accessibility, Lighthouse, performance, responsive, or live-browser investigation beyond normal tests.
| name | release-readiness-harness |
| description | Define and validate what ready-to-ship means beyond tests passing. Use when a repo needs release checklists, smoke tests, rollback plans, changelog/versioning guidance, deployment verification, or scripts/smoke-test. |
Prevent agents from treating a passing test suite as the whole release decision.
Define readiness.
./scripts/validate or documented equivalent.Add release assets.
docs/release/checklist.mddocs/release/rollback.mdscripts/smoke-test where feasible; keep it fast and runtime/deployment-focused, not a default alias for full ./scripts/validate./health or the configured health endpoint.CHANGELOG.md when the project uses changelogs or the user asks.Wire checks.
ci-cd-harness for deployment gates.migration-and-schema-harness for migration risk.termination-gatekeeper so release readiness is not claimed before task completion evidence exists../scripts/smoke-test when present../scripts/validate separately from smoke evidence.