Runs one request through the whole governed cycle in a single pass — research, spec, challenge, council, build, review, verify, security, audit, ship — and stops only to hand a person a tested thing to try. Your invocation is the standing approval; nobody else steps in until the end. The bar is the green gate plus an independent critic's verdict on the real artifact, looped until both hold. Trigger for "finish this without me, give me something to test", "run the whole gauntlet to a green gat...
Scanned 9/3/2026
Install to Claude Code
npx -y skills add arcasilesgroup/ai-engineering --skill ai-goal --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Ai Goal?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/arcasilesgroup-ai-goal)More formats (shields.io, HTML) on the badges page.
---
name: ai-goal
description: >-
Runs one request through the whole governed cycle in a single pass — research, spec,
challenge, council, build, review, verify, security, audit, ship — and stops only to
hand a person a tested thing to try. Your invocation is the standing approval; nobody
else steps in until the end. The bar is the green gate plus an independent critic's
verdict on the real artifact, looped until both hold. Trigger for "finish this without
me, give me something to test", "run the whole gauntlet to a green gate". Not for one
stage on its own — call that stage directly. Not for approving anything: you finish,
then hand over.
license: Apache-2.0
compatibility: needs git
disable-model-invocation: true
---
# One run, no mid-run stop
`/ai-goal <goal>` is the person saying "this one runs without me". The whole cycle runs
in one pass and the person comes back only when there is a finished thing to test. The
invocation is the standing approval; you never ask again, and you never claim an approval
you did not earn.
## What it produces
The finished thing handed to the person: the change committed at `HEAD`, the
`ai-eng audit verify` gate output shown in full, and the acceptance checklist the person
runs against the real artifact.
## The order
Read `policy/skill-sequence.toml` and follow it; if that file is absent, refuse to
continue — the order is data, not prose. Load each stage's own skill and follow it:
`/ai-research`, `/ai-spec`, `/ai-challenge`, `/ai-council`, `/ai-build`, `/ai-review`,
`/ai-verify`, `/ai-security`, the audit verb, then `/ai-ship`.
## Tiers, per the repository's pin
Each stage runs on the tier the repository's `[models]` section configures — never a
model name coded into this skill, and never a provider the repository did not choose.
Ask the tier the stage deserves, matching `model_router`'s own mapping: research and
spec run on the **low** tier, security, review, plan and audit on the **top** tier, and
build, verify, ship (and everything the pin leaves untiered) on **medium**, falling back
to `default_tier` when a tier is not configured. The command event records which model
the pin says each verb routes to (`tier_model`) and what the surface actually ran
(`model`); the two are different facts and the run never conflates them.
## Tools are whatever the client has
The cycle uses only the tools present on this machine: the local floor (the repository,
the IDE and the assigned surface, the `ai-eng` harness, the model available) is always on,
and a web provider or NotebookLM is used only when the client configured it. An absent tool
degrades the stage that would use it — the research stage names `degraded-tool: <name>`
and carries on with the local floor. Nothing in this skill depends on a tool the client
does not have.
## Two bars, both green, neither negotiated
1. The governed gate: run `ai-eng audit verify` and show its output. Nothing silenced, no
suppressed test, no loosened bound. Green means the gate a person runs is green.
2. The goal: measurable acceptance criteria written into the spec. A critic in its own
context, with no memory of the builder's reasoning, compares the real artifact against
those criteria and answers met or not — one or the other, never maybe.
Not green is not done. A red bar sends the work back through build and the critics.
## The loop is bounded
Every red is a chance to build again, not an infinite chase. Two attempts per task and
failing recipe before you change course. When the verdict is close, the critic judges
blind: it never sees your reasons, only what you built. A fixed cap on automatic work and
a short no-progress guard stop a loop that is not converging. When the cap or the guard
fires, write a page a person can act on: what failed, what was tried, what the honest fix
costs. Never a silent stop, and never "until perfect" — that is not a stop condition.
## The cycle never waits, and the wall is measured
No step of an unattended run waits for input. A command that refuses is repaired, or the
turn closes with one line — `BLOCKED: <what is stopping you> — unblock: <one thing the
person can do in under a minute>` — and a fork that hangs past its box is a `TIMEBOXED`
verdict, never silence. One red never relaunches the whole gate: a new failure joins the
others, the batch is repaired together, and `just check-all` runs once and lists every
red step. At the close, the handover prints `ai-eng report vitals --session <id>` beside
`ai-eng audit verify`: the wall minutes are read from the event record, the budget is
`contract.CYCLE_WALL_BUDGET_MINUTES`, and the clock disqualifies a cycle and never
approves one.
## Simplicity is the standing bar
KISS, YAGNI, DRY, SOLID, BDD, TDD, Clean Code, Clean Architecture. When two answers both
work, the smaller one wins. Keep the change the smallest thing that works and delete what
the change obsoletes. A simpler path exists and you did not take it — that is a defect.
## What this is not
- "The gate is green, so the critic's verdict is redundant" — the bars are two and neither is negotiated: an independent critic with no memory of your reasoning must compare the real artifact against the acceptance criteria.
## Done when — stop, and hand over
Both bars are green, the committed change and its gate output are shown, and the person
holds the acceptance checklist to test the handover like a client. You do not approve the
work and you do not claim a green you did not produce — you finish, then you hand over.
The handover carries the `file://` link of `ai-eng report recap --spec <NNN> --base
<approval commit>` — the person tests the work against a page that says what changed,
not against your memory of it.Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!