finish-task
Skill1 starsChanged 38 days agoMITView on GitHub
Use when a change is done, or thought to be done, and has to be wrapped up, as when the user says to finish, wrap up, finalize or commit the work, or the implementation has just ended and nothing has been checked or committed yet. Not for work still in progress, a question, or a request only to review.
5 other projects use a version of this.
Adopted by
Most recently taken up by
- peterpme/skillstheir own version, first seen Nov 1, 2026
- sensei-hacker/inav-claudetheir own version, first seen Oct 3, 2026
- SrdjanCoric/skillstheir own version, first seen Aug 2, 2026
- MetaMindTeam/ssot-kittheir own version, first seen Jul 21, 2026
- zahardev/aicontexttheir own version, first seen Apr 22, 2026
Other versions5 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 5
- peterpme/skills★ 28same name
- SrdjanCoric/skills★ 18same name
- sensei-hacker/inav-claude★ 6same name
- zahardev/aicontext★ 2same name
- MetaMindTeam/ssot-kit★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository4 other files it gives its agents.
- .claude/CLAUDE.mdCLAUDE.md
- learnSkill
- reuseSkill
- verify-assumptions-firstSkill
The file
We split this skill into the rules it gives an agent
9 rules. 0 are common, 8 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 5 edited versions we read keep these.
8
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Read the whole diff, untracked files included.
- Distinctive: line 19
Look; do not answer from memory.
- Distinctive: line 27
Run each one on the list. A check that fails because of how it was called (a missing argument, a wrong directory) was not run: correct the …
- Distinctive: line 32
When a check reports a problem, fix the work.
- Distinctive: line 36
After any fix, run ALL the checks again, not only the one that failed.
- Distinctive: line 41
Search the documentation, the examples, the comments and the project's notes or changelog for the names and the behaviour the change …
- Very specific: line 47
If a command failed along the way and was then corrected, or a [compound] message says a lesson is owed, invoke the compound:learn skill …
- Distinctive: line 53
Commit the files of this change and no others, with a message in the project's own style (read the log) that says what changed and why.
- Distinctive: line 57
Do not push, open a pull request, tag, release or publish anything unless the user asked for exactly that.
“Common” is measured: kept by at least 6 in 10 of the 5 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Finish the task
A change is finished when it was reviewed, every check the project has passes, what it made stale was updated, and it is committed. Do the steps in this order. Do not stop after the first check that passes.
1. Review the change
Read the whole diff, untracked files included. Does it do what was asked, and only that? Take out what does not belong: debugging output, stray files, anything secret.
2. Find every check the project has
Look; do not answer from memory. A project says how it is checked in its README or contributing guide, its CI configuration, its task runner or build file, and the configuration files of its test runner, linters, type checker, documentation build and validators. Write the list down before running anything. One test command is rarely the whole list.
3. Run every check
Run each one on the list. A check that fails because of how it was called (a missing argument, a wrong directory) was not run: correct the call and run it.
4. Fix what fails, in the code
When a check reports a problem, fix the work. Never make a check pass by weakening it: do not delete, skip, loosen or rewrite a test or a rule to fit the code. If a check is itself wrong about what was asked for, say so and ask the user before changing it.
After any fix, run ALL the checks again, not only the one that failed. Repeat until one pass over the whole list is clean.
5. Update what the change made stale
Search the documentation, the examples, the comments and the project's notes or changelog for the names and the behaviour the change touched. Correct every statement that is no longer true. Add notes only where the project keeps them.
6. Record what was learned
If a command failed along the way and was then corrected, or a [compound] message says
a lesson is owed, invoke the compound:learn skill (Skill tool) now. A check that
correctly reported a problem in the work is not a lesson.
7. Commit
Commit the files of this change and no others, with a message in the project's own style (read the log) that says what changed and why. If steps 4 to 6 changed files, they are part of the commit. Where there is no version control, say so.
Do not push, open a pull request, tag, release or publish anything unless the user asked for exactly that.
8. Report
Say what the review found, each check that was run and its result, what was updated, and the commit. Say plainly what was not done and why.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.