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 KaydenClark/LLM_Workbench --skill spec-plannergit clone --depth 1 https://github.com/KaydenClark/LLM_WorkbenchWrote 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/kaydenclark/llm_workbench/spec-planner)<a href="https://agentmods.dev/skills/kaydenclark/llm_workbench/spec-planner"><img src="https://agentmods.dev/badge/skills/kaydenclark/llm_workbench/spec-planner/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/kaydenclark/llm_workbench/spec-planner"><img src="https://agentmods.dev/badge/skills/kaydenclark/llm_workbench/spec-planner.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.00023 | $0.01022 |
| Opus 5.5 | $0.00009 | $0.00409 |
| Sonnet 5.5 | $0.00005 | $0.00204 |
| Haiku 4.5 | $0.00002 | $0.00102 |
Grade A, and why
spec-planner 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 12d 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 — 89 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Spec Planner
Purpose
Plan small Tasks and parallel vertical slices for the one assigned Spec from current Actuality when its flight launches, and hand the executable plan to Spec Manager.
Adopt only the stance already set in the assigned SPEC and TASK. It is
composed with an already assigned Dispatcher role (the dispatcher skill):
the role supplies the scope (one Spec and its branch) and the dispatch
responsibility; this stance supplies the planning method and obligations. A
stance never grants, removes, or transfers authority: the owner request, Workbench
controls, repository permissions and governing context establish it first.
Loading this skill never spawns an agent. Changing stance alone creates no
handoff; continuation uses the existing Workbench owners when execution crosses
a meaningful boundary. Do not choose or record a new normal stance or invent a
next task. Troubleshooting stance selection is outside this skill. The
accepted role model is
workbench/docs/adr/000P-roles-scope-work-and-stances-define-the-job.md and
workbench/wiki/design-concepts/roles-and-stances.md.
Method / Posture
Resolve the assigned Spec and support lanes through workbench/manifest.json.
Plan only at flight launch or Spec activation, and only for the assigned Spec.
Never enumerate execution Tasks when merely authoring a planned Spec: a planned
Spec gets no Tasks until the same request activates it.
Before cutting anything, inspect live Actuality: the Spec's accepted requirements, decisions and acceptance lines, the source and tests they cite at the current integration tip, the remaining gaps its evidence log records, and its dependencies on other Specs. Plan from what is verified now, not from the Spec's original assumptions; record what was inspected and at which commit.
Cut small complete-path vertical slices with tracer-bullet discipline: each
Task pierces every layer its acceptance line needs and finishes in one Chat.
Give every Task explicit acceptance (the Spec lines it satisfies), the proof it
must produce, its dependencies (Blockers holds only S-###/TK-### ids)
and one named writer per shared file. State which groups may run concurrently
within the Spec and which wait on others; serialize conflicting writes under
the named writer rather than splitting one file between Tasks.
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.
- 12d ago First seen · 89 lines · 23 tokens per session scan A a400ad1cc174
spec-planner is a skill published in the GitHub repository KaydenClark/LLM_Workbench (2 stars, last pushed 2d ago), licensed MIT. It adds 23 tokens to every session and 1,022 once invoked, about $0.0001 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-10-07.
Other skills, from other repositories
story-readiness
Is a story implementation-ready? Checks clear acceptance criteria, open questions, ADR refs. READY/NEEDS WORK/BLOCKED/NOT ASSESSED.
recipe-create-meet-space
Create a Google Meet meeting space and share the join link.
workthreads
SpecStory Workthreads - a weekly work-thread rollup across a team's repos from SpecStory coding histories (any agent - Claude Code, Codex, Cursor, Gemini, and more). It groups the window's sessions into threads of work per project and labels each new / open / recently closed, so a lead sees what shipped, what is still…
atmos-config
Atmos root configuration: atmos.yaml discovery, precedence, deep merging, basepath, imports, minimal bootstrap, and routing to narrower Atmos skills.
projects
List all managed projects with status, branch, open PRs, and open issue counts — portfolio-level view.
handle-linkedin-connection-request-signal
Use this skill when someone sends a team member an inbound LinkedIn connection request. An inbound request is a deliberate, ACTIVE first-party intent signal — meaningfully stronger than a passive profile view — and it deserves different scoring rules. The skill resolves and enriches the requester, gates them through…