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 epicsagas/epic-harness --skill discovergit clone --depth 1 https://github.com/epicsagas/epic-harnessWrote 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/epicsagas/epic-harness/discover)<a href="https://agentmods.dev/skills/epicsagas/epic-harness/discover"><img src="https://agentmods.dev/badge/skills/epicsagas/epic-harness/discover.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.1 | $0.00028 | $0.02351 |
| Opus 5 | $0.00014 | $0.01175 |
| Sonnet 5 | $0.00006 | $0.00470 |
| Haiku 4.5 | $0.00003 | $0.00235 |
Grade A, and why
discover 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 7d 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 — 237 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Discover — Problem Discovery
You are starting the Discover phase. Your job is to help the user articulate what problem they are actually trying to solve, before jumping to solutions or specs.
CRITICAL: Run HARNESS_DIR=$(epic-harness path) first. NEVER use .harness/ in the project directory.
Iron Law
NO SPEC WITHOUT A PROBLEM STATEMENT. Building the wrong thing well is worse than building the right thing poorly.
Process
Step 0: Prerequisites
- Resolve harness directory:
HARNESS_DIR=$(epic-harness path) - Read any existing context (CLAUDE.md, README, codebase structure)
- Check for existing problem statements in
$HARNESS_DIR/specs/PROBLEM-*.md - Call
mem_recallwith a hint describing the current topic area - Check for past
decisionorpatternnodes related to this domain - If prior problem exploration exists, reference it: "We discussed something similar before..."
- If existing PROBLEM files are found, review them — the user may be continuing prior work
Why: Past context prevents re-exploring ground already covered. The knowledge graph connects today's vague request to yesterday's decisions.
Step 1: Listen
Read the user's request carefully. Repeat it back in your own words and ask:
- "Is that the core of it, or is there more?"
Categorize the request:
| Category | Signal | Example |
|---|---|---|
| Solution without problem | User names a technology or approach | "Add Redis caching" |
| Feature without context | User describes output, not why | "Build a dashboard" |
| Systemic complaint | Broad negative without specifics | "Everything is slow" |
| Vague ambition | Goal with no boundaries | "Make it better" |
| Clear problem | Observable gap stated | "Login fails for 5% of users" |
Why: Categorization determines the probing technique. Misreading the category leads to wrong questions.
Step 2: Probe
Select the technique based on the category identified in Step 1. Ask max 3 questions per round, run max 3 rounds. If the user can't answer or says "I'm not sure", proceed to Frame with what you have.
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.
- 7d ago First seen · 237 lines · 28 tokens per session scan A 29f4e53f32c2
discover is a skill published in the GitHub repository epicsagas/epic-harness (18 stars, last pushed yesterday), licensed Apache-2.0. It adds 28 tokens to every session and 2,351 once invoked, about $0.0001 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-30.
Other skills, from other repositories
opensrc
Fetch dependency source code to give AI agents deeper implementation context. Use when the agent needs to understand how a library works internally, read source code for a package, fetch implementation details for a dependency, or explore how an npm/PyPI/crates.io package is built. Triggers include "fetch source for"…
lx
Codebase exploration tool that reads many files or whole directories in a single call, with per-file headers, glob include/exclude filters, function/type skeleton extraction (signatures only, no bodies), and head/tail line slicing.
pypi-release
This skill should be used when releasing tunacode-cli to PyPI. It keeps the existing local release checks, then hands the actual PyPI upload to a GitHub Actions workflow that uses the repository's PYPIAPITOKEN secret.
audit-harness
Use when auditing HARNESS.md, pre-commit hooks, pre-push hooks, architecture gates, or CI workflows for tunacode-cli. This skill treats any mismatch, skipped gate, or failing check as a critical failure and requires manual one-by-one execution rather than make targets, batch wrappers, or summary-only audits.
toxic-senior-reviewer
Code review in the voice of a toxic senior developer — dry sarcasm without profanity, no fluff, no empty praise. Use this skill whenever the user asks for a code review, says "how can I improve this", "what do you think of this code", "take a look at this", "rate this solution", "critique this", "do a code review"…
execute-plan
Execute an approved plan step-by-step with a checkpoint after each. Triggers on execute the plan, run the plan, do the steps, implement the plan.