Borrowing it
Nothing to install: this file belongs to xetenet/xete-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/xetenet/xete-mcp/main/.claude/skills/spec-and-plan/SKILL.mdgit clone --depth 1 https://github.com/xetenet/xete-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/xetenet/xete-mcp/spec-and-plan)<a href="https://agentmods.dev/skills/xetenet/xete-mcp/spec-and-plan"><img src="https://agentmods.dev/badge/skills/xetenet/xete-mcp/spec-and-plan/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/xetenet/xete-mcp/spec-and-plan"><img src="https://agentmods.dev/badge/skills/xetenet/xete-mcp/spec-and-plan.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.00106 | $0.00602 |
| Opus 5 | $0.00053 | $0.00301 |
| Sonnet 5 | $0.00021 | $0.00120 |
| Haiku 4.5 | $0.00011 | $0.00060 |
Grade A, and why
spec-and-plan 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 12d 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 — 49 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Spec and Plan
Code written without a spec optimizes for the first interpretation, not the right one. This skill front-loads the disagreement.
Step 1: Spec (before any code)
Write specs/SPEC-<feature>-<YYYYMMDD>.md:
# SPEC: <feature>
## Problem — what breaks or is missing today, in user/agent terms
## Non-goals — what this explicitly does NOT do (at least 2)
## Interface — exact function signatures, message formats, account layouts, or UI states. No prose where a type will do.
## Invariants — what must remain true after this ships (these become doubt-driven-review claims)
## Open questions — anything unresolved, each assigned to a person
Rules:
- A spec with zero non-goals or zero open questions has not been thought about hard enough. Add them or state why the task is genuinely trivial — in which case it doesn't need this skill.
- Interfaces are written in the target language (Rust types, JSON schemas), not English descriptions of them.
- The spec is the handoff unit. Jo or an agent session should be able to execute from the spec alone, without this conversation's history.
Step 2: Plan
Append to the same spec file:
## Plan
- [ ] Task 1 — <one atomic commit, ~100 lines max, independently verifiable>
- [ ] Task 2 — ...
## Verification per task — how each task is proven done (test name, manual check, or invariant)
Rules:
- Each task must be completable and verifiable in isolation. If a task can't be verified until three tasks later, restructure.
- Tasks touching contract paths inherit the doubt-driven-review + security-hardening gates automatically.
- Order tasks so the system compiles/runs after every commit. No "big bang" integration steps.
Step 3: Execute against the plan
- Check off tasks in the spec file as commits land; the commit message references the spec (
SPEC-<feature>: task N). - Scope drift rule: work not in the plan gets added to the plan first (one line, with verification), then implemented. Undeclared drift is how immutable mistakes ship.
- When the plan is complete, the spec's Invariants section becomes the claim list for the final doubt-driven review.
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.
- 12d ago First seen · 49 lines · 106 tokens per session scan A 7516189c6fd0
spec-and-plan is a skill published in the GitHub repository xetenet/xete-mcp (0 stars, last pushed today), licensed MIT. It adds 106 tokens to every session and 602 once invoked, about $0.0005 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-08-31.
Other skills, from other repositories
legacy-shield
Secure zero-knowledge document vault for AI agents. Persistence for your secrets.
ironmesh-send
Send an application message (MSG) to a specific IronMesh peer. Use when the user asks to "send X to agent Y" or "ping peer Z". Has side effects — only invoke when the user explicitly asks.
ironmesh-audit
Tail the tamper-evident IronMesh audit log for security events. Use when investigating a TOFU mismatch, auth failure, peer dropping out, or a suspected attack.
ironmesh-peers
Drill into per-peer IronMesh metrics — retry reasons, session rekeys, offline-since, transport type. Use when ironmesh-status shows a problem on a specific peer and you need detail.
ironmesh-status
Report IronMesh mesh health — uptime, active peer count, message lifetime percentiles, queue pressure. Use when the user asks "is the mesh ok", "how's ironmesh", or before taking actions that depend on a peer being reachable.
ironmesh-trust
Inspect and manage IronMesh's TOFU trust store — list pinned peers, show revocations, revoke a compromised peer. Revoke has side effects and requires the user's explicit confirmation.