work-concern

A read-only review that lists a few concrete concerns about the current implementation, supported by its code and actual flow.

In plain words
What is it for?
Use it to check correctness, reliability, permissions, destructive actions, persistence, usability, and meaningful test coverage before trusting an implementation.
Why use it?
It surfaces risks and weak assumptions without editing files or expanding into a full audit or repair plan.

Skill for Claude CodeCodex

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add skills/xcaeser/work-skill/work-concern
Any agent
npx skills add xcaeser/work-skill --skill work-concern
Clone the repo
git clone --depth 1 https://github.com/xcaeser/work-skill

Made for: Claude Code, Codex.

Per session 53 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 741 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00053 $0.00741
Opus 5 $0.00026 $0.00370
Sonnet 5 $0.00011 $0.00148
Haiku 4.5 $0.00005 $0.00074

Measured 2d ago against content hash 57a0bd444eeb, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

work-concern scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

skills/work-concern/SKILL.md · 72 lines

How it starts

The opening of the file, as written. The whole thing — 72 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Work / 5. Concern

Answer this question:

What about the current implementation gives you pause? Identify only concrete risks, weak assumptions, or user-facing failure modes supported by the code and actual flow. What should be verified next before trusting it?

This is a lightweight, read-only judgment pass. Apply reliability, simplicity, user-state safety, meaningful testing, and clean-break rules directly. Do not spawn agents, create goals, edit files, commit, deploy, or produce a full fix plan. Use $work-audit when the user wants exhaustive review, severity-ranked findings, or a detailed executor-ready remediation plan.

Inspect

  1. Use the target named by the user. Otherwise inspect the current diff, implementation discussed in the conversation, or the smallest relevant feature and its consumers.
  2. Read local instructions, the implementation, existing tests, public APIs, call sites, and the actual user flow before forming a concern.
  3. Check only material axes supported by the target: correctness, reliability, data integrity, permissions, security, destructive actions, persistence, error recovery, usability, maintainability, and meaningful test coverage.
  4. Distinguish a verified concern from an unknown, tradeoff, taste judgment, or preference. Do not turn uncertainty into a finding.

Judgment

  • Prefer two strong concerns over ten speculative ones.
  • Cite the exact path, symbol, behavior, test, or observation behind each concern.
  • Explain the realistic consequence, not an imaginary catastrophe.
  • Do not invent requirements, impossible states, hypothetical attacks, or edge cases the implementation neither promises nor handles.
  • Do not flag framework behavior, stylistic preference, or deliberate tradeoffs as defects without evidence of material harm.
  • Do not create a concern to fill the response. If nothing material survives inspection, say so and name the limits of the review.
  • Keep remediation to one smallest next check. Do not redesign or prescribe a full solution unless the user asks.
  • Use high confidence for directly reproduced or contract-proven concerns, medium for strongly supported code-path risks, and low only for an important unknown with a decisive next check. Do not pad the table with low-confidence items.

Read the full file on GitHub · 72 lines

Files

What ships with it

1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 72 lines · 53 tokens per session scan A 57a0bd444eeb

Subscribe to this mod's changes

work-concern is a skill published in the GitHub repository xcaeser/work-skill (2 stars, last pushed 21d ago), licensed MIT. It adds 53 tokens to every session and 741 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.

Related

Other skills, from other repositories

changes-report

Report all repository changes that entered a target branch during one required date or period, grouped by product change and written as plain English for a broad audience. Use for daily, weekly, date-range, or relative-period change summaries rather than explaining one known diff.

yarlson/yarstack · 54 tokens

jira-issue-create

Create one or more Jira issues through acli from user-approved drafts using heading-based Context, Acceptance criteria, and Engineering notes sections. Use only when explicitly invoked to create Jira issues; use jira-issue-refine when requirements still need refinement.

yarlson/yarstack · 53 tokens

claude-review

Run an independent Claude Opus review of the complete current change against the repository's default branch, then verify its findings locally. Use after focused checks pass when you want a second model to review the change before further edits or delivery.

yarlson/yarstack · 50 tokens

test-gap-review

Review whether existing tests and verification credibly prove a scoped behavior contract. Use during validation when evidence may omit important behavior or provide false confidence.

yarlson/yarstack · 32 tokens

orcast

Use when orchestrating multiple agents in Orca: fan out parallel workers, pipeline work across stages, adversarially verify findings, run judge panels or loop-until-dry sweeps, or delegate a task and get the result back. You write a Plan definition in real JavaScript — a worker-workflow graph of worker, action, and…

RubinCarter/orcast · 139 tokens

jira-issue-deliver

Autonomously deliver one Jira issue from intake to a ready GitHub pull request. Use only when the user authorizes implementation, commits, pushes, PR state changes, CI remediation, and resolution of requested automated review feedback.

yarlson/yarstack · 51 tokens