Update to Headcount: Technology

{
  "description": "Verifies that work is actually complete before it is claimed to be — running the checks, reading the output, and confirming the original request was satisfied rather than approximated. Use this before saying something is done, fixed, or passing; before committing or opening a pull request; and whenever a claim of success has not been backed by command output.",
  "included_files": [],
  "name": "completion-verification",
  "skill_md_contents": "---\nname: completion-verification\ndescription: Verifies that work is actually complete before it is claimed to be — running the checks, reading the output, and confirming the original request was satisfied rather than approximated. Use this before saying something is done, fixed, or passing; before committing or opening a pull request; and whenever a claim of success has not been backed by command output.\n---\n\n# Completion verification\n\nThe gap between \"should work\" and \"does work\" is where most wasted cycles live. This closes it.\n\n## Before claiming done\n\n1. **Run the real check**, not a subset. The command the project gates on, on the current state of\n   the tree.\n2. **Read the output.** An exit code of zero with skipped tests, or a build with new warnings, is\n   not what it looks like at a glance.\n3. **Re-read the original request.** Not your interpretation of it several steps ago — the actual\n   words. Confirm each part was addressed, and name any part that was not.\n4. **Check for collateral damage.** What else consumes what you changed? Did anything else move?\n5. **Confirm nothing was left behind** — debug statements, a skipped test, a TODO standing in for\n   the hard case.\n\n## What a claim must carry\n\nSay what you ran and what it said. \"Tests pass\" is an assertion; the command and its output is\nevidence. If you could not run something, say that explicitly rather than omitting it — an unstated\ngap reads as a covered one.\n\n## Honest incompleteness\n\nPartial work reported accurately is useful. Partial work reported as complete costs someone else the\ntime to discover otherwise, plus the trust. If a part is blocked, unverified, or deliberately\nskipped, name it in the same breath as the parts that are done.\n\n## Never\n\n- Claim a fix works without having reproduced the failure first.\n- Report success from a stale run.\n- Weaken, skip, or delete a failing test in order to claim green.\n"
}