iWP Claudy
39a637410c
WordPress plugin rebrand/conventions/remote-CLI patterns, Gitea release workflow, bastille jail provisioning, remote shell quoting safety, server fleet map, delegate brief writing, and verification discipline -- all derived from real incidents this session, plus two skills adapted (MIT license, attributed) from obra/superpowers and andrej-karpathy-skills.
2.9 KiB
name, description, license, source
| name | description | license | source |
|---|---|---|---|
| verification-before-completion | Use before reporting any task as done, especially when the work was done by a delegate/subagent. Never relay a self-report as fact. | MIT | adapted from obra/superpowers (MIT license), condensed for delegate-brief reuse |
Verification Before Completion
A delegate's "done" is a claim, not a fact. This applies whether the delegate is another AI agent, a subagent, or your own past self in an earlier step. Re-derive the result yourself before reporting completion to whoever is waiting on it.
The rule
Never report "done" based solely on:
- A delegate saying it's done.
- A test that wasn't actually re-run by you.
- Code that "should work" based on reading it, when running it was possible.
Instead, for each claim, do the cheapest check that would actually catch a wrong claim:
| Claim | Real check |
|---|---|
| "The file was created" | ls/cat it yourself |
| "The syntax is valid" | Actually run the linter yourself, don't trust a self-report of having run it |
| "The tests pass" | Run them yourself, read the actual output |
| "The API returns X" | Make the actual call yourself |
| "The deploy succeeded" | Check the live system, not the deploy log's exit code alone |
| "The old code is gone" | grep for it yourself |
Why this matters (not just process theater)
Across a real multi-delegate session, every single delegate's first self-report claimed success. Independent re-verification (re-running the linter, re-grepping, and — critically — testing the actual live end-to-end pipeline rather than just checking that files existed) is what actually confirmed correctness. In an earlier phase of the same session, a wrapper-agent pattern (spawn an agent whose only job is to invoke one CLI tool and report back) repeatedly ended its own turn the instant it started a background process, before that process had produced any real result — producing a loop of confident-sounding "still running" reports that carried zero information. The fix was to stop trusting the wrapper's self-reported status and directly monitor the actual underlying process.
Escalating verification for higher-stakes changes
- Low-stakes (a text file, a doc change): read it back.
- Medium-stakes (application code): lint + a targeted functional test.
- High-stakes (something that serves real traffic, handles money, or changes shared/production state): the actual end-to-end path a real user would hit — not a unit test in isolation, the real live pipeline. If you cannot exercise the real path yourself (e.g. no browser available for a checkout flow), say so explicitly rather than reporting success on a partial check.
What NOT to do
Don't pad out a report with hedging language as a substitute for actually checking ("this should work", "this is likely correct"). Either verify it, or clearly state it's unverified and why — don't blur the line between the two.