New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Os Check Work

by kharmanskyi in kharmanskyi/open-steps

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…

MITAuto-check passedWriting & Content

Install Os Check Work

skills CLI
$ npx skills add kharmanskyi/open-steps --skill os-check-work -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install kharmanskyi/open-steps os-check-work --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/kharmanskyi/open-steps.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/os-check-work .claude/skills/os-check-work && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
os-check-work
GitHub stars
1.3k
Token cost
~1.9k tokens
SKILL.md length
1,038 words
Files
2 (incl. references)
Skills in repo
7
Repo updated
First seen
Licence
MIT

At a glance

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…

  • Works in 5 steps: Find the claim. Read the transcript tail… → Verify each claim at its source. → Name the gaps - the deliverable. One… → …
  • Asks about work done outside this session - check work
  • SKILL.md covers Language, The stance, Two modes and Sweep, plus 5 more sections
  • Calls gh

What it does

Os Check Work is an agent skill from kharmanskyi/open-steps. 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.

Its SKILL.md is about 1.9k tokens, which your agent loads only when the skill is triggered. The skill folder holds 2 other files, including reference files (for example `references/01-accepting-a-build-session.md`).

It sits in Writing & Content. The repository describes itself as: Plain-language agent skills for Claude Code, Codex, Cursor and Gemini CLI: honest session reports, straight verdicts, steps you can follow. MIT. The licence is MIT.

When your agent uses it

  • Asks about work done outside this session - check work
  • Check the others
  • Check other sessions -
  • Accept one: the session is done

Example prompts

  • “check work”
  • “check the others”
  • “check other sessions”
  • “/os-check-work”

