Codex adaptation boundary

This mirror uses the native Codex project-local skill root .agents/skills/verify-<app>/. It discovers the real surface from the repository, selects the proof path through proof-orchestrator, and respects the selected model and effort through model-capability-router. The native verification runner is required for a verified result. If the harness or startup is missing, preserve the project and report blocked. Generation never installs a global skill, publishes an artifact, opens a PR, kills by process name, or changes product code. The feature-map references intentionally retain the reproducible upstream control-notes commands; adapt them to concrete commands observed in the target repository before use. Map browser/Electron/web actions to cursor-control-ui, and CLI/TUI actions to cursor-control-cli, only when those skills are installed and applicable; otherwise record the exact surface gap. The bounded CLI fixture uses separate subprocesses, runs syntax/version/health Doctor checks, drives each mapped feature, captures stdout/stderr/exit plus regular-file side effects, cleans only declared app state, and writes only the explicit project-local skill tree. A separate disposable local web fixture was driven through the native Codex in-app browser with accessibility-tree and screenshot evidence; this still does not claim production/live target or native-host verification.

Create a verification skill

Every serious project needs a scripted way to drive the real app and prove behavior: launch it, exercise a feature the way a user would, and capture evidence. This skill generates that as a project-local skill (.agents/skills/verify-<app>/) tailored to the repo. You write the generator's output for the next agent, not for a human: it will be read cold, mid-task, by an agent that has never seen the app.

1. Interview the repo, not the user

Answer these from the codebase and only ask the user what you cannot observe:

• Surface: what does a user actually touch? A web UI, a CLI/TUI, a desktop app, an API, a mobile app, a library? A repo can have several; pick the primary one and note the rest.
• Run: how does the app start locally? Prefer the repo's own documented dev command (package scripts, Makefile, README quickstart). Note ports, env vars, seed data, auth.
• Drive: how can an agent interact with it programmatically? Existing harnesses first — Playwright/Cypress specs, expect scripts, PTY helpers, curl-able endpoints, a debug port. Only then pick a generic recipe: browser/CDP for web and Electron, a tmux/PTY harness for CLI/TUI, plain HTTP for services.
• Observe: what evidence can be captured? Screenshots, terminal transcripts, response bodies, logs, exit codes, DB state.
• Isolate: can two instances run side by side (ports, data dirs, profiles)? If not, say so in the generated skill: refusing to double-drive a shared instance beats corrupting the user's session.

If the checkout doesn't build or start as-is, fix that first (or report it precisely) before generating; a skill written against a broken base teaches wrong steps. When an irrelevant missing asset blocks startup (a static dir the API never serves, a sample config), the generated skill may create it, clearly marked as verification scaffolding, and remove it in cleanup.