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 skills add HelixDevelopment/code --skill reporting-workable-itemsgit clone --depth 1 https://github.com/HelixDevelopment/codeWrote 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/helixdevelopment/code/reporting-workable-items)<a href="https://agentmods.dev/skills/helixdevelopment/code/reporting-workable-items"><img src="https://agentmods.dev/badge/skills/helixdevelopment/code/reporting-workable-items/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/helixdevelopment/code/reporting-workable-items"><img src="https://agentmods.dev/badge/skills/helixdevelopment/code/reporting-workable-items.svg" alt="Reviewed on agentmods" width="80" 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.1 | $0.00121 | $0.01568 |
| Opus 5.5 | $0.00048 | $0.00627 |
| Sonnet 5.5 | $0.00024 | $0.00314 |
| Haiku 4.5 | $0.00012 | $0.00157 |
Grade A, and why
Reporting Workable Items 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.
How it starts
The opening of the file, as written. The whole thing — 103 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Reporting Workable Items (§11.4.202 · §11.4.148 · §11.4.171)
A report that is only acknowledged is a lost requirement. Answering "yes, that's a bug, I'll look into it" in prose — without creating a tracked item — is a §11.4.197 requirements-integrity violation: the requirement was accepted, then silently evaporated. Every report becomes a real, fully-populated, fully-synced workable item, or it is explicitly and honestly refused.
The three report directives
| Directive | Use when | Resulting Type |
|---|---|---|
/helix:bug (/default-bug) |
A product defect — regression, user-visible broken behaviour | Bug |
/task |
An internal workstream — refactor, doc, infra, gate, audit | Task |
/issue |
Anything trackable, type not yet decided | classified into {Bug｜Feature｜Task} |
Note: the bare /bug collides with Claude Code's built-in — always use
/helix:bug or /default-bug (see the action-prefix-system skill).
Classification is a closed set (§11.4.16)
Bug · Feature · Task. There is no fourth type and no "Issue" type —
/issue is an entry point, not a type. Inventing a type is a §11.4.16
violation.
- Classify from the report's own content, stated as FACT (§11.4.6 — never a guess).
- If the content does not determine the type, ASK (§11.4.66 / §11.4.105) before creating the item.
- Only when running autonomously where asking is impossible (§11.4.101), default
to the lowest-stakes
Task, record the literalClassification: defaulted-to-Task (§11.4.16 ambiguity default — reclassify)in the description, and surface the reclassification command to the operator. Never silently assert a type the report does not support.
What a GOOD report contains
The item's description must be comprehensive and human-readable — a team member who was not in the room must understand it without reading code (§11.4.171). Structure it (§11.4.148 D2):
- WHAT — subject + problem/goal in one self-contained sentence. Never a bare fragment like "Composes with" or "Critical" (§11.4.91 forbids those).
- SCOPE / MANIFEST — the components, files, surfaces, or platforms touched.
- REPRODUCTION — for a
Bug: the exact sequence that reproduces it. If a working reproduction already exists, use its exact sequence — a deviating repro that never reaches the precondition proves nothing (§11.4.199). - ACCEPTANCE — the observable, machine-checkable condition that means done (the §11.4.108 runtime signature: what must be true on a clean deployment).
- EVIDENCE — captured artefact paths that back the report (§11.4.5 / §11.4.69): log, recording, sink-probe, crash trace, screenshot.
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.
- 2d ago Changed · +54 lines · +99 tokens per session c2a2c14d27d9
- 1mo ago First seen · 49 lines · 22 tokens per session scan A 0d2a28066a24
Reporting Workable Items is a skill published in the GitHub repository HelixDevelopment/code (2 stars, last pushed 2d ago), licensed MIT. It adds 121 tokens to every session and 1,568 once invoked, about $0.0005 per session on Opus 5.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
pipeline-conductor
Operating procedure for the kirocrew-pipeline-conductor agent. Use when a pipeline conductor session is seeded, inspected or debugged. You MANAGE one issue/PR pipeline on one repo: two columns per item (session working? item solved?), send intent, never re-derive a red yourself.
babysit
Use when a user asks to babysit, monitor, keep checking, keep an eye on, or report when a pull request, CI run, ticket, deployment, or other changing target reaches an outcome.
feature-request
Conversational workflow for gathering user feedback and filing GitHub Issues on the Kiro Crew repository. Load when the user clicks "Request a Feature", wants to report a bug, or suggest an improvement.
goal-loop
Bootstrap a goal-driven self-improving AutoNudge loop from a goal plus an anchor directory, then run the board autonomously until the Definition of Done is met.
team-lead
Run a goal as a team when you can also do the work yourself: decide what you keep, dispatch the rest, and keep the status board honest. The delta over goal-conductor, which carries the dispatch, patrol and acceptance procedure this one points at. Load it when you are handed a goal, not a task.
goal-ledger-conductor
Deprecated alias of goal-conductor, removed next release. The work-ledger conducting procedure now lives in goal-conductor; read that skill instead.