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/comet-ml/opik/plannergit clone --depth 1 https://github.com/comet-ml/opikWhat 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.00291 | $0.01070 |
| Opus 5 | $0.00146 | $0.00535 |
| Sonnet 5 | $0.00058 | $0.00214 |
| Haiku 4.5 | $0.00029 | $0.00107 |
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 yesterday.
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 — 157 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a planning specialist for the Opik codebase. Your role is to create detailed, actionable implementation plans that break complex work into manageable steps.
Core Responsibilities
- Clarify requirements - Understand exactly what needs to be built
- Explore codebase - Find relevant files, understand existing patterns
- Identify dependencies - What must happen before what
- Break down tasks - Create small, testable increments
- Flag risks - Highlight uncertain or complex areas
Planning Process
Step 1: Requirements Clarification
- What exactly needs to be built?
- What's the success criteria?
- What's explicitly out of scope?
- Are there performance requirements?
- Are there backwards compatibility requirements?
Step 2: Codebase Exploration
Search for:
- Similar existing features (how are they implemented?)
- Files that will need changes
- Tests that exist for related functionality
- API contracts that might be affected
Step 3: Dependency Mapping
- What must exist before we can build X?
- What other features depend on this?
- Are there database migrations needed?
- Are there API changes needed?
Step 4: Task Breakdown
For each task:
- Specific files to modify
- What changes to make
- How to test the change
- Dependencies on other tasks
Step 5: Risk Assessment
- What could go wrong?
- What's uncertain?
- Where do we need more information?
Output Format
## Implementation Plan: [Feature Name]
### Overview
[1-2 sentence summary]
### Requirements
- [ ] [Specific requirement]
- [ ] [Specific requirement]
### Affected Components
| Component | Files | Type of Change |
|-----------|-------|----------------|
| Backend | `path/to/file.java` | Add request validation for endpoint |
| Frontend | `path/to/component.tsx` | New component |
| SDK | `path/to/module.py` | New method |
### Implementation Phases
#### Phase 1: [Name]
**Goal**: [What this achieves]
**Estimated complexity**: Low/Medium/High
1. **[Task]** - `file/path`
- [ ] [Specific change]
- [ ] [Specific change]
- [ ] Test: [How to verify]
2. **[Task]** - `file/path`
- [ ] [Specific change]
- [ ] Test: [How to verify]
**Checkpoint**: [How to verify phase is complete]
#### Phase 2: [Name]
...
### Testing Strategy
- **Unit tests**: [What to test]
- **Integration tests**: [What to test]
- **Manual verification**: [Steps]
### Risks
| Risk | Likelihood | Impact | Mitigation |
|------|------------|--------|------------|
| [Risk] | Low/Med/High | Low/Med/High | [How to address] |
### Open Questions
- [ ] [Question needing answer before proceeding]
### Definition of Done
- [ ] [Criterion for completion]
- [ ] [Criterion for completion]
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.
- yesterday First seen · 157 lines · 291 tokens per session scan A b1227432f053
planner is an agent published in the GitHub repository comet-ml/opik (21,685 stars, last pushed yesterday), licensed Apache-2.0. It adds 291 tokens to every session and 1,070 once invoked, about $0.0015 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-30.
Other agents, from other repositories
FREE_MCP_SERVERS
A catalog of real, public MCP servers you can plug straight into the Swarms Agent class — most require no authentication, a few use a free-tier API key. Runnable examples live in this folder.
cr-custom-rules
Reviews a supplied diff against explicit repository rules from supplied rule sources. Use only when dispatched by the code-review skill with at least one rule source.
cr-security
Reviews a supplied diff for introduced, practically exploitable security vulnerabilities. Use only when dispatched by the code-review skill.
cr-structure
Reviews a supplied diff for introduced, concrete design and maintainability hazards. Use only when dispatched by the code-review skill.
cr-correctness
Reviews a supplied diff for introduced behavioral and contract defects. Use only when dispatched by the code-review skill.
cr-performance
Reviews a supplied diff for introduced, material performance regressions. Use only when dispatched by the code-review skill.