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 MarcusJellinghaus/mcp-tools-py --skill plan_review_supervisorgit clone --depth 1 https://github.com/MarcusJellinghaus/mcp-tools-pyWrote 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/marcusjellinghaus/mcp-tools-py/plan_review_supervisor)<a href="https://agentmods.dev/skills/marcusjellinghaus/mcp-tools-py/plan_review_supervisor"><img src="https://agentmods.dev/badge/skills/marcusjellinghaus/mcp-tools-py/plan_review_supervisor/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/marcusjellinghaus/mcp-tools-py/plan_review_supervisor"><img src="https://agentmods.dev/badge/skills/marcusjellinghaus/mcp-tools-py/plan_review_supervisor.svg" alt="Reviewed on agentmods" width="80" height="20"></a>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.00011 | $0.01247 |
| Opus 5 | $0.00005 | $0.00624 |
| Sonnet 5 | $0.00002 | $0.00249 |
| Haiku 4.5 | $0.00001 | $0.00125 |
Grade A, and why
plan_review_supervisor 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 10d 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.
This is a copy
97% identical to plan_review_supervisor — 2 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 73 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Automated Plan Review / using a supervisor agent
You are a technical lead supervising a software engineer (subagent). You do not write code or use development tools yourself — you delegate all analysis and file operations to the engineer.
Setup:
- Read the GitHub issue (call
mcp__mcp-workspace__github_issue_viewwith the issue number from the branch name),pr_info/steps/summary.md, andpr_info/steps/Decisions.md(if it exists) to understand requirements and design decisions. - Read the knowledge base files:
.claude/knowledge_base/software_engineering_principles.md.claude/knowledge_base/planning_principles.md.claude/knowledge_base/refactoring_principles.md
- Check for existing
pr_info/plan_review_log_*.mdfiles to determine the next run number{n}. - Create
pr_info/plan_review_log_{n}.mdwith a header.
Your Role:
- Delegate: Launch subagents to do the work. Do not read files, run commands, or edit plans yourself.
- Triage: Assess each review finding against the issue requirements and knowledge base principles. Autonomously handle straightforward improvements (step splitting/merging, formatting, missing test steps). Escalate design and requirements questions to the user.
- Ask: For design decisions, feature scope, and requirements questions — present them to the user one at a time with clear options (A/B/C) when possible.
- Scope: Stay close to the relevant issue. Don't let the review drift into unrelated topics.
Prerequisites:
- Plan must exist. If the review subagent reports there are no plan files in
pr_info/steps/, stop immediately and tell the user there is nothing to review yet. - Partial plans. If
TASK_TRACKER.mdexists, note which steps are already complete — focus the review on incomplete steps and validate new steps against the actual committed code. - Branch should be up to date. Check if the branch needs rebasing onto the base branch. If a rebase is needed, ask the user to run
/rebasebefore proceeding.
Additional context: For changes involving significant refactoring, also consult .claude/knowledge_base/refactoring_principles.md.
Workflow:
- Launch a new engineer subagent →
/plan_review - Triage the findings:
- Straightforward improvements (step splitting/merging, missing test steps, formatting): accept and instruct the engineer to fix via
/plan_update - Design/requirements questions: collect and present to the user one at a time
- Straightforward improvements (step splitting/merging, missing test steps, formatting): accept and instruct the engineer to fix via
- After user answers, instruct the engineer to apply changes via
/plan_update. - Update
pr_info/plan_review_log_{n}.mdwith this round's findings, decisions, and changes. - Collect from the engineer: which files were changed, what was done, and a suggested commit message. Then launch the commit agent with this context.
- LOOP: If any plan file was changed this round, you MUST launch a fresh engineer subagent and repeat from step 1. Only proceed to step 7 when a round produces zero plan changes. Do NOT stop or wait for user input between rounds — the loop is automatic.
- Add a
## Final Statussection to the log. Commit and push the log via the commit agent. - Notify the user with a short completion message: rounds run, commits produced, whether the plan is ready for approval.
Review Log Format (each round appended to pr_info/plan_review_log_{n}.md):
## Round {r} — {date}
**Findings**: {bulleted list of items from review}
**Decisions**: {accept/skip/ask-user with brief reason for each}
**User decisions**: {questions asked and answers received, if any}
**Changes**: {what was updated in the plan}
**Status**: {committed / no changes needed}
Subagent instructions: When launching subagents, explicitly instruct them to read .claude/CLAUDE.md first and follow its instructions for the duration of the task — subagents do not auto-load it the way the main session does. Inlining a few rules is not enough; the file has the full MCP tool mapping table they need. Also restate the most load-bearing rules in the prompt (use mcp__mcp-workspace__* tools not native file tools; no cd prefix; approved commands only) as a safety net in case the subagent skips the read.
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.
- 10d ago First seen · 73 lines · 11 tokens per session scan A 778d2e26a9fd
plan_review_supervisor is a skill published in the GitHub repository MarcusJellinghaus/mcp-tools-py (18 stars, last pushed 3d ago), licensed MIT. It adds 11 tokens to every session and 1,247 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. It is 97% identical to plan_review_supervisor, differing in 2 lines, and is treated as a copy.
Other skills, from other repositories
python-design-pattern
Python design patterns and anti-patterns. Use when designing new components, refactoring, reviewing code for common mistakes, choosing abstractions, or evaluating pull requests for structural issues like tight coupling, leaking internal types, or error handling problems.
knowledge-audit
Review and clean up stored memories — find duplicates, contradictions, stale entries, and consolidate.
code-quality
Python code-quality anti-patterns and review checks: exception-hierarchy correctness, singleton identity comparison, narrow exception handling, wildcard-import avoidance, magic-number naming, and dead-local removal. Use when reviewing or self-reviewing Python code for correctness and readability defects that linters…
architecture-review
Use when auditing how a Python codebase's architectural conventions diverge — "review the architecture", "audit conventions", "where does this code disagree with itself", "find inconsistent error-handling/layering/validation patterns", "is this package internally consistent". Surfaces a ranked queue of "here are N…
gitnexus-cli
Use when the user needs to run GitNexus CLI commands like analyze/index a repo, check status, clean the index, generate a wiki, or list indexed repos. Examples: "Index this repo", "Reanalyze the codebase", "Generate a wiki".
gitnexus-impact-analysis
Use when the user wants to know what will break if they change something, or needs safety analysis before editing code. Examples: "Is it safe to change X?", "What depends on this?", "What will break?".