Imported from codepharm99/codex-g3 (
skills/g3/SKILL.md). Install upstream withnpx skills add codepharm99/codex-g3 --skill g3. Copyright stays with the author.
name: g3 description: Run a compact Codex-native feature loop: implement a bounded task, review the actual diff, run real verification, and check acceptance criteria. Use when the user asks to build or fix a scoped feature and wants it checked before handoff.
g3 — evidence-first feature loop
Use this skill only for a concrete, bounded implementation or bug-fix request. Work in the current session and current repository; do not call Claude-specific workflow APIs, demand a specific model, create a branch, commit, push, or install dependencies unless the user separately asks.
Contract
The loop is:
builder → breaker → hopper → solo → repair if needed (maximum two rounds) → final hopper
Each stage must use the files and command output left by earlier stages. Do not describe a stage as run unless you actually performed its work.
Stage 0 — scope
State the task, its acceptance criteria, and the smallest expected file scope. Read repository instructions first (AGENTS.md, then relevant local instructions). Inspect the current working tree. If unrelated user changes exist, preserve them and keep the task to its named files.
Stage 1 — builder
Follow the g3-builder skill: inspect the existing path, identify the smallest reusable sibling pattern, implement the change, and add or update the most relevant test. Run the narrow verification command that establishes the new behavior.
Stage 2 — breaker
Follow g3-breaker against the actual diff. It is read-only. Findings must include severity, a concrete reproduction or evidence, and affected files. Ignore style nits and theoretical risks without an actionable failure mode.
Stage 3 — hopper
Follow g3-hopper. Run the narrow feature test first, then the project’s relevant typecheck, lint, build, or integration command when it is known and proportionate. Report every command and its exit status. Do not fabricate green status when a command cannot run.
Stage 4 — solo
Follow g3-solo. Translate the original request into 2–5 observable acceptance checks and validate each using test output, a command, or precise code inspection.
Repair loop
If Breaker reports a blocking issue, Hopper reports a failing command, or Solo reports a failed criterion, give Builder only those findings and make the smallest repair. Repeat Breaker, Hopper, and Solo. Stop after two repair rounds; report the unresolved findings instead of burning time.
Handoff
Report: files changed; implementation choice and reused sibling; exact verification commands and results; acceptance checks; and any unresolved limitation. Only say ready when all available checks passed and no blocking finding remains.