honesty-check

Solid

Run the volunteering ledger before declaring work done. Forces surfacing of what changed/didn't, what was noticed-but-not-fixed, what was guessed, and what tradeoffs were made on the principal's behalf. The standard - the principal should never be surprised later by something the agent knew at the time.

AI & Automation 18 stars 5 forks Updated 3 days ago MIT

Install

View on GitHub

Quality Score: 81/100

Stars 20%
43
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# Honesty Check Before saying "done", "shipped", "complete", or "ready for review" — run this checklist. The standard: **the principal should never be surprised later by something the agent knew at the time.** If known, told. ## When to use - About to declare a piece of work complete - About to post "PR ready for review" / "fix shipped" - After any non-trivial fix, port, refactor, or feature - Triggered by Caddy on prompts like: "done", "shipped", "complete", "ready for review", "PR ready", "all good", "fix is in", "wrapped up", "task complete" ## The ledger (volunteer ALL that apply, even unasked) ### 1. What changed AND what didn't - Files modified with 1-line summary each - The "untouched" section — equally important. What stayed the same that someone might assume changed? ### 2. Anything noticed but not fixed - Adjacent bugs you saw but didn't address (out of scope) - Tech debt encountered in the same file - Failing tests that were already failing - Dead code, stale comments ### 3. Any remaining uncertainty after verification - "I tested case X and Y. Case Z I could not reproduce locally — possible cause is W." - "Verification passed at runtime but I did not test the recovery path." ### 4. Any tradeoff made on the principal's behalf - Simplicity over flexibility ("could have made this configurable; chose constant for now") - Small fix over refactor ("the regex works but the right fix is a parser") - Speed over thoroughness ("I didn't update the 3 callers in test f...

Details

Author
wrg32786
Repository
wrg32786/aigent-os
Created
2 months ago
Last Updated
3 days ago
Language
JavaScript
License
MIT

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Solid

check

Use when about to claim anything works, is fixed, is complete, or passes - before committing, replying to the user, or moving to the next task. Also use when relaying a subagent's or tool's success report, and especially at the end of a long session when the pull to say "done" is strongest.

60 Updated 1 months ago
escoffier-labs
AI & Automation Featured

verification-before-completion

Before telling the user a coding task is done, actually verify it — build, run the relevant tests/linter, and confirm the change does what was asked with no regressions. Use whenever you are about to claim a change is finished, fixed, or working.

505 Updated today
duckbugio
AI & Automation Listed

coding-agent-discipline

The reporting and restraint rules for an AI agent changing someone's codebase: never claiming a result that was not observed, saying which commands ran and what they printed, reporting what could not be verified rather than omitting it, keeping the diff to what was asked, preserving behaviour that was not in scope, checking APIs against the versions the project actually depends on, and refusing to make a test pass by weakening it. Use before reporting that work is complete, when about to write "this should work" or "tests pass", when a change is growing beyond the request, when a test is failing and deleting or disabling it is tempting, when an API is being used from memory rather than checked, or when two instructions cannot both be satisfied. Does not cover the order of work (clean-delivery-workflow), which checks to run (quality-gates), or how to phrase a message to a human (engineering-communication).

2 Updated 5 days ago
robsonkades