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 agentmods add skills/gitrasheed/metis-skill/p14b-validassertnpx skills add gitRasheed/metis-skill --skill p14b-validassertgit clone --depth 1 https://github.com/gitRasheed/metis-skillWhat 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 | $0.00000 | $0.03267 |
| Opus 5 | $0.00000 | $0.01633 |
| Sonnet 5 | $0.00000 | $0.00653 |
| Haiku 4.5 | $0.00000 | $0.00327 |
Grade A, and why
P14b-validassert 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 yesterday.
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
77% identical to metis — 39 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 — 178 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Metis
Write code that favors plain data, pure logic, clear call sites, and early architectural thinking. These are strong defaults, not rigid laws: follow the surrounding codebase, framework constraints, and language norms when they clearly matter more.
Apply sections by phase instead of holding everything at once:
- Designing or starting a task: Design principles, LLM agent process
- Implementing: Working rules, Implementation rules, plus the SOLID checklist for non-trivial modules
- Writing tests: Testing checklist
- Reviewing a diff or PR: Code review mode
- Before claiming done, committing, or pushing: Final verification checklist
Design principles
- Start from the call site, by wishful thinking: pretend the perfect helpers already exist, name them the way you would want to call them, and get the top-level usage reading cleanly. If the calling code reads awkwardly, the abstractions are wrong — and you find out before building anything.
- Prefer plain data plus focused functions, modules, or systems over behavior-heavy objects. Draw boundaries around what systems do, not what entities are.
- Choose the simplest state model that matches reality: discriminated unions for mutually exclusive states, composable data for orthogonal features, and a plain flat record when neither pressure exists — do not over-architect the simple case.
- Isolate mutation and I/O near the edges. Orchestration decides what happens; inner helpers do narrow, understandable work.
- Push ifs up, fors down. Keep high-level control flow in parents and leaf functions low-branch and easy to test.
- Validate untrusted data where it crosses a trust boundary — parsing, persistence, external APIs — and assert internal invariants whose failure would mean a programming error: state transitions, function contracts. Check what must be true and, when useful, what must not be.
- Prefer explicit, behavior-focused tests without indirection that hides intent.
- Sanity-check the likely bottleneck first — network, disk, memory, then CPU. Prefer architecture changes over late micro-optimizations.
- Design for the hardest real requirement first, then simplify downward. Do not architect for the easy case and try to scale it up later.
- When elements of a batch can invalidate each other — duplicates, conflicts, cross-record constraints — classify the whole batch before applying any element, even when applying incrementally looks cleaner.
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.
- yesterday First seen · 178 lines · 0 tokens per session scan A 299deab0eedb
P14b-validassert is a skill published in the GitHub repository gitRasheed/metis-skill (2 stars, last pushed 10d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 3,267 tokens. A static security scan graded it A with 0 findings. It is 77% identical to metis, differing in 39 lines, and is treated as a copy.
Other skills, from other repositories
feishu
Work with Feishu or Lark bots, docs, sheets, bitables, approval flows, and OpenAPI/MCP setup without hardcoding credentials.
interview
Ask one useful structured question at a time only when material product/implementation choices are genuinely missing; remember answers and produce a brief/spec. Discoverable facts should be investigated instead of asked.
writing
将共享历史中的已验证事实和计算结果整理成符合受众、格式与长度约束的成稿。.
test
Detect the project’s test stack, run the narrowest useful tests, create tests when authorized, and report coverage/gaps honestly.
verify
Exercise the real app/API/CLI and collect observable evidence; tests alone do not count as end-to-end verification.
build-teaql-app
Build or change a TeaQL application in Java, Rust, Go, Swift, Python, C#/.NET, or TypeScript, including Kotlin/JVM applications that consume Java-generated libraries. Mandatory order: first draft and save a complete KSML model, then verify the client and evaluate that saved model, repair it through repeated evaluation…