| name | do-the-work |
| description | Do the actual work instead of avoiding it, and don't make the user repeat feedback. Use whenever the task is to fix something — fix CI, fix a failing or flaky test, fix the build, make a check green, resolve a bug — or any time you are tempted to skip, disable, exclude, defer, or stop early. Read and apply the repo feedback log before working; append to it when corrected. |
Do the work (hammerkit)
The job is to fix the thing, not to find a way around fixing it. This skill
exists because avoidance kept showing up as the default reflex, and because the
user does not want to repeat feedback he has already given.
The contract
When the task is to make something pass — CI, a test, the build, a check — the
deliverable is that it passes because the underlying problem is fixed. The
following are never the resolution (only do them if the user explicitly asks in
this conversation):
.skip / it.skip / describe.skip / xfail / test.todo- excluding files or paths from a suite, or commenting-out / deleting a test
- loosening or removing an assertion so it stops failing
- raising a timeout to a giant fixed value to paper over a hang
- declaring something "flaky locally" and moving on
- stopping early and handing back an unfixed failure as if it were done
Instead: diagnose the root cause (timing, environment, file-watching, resource
leaks, ordering, a real bug) and fix it so the check passes legitimately. If a
failure is genuinely container/k8s/infra-only and can't be reproduced on this
host, say so explicitly and rely on CI to confirm — that is honest reporting,
not skipping.
Good questions vs. avoidance dressed as a question
- Ask freely: how to implement something, which design/approach to take,
genuine ambiguity in the requirements, trade-offs that change the outcome. These
are welcome.
- Don't ask — just do it: "Can I skip this test?", "Is it ok to leave this
failing?", "Should I just remove/disable it?", "Want me to stop here?" If the
effect of the question is to avoid the assigned work, the answer is already no
— do the work.
- Only escalate when truly blocked: missing access/credentials, a product
decision only the user can make, or contradictory requirements. Even then,
propose the fix path, not the avoidance.
Feedback discipline (don't make the user repeat himself)
The repo keeps a durable log at .agents/FEEDBACK.md.
- Read it before you start working and apply every rule there.
- Don't re-ask anything it already answers.
- When the user corrects you or states a preference, append an entry to it
immediately (rule + Why + How to apply + date), so it's never
re-litigated.
Canonical instance
"Never skip tests to go green" is the sharpest example of the contract — see the
never skip tests rule in .agents/FEEDBACK.md. The fix-ci and before-commit
skills are how you actually fix CI without skipping.
