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/cbdreamer11/cb-loop-kit-claude-plugin/loop-plannpx skills add cbdreamer11/CB-loop-kit-claude-plugin --skill loop-plangit clone --depth 1 https://github.com/cbdreamer11/CB-loop-kit-claude-pluginWrote 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/cbdreamer11/cb-loop-kit-claude-plugin/loop-plan)<a href="https://agentmods.dev/skills/cbdreamer11/cb-loop-kit-claude-plugin/loop-plan"><img src="https://agentmods.dev/badge/skills/cbdreamer11/cb-loop-kit-claude-plugin/loop-plan.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.00050 | $0.00751 |
| Opus 5 | $0.00025 | $0.00376 |
| Sonnet 5 | $0.00010 | $0.00150 |
| Haiku 4.5 | $0.00005 | $0.00075 |
Grade A, and why
loop-plan 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 3d 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 — 74 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Plan the epic
This is the session that decides everything the cheaper sessions will do. It is worth spending real thinking here — but the thinking must land on disk, because a plan that only exists in this conversation dies with it.
1 · Get the goal straight first
Before planning how, state what this is for and what it has to actually achieve. If that is not clear, clarify it now — with the owner if it is a business decision, by reading the code if it is a technical one. A plan aimed at a fuzzy goal produces work that is complete and useless.
2 · Dispatch the expensive thinking
Send the planning work to the loop-planner agent (its model and effort are
fixed in its own definition, so the quality of the plan does not depend on how this
session happened to be launched). Give it: the goal, the relevant paths, and
.loop/VERIFY.md.
If the epic has more than one plausible shape, dispatch two or three planners with different framings in a single message (for example: smallest-shippable-first, risk-first, user-first), then take the best and graft what is worth keeping from the others. Say which framing won and why.
For anything touching money, permissions, auth, or schema, run loop-council on the
design before it becomes a slice.
3 · Write the plan to .loop/STATE.md
# Epic: <name> Goal: <what it must actually achieve>
[ ] 1. <slice>
non-negotiables: <what must be true to count as done>
verify: BUILD + OBSERVE + DATA
run: ./loop build # session role that should execute it
[ ] 2. <slice>
...
Deliberately out of scope: <what and why>
Order the slices so each one is safe to stop after. Depth before breadth: one epic at a time, and nothing new opens until what is open is closed.
4 · Assign a role to each following session
Each slice carries the command that runs it. The roles exist because the work is not all the same shape:
| Role | Command | What it is for |
|---|---|---|
| plan | ./loop plan "<goal>" |
this session — split, decide, do not code |
| build | ./loop build |
implement the next slice completely |
| verify | ./loop verify |
run the contract and judge honestly |
| close | ./loop close |
adversarial audit, ledger, handoff |
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.
- 3d ago First seen · 74 lines · 50 tokens per session scan A 1b0bfa6e473e
loop-plan is a skill published in the GitHub repository cbdreamer11/CB-loop-kit-claude-plugin (8 stars, last pushed 1mo ago), licensed MIT. It adds 50 tokens to every session and 751 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
audit-context
Evaluates ambient context artifacts (CLAUDE.md, memory, local skills, settings hooks) for compatibility with swarm governance. Returns a classified report so users can address interference before launching a team.
agentic-workflow-audit
Use when reviewing or auditing an existing agent / LLM-pipeline architecture — e.g. 'is my workflow actually decomposed or secretly a mega-agent?', 'are my task boundaries and success criteria right?' — even without the word 'audit'. ｜ 要檢視／review／稽核既有 agent 或 LLM pipeline 的架構，或問「有沒有拆好」「是不是變成 mega agent」「task…
feature-execution
This skill should be used when the user asks to "orchestrate the feature", "run the phases", "resume implementation", "continue the plan", "the phase agent died", "the agent stopped on its usage limit", "accept this phase", "can these phases run in parallel", "is this phase done", "does this shortfall matter", or…
phase-agent
Use this agent when a phase of a zforge feature plan is ready to implement and its work should run in its own context. Typical triggers include $zforge:feature-orchestrate spawning a READY phase, resuming a phase whose agent was interrupted mid-run, and re-running a phase after a decision was rejected in review. See…
async-reasoning
This skill should be used when implementing or designing code with async data flows — "state management design", "async data flow", "stale data", "cache invalidation", "optimistic update", "init order", "race condition", "write then read", "data not updating", "cache not refreshing", "UI shows old data after save"…
retro
This skill should be used when the user asks to "retro", "evaluate zforge", "review plugin performance", "score this session", or wants to assess how well zforge's workflow served a feature. Evaluates zforge's workflow scaffolding, not the project's technical decisions or LLM reasoning quality.