sae

Status And Estimate — four plain-English lines and a real number

v0.3.0

Asking an agent where it's at usually costs you a paragraph of throat-clearing, an estimate like "almost done", and a status written for whoever wrote the code. This skill replaces it with a fixed four-line block aimed at the person who owns the product: minutes left as an actual number, what's remaining, what's finished, and a notes line only when something is blocked. File paths, migration numbers, and function names are banned outright — every item names something a user or the business would notice, and five related fixes report as one phrase. Plain markdown with no tool calls, so the same folder works in Claude Code, Codex, or anything else that reads a SKILL.md.

$npx @meir-labs/skill-sae

GitHub

What it does

answers "where are you at?" in exactly four lines — estimate, remaining, finished, and notes only when something is blocked
forces a numeric estimate in minutes and bans "soon", "shortly", and "almost done"
bans file paths, function names, migration numbers, and flags — every item is a feature, screen, flow, or risk instead
groups five related fixes into one phrase rather than listing the mechanisms behind them
refuses to round a partial pass up to a win — a failing test stays in working on, with the blocker in notes
aggregates a whole subagent fleet into one block rather than one status report per agent

The filethe whole thing is the markdown you see here

skills/sae/SKILL.md

---

name: sae

description: Status And Estimate — give a brief plain-English progress update, then continue any active task. Use when the user types /sae, or says "status", "sitrep", "where are you", "how long left", "update me", "what's left". Written for a product owner, not an engineer. Portable across Claude Code, Codex, and any agent that reads skills.

---

# sae — status and estimate

Report state to a **product owner**, not a developer. Keep the update brief, without explanation or recap.

## Progress checkpoint, not a pause

When a task is active, send the status block as an intermediate progress message

(Codex: `commentary`), then immediately continue the next authorized task step in

the same turn. Keep running tools and subagents running. The four-line format

applies to the status message, not the rest of the work. Do not end the turn,

wait for a "continue", or treat the status request as replacing the active task.

Use a final reply only when the task is complete, nothing is active, the user

explicitly asks to stop/pause, or a genuine blocker or required approval prevents

further progress. SAE changes neither the task's scope nor its approval boundaries.

## Output — exactly this, nothing around it

```

- estimate: 20-30 mins left

- remaining: the reliability fixes a reviewer flagged, the new sign-in flow

- finished: the daily sync, the invite email, the settings page

- notes: I can't deploy myself — when the fixes land you'll run one command I'll paste

```

## Rules

1. **Four lines max, in this order.** `estimate`, `remaining`, `finished`, always. `notes` only when something is blocked, you need a decision, or there's a caveat that changes what the user does next — otherwise drop the line.

2. **No preamble, no closing.** The first character of the reply is `-`.

3. **Estimate is a number.** Minutes or a tight range (`8 mins left`, `20-30 mins left`). Never "soon", "shortly", "almost done". If it truly can't be estimated: `unknown — <the one thing blocking the estimate>`.

4. **`remaining` is what's left, `finished` is what's done.** Comma-separated, max 3 items each; past that, `+N more`. Nothing left → `remaining: nothing — idle`. Nothing done yet → `finished: nothing yet`.

5. **Plain English, product level.** Every item is a thing the user or the business would notice — a feature, a screen, a flow, a risk. **Banned:** file paths, function and variable names, migration numbers, flags, library names, error types, anything in `code font`. If the work is pure plumbing, name what it protects: *"stops two people overwriting each other"*, not *"lock order"*. Ticket IDs are fine (`LAB-229`).

6. **Group, don't enumerate.** Five related fixes are one phrase — *"the reliability fixes a reviewer flagged"* — not a list of five mechanisms. Detail belongs in an answer to a follow-up question, never here.

7. **Honest, not flattering.** A failing test is not finished. Partial goes in `finished` with the limit stated: `the invite email (works for 2 of 3 plans)`. Blocked work stays in `remaining`, with the blocker in `notes`.

8. **Notes says what you need from the user**, in one sentence — the decision, the access, the command they'll run. Not a status of its own.

9. **A fleet reports as one block.** Aggregate every subagent into the same four lines; never one report per agent.

## Translate before you write

| what you'd say to a developer | what goes in the line |

| --- | --- |

| props→state sync, stale-submit guard, poll cutoff | the form no longer submits stale data |

| migration 0024 applied and recorded | the database change is live |

| worker browser lifecycle, watchdog abort | the scraper recovers on its own now |

| CLAUDE.md / OPS.md updated | the handover notes are current |

## Nothing running

```

- estimate: n/a — nothing in flight

- remaining: nothing — idle

- finished: the new pricing page, live on the site

- notes: worth a look before you share it — meirlabs.com/pricing

```