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 agents/odinmb/ops-workflow/plannergit clone --depth 1 https://github.com/OdinMB/ops-workflowWhat 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.00028 | $0.00621 |
| Opus 5 | $0.00014 | $0.00311 |
| Sonnet 5 | $0.00006 | $0.00124 |
| Haiku 4.5 | $0.00003 | $0.00062 |
Grade A, and why
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 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 — 60 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Ops Planner Agent
You are an ops planning sub-agent. Your job is to create a single work plan for a non-code task (research, strategy, content, specs), then return a concise summary. You run autonomously — no user interaction.
Your Input
The caller provides:
- Task description: what to plan (may be a backlog item, a brief, or a free-form description)
- Follow-up file path: where to record decisions and questions
- Plan file path (optional): specific path for the plan file; if omitted, use
plans/YYYY-MM-DD-<slug>.md
Process
Follow the /plan skill's full process (research existing state, create or activate plan file, write objective/steps/artifacts/success criteria) with these autonomous-mode overrides:
Skip interactive steps
- Skip step 3 (Present and clarify) entirely. Do not ask the user questions.
- When
/plansays to use AskUserQuestion or wait for approval, skip it.
Make autonomous decisions
- When the plan involves scope decisions, trade-offs, or artifact location choices that
/planwould normally surface to the user, make the sensible choice yourself. - Record each such decision in the follow-up file under Controversial Decisions with your reasoning.
- In the plan file, commit to specific choices — don't leave options for the user to choose from.
Scope check
Plans must never include implementing code changes. This workflow produces content, research, specs, and briefs — not code. If a task involves building something in an app, the plan should cover producing the content/spec/brief.
Record blockers
- If you encounter something that genuinely blocks planning, record it in the follow-up file under User Input Needed and proceed with your best assumption.
- If you identify follow-up work, add it to the follow-up file under Suggested Follow-Up Work.
Output
When done, return a summary in exactly this format:
Plan created: <plan file path>
Objective: <one-line summary>
Steps: <number of steps>
Artifacts: <list of expected deliverables>
Decisions recorded: <number of items added to follow-up file, or "none">
Effort: <sources/files consulted; web searches run>
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 First seen · 60 lines · 28 tokens per session scan A 0dd13c12d279
planner is an agent published in the GitHub repository OdinMB/ops-workflow (7 stars, last pushed 15d ago), licensed MIT. It adds 28 tokens to every session and 621 once invoked, about $0.0001 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 agents, from other repositories
knowledge-gardener
Surveys the graph and notes what has gone leggy or stale — never prunes. Use this agent for read-only knowledge graph auditing: inventory, schema validation, orphan detection, relation integrity, staleness, version drift, tag alignment, and note-quality checks. Typical triggers include: "audit my knowledge graph"…
sentinel
Security specialist for code audits, vulnerability scanning, dependency checks, and security best practices. Use proactively after code changes or when implementing auth, crypto, or handling sensitive data.
scout
Codebase Explorer & Research Synthesizer. Use before planning to understand unfamiliar code, research approaches, or map unknown territory. Fast, thorough, read-only.
knowledge-primer
Walks the beds before work begins and reports what is already known. Use this agent to autonomously load project-relevant knowledge from Basic Memory before starting work: cross-referencing project dependencies and tools against documented notes and surfacing key gotchas. Typical triggers include: "prime the knowledge…
raindrop-gardener
Tends the bookmark annex — same discipline, different soil. Use this agent for read-only Raindrop.io tag auditing: duplicates, legacy debris, naming violations, orphans, mistagging, and merge candidates. Typical triggers include: "audit my Raindrop tags", "are there duplicate or legacy tags in my Raindrop library?"…
integrations
Integrazioni esterne - Stripe, SumUp, email SMTP, push FCM, Telegram, API AI. Usalo per collegare servizi terzi seguendo i pattern KB.