Open Agents is an open-source reference application for running background coding agents through a web interface, durable workflows, isolated Vercel sandboxes, and GitHub integration. Developers fork and adapt it to let agents make code changes without keeping a local computer running. The catalogue entries provide skills, agents, and instructions for its workflow.
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 vercel-labs/open-agents --skill plan-modegit clone --depth 1 https://github.com/vercel-labs/open-agentsWrote 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/vercel-labs/open-agents/plan-mode)<a href="https://agentmods.dev/skills/vercel-labs/open-agents/plan-mode"><img src="https://agentmods.dev/badge/skills/vercel-labs/open-agents/plan-mode/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/vercel-labs/open-agents/plan-mode"><img src="https://agentmods.dev/badge/skills/vercel-labs/open-agents/plan-mode.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
SkillSpector: 1 finding, up to low
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- low Excessive Agency · line 14 Skill's behavior or capabilities extend beyond its stated purpose. Scope creep allows an agent to perform actions unrelated to its documented functionality, increasing the attack surface.Fix: Limit the skill's scope to its documented purpose. Remove instructions that enable the agent to perform actions outside its stated functionality.
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.00060 | $0.01426 |
| Opus 5.5 | $0.00024 | $0.00570 |
| Sonnet 5.5 | $0.00012 | $0.00285 |
| Haiku 4.5 | $0.00006 | $0.00143 |
Grade A, and why
plan-mode 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 2mo 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 — 113 lines — stays where its author put it; the contents beside it link to each section on GitHub.
For non-trivial implementation tasks, plan before you code. Treat every change as a system change, not an isolated patch. Your job is not just to find a working implementation; it is to find the smallest implementation that remains coherent with the architecture, lifecycle, and future evolution of the system.
Planning Doctrine
- Think broadly, implement narrowly. Analyze the surrounding system before deciding where the change belongs.
- Every change has system implications. Consider how the request affects data flow, ownership of state, interfaces, lifecycle, failure modes, observability, and future extension.
- Prefer authoritative, derivable designs. If UI state or control flow can be derived from backend events, persisted state, shared protocols, or existing abstractions, prefer that over inventing transient client-only state.
- Choose the smallest coherent solution. Do not default to the smallest local patch if it distorts the architecture or adds hidden follow-on complexity.
- Expand scope only when it simplifies the system. Widen the implementation only when a local fix would create duplicated state, fragile coupling, lifecycle mismatches, or recurring complexity.
- Do not gold-plate. Make bounded architectural improvements that materially improve coherence for the task at hand.
Plan File
Write your plan to a PLAN.md file in the project root. Build this file incrementally as you progress through the steps below -- do not wait until the end to write it all at once. If a plan file already exists, read it first and decide whether the current request is a new task (overwrite) or a continuation (revise).
Step 1: Explore
Thoroughly explore the codebase to understand the request before designing anything.
- Read the relevant files and understand existing patterns, architecture, and conventions.
- Trace the end-to-end flow, not just the local implementation point.
- Identify the current source of truth, state ownership, boundaries between subsystems, and any existing invariants.
- Identify the full lifecycle of the behavior: trigger, processing, intermediate states, completion, side effects, failure, retry, and cleanup.
- Search for similar features and prior art in the codebase.
- Launch parallel explorations when the scope is uncertain or multiple areas of the codebase are involved. Give each exploration a specific, distinct search focus (e.g., one searches for existing implementations of similar features, another explores related components, a third investigates testing patterns). Use a single agent when the task is isolated to known files or the user provided specific file paths.
- Do not start implementing yet.
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.
- 2mo ago First seen · 113 lines · 60 tokens per session scan A aa0ac4bab69a
plan-mode is a skill published in the GitHub repository vercel-labs/open-agents (5,884 stars, last pushed 2mo ago), licensed MIT. It adds 60 tokens to every session and 1,426 once invoked, about $0.0002 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.
plan-mode compared with skills from other repositories
| Mod | Type | Stars | Last push | Licence | Scan | Tokens | Works with |
|---|---|---|---|---|---|---|---|
| plan-modevercel-labs/open-agents | Skill | 5.9k | 2mo ago | MIT | A | 60 | Claude Code, Codex |
| adk-unit-designgoogle/adk-python | Skill | 22k | today | Apache-2.0 | A | 181 | Claude Code, Codex |
| security-conductorkirodotdev/KiroCrew | Skill | 4.8k | today | Apache-2.0 | A | 57 | Claude Code, Codex |
| artifact-deploykirodotdev/KiroCrew | Skill | 4.8k | today | Apache-2.0 | A | 74 | Claude Code, Codex |
| explain-forkirodotdev/KiroCrew | Skill | 4.8k | today | Apache-2.0 | A | 71 | Claude Code, Codex |
| learn-from-sagekirodotdev/KiroCrew | Skill | 4.8k | today | Apache-2.0 | A | 56 | Claude Code, Codex |
| web-verifykirodotdev/KiroCrew | Skill | 4.8k | today | Apache-2.0 | A | 0 | Claude Code, Codex |