autodev

name	autodev
description	Use when the user asks to take a task end-to-end autonomously (e.g. "autodev", "/autodev", "build this on autopilot"). Runs the full chain — plan → implement → review → PR → converge — stopping only at real decisions.
metadata	{"short-description":"Autopilot — plan, build, review, PR, converge"}

Autodev (Codex)

Full-pipeline autopilot, Codex-side. Same workflow as Claude's /autodev; this skill adapts it for a Codex cockpit.

Canonical procedure: read ~/.codex/skills/skyhook-skills-commands/autodev.md and follow it (chain, modes, plan gate, the --auto ceiling, hand-back). Apply these Codex translations wherever it names a Claude command:

Claude command	Codex equivalent
/plan-loop	the plan-loop skill
/review-loop	the review-loop skill
/cross-review (cross-model)	the claude-review skill — from Codex the secondary reviewer stays Claude (it reviews your work)
/qa	read the repo's .claude/commands/qa.md and follow it (Codex reads it as a file)
/pr (verify + open/update PR)	inline via git + gh: run /qa, then create/update the PR (stage relevant files only, --force-with-lease). Write the body per ~/.codex/skills/skyhook-skills-commands/pr.md — depth proportional to the change, lead with motivation + design, no review-fix trivia, re-derive don't append. (Codex especially tends to dump 4 terse bullets — don't.)
/fix-pr-loop (converge)	inline the reactive loop: wait for CI + bots (gh pr checks, gh pr view --json comments,reviews), triage each finding skeptically, fix the real ones, push, repeat until settled or capped. Don't block on CodeQL >5 min — if it's the only laggard, proceed and note CodeQL pending
/triage-findings, /fix-findings, /simple	no such commands — perform the discipline inline (read the real code, never auto-accept, cite evidence on skips, don't ping-pong, fix confirmed issues)

Non-negotiable invariants (don't let translation lose them):

• Default mode gates on the plan — stop for sign-off before code. --auto logs assumptions to NOTES.md and proceeds, but always stops for the ceiling: prod/deploy/data-migrations · external-publish/money · security/auth/secrets · breaking-public-API/destructive-file-ops.
• Triage every reviewer skeptically; never auto-accept. Cross-review only when nontrivial.
• Scenario-sensitive work needs a ledger before "done." For user-facing copy, diagnostics/remediation, detector precision, error classification, security/permissions, or UI states, list each scenario with expected final behavior/copy, source-of-truth evidence, self-review verdict, Claude status, tests/live proof, and open decision. Claude status is either the verdict or skipped: <reason> when cross-review was intentionally skipped. If review happened before later fixes, state whether the final head was re-reviewed.
• Risk / blast radius belongs in the hand-back. For nontrivial changes, state affected surface, likely failure mode, mitigation/test proof, and residual risk. Keep it proportional; low-risk copy/test-only work can be one sentence.
• Every loop caps and reports — never loop or proceed-past-a-blocker silently.
• Never merge, deploy, push to main, hard---force, or stage unrelated files. PRs are fine; shipping is the user's call.
• Narrate the run with the glyph-tagged phase banners and close with the end-of-run summary ledger defined in the canonical file (per-step counts, triage breakdowns, result line, --auto assumptions, open items).
• Phases are judgment calls, not a fixed sequence — decide which apply each run, and honor free-text steering in the invocation (e.g. consult claude, no PR, plan only, quick, focus on <area>) as an override, per the canonical file's directives section.
• UI / product-facing features: lean toward running visual-test + product-review in the review phase, before opening the PR (recommended, not forced — a skip is fine when small/non-visual, but must be stated). State visual-test and product-review status in the hand-back (ran/skipped + why), never silent. Don't open the PR blind to its own rendered result.