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 workable-item-lifecyclegit 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/workable-item-lifecycle)<a href="https://agentmods.dev/skills/helixdevelopment/code/workable-item-lifecycle"><img src="https://agentmods.dev/badge/skills/helixdevelopment/code/workable-item-lifecycle/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/workable-item-lifecycle"><img src="https://agentmods.dev/badge/skills/helixdevelopment/code/workable-item-lifecycle.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.00089 | $0.01439 |
| Opus 5.5 | $0.00036 | $0.00576 |
| Sonnet 5.5 | $0.00018 | $0.00288 |
| Haiku 4.5 | $0.00009 | $0.00144 |
Grade A, and why
Workable Item Lifecycle 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 — 112 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Workable Item Lifecycle
The workable-items SQLite DB is the single source of truth (§11.4.93, tracked in git per §11.4.95). Issues / Fixed / the summaries and their HTML / PDF / DOCX siblings are generated outputs (§11.4.12 / §11.4.53 / §11.4.65 / §11.4.106). Never hand-edit a generated doc — change the DB and regenerate, or the next regeneration silently reverts your edit.
Status — closed set (§11.4.15 / §11.4.21 / §11.4.90)
Queued · In progress · Ready for testing · In testing · Reopened ·
Operator-blocked · terminal closure · Obsolete (→ Fixed.md)
Type — closed set (§11.4.16)
Bug · Feature · Task. No fourth value. Task is the lowest-stakes default
when genuinely ambiguous.
Closure vocabulary is TYPE-AWARE (§11.4.33)
| Type | Closure Status |
|---|---|
Bug |
Fixed (→ Fixed.md) |
Feature |
Implemented (→ Fixed.md) |
Task |
Completed (→ Fixed.md) |
Closing a Feature as "Fixed", or a Task as "Implemented", is a §11.4.33
violation. All three are semantically equivalent ("closed, positive evidence
captured") but the literal must match the Type.
Closure requires captured evidence — always (§11.4.123 / §11.4.108)
An item may be closed only with rock-solid captured proof (§11.4.5 / §11.4.69 / §11.4.107). Forbidden as proof: metadata-only, configuration-only, absence-of-error, and grep-without-runtime.
"Done" means the item's runtime signature verifies on a clean deployment (§11.4.108) — source-committed ≠ artifact-contains-it ≠ active-on-clean-target ≠ works-for-the-user. Green at the source layer says nothing about the other three.
If you are unsure how to validate something, that is a research trigger, not a licence to accept a weak PASS: do the deep research first (§11.4.123).
Reopening (§11.4.34 / §11.4.55)
A reopen is a demotion from closed and therefore requires positive evidence captured under the conditions that re-exposed the defect (§11.4.7). Record:
- By:
AIorUser - On: ISO date
- Reason: from the closed vocabulary —
test-failed·manual-testing-detected·captured-evidence-contradicts·end-user-report·cycle-re-discovered·design-reconsidered - Evidence: path to the captured artefact
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 · +55 lines · +62 tokens per session 1fe6a9586c08
- 1mo ago First seen · 57 lines · 27 tokens per session scan A a7e701b4f34e
Workable Item Lifecycle is a skill published in the GitHub repository HelixDevelopment/code (2 stars, last pushed 2d ago), licensed MIT. It adds 89 tokens to every session and 1,439 once invoked, about $0.0004 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.