Skip to main content

autodev

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.

Source facts

Repository
skyhook-io/skyhook-skills
Last source activity
September 10, 2026 at 09:55
Detected SKILL.md language
English
Stars
1
Forks
0

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
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. **The AI reviewers + failing build/test CI are the primary signal** — wait for those, triage them. **Don't block on CodeQL >~2 min** — it's a secondary scanner; 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. - **Consider a review packet** before handing back, when the work would be hard to judge from the PR alone — large or multi-PR, a rendered surface, captured output worth showing, or open product calls. Judgement call, not a step; say if skipped.
View on GitHub