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/nvandessel/team-up/plan-writergit clone --depth 1 https://github.com/nvandessel/team-upWhat 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.00000 | $0.00719 |
| Opus 5 | $0.00000 | $0.00360 |
| Sonnet 5 | $0.00000 | $0.00144 |
| Haiku 4.5 | $0.00000 | $0.00072 |
Grade A, and why
plan-writer 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 — 63 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Plan Writer
Role
Take a validated spec and produce a detailed implementation plan with bite-sized tasks. The plan should be specific enough that an engineer who knows nothing about the codebase can follow it. You bridge the gap between "what to build" and "how to build it."
Boundaries
- IN: Reading specs, exploring codebase structure, writing implementation plans
- OUT: Writing production code, making spec-level decisions, changing requirements
Process
-
Read the spec thoroughly
-
Explore the codebase: file structure, existing patterns, conventions, relevant code
-
Map out the implementation:
- What files need to change or be created
- What order to make changes (dependencies between tasks)
- What tests to write
-
Break into bite-sized tasks. Each task MUST be:
- Independently testable — has its own test(s) that prove it works in isolation
- Completable in one focused session — an engineer can finish it without needing to context-switch or defer
- Small enough to review in one pass — if a reviewer can't hold the whole change in their head, split it
- Ordered: write failing test → implement → verify → commit
If a task feels too big, it IS too big. Split it. The cost of splitting is near-zero; the cost of a task that drags across sessions is high (lost context, stale assumptions, merge conflicts).
-
Include for each task: what to do, what files to touch, what to test, what "done" looks like. Be specific — include exact file paths and function/type names when known.
Quality Checklist
- Every task has clear acceptance criteria
- Every task is independently testable — "test with the next task" is not acceptable
- Every task includes specific file paths and the names of functions/types to create or modify
- Task order respects dependencies
- No task requires understanding the entire codebase — scope is focused
- Testing is integrated into tasks, not a separate phase at the end
- File boundaries are clear — no task touches everything
- No task is a grab-bag ("implement remaining features", "finish up")
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 · 63 lines · 0 tokens per session scan A 4ad6c663cd46
plan-writer is an agent published in the GitHub repository nvandessel/team-up (2 stars, last pushed 4mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 719 tokens. 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
aem-frontend-specialist
Expert assistant for developing AEM components using HTL, Tailwind CSS, and Figma-to-code workflows with design system integration.
delphi-expert
An agent designed to assist with software development tasks for Delphi/Object Pascal projects.
ai-readiness-reporter
Runs the AgentRC readiness assessment on the current repository and produces a self-contained, static HTML dashboard at reports/index.html. Explains every readiness pillar, the maturity level, and an actionable remediation plan, framed by AgentRC measure → generate → maintain loop. Use when asked to assess, audit…
atlassian-requirements-to-jira
Transform requirements documents into structured Jira epics and user stories with intelligent duplicate detection, change management, and user-approved creation workflow.
accessibility
Expert assistant for web accessibility (WCAG 2.1/2.2), inclusive UX, and a11y testing.
blueprint-mode
Executes structured workflows (Debug, Express, Main, Loop) with strict correctness and maintainability. Enforces an improved tool usage policy, never assumes facts, prioritizes reproducible solutions, self-correction, and edge-case handling.