Borrowing it
Nothing to install: this file belongs to secure-ssid/hpe-networking-mcp. 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/secure-ssid/hpe-networking-mcp/main/.agents/skills/project-review/SKILL.mdgit clone --depth 1 https://github.com/secure-ssid/hpe-networking-mcpWrote 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/secure-ssid/hpe-networking-mcp/project-review)<a href="https://agentmods.dev/skills/secure-ssid/hpe-networking-mcp/project-review"><img src="https://agentmods.dev/badge/skills/secure-ssid/hpe-networking-mcp/project-review/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/secure-ssid/hpe-networking-mcp/project-review"><img src="https://agentmods.dev/badge/skills/secure-ssid/hpe-networking-mcp/project-review.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.00033 | $0.00631 |
| Opus 5 | $0.00016 | $0.00316 |
| Sonnet 5 | $0.00007 | $0.00126 |
| Haiku 4.5 | $0.00003 | $0.00063 |
Grade A, and why
project-review 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.
How it starts
The opening of the file, as written. The whole thing — 67 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Reviewing in a pika repository
What counts as evidence
In order of authority:
- A green
pika check. The ladder ran the repository's own declared commands. This is the only completion signal. - The evidence receipt at
.project/evidence/<work-id>.json— issued by the kernel from what it observed: the gates it ran, their exits and durations, the commit and tree it produced, baseline failures and regressions. - The run record at
.project/state/work/<work-id>/record.json— local, gitignored, showing every phase the run passed through.
A narrative claim is not on this list. Neither is a diff that looks correct.
What a reviewer must not do
Do not write or overwrite a receipt. A receipt supplied by the subject of
the work is a claim; one issued by the component that ran the gates is evidence.
publish_evidence refuses to overwrite a kernel-issued receipt, and that
refusal is the point.
Do not accept a green ladder that was made green by weakening it. Check
whether a gate command, an assertion, or a test's scope changed in the same
change that made it pass. pika explain <gate-id> tells you what a gate is for.
Do not treat a warning as a finding to fix. Warnings do not fail gates. Ask whether the warning is telling you something true before asking anyone to act on it.
Do not read raw transcripts. They are local by design. Review the receipt, the record, and the diff.
Reading a receipt
The fields that matter most:
completion.complete— withreasonrequired when false, andblockerforbidden when true.commands[]— each gate's argv, exit and duration, in ladder order: baseline first, then recheck.baseline_failures[]versusregressions[]— a pre-existing failure is not a regression, and conflating them is how a red baseline gets blamed on a change that did not cause it.changed_files[]with ownership.
Every string in a receipt has passed redaction. If you find a credential in one, that is a defect in the redactor, not something to fix by hand.
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 First seen · 67 lines · 33 tokens per session scan A 731c17dfd2b6
project-review is a skill published in the GitHub repository secure-ssid/hpe-networking-mcp (1 stars, last pushed 5d ago), licensed MIT. It adds 33 tokens to every session and 631 once invoked, about $0.0002 per session on Opus 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-05.
Other skills, from other repositories
sumo-qa-implementing-with-tdd
Use after sumo-qa-deciding-approach picks tdd-scaffold, regression-first, or coverage-first-then-refactor — e.g. "write a regression test for this bug" or "scaffold the failing tests first". Walks plan → name-the-risk-and-test-idea → confirm → red → hand off → green → review, one section per turn with confirmation…
sumo-qa-planning-qa-rollout
Use when you have a chunk of QA work (a story, a PR, a strategy phase) that needs to be turned into a written plan of bite-sized, independently-executable tasks before any test code is written. Walks scope → file structure → bite-sized tasks → confirm, one section per turn. Produces docs/qa/plans/YYYY-MM-DD- .md ready…
sumo-qa-finishing-qa-work
Use at the end of a QA rollout (after sumo-qa-executing-qa-rollout, or after a manual multi-step QA task) to capture evidence, produce a PR-ready summary, and close the loop. Runs the suite one last time, captures coverage / risk-to-test map / open follow-ups, writes a markdown summary to docs/qa/runs/YYYY-MM-DD- .md…
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…
sumo-qa-deciding-approach
Use as the FIRST step on any QA intent. Loads classifications + approaches (the two needed to route), then reasons over the user's intent to pick the canonical approach and routes to the matching sub-skill (which loads any further catalogues on demand).
sumo-qa-preparing-for-work
Use when the user asks to plan QA for a story, ticket, or piece of work before coding starts. Identifies named risks anchored in the change shape, then proposes a smallest useful test set tied to those risks. Lighter-weight than sumo-qa-creating-test-plan; no formal entry/exit criteria.