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/lbk-open/super-spec/ss-inspectnpx skills add lbk-open/super-spec --skill ss-inspectgit clone --depth 1 https://github.com/lbk-open/super-specWrote 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/lbk-open/super-spec/ss-inspect)<a href="https://agentmods.dev/skills/lbk-open/super-spec/ss-inspect"><img src="https://agentmods.dev/badge/skills/lbk-open/super-spec/ss-inspect.svg" alt="Measured on agentmods" 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 | $0.00072 | $0.05249 |
| Opus 5 | $0.00036 | $0.02625 |
| Sonnet 5 | $0.00014 | $0.01050 |
| Haiku 4.5 | $0.00007 | $0.00525 |
Grade A, and why
ss-inspect 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 4d 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 — 350 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Root Cause Investigation
Systematically investigate technical issues by gathering evidence from multiple independent sources, tracing the root cause through the full call chain, and designing a verified repair at the correct abstraction boundary. Never guess — follow the evidence.
This skill is report-only. It never edits code or configuration, changes runtime state, creates a branch, applies a mitigation, or invokes a coding workflow. Execution belongs to a downstream workflow after the report is complete and its root cause is confirmed.
Core principle: always establish root cause before designing a permanent repair. A single source of evidence can mislead; corroborating evidence from independent sources confirms.
When to use
Use this for any technical issue: bugs, alerts, performance problems, unexpected behavior, integration failures.
Use it especially when:
- You're under time pressure — guessing under pressure is what makes incidents drag on; being systematic is faster, not slower.
- "Just restart it" looks like the easy fix.
- A previous fix attempt didn't work.
- You don't yet fully understand the issue.
- Different people have different theories about the cause.
Don't skip it because the issue looks simple (simple bugs have root causes too), because you're in a hurry (rushing guarantees rework), or because someone suggests "just try X" (guessing costs more time than investigating).
The iron law
NO FIX WITHOUT A ROOT CAUSE CONFIRMED BY EVIDENCE FROM 2+ INDEPENDENT SOURCES
NO PERMANENT REPAIR PLAN BEFORE UNDERSTANDING THE RELEVANT DESIGN AND IMPLEMENTATION
These are separate, mandatory gates. Evidence confirms why the failure occurs; design and implementation understanding determines where the system owns the behavior and therefore where the repair belongs. Investigation tier changes evidence breadth and explanation depth only — it never permits skipping the design-understanding gate.
If you haven't gathered corroborating evidence from at least two independent sources (e.g., logs + traces, metrics + code), you cannot propose a fix.
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.
- 4d ago First seen · 350 lines · 72 tokens per session scan A 191f9896b9b8
ss-inspect is a skill published in the GitHub repository lbk-open/super-spec (1 stars, last pushed 13d ago), licensed Apache-2.0. It adds 72 tokens to every session and 5,249 once invoked, about $0.0004 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
110-java-maven-best-practices
Use when you need to review, improve, or troubleshoot a Maven pom.xml file — including dependency management with BOMs, plugin configuration, version centralization, multi-module project structure, build profiles, or any situation where you want to align your Maven setup with industry best practices. This should…
012-agile-epic
Guides the creation of agile epics with comprehensive definition including business value, success criteria, and breakdown into user stories. Use when the user wants to create an agile epic, define large bodies of work, break down features into user stories, or document strategic initiatives. This should trigger for…
022-root-cause-analysis
Use when a framed problem needs root-cause investigation rather than a symptom-level fix, applying Five Whys, Fishbone (Ishikawa), Current Reality Tree, and constraint identification. This should trigger when an issue's Root Cause Analysis point of view needs evaluation, or when a maintainer directly asks to find the…
041-planning-plan-mode
Use when creating or refining a structured Java implementation plan from trusted issue summaries, approved designs, ADRs, OpenSpec changes, existing plans, or a valid combination. The plan records its source artifacts and derivation direction and can remain the execution artifact without requiring OpenSpec. This…
044-planning-jira
Use when you need Jira CLI (jira) installation/authentication guidance and a maintainer-authored Jira issue inventory workflow. The agent does not ingest raw Jira issue or JQL output directly; it asks the Jira project maintainer/operator to author sanitized issue summaries before analysis or @014-agile-user-story…
122-java-type-design
Use when you need to review, improve, or refactor Java code for type design quality — including establishing clear type hierarchies, applying consistent naming conventions, eliminating primitive obsession with domain-specific value objects, leveraging generic type parameters, creating type-safe wrappers, designing…