os-done-or-not

Featured

ALWAYS invoke this skill when work wraps up or the user asks how it went - "done or not", "are we done", "what happened", "report" - in any language, and when a Stop hook asks for a session report. Produces a ten-line plain- language report: a lead, a checkmark table, and a verdict - fully done, anything needed from you, new debt, safe to close. Every "yes" names its proof; unverified says "not checked". Saves the report so the next session starts from it instead of re-exploring the repo.

AI & Automation 355 stars 67 forks Updated yesterday MIT

Install

View on GitHub

Quality Score: 93/100

Stars 20%
85
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# os-done-or-not One question, one screen: **did the agent finish, and what actually happened** - in words a reader who does not code will understand. Nothing happened (pure questions, no files touched) → one line saying so, no report. ## Language The language the user speaks in this session, detected from the conversation - translate every template label. Code, files, commands stay English. ## Step 1 - gather proof that takes seconds Fast checks only; never re-run the test suite - use results this session already produced. Not confirmable in seconds, or still running → **"not checked"**, never "yes". ```bash git status --porcelain # uncommitted? git log --oneline -10 # what landed git log origin/HEAD..HEAD --oneline 2>/dev/null # unpushed? gh pr view --json state,mergeStateStatus && gh pr checks # if a PR exists ``` ## Step 2 - name the outcome Sessions end one of eight ways; pick the match **before** writing, or the report says "fully done: yes" and "safe to close: no" in the same breath. | # | Outcome | Verdict shape | |---|---|---| | 1 | Shipped and verified | done Yes · nothing needed · close Yes | | 2 | Done - one action is yours | done Yes · needed = that action · close Yes | | 3 | Stalled on your decision | done No · needed = the decision · close No | | 4 | Partly done, rest deferred | core Yes, rest recorded as debt · close Yes | | 5 | Didn't work - rolled back | done No · lead = what was learned · close Yes | | 6 | Something broke...

Details

Author
kharmanskyi
Repository
kharmanskyi/open-steps
Created
2 weeks ago
Last Updated
yesterday
Language
Shell
License
MIT

Bundled in these plugins

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Featured

os-whats-next

ALWAYS invoke this skill when the user asks what to do next, what is left, or what is blocked - "what's next", "what now", "what should we work on", "anything I can do" - in any language. This skill picks the next piece of work; when the user asks HOW to do a thing or says they do not understand what to do, that is os-step-by-step. Reads the last report, local changes, open pull requests and always the backlog. First finishes what is finished: verified-ready pull requests merge in the same pass. Then sorts the rest into doable-alone and needs-you, ending with one recommended next task in plain words - what it closes or unblocks. Never invents tasks.

355 Updated yesterday
kharmanskyi
AI & Automation Featured

os-check-work

ALWAYS invoke this skill when the user asks about work done outside this session - "check work", "check the others", "check other sessions" - or to accept one: "the session is done, check it", "can we merge it" - in any language. You are the receiving party: treat the report as a claim, verify each part against machine state, name every gap between claimed and true. Verified-ready work merges in the same pass. End with what is left, one next step, and any reply another session needs, ready to paste.

355 Updated yesterday
kharmanskyi
Code & Development Listed

done

End-of-session shipping gate — "prove it works, then ship it." Runs an evidence checklist (full test suite, lint/typecheck, build, and actually running the change — output quoted, never asserted), then a fresh-context two-stage review by a sub-agent that sees only the diff and the spec: spec-compliance first, correctness second, style never — joined by a cross-model second opinion when a codex/gemini CLI is installed. Flags fake-green tripwires (edited or deleted tests, new TODOs or skips, hardcoded expectations) and ends with a verdict — SHIP, FIX FIRST, or NEEDS HUMAN — before drafting the commit/PR for the user's approval. Use at the end of any coding session or when the user asks "is this done", "ready to ship?", "/done", "wrap this up", "review and commit this". It is the closing step of both feature and bugfix, but works standalone on any uncommitted or branch diff.

9 Updated 3 days ago
duthaho