status-report

Files (2)

• SKILL.md
• openai.yaml · agents/

SKILL.md (first lines)

# Status Report

## Goal

Give the user an immediate, evidence-backed picture of the whole project, not
just the last local action. Assume the user has been away and does not remember
agent-internal labels. Re-ground the report in the user's goal words, then zoom
into the active work.

The global view is not decoration. It prevents the most common failure in long
agent work: reporting the command or trace that just changed while hiding the
state of the actual objective. A user should be able to answer, from the report
alone: "Are we closer to the full goal, which parts are still untouched, what is
quietly risky, what could be shown publicly, and what decision would change the
plan?"

## Evidence First

Verify live state before reporting when tools are available. Check the sources
that matter for the claim: running processes, trace counts, logs, docs, costs,
git state, generated artifacts, or test output. If a number is not checked in
this turn, label it as last-known or omit it.

Never say a goal is done, fixed, clean, safe, or verified without a concrete
artifact. Say "written but not rechecked" or "current evidence says..." when
that is the truth.

## Report From Wide To Narrow

Every non-trivial report should move through these layers. Do not force a fixed
layout; choose prose, bullets, or tables based on what carries the most signal.

1. **Overall**: the full roadmap in the user's terms. This must be a real
   orientation section, not a one-sentence preface. For a complex project, start
   with an arrow-chain that draws on all major todos and clearly marks the
   current position, then explain the chain in
   roughly 2-4 compact paragraphs or an equally rich bullet block. Cover the
   main experiment, not-started future models or conditions, analysis,
   documentation, budget, reviewer work, merge/isolation work, and claim
   readiness. For a benchmark-construction project, this can be
   "task design -> dataset audit -> **baseline reproduction** -> new-method
   validation -> leaderboard release." For a safety evaluation, this can be
   "threat model✓ -> task suite✓ -> baseline behavior✓ -> intervention:
   [AutoDan✓ / GCG waiting] (**here**; more methods may be added after the
   literature check, currently 70% done) -> red-team review -> redaction and
   release." Name what is working, what is paused, what is missing, and what
   blocks scale-up. Include target vs current counts and percentages when
   useful. The point is to help the user steer the whole project, not just
   understand the currently running process.
2. **Current**: the active slice being worked now. Say what is running, paused,
   questionable, working, or waiting. Use an arrow-chain for the active step too, and
   bold the substep currently in progress. For every active item, say what is
   happening in measurable terms: current count, denominator, percent, last
   progress, target, and stop/continue trigger. For a retrieval study, this can
   be "corpus audit -> source-hit checking -> answer scoring -> error
   classification -> claim draft." For a finetuning project, this can be "data
   curation -> leakage check -> training -> held-out evaluation -> ablation ->
   model card." Do not write vague verbs like
   "continuing" unless the sentence says continuing from what count toward what
   target.
3. **ATM**: exact ground truth from the latest check: trace counts, statuses,
   spend, active processes, newest artifacts, or relevant logs.
4. **Next**: the next action and trigger condition. Say what will happen by
   default if the user does not intervene.
5. **Could use human review**: only decisions where user judgment or approval
   changes the path. Do not invent review needs.
6. **ETA**: time to the next useful update, and larger completion estimates only
   if the evidence supports them.

For complex goals, include an "outside main loop" view: supporting areas such as
documentation, merge planning, isolation research, budget tracking, deep trace
analysis, and reviewer/subagent work. This prevents the report from collapsing
into only the current command or current trace.

If the report omits inactive or paused areas, the user gets a false sense of
progress. A run can be working while the paper, comparison models, reviewers,
budget projection, merge plan, or analysis remain far behind. Say that plainly.

## Minimum Substance For Large Projects

For a large experiment, long-running implementation, paper effort, or multi-part
research task, a status report is incomplete unless it gives the user enough
detail to steer without asking follow-up questions. A good report should usually
include all of these, unless the user explicitly asks for a tiny update:

- **Global completion map**: each major part of the user's goal, with current
  evidence and what remains. For example: main experiment, future model slices,
  trace analysis, docs, merge planning, isolation, budget, reviewer work, and
  paper/slide readiness.
- **Active experiment map**: each currently running or paused run, with counts,
  status split, exact/near score, spend, and why it is running or paused.
- **Quality judgment**: what evidence can support claims, what evidence is only
  useful for debugging or learning, what is questionable, and what is too early to
  use. State the reason, not just the label. For a multimodal study, this can
  be "input rendering -> perception check -> reasoning trace -> scoring -> human
  verification." For an agent evaluation, this can be "task setup -> tool
  allowed-tool and allowed-file checks -> transcript review -> scoring -> behavior taxonomy."
- **Decision log**: important pauses, restarts, abandoned attempts, and why the
  decision changed the plan.
- **Risk register**: current risks that could invalidate claims, waste budget,
  or require a fresh run identity.
- **Concrete next triggers**: "continue until N traces," "pause if X repeats,"
  "launch next models only after Y," not just "keep monitoring."
- **Public-release readiness**: what can be shown to reviewers or users now,
  what must stay internal, what needs another verification pass, and what would
  mislead people if released today. For artifact release, this can be "freeze
  run IDs -> verify reproduction commands -> check data cards -> check figures
  -> fresh-reader handoff -> release tag."

If a report gives only the active phase name and a few live counts, it is too
thin for a global status request. The user needs a compact operating picture,
not just a dashboard tile.

## Zoom Levels

Use deeper zoom sections when the user needs more than one level of context.

- **Overall chain**: the full goal sequence, using every major todo area.
- **Current chain**: the active step's substeps, with the active substep in bold.

From GithuBarry/AntiAIAISkills, MIT.

More from GithuBarry/AntiAIAISkills