job

Stars10

Forks2

UpdatedAugust 1, 2026 at 19:42

Run multi-step work as a background minimise job — authors a plan YAML, wires the review gates, runs it, and reports what landed.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

dosatos

dosatos/minimise

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Computer Occupations, All OtherComputer and Mathematical Occupations·SOC 15-1299

File Explorer

2 files

SKILL.md

readonly

name	job
description	Run multi-step work as a background minimise job — authors a plan YAML, wires the review gates, runs it, and reports what landed.

Running work as a minimise job

Why a job beats this session

A mini job runs each task in a fresh agent session that sees only the previous task's diff and completion report, so context does not rot across a long build the way it does here. The plan is a YAML file the user reviews, edits, and commits — the pipeline lives in the repo instead of evaporating in a transcript. Failed tasks retry; a crash mid-run resumes from the first incomplete task. And hooks gate the work: a pre_plan review can block a bad plan before any code runs, and a post_task review can re-run a task with the findings fed back in.

Prerequisite

If mini --help fails, mini is not installed. Tell the user to run /minimise:setup and stop. Do not install it from here.

PROPOSE — nothing runs until the user says yes

The user asked for a job; they have not yet seen the shape of it. Never author a plan, never run mini job new, before they agree to the breakdown. Put in front of them:

The task breakdown — 2–6 tasks, each with a one-line goal, in the order they must run. Say what each task hands the next one. If you cannot break the work into tasks that stand alone with only the previous diff as context, say so — that work belongs inline, not in a job.
The gates you would wire — at minimum a pre_plan /minimise:review-plan hook.
The ask — "Want me to set this up as a mini job, or just do it here?"

Then wait. If the user says no, do the work inline without further mention of minimise.

On a yes

Author the plan YAML. Schema, required fields, and the hook contract: reference/plan-schema.md. Read it — estimated_duration_min is required on every task and hook, and a plan missing it fails at mini job new. Write it to worklogs/scratch/ if that exists, otherwise a plans dir the project already uses (docs/plans/), otherwise ask where it should live. Do not drop YAML in the repo root.
Wire the review-plan gate — a plan-level pre_hooks entry running /minimise:review-plan (exact shell string in the reference). It is a blocking gate: a failing review aborts the job before any task runs.
Show the user the plan file before running it. It is theirs to edit.
Run it:

mini job new --plan <file>     # → Job ID; validates the plan, creates it PENDING
mini job start <id>            # runs in the foreground until done

Monitor with mini job status <id> (add --format json to poll from a script) and mini job logs <id> -f for live narration.
Report with mini job results diff <id> and mini job results logs <id>. Summarize what landed and what the review hooks said — the user delegated so they would not have to read the logs.

If the job fails, mini job start <id> again resumes from the first incomplete task; already- committed tasks are not re-run. Read the failing task's logs before re-running blindly.

More from this repository

same repository

brainstorm

dosatos/minimise

Author a mini job or loop plan under control — triage loop-vs-job, run a retrieval-aware interview pre-filled from existing personas and recent runs, then preview the exact YAML behind an approve/edit/reject gate before handing off to the unchanged `mini job new` / `mini loop new`. Use when starting a new job or loop from a one-liner and you want to review the plan before anything runs.

2026-08-0110

loop

dosatos/minimise

Run open-ended iteration on one artifact as a minimise refinement loop — plan → implement → evaluate, repeating until the goal is met or max_iterations is hit.

2026-08-0110

review-implementation

dosatos/minimise

Reviews what a minimise job actually IMPLEMENTED against its plan — a NON-BLOCKING advisory reviewer that reads the plan (YAML) from stdin, inspects the job's git diff, and reports findings without ever aborting the job. Use when invoked as `/minimise:review-implementation`, or when a minimise `post_plan` hook runs `claude -p '/minimise:review-implementation'` to critique the finished work. Always exits reporting; it never fails the job. Checks correctness, completeness vs. the plan's goals, obvious bugs, missing tests, and over-engineering — mirroring ralphex's post-implementation review, trimmed to the essentials.

2026-08-0110

review-plan

dosatos/minimise

Reviews a minimise job plan or loop spec as a pragmatic BLOCKING quality gate, reading it (YAML) from stdin and printing a machine-readable REVIEW: PASS / REVIEW: FAIL verdict. Use when invoked as `/minimise:review-plan`, or when a minimise `pre_plan` hook runs `claude -p '/minimise:review-plan'` to gate a job before implementation. Reports ONLY severe issues (correctness bugs, data-loss/destructive risk, missing steps that make a task unimplementable, internal contradictions, factually wrong claims about the codebase, a loop goal with no stopping condition) and ignores style, wording, and nice-to-haves.

2026-08-0110

setup

dosatos/minimise

Verify and install the prerequisites for minimise — the `mini` CLI, the `claude` CLI, and a git repo.

2026-08-0110

Running work as a minimise job

Why a job beats this session

Prerequisite

If mini --help fails, mini is not installed. Tell the user to run /minimise:setup and stop. Do not install it from here.

PROPOSE — nothing runs until the user says yes

The user asked for a job; they have not yet seen the shape of it. Never author a plan, never run mini job new, before they agree to the breakdown. Put in front of them:

The task breakdown — 2–6 tasks, each with a one-line goal, in the order they must run. Say what each task hands the next one. If you cannot break the work into tasks that stand alone with only the previous diff as context, say so — that work belongs inline, not in a job.

The gates you would wire — at minimum a pre_plan /minimise:review-plan hook.

The ask — "Want me to set this up as a mini job, or just do it here?"

Then wait. If the user says no, do the work inline without further mention of minimise.

On a yes

Author the plan YAML. Schema, required fields, and the hook contract: reference/plan-schema.md. Read it — estimated_duration_min is required on every task and hook, and a plan missing it fails at mini job new. Write it to worklogs/scratch/ if that exists, otherwise a plans dir the project already uses (docs/plans/), otherwise ask where it should live. Do not drop YAML in the repo root.

Wire the review-plan gate — a plan-level pre_hooks entry running /minimise:review-plan (exact shell string in the reference). It is a blocking gate: a failing review aborts the job before any task runs.

Show the user the plan file before running it. It is theirs to edit.

Run it:

mini job new --plan <file> # → Job ID; validates the plan, creates it PENDING mini job start <id> # runs in the foreground until done

Monitor with mini job status <id> (add --format json to poll from a script) and mini job logs <id> -f for live narration.

Report with mini job results diff <id> and mini job results logs <id>. Summarize what landed and what the review hooks said — the user delegated so they would not have to read the logs.

If the job fails, mini job start <id> again resumes from the first incomplete task; already- committed tasks are not re-run. Read the failing task's logs before re-running blindly.