v1.0.0 to v1.0.0

---

name: quick-task

description: >-

Use when a change is small enough to skip the full task pipeline — one focused fix or

version: 1.0.0

author: ai-badger

license: MIT

platforms: [linux, macos, windows]

scope: default

metadata:

hermes:

tags: [workflow, fast-path, single-commit, tests, review]

related_skills: [task, test-economy, code-review-checklist, status-report, multi-agent-communication]

---

# quick-task

The fast lane between "just edit it" and the full `task` pipeline. One focused change,

planned in minutes, verified on the surface it touches, reviewed once, shipped as a single

## The shape (all of it, or escalate)

A change qualifies for quick-task only when every answer is yes:

- **One sentence.** You can state the whole change in one sentence a reviewer could act on.

- **One surface.** It touches one area — one module, one component, one workflow file, one

doc. Cross-layer work (API + client, schema + code, code + generated manifests) does not

fit; that is `task` work.

- **No rulings needed.** The owner's intent is already known; no design decision is being

made, only executed. New decisions are `task` (or `create-task-spec`) work.

Chores count: a dependency bump, a doc fix, a lint cleanup, a config tweak — as long as the

shape above holds.

## Flow

1. **Scope check.** State the one sentence and the touched surface. Run the five shape

questions; any "no" means stop and escalate to `task`. Say out loud that you are in

quick-task mode so the reduced ceremony is a decision, not an accident. When other

sessions share the project, announce the start on the bus — read

`multi-agent-communication` when parallel work is active.

2. **Minimal plan.** Three to six bullets in the working notes — what changes, which files,

which tests cover it, which docs need updating. No plan file, no ledger record, no

tracking artifacts. If the plan needs more than six bullets, escalate.

behavior, updated tests for changed behavior, and a run of the tests that cover the

touched surface. Follow the repo's own test discipline (which runner, which directory

tests run from). Do not fix unrelated failures you discover — note them and move on;

fixing the world is how quick-tasks become incidents.

- the touched surface's tests (only those), once per change — a fix makes the next run new,

and a re-run to watch it pass again is the theater the next bullet bans,

- the repo's lint for the languages touched,

- the repo's docs checks IF governed docs were touched — and record/update them per the

repo's own mechanism, inside the same commit,

- typecheck/build only if the repo's gate requires it for the touched paths.

A full suite run, e2e, or infrastructure validation is NOT part of quick-task — if you

believe one is needed, the change is bigger than the shape.

The CI variable decides what proves the push (test-run-economy invariant): CI alive —

public repos always — skip every slow gate, push, and treat CI's run as the verdict; read

it. CI dead or absent: run the project's full local gates once before the push; nothing

hooked up, one manual full-suite run first. Lint and docs gates sit on no skip side of

this trade — they run in both branches.

bullets — does the diff do exactly what was planned, do the tests assert behavior rather

than implementation, are there stray files, debug prints, or unrelated edits, does the

commit message describe it. For anything touching auth, money, data loss, or generated

contracts, make this pass a delegated second pair of eyes instead of self-review.

## Model tier contract

Quick-task uses the same delegation contract as `task`: `effort` picks the lane, `level` picks the model tier — they are independent.

The `level` field is optional (`low`, `medium`, or `high`), resolved to that model tier's preferred registry entry.

An explicit `model` always wins over `level`.

With neither `level` nor `model`, the dispatch inherits the session (or parent) default model.

The registry lives at `.ai-badger/model-groups.json`; it holds the IDs and prices, so this skill names neither.

See `.ai-badger/delegation.md` (reasoning-model dispatch) for lane routing.

## Gotchas

- **Discovered breakage is a fork in the road.** If the touched-surface run fails on code

you did not touch, or the fix clearly spans two surfaces: stop, escalate to `task`, and

to discover a second problem.

- **Docs are not optional.** If the change invalidates or lands in governed documentation,

the doc update AND its ledger/record step happen inside the same commit; a quick-task

that leaves the docs gate red fails the next push from the checkout.

- **No verification theater.** Running the full suite to feel safe defeats the point and

hides the touched-surface signal; if the full suite is genuinely required, escalate. The

same theater in miniature is re-running a touched suite that already passed to watch it

pass again — repetition is diagnosis work, not verification.

## Verification checklist

- [ ] The five shape questions all answered yes (one sentence, one surface, one commit,

reversible, no rulings)

- [ ] Plan was three to six bullets; no tracking artifacts created

- [ ] Touched-surface tests ran green — once per change, no stability re-runs

- [ ] CI verdict read and reported (CI alive), or local gates / manual full suite ran once before push (CI dead)

- [ ] Lint + docs gates ran for the touched paths; governed docs recorded if touched

- [ ] One focused review happened BEFORE the push (delegated for auth/money/data/contracts)