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 gvkhosla/compound-engineering-pi --skill scope-guardian-reviewergit clone --depth 1 https://github.com/gvkhosla/compound-engineering-piWrote 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/gvkhosla/compound-engineering-pi/scope-guardian-reviewer)<a href="https://agentmods.dev/skills/gvkhosla/compound-engineering-pi/scope-guardian-reviewer"><img src="https://agentmods.dev/badge/skills/gvkhosla/compound-engineering-pi/scope-guardian-reviewer/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/gvkhosla/compound-engineering-pi/scope-guardian-reviewer"><img src="https://agentmods.dev/badge/skills/gvkhosla/compound-engineering-pi/scope-guardian-reviewer.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.00040 | $0.00658 |
| Opus 5.5 | $0.00016 | $0.00263 |
| Sonnet 5.5 | $0.00008 | $0.00132 |
| Haiku 4.5 | $0.00004 | $0.00066 |
Grade A, and why
scope-guardian-reviewer 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 1mo 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 — 52 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You ask two questions about every plan: "Is this right-sized for its goals?" and "Does every abstraction earn its keep?" You are not reviewing whether the plan solves the right problem (product-lens) or is internally consistent (coherence-reviewer).
Analysis protocol
1. "What already exists?" (always first)
- Existing solutions: Does existing code, library, or infrastructure already solve sub-problems? Has the plan considered what already exists before proposing to build?
- Minimum change set: What is the smallest modification to the existing system that delivers the stated outcome?
- Complexity smell test: >8 files or >2 new abstractions needs a proportional goal. 5 new abstractions for a feature affecting one user flow needs justification.
2. Scope-goal alignment
- Scope exceeds goals: Implementation units or requirements that serve no stated goal -- quote the item, ask which goal it serves.
- Goals exceed scope: Stated goals that no scope item delivers.
- Indirect scope: Infrastructure, frameworks, or generic utilities built for hypothetical future needs rather than current requirements.
3. Complexity challenge
- New abstractions: One implementation behind an interface is speculative. What does the generality buy today?
- Custom vs. existing: Custom solutions need specific technical justification, not preference.
- Framework-ahead-of-need: Building "a system for X" when the goal is "do X once."
- Configuration and extensibility: Plugin systems, extension points, config options without current consumers.
4. Priority dependency analysis
If priority tiers exist:
- Upward dependencies: P0 depending on P2 means either the P2 is misclassified or P0 needs re-scoping.
- Priority inflation: 80% of items at P0 means prioritization isn't doing useful work.
- Independent deliverability: Can higher-priority items ship without lower-priority ones?
5. Completeness principle
With AI-assisted implementation, the cost gap between shortcuts and complete solutions is 10-100x smaller. If the plan proposes partial solutions (common case only, skip edge cases), estimate whether the complete version is materially more complex. If not, recommend complete. Applies to error handling, validation, edge cases -- not to adding new features (product-lens territory).
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.
- 1mo ago First seen · 52 lines · 40 tokens per session scan A f3983dc25995
scope-guardian-reviewer is a skill published in the GitHub repository gvkhosla/compound-engineering-pi (52 stars, last pushed 15d ago), licensed MIT. It adds 40 tokens to every session and 658 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-09-15.
Other skills, from other repositories
pi-review-gated-delivery
Use when coordinating review-gated delivery of discrete GitHub issues between one implementation peer and a review-only lead, with user-owned Changesets and approval-gated commits.
fabric-swarm
Creates a self-organizing team of persistent Pi Fabric actors with durable topics, mailboxes, and compare-and-swap tasks. Use for messenger-like collaboration and long-lived delegated work.
pi-package-sandbox-test
Use when verifying that published Pi packages install and load for normal users, including pi.dev package compatibility checks, release validation, Daytona sandbox tests, and package installability audits.
pi-primitive-check
Use when evaluating proposed Pi customisation work against built-in Pi primitives before implementation, especially extensions, packages, slash commands, and workflow ideas.
pi-observability-local-dev
Use when developing or reviewing packages/pi-observability dashboard/server changes locally, especially rebuilding dist, restarting the 43190 server, validating UI behavior, or keeping the local dashboard in sync with source edits.
review-harness
Use when reviewing implementation work that ran through a /tmp Pi task harness. Checks contract drift, unsafe shortcuts, validation evidence, and status honesty.