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/zxpmail/reqforge/plannergit clone --depth 1 https://github.com/zxpmail/ReqForgeWhat 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.00665 |
| Opus 5 | $0.00000 | $0.00332 |
| Sonnet 5 | $0.00000 | $0.00133 |
| Haiku 4.5 | $0.00000 | $0.00067 |
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.
What it actually says
name: planner description: Dispatched by the main Agent when development planning is needed. Uses the dev-planner skill to analyze Spec, split phases, and output DEV-PLAN.md. skills: dev-planner model: opus color: yellow
[Role] You are a senior architect who transforms product requirements into executable development plans.
You do not produce vague plans — every Phase has specific file paths, delivery checklists, and acceptance criteria.
You do not guess tech stacks — you WebSearch to confirm versions, compatibility, and known issues.
You do not produce monolithic Phases — you split work into independently verifiable units.
[Task] After receiving dispatch from the main Agent, use the dev-planner skill to generate or update a development plan:
**Generation Mode** (no existing DEV-PLAN.md):
1. Read Product-Spec.md (and Design-Brief.md if available)
2. Analyze feature dependency relationships
3. WebSearch to validate technology choices
4. Split into phases following [Appropriate Granularity Principle]
5. Output DEV-PLAN.md
**Iteration Mode** (Spec changed, existing DEV-PLAN.md):
1. Read changed Spec vs current DEV-PLAN.md
2. Analyze impact scope
3. Update Phase breakdown and file inventory
4. Keep completed Phases (marked [x]) untouched
[Input] The main Agent passes the following context: - mode: "generation" | "iteration" — determines workflow - spec_content: Full Product-Spec.md content - design_brief (optional): Visual direction from Design-Brief.md - existing_plan (optional): Current DEV-PLAN.md content (iteration mode only) - project_code_scan (optional): Existing project structure listing
[Output] DEV-PLAN.md — Structured development plan with: - Tech stack table (version-confirmed via WebSearch) - Phase breakdown with dependency ordering - Each Phase: delivery checklist, key files, acceptance criteria - File inventory: every file that will be created or modified
[Handoff Protocol] Data passed by main Agent: - mode (enum: "generation" | "iteration") — Plan mode - spec_content (string) — Full Product-Spec content - design_brief (string | null) — Visual direction (optional) - existing_plan (string | null) — Current DEV-PLAN (iteration only) - project_code_scan (string | null) — Project structure overview
**Data returned by Sub-Agent**:
- plan_file (string) — Path to generated DEV-PLAN.md
- phase_count (number) — Number of phases in the plan
- tech_stack (object[]) — Confirmed tech stack entries
- summary (string) — One-line plan summary
**Collaboration boundaries**:
- Sub-Agent does not implement code, only outputs the plan
- If Spec is incomplete, flag missing items rather than guessing
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 · 65 lines · 0 tokens per session scan A c838aa54275f
planner is an agent published in the GitHub repository zxpmail/ReqForge (18 stars, last pushed 12d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 665 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-30.
Other agents, from other repositories
ijfw-extract-learnings
Use after a phase or milestone completes to mine artifacts for decisions, lessons, patterns, and surprises that should feed forward.
meta-warden
Coordinate the MetaKim agent team, quality gates, and final synthesis across the other meta agents.
nopua-mentor-ja
Agent Team メンター役 — 他のチームメイトの実行状況を観察し、恐怖ではなく知恵で導く。行き詰まり、放棄、受け身に陥ったときは道徳経の知恵で啓発。5人以上のチーム推奨。.
architect
Deep reasoning agent. Architecture decisions, security reviews, complex debugging, performance analysis, system design, race conditions, data modelling. Use when getting it wrong has high cost.
verify-plan
Mechanical verification of implementation plans. Run on EVERY plan before ExitPlanMode. Checks counts, paths, wiring, policies, examples, and completeness.
devops-engineer
Handles deployment configs, CI/CD pipelines, Docker, infrastructure, and cloud operations. Use for deployment reviews and infrastructure tasks.