Requirements

  • Pre-approved tools (allowed-tools): Read(~/.claude/open-steps/**), Bash(gh pr list *), Bash(gh pr view *), Bash(gh pr checks *), Bash(gh pr checks), Bash(gh pr diff *), Bash(gh pr diff), Bash(gh pr merge *)

Workflow steps

5 steps, taken from the first numbered list in SKILL.md.

  1. Find the claim. Read the transcript tail where tools allow - the last
  2. Verify each claim at its source.
  3. Name the gaps - the deliverable. One line each: Claimed: … Measured: ….
  4. Accept, hand back, or unblock.
  5. Clean up. Remove its leavings - working copy, branch, temp files; ask

What it can do on your machine

Read from SKILL.md and the folder at commit 4fa744b. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves these tools, so the agent can use them without asking each time:

    • Read(~/.claude/open-steps/**)
    • Bash(gh pr list *)
    • Bash(gh pr view *)
    • Bash(gh pr checks *)
    • Bash(gh pr checks)
    • Bash(gh pr diff *)
    • Bash(gh pr diff)
    • Bash(gh pr merge *)

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • gh

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use gh, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Os Check Work loads about 1.9k tokens when it runs, and up to ~2.5k if it reads all its reference files. Until then it costs about 130 tokens; SKILL.md has 1,038 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~130
When it runs · the whole SKILL.md, loaded when a task matches
~1.9k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~2.5k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from kharmanskyi/open-steps at commit 4fa744b, republished under its MIT licence (© kharmanskyi). 1,038 words, ~1,889 tokens.

Download SKILL.mdSave it as .claude/skills/os-check-work/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
os-check-work
description
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.
allowed-tools
Read(~/.claude/open-steps/**), Bash(gh pr list *), Bash(gh pr view *), Bash(gh pr checks *), Bash(gh pr checks), Bash(gh pr diff *), Bash(gh pr diff), Bash(gh pr merge *)

os-check-work

You are the receiving party: another session says it finished, and your job is to find out whether that is true. Reports run optimistic - they are written by whoever did the work. Triggers live in the description above; one more is taking over work you did not do.

Language

Write in the language the user speaks in this session, detected from the conversation. Code, file names and identifiers stay English.

The stance

  • A report is a claim by the party being assessed, and its adjectives are not measurements: "tests are green" vs the count that ran. Ask for the number.
  • "Done" is a snapshot. Reviews get revoked, branches fall behind and checks flip, often with no new commit. Re-read immediately before you act.

Two modes

Plural is a sweep: every sibling session, one line each, statuses only. Singular - "accept this", a named session or pull request - is an accept: full verification, then acceptance. A sweep that finds verified-ready work rolls into accepting it - the accept steps run first, never skipped. Where your tool cannot list other sessions, sweep the open pull requests instead (gh pr list) and say so.

Sweep

One line per session, one call per pull request - the reader skims these and reads the closing block. No table:

<name a person recognises (#PR)> - <product change>; <all done? plus proof in 2-4 words, or what is missing>; <archive: yes / not yet>.

  • Name from the ticket or PR title, never your shorthand; the change for the product, not a file list.
  • A yes carries its proof ("checks green, review approved"); never a bare yes.
  • "All done" ≠ "can archive": finished work can still await acceptance.
  • Order: needs-the-user, then broken, then still-working - a running session is one word, not a finding.
  • No deep verification in a sweep: say what you did not open and what that leaves unverified. Never announce your working mode - "cheap checks" is bookkeeping.
  • A session waiting on an answer gets it in the same pass - see "The reply"; when that needs the deep read, the reply becomes the do-this-next.
  • Name the sessions you could not read, and why.

Accept - steps 1 to 5 (never per-session inside a sweep)

  1. Find the claim. Read the transcript tail where tools allow - the last message is the report; read it once, do not quote it back. No tools → the pull request is the artefact; say so.

  2. Verify each claim at its source.

    The session claimsWhere the truth lives
    checks are greengh pr checks - counts and states, not the summary word
    it was approved--json reviewDecision,latestReviews - revocable on the same commit
    no open discussionsthe unresolved-thread count, not "I addressed the comments"
    ready to mergemergeStateStatus - and again right before merging
    tests were addedfind them in gh pr diff - the most common false report
    it stayed in scopegh pr diff --name-only vs the task; flag unasked files
    linked to the taskthe ticket in branch, title or body

    Prefer numbers to words. Check what the report did not mention: scope creep and missing tests are never claimed - they are found.

  3. Name the gaps - the deliverable. One line each: Claimed: … Measured: …. No gaps → say so in one line; a clean intake is a real result.

  4. Accept, hand back, or unblock.

    • Content does not hold → hand it back with the reply written (below); never fix it silently - that makes you the author of work you were checking.
    • Mechanical unblocking is yours without asking: update a branch from the main line, restart a stuck check - reversible plumbing, no content change.
    • Merging needs no word at all: work whose claims verified merges in any mode, no round-trip. Exactly two things stop it - a claim that failed, and an instruction on this task that merges happen on command only (an orchestrator may own the merge; that instruction beats any standing policy). The verification itself is never skipped.

  5. Clean up. Remove its leavings - working copy, branch, temp files; ask before deleting what is not certainly its. Archive verdict → closing block.

Show full SKILL.md (367 more words)Show less

The reply is part of the pass

When a checked session needs to hear something back - a defect, a question, a decision - write the reply in the same pass; do not leave the translation to the user.

**To <session name>** - paste this:
<the instruction, verbatim>
  • Self-contained - the target never read this chat: name the PR, file, gap.
  • It speaks as the user: a plain instruction, not a review essay.
  • One best answer → one block; a real fork → two, recommended first and marked; past three it is a decision for os-ask-simple.
  • Carry the claimed/measured pair - evidence, not adjectives.

Ending the pass

Both modes end the same way, always last, nothing after it:

| | |
|---|---|
| **Still open** | <what remains, or "nothing"> |
| **Do this next** | <the one action> - <one clause of reasoning> |
| **On your word** | <what you will do once they say it> |
  • Say whether anything is left, including what waits on the user; a remainder past three items goes to os-whats-next.
  • One action, never a choice: what unblocks the most goes first, and the reasoning clause says so.
  • Nothing ready is a real answer - "nothing to accept yet, watch X". Never invent an action; a step that is not yours → say whose (os-step-by-step).
  • Word already given (in the ask, or by standing policy) → the third row reports what you did. Pass closed everything → run os-whats-next.
  • Never end on a question mark - you have the measurements, so the opinion.

Hard rules

  1. Never repair another session's work silently - name it, return it.
  2. Never accept on the strength of the report alone; detail is not evidence.
  3. Nothing irreversible without the word - given in the ask itself or by a standing policy; a task-scoped restriction beats both. Merging verified work already has that policy: step 4.
  4. Re-read state immediately before acting.
  5. Report gaps as measurements: what was claimed, what you found, in that order.
  6. Say what you could not check - no access is a gap, not absence of problems.
  7. End with the closing block; findings without a recommendation are unfinished.

Known gotchas

  • Behind the main line ≠ conflicted: it needs an update, not the author.
  • A conflicted branch may have run no checks: nothing-ran looks green.
  • Delete a branch only from outside its own working copy.
  • Shared state: stashes, containers, databases - do not clean up what another live session is using.
  • A draft is not a finished session; check the author considers it done.

© kharmanskyi, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 1 other file (references) in skills/os-check-work of kharmanskyi/open-steps.

  • SKILL.md
  • references/01-accepting-a-build-session.md

Open the folder on GitHubat commit 4fa744b

Compare with similar skills

Os Check Work next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Os Check Work compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Os Check Work this skillkharmanskyi/open-steps1.3k—~1.9kAutomated safety check: PassMIT
Socialcoreyhaines31/marketingskills54k4 repos~4.5kAutomated safety check: PassMIT
HumanizerAzure-Samples/interview-coach-agent-framework17237 repos~5.8kAutomated safety check: PassMIT
Avoid AI Writingconorbronsdon/avoid-ai-writing4.9k3 repos~8.1kAutomated safety check: PassMIT
JavaScript Concept Fact Checkerleonardomso/33-js-concepts67k1 repos~5kAutomated safety check: PassMIT
User-Facing Text Cleanupguillaumemeyer/watermarks-remover24k—~3.5kAutomated safety check: PassMIT

Similar skills

  • Social

    coreyhaines31/marketingskills

    When the user wants help creating, scheduling, or optimizing social media content for LinkedIn, Twitter/X, Instagram, TikTok, or Facebook, or wants to do social listening and engagement triage.

    54k GitHub starsUsed in 4 repos~4.5k tokens
    Writing & ContentAuto-check passed

  • Humanizer

    Azure-Samples/interview-coach-agent-framework

    Official

    Remove signs of AI-generated writing from text. An agent skill from Azure-Samples/interview-coach-agent-framework.

    172 GitHub starsUsed in 37 repos~5.8k tokens
    Writing & ContentAuto-check passed

  • Avoid AI Writing

    conorbronsdon/avoid-ai-writing

    Audit and rewrite content to remove AI writing patterns ("AI-isms").

    4.9k GitHub starsUsed in 3 repos~8.1k tokens
    Writing & ContentAuto-check passed

  • JavaScript Concept Fact Checker

    leonardomso/33-js-concepts

    Verifies the technical accuracy of JavaScript concept pages by checking code examples, MDN and ECMAScript claims and external links through a five-phase method.

    67k GitHub starsUsed in 1 repo~5k tokens
    Writing & ContentAuto-check passed

  • User-Facing Text Cleanup

    guillaumemeyer/watermarks-remover

    Audits prose for invisible Unicode characters and rewrites it while keeping facts, citations, code and required disclosures unchanged and the writer's voice intact.

    24k GitHub stars~3.5k tokensUpdated today
    Writing & ContentAuto-check passed

  • Install Anti Slop

    trycompai/crm

    Install and configure the anti-slop Oxlint plugin in a local TypeScript or JavaScript repository.

    11k GitHub starsUsed in 1 repo~881 tokens
    Writing & ContentAuto-check passed

More from kharmanskyi/open-steps

  • Os Big Picture

    kharmanskyi/open-steps

    ALWAYS invoke this skill when the user asks where the project as a whole stands - "where are we", "what's the big picture", "what have we built", "what is in this project", "map the project", "what…

    1.3k GitHub stars~1.9k tokensUpdated 4 days ago
    Auto-check passed

  • Os Ask Simple

    kharmanskyi/open-steps

    ALWAYS invoke this skill before asking the user any technical question or offering options, and whenever they ask to be asked in plain words - "ask simple", "ask me simply", "ask me in plain words"…

    1.3k GitHub stars~1.4k tokensUpdated 4 days ago
    Auto-check passed

  • Os Whats Next

    kharmanskyi/open-steps

    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.

    1.3k GitHub stars~1.9k tokensUpdated 4 days ago
    Auto-check passed

  • Os Done Or Not

    kharmanskyi/open-steps

    ALWAYS invoke this skill when work wraps up or the user asks how it went - "done or not", "are we done", "what happened", "report", "what's the status of this ticket" - in any language, and when a…

    1.3k GitHub stars~1.8k tokensUpdated 4 days ago
    Auto-check passed

  • Os Say Simple

    kharmanskyi/open-steps

    ALWAYS invoke this skill when the user asks for simpler or shorter about something said or written - "say it simply", "what does this mean", "I don't understand your answer", "too long", "wait…

    1.3k GitHub stars~1.3k tokensUpdated 4 days ago
    Auto-check passed

  • Os Step By Step

    kharmanskyi/open-steps

    ALWAYS invoke this skill when you need the user to act - run a command, paste a secret, click, approve - and whenever they ask how to do something or say they do not know what to do: "step by step"…

    1.3k GitHub stars~1.9k tokensUpdated 4 days ago
    Auto-check passed

Categories

Questions about Os Check Work

What does Os Check Work do?

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…. Os Check Work is an agent skill from kharmanskyi/open-steps. 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.

When should I use Os Check Work?

Os Check Work fits situations like: asks about work done outside this session - check work; check the others; check other sessions -; accept one: the session is done.

How do I install Os Check Work in Claude Code?

Run `npx skills add kharmanskyi/open-steps --skill os-check-work -a claude-code`. Or copy the skill folder (skills/os-check-work in kharmanskyi/open-steps) into .claude/skills/os-check-work in your project. Claude Code loads it when a task matches its description.

How do I install Os Check Work in Codex?

Run `npx skills add kharmanskyi/open-steps --skill os-check-work -a codex`. Or copy the skill folder (skills/os-check-work in kharmanskyi/open-steps) into .agents/skills/os-check-work in your project. Codex loads it when a task matches its description.

Can I use Os Check Work in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add kharmanskyi/open-steps --skill os-check-work -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/os-check-work, .gemini/skills/os-check-work, .github/skills/os-check-work and .opencode/skills/os-check-work in your project.

What does Os Check Work need to run?

Going by SKILL.md and its folder, Os Check Work needs the command-line tools its instructions call (gh). Its frontmatter pre-approves these tools: Read(~/.claude/open-steps/**), Bash(gh pr list *), Bash(gh pr view *), Bash(gh pr checks *), Bash(gh pr checks), Bash(gh pr diff *), Bash(gh pr diff), Bash(gh pr merge *).

Does Os Check Work access the network?

SKILL.md contains no URLs. Its commands use gh, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Os Check Work safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Os Check Work use?

Os Check Work is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Os Check Work use?

About 1.9k tokens (SKILL.md is roughly 7.6k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 592 tokens, read only when the agent opens those files.

What are the alternatives to Os Check Work?

Skills that share tags, products or a category with Os Check Work: Social (coreyhaines31/marketingskills, 54k stars), Humanizer (Azure-Samples/interview-coach-agent-framework, 172 stars), Avoid AI Writing (conorbronsdon/avoid-ai-writing, 4.9k stars) and JavaScript Concept Fact Checker (leonardomso/33-js-concepts, 67k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Os Check Work?

kharmanskyi (a GitHub user) maintains it in kharmanskyi/open-steps, which has 1,272 GitHub stars. The repository holds 7 skills in this directory. The repository was last updated on October 5, 2026.

Source: kharmanskyi/open-steps on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.