Borrowing it
Nothing to install: this file belongs to MarcusJellinghaus/mcp-workspace. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/MarcusJellinghaus/mcp-workspace/main/.claude/skills/implementation_review_supervisor/SKILL.mdgit clone --depth 1 https://github.com/MarcusJellinghaus/mcp-workspaceWrote 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-workspace/implementation_review_supervisor)<a href="https://agentmods.dev/skills/marcusjellinghaus/mcp-workspace/implementation_review_supervisor"><img src="https://agentmods.dev/badge/skills/marcusjellinghaus/mcp-workspace/implementation_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-workspace/implementation_review_supervisor"><img src="https://agentmods.dev/badge/skills/marcusjellinghaus/mcp-workspace/implementation_review_supervisor.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00014 | $0.01493 |
| Opus 5.5 | $0.00006 | $0.00597 |
| Sonnet 5.5 | $0.00003 | $0.00299 |
| Haiku 4.5 | $0.00001 | $0.00149 |
Grade A, and why
implementation_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 5d 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.
Copies of this mod
2 near-identical copies found in the catalogue:
- implementation_review_supervisor — 94% identical, 6 lines differ
- implementation_review_supervisor — 89% identical, 6 lines differ
How it starts
The opening of the file, as written. The whole thing — 79 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Automated Implementation Review (Code 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 implementation work 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. Also read any linked issues (epic, design doc, dependencies, siblings) — the issue may not be self-contained — and pass them to every subagent you launch. - Read the knowledge base files:
.claude/knowledge_base/software_engineering_principles.md.claude/knowledge_base/python.md
- Check for existing
pr_info/implementation_review_log_*.mdfiles to determine the next run number{n}. - Create
pr_info/implementation_review_log_{n}.mdwith a header.
Your Role:
- Delegate: Launch subagents to do the work. Do not execute code, read files, or run tests yourself.
- Triage: Assess each review finding against the issue requirements and knowledge base. Skip items that are out of scope, cosmetic, or speculative. Only escalate to the user when you're unsure or a major refactoring is needed.
- Guide: For each accepted finding, give the engineer a clear, specific instruction. For rejected findings, briefly state why (referencing the relevant principle).
- Scope: Stay close to the relevant issue. Don't let the review drift into unrelated improvements.
Pre-flight: Task Tracker Check
- Check
pr_info/TASK_TRACKER.mdfor unchecked items under## Tasksonly. Ignore other sections (## Pull Requestor## Code Review, etc.) — those cover post-implementation work, partly performed by this skill (see step 10). - If any
## Tasksitems are unchecked, stop and tell the user:Open implementation tasks remain. Run
/implementation_finalisefirst.
Prerequisites:
- Code must exist. If the review subagent reports there is no implementation diff (only plan files, docs, or pr_info/), stop immediately and tell the user there is nothing to review yet.
Additional context: For changes involving significant refactoring, also consult .claude/knowledge_base/refactoring_principles.md.
Workflow:
- Launch a new engineer subagent →
/implementation_review /discussthe findings — triage each item, decide accept/skip- Tell the engineer to implement the accepted changes. If a major refactoring is needed, stop and talk to the user.
- Update
pr_info/implementation_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. The commit agent should verify only the expected files are modified before committing.
- Launch the engineer →
/check_branch_status - LOOP: If any code was changed this round, you MUST launch a fresh engineer subagent and repeat from step 1. Only proceed to step 8 when a round produces zero code changes. Do NOT stop or wait for user input between rounds — the loop is automatic.
- Run
run_vulture_checkandrun_lint_imports_checkyourself. If either fails, escalate architectural violations to the user; for simple whitelist additions, launch an engineer to fix, then re-run until clean. - Add a
## Final Statussection to the log. Commit and push the log via the commit agent. - Launch the engineer →
/check_branch_statusto verify CI, rebase need, and overall readiness. Include the result in the completion message. - Perform any PR-section tasks this skill covers — typically
PR revieworCode review. Once done, tick them inpr_info/TASK_TRACKER.mdand commit via the commit agent (separate commit from the log). Leave unrelated tasks likePR summaryalone. - Notify the user with a short completion message: rounds run, commits produced, whether any issues remain, and branch status (CI, rebase needed). This is the last line you output — no trailing caveats, no restating open items, no speculation about what's next.
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.
- 5d ago Changed 08a67f29881a
- 1mo ago First seen · 79 lines · 14 tokens per session scan A 64175e0b3a39
implementation_review_supervisor is a skill published in the GitHub repository MarcusJellinghaus/mcp-workspace (48 stars, last pushed today), licensed MIT. It adds 14 tokens to every session and 1,493 once invoked, about $0.0001 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-30.
Other skills, from other repositories
gitnexus-pr-review
Use when the user wants to review a pull request, understand what a PR changes, assess risk of merging, or check for missing test coverage. Examples: "Review this PR", "What does PR #42 change?", "Is this PR safe to merge?".
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?".
gitnexus-refactoring
Use when the user wants to rename, extract, split, move, or restructure code safely. Examples: "Rename this function", "Extract this into a module", "Refactor this class", "Move this to a separate file".
code-review
Reviews a supplied code path or diff for correctness, security, maintainability, and style without executing or modifying it.
reviewing-update-sets
Reviewing, analyzing, and comparing ServiceNow update sets before promotion, singly or in batches. Shows changes, risks, dependencies, and conflicts. Use when the user mentions update sets, customizations, promotion, code review, change tracking, pre-deployment review, sysupdatexml, customer updates, 'what changed in…
live-audit
Audit steam-games-mcp — build/test/lint gate, live MCP tool edge-case sweep (input validation, SteamID64/vanity/appid edge cases, key-gating), and source-level code review. Use when asked to test/audit the published or just-fixed steam-games-mcp package, hunt for bugs/edge cases, or repeat "the same kind of testing as…