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 gitRasheed/metis-skill --skill p8-agenticgit clone --depth 1 https://github.com/gitRasheed/metis-skillWrote 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/gitrasheed/metis-skill/p8-agentic)<a href="https://agentmods.dev/skills/gitrasheed/metis-skill/p8-agentic"><img src="https://agentmods.dev/badge/skills/gitrasheed/metis-skill/p8-agentic/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/gitrasheed/metis-skill/p8-agentic"><img src="https://agentmods.dev/badge/skills/gitrasheed/metis-skill/p8-agentic.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.00000 | $0.00878 |
| Opus 5.5 | $0.00000 | $0.00351 |
| Sonnet 5.5 | $0.00000 | $0.00176 |
| Haiku 4.5 | $0.00000 | $0.00088 |
Grade A, and why
P8-agentic 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 — 80 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Metis (condensed)
Write code that favors plain data, pure logic, clear call sites, and early architectural thinking. Strong defaults, not laws: follow the codebase, framework, and language when they clearly matter more.
Design
- Start from the call site by wishful thinking: write the caller you wish existed, then make helpers match. Awkward calling code means wrong abstractions — found before building anything.
- Plain data + focused functions/modules over behavior-heavy objects. Boundaries around what systems DO, not what entities ARE.
- Simplest state model that matches reality: discriminated unions for mutually exclusive states, composable data for orthogonal features, a flat record when neither pressure exists.
- Mutation and I/O at the edges; orchestration decides, leaves do narrow work; push ifs up, fors down.
- Assert at boundaries both ways (entering and leaving): parsing, persistence, APIs, state transitions. Check what must be true AND what must not be.
- Design for the hardest real requirement first, then simplify down. When batch elements can invalidate each other, classify the whole batch before applying any element.
- Trace invariants before adding defensive checks: if an upstream parser/type/boundary already guarantees it, do not re-check.
Working
- Prefer pure functions and data transformations; adapters around awkward external APIs; invariants next to the operations that need them (do not validate early and trust it later if data can drift).
- Self-explaining names; comments only for a non-obvious WHY, one line.
- SOLID as a checklist without ceremony: one reason to change; extend via a focused function/variant/adapter, never pre-built extension points; variants honor the contract; narrow interfaces; policy depends on stable abstractions, not I/O details.
Tests
Decide expected behavior BEFORE implementing; prefer a failing behavior check first (red-green) when practical. Prefer integration/contract tests over implementation-mirroring unit tests. One visible behavior per test; no loops/branches hiding the harness. Never move goalposts to make broken code look right. Delete scaffolding tests before done.
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 · 80 lines · 0 tokens per session scan A 4ae52fde4051
P8-agentic is a skill published in the GitHub repository gitRasheed/metis-skill (2 stars, last pushed yesterday), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 878 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-31.
Other skills, from other repositories
necessary-code-audit
A review process for deciding whether code that still has callers is genuinely needed. It examines wrappers, compatibility layers, old public interfaces, fallbacks, defaults, defensive branches, configuration, and duplicate data sources.
unused-code-audit
A code-audit skill for proving whether files, exports, functions, components, types, or helpers have real users before removal.
find-simplifications
Use for a periodic repo-wide sweep of qwen-code for accumulated excess surface — dead components and files, orphaned locale keys, exports nothing consumes, added-then-removed scaffolding — filing candidates on a tracking issue and landing only what a maintainer has said yes to. Repo-wide and evidence-first; every…
review-work
Post-implementation gate review: run manual QA on the real surface yourself, then launch ONE gate reviewer (never a panel) to audit goal, constraints, code quality, security, missed context, and QA evidence. Use before a PR handoff or when the user explicitly asks to review completed work.
critical-code-reviewer
Rigorously review code or pull requests for correctness, security, accessibility, maintainability, tests, and edge cases. Use when users request a critical code review, want a guided walkthrough of findings, need implementer-facing feedback, or want to prepare, create, or submit a GitHub pull request review.
pr-description-writer
Redacta una descripción de pull request clara y estructurada a partir de un diff de git, resumen de rama o lista de commits. Úsalo cuando te pidan escribir una descripción de PR, redactar una solicitud de cambios o documentar cambios de código. Produce una descripción con resumen, motivación, cambios realizados, pasos…