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.
npx agentmods add skills/qball-inc/clear/cf-workpackagenpx skills add QBall-Inc/clear --skill cf-workpackagegit clone --depth 1 https://github.com/QBall-Inc/clearWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/qball-inc/clear/cf-workpackage)<a href="https://agentmods.dev/skills/qball-inc/clear/cf-workpackage"><img src="https://agentmods.dev/badge/skills/qball-inc/clear/cf-workpackage.svg" alt="Measured on agentmods" height="20"></a>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.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00057 | $0.03036 |
| Opus 5 | $0.00028 | $0.01518 |
| Sonnet 5 | $0.00011 | $0.00607 |
| Haiku 4.5 | $0.00006 | $0.00304 |
Grade A, and why
cf-workpackage 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 4d 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.
How it starts
The opening of the file, as written. The whole thing — 207 lines — stays where its author put it; the contents beside it link to each section on GitHub.
CLI Usage: When unsure about a CLI's interface or flags, run it with
--helpfirst. Do NOT attempt to discover functionality by reading plugin source code — doing so leads to incorrect execution from assumptions made without context of the holistic flow.
Workpackage Management
Manage the workpackage lifecycle: view status, list, create, start, pause, track progress, validate, complete, or delete workpackages.
Plugin Root Resolution
CLI commands in this skill reference $CLEAR_PLUGIN_ROOT — a .claude/settings.json env var the shell expands. The SessionStart hook persists it, but settings env vars load at session launch, so on a brand-new consumer's first session (before its next restart) the variable is empty and node "$CLEAR_PLUGIN_ROOT/build/..." fails with MODULE_NOT_FOUND.
First-session bootstrap — if $CLEAR_PLUGIN_ROOT is empty, set it inline in the same Bash call as the CLI (each Bash call is a fresh shell, so a separate export would not carry over):
export CLEAR_PLUGIN_ROOT="${CLEAR_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}"
Prepend it to the CLI in one shell line: export CLEAR_PLUGIN_ROOT="${CLEAR_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}"; <node "$CLEAR_PLUGIN_ROOT/build/..." command>. ${CLAUDE_PLUGIN_ROOT} resolves in this SKILL.md body to the actually-loaded plugin path; once the consumer restarts, $CLEAR_PLUGIN_ROOT is populated and the assignment is a harmless no-op. Reference files are left unchanged.
When to Use This Skill
| Trigger | Examples |
|---|---|
| Active workpackage status | "What workpackage am I on?", "Current WP?" |
| List or show workpackages | "Show all workpackages", "What's in phase 2?" |
| Lifecycle actions | "Start WP-2.1", "Let's begin the next workpackage", "Pause this one" |
| Progress or validation | "Update progress to 80%", "Is this WP ready to complete?" |
| Complete or delete | "Mark this workpackage done", "Delete WP-1.3" |
Not for: Plan operations (/cf-plan), knowledge base (/cf-knowledge), session status (/cf-status).
What ships with it
15 files 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.
- references/complete.md 1.1 KB
- references/create.md 2.9 KB
- references/default.md 941 B
- references/defer.md 1.6 KB
- references/delete.md 1.2 KB
- references/deps.md 1.8 KB
- references/help.md 1.2 KB
- references/list.md 1.1 KB
- references/pause.md 716 B
- references/progress.md 3.9 KB
- references/reorder.md 1.7 KB
- references/show.md 1015 B
- references/start.md 2.3 KB
- references/update.md 4.3 KB
- references/validate.md 739 B
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.
- 4d ago First seen · 207 lines · 57 tokens per session scan A 35dda9d468b4
cf-workpackage is a skill published in the GitHub repository QBall-Inc/clear (3 stars, last pushed 2mo ago), licensed Apache-2.0. It adds 57 tokens to every session and 3,036 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.
Other skills, from other repositories
implement
End-to-end workflow for taking MCP work items from backlog to merged PR. Handles git branching, schema-driven planning, implementation, independent review, and PR creation. Composes spec-quality, review-quality, and schema-workflow skills into a single pipeline. Use when a user says "implement this", "work on this…
review-proposals
Triages pending improvement-proposal MCP items — presents each with its scope and evidence, collects an accept/reject/defer decision per proposal, and carries out the disposition: project-scoped acceptances get their exact YAML applied to .taskorchestrator/config.yaml and pushed per-root; global acceptances get a…
work-summary
Generates a project dashboard from MCP work items. Default is a lean, attention-first view: what's in flight, what's blocked, what to do next, what's queued. Use when the user says: project status, what's active, show me the dashboard, work summary, what should I work on, project health, what's blocked, where did I…
adopt-project-scope
Migrates an already-populated, unscoped Task Orchestrator database in place to the project-scoping convention — creates a project anchor root, re-parents existing work trees under it, and writes rootId back to config.yaml. Use when a user says: adopt project scope, migrate this database to project scoping, make this…
create-item
Creates an MCP work item from conversation context. Scans existing containers to anchor the item in the right place (Bugs, Features, Tech Debt, Observations, etc.), infers type and priority, creates single items or work trees, and pre-fills required notes. Use when the conversation surfaces a bug, feature idea, tech…
dependency-manager
Visualizes, creates, and diagnoses dependencies between MCP work items. Use when a user says: what blocks this, add a dependency, show dependency graph, why can't this start, link these items, unblock this, remove dependency, or show blockers.