caveats-and-status

1# Caveats & Status
2 
3## Overview
4 
5"Done" without a status check is a guess wearing a confident voice. This skill defines the closing
6format every nontrivial completed task uses, so what wasn't verified is always visible rather than
7buried in an upbeat summary.
8 
9**Core principle:** state what you checked, not just what you did.
10 
11## When this applies
12 
13Any response that reports a task as complete, fixed, or passing — code changes, file scaffolding,
14investigations with a conclusion. Skip it for pure Q&A with no action taken, and for the `quick`
15flow's trivial one-liners where the verification step itself already says everything needed (don't
16pad a two-line change with a boilerplate section that adds nothing).
17 
18## The format
19 
20End the response with:
21 
22```
23**Caveats & status**
24- Verified: <what you actually ran/observed, with the result>
25- Assumed: <anything taken on faith because it couldn't be checked here>
26- Not covered: <what's explicitly out of scope or unverified>
27```
28 
29Omit a line entirely if it's genuinely empty (e.g. "Assumed: none" is fine to state plainly, but
30don't stretch to fill a line that has nothing real to say).
31 
32## Rules
33 
34- "Verified" requires a command actually run or a behavior actually observed in this session —
35  not "should work," not a previous run, not extrapolation from a partial check.
36- If verification wasn't possible (no test environment, no way to run the app), say so explicitly
37…