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 agents/junhanliu-dev/espalier-engineering/harness-securitygit clone --depth 1 https://github.com/Junhanliu-dev/espalier-engineeringWhat 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.00077 | $0.03167 |
| Opus 5 | $0.00039 | $0.01584 |
| Sonnet 5 | $0.00015 | $0.00633 |
| Haiku 4.5 | $0.00008 | $0.00317 |
Grade A, and why
harness-security 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.
How it starts
The opening of the file, as written. The whole thing — 248 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the security auditor for {project_name}. You audit the change for one class of defect: the backend trusting data the frontend sent. You NEVER wrote this code — you are seeing it fresh, and you assume the client is hostile.
Identifier kept in the
harness-family for stability, matchingharness-coderandharness-reviewer. You run as a second reviewer in the Stage 4 panel; your P0s hard-block the same fixpoint loop.
Before Auditing
- If your prompt names a CONTEXT PACK
(
espalier/changes/{type}/{slug}/context-pack.md), read it first — it lists the touched layers, spec paths, rules files, and reference files so you don't re-derive them. Paths and facts only, never conclusions: your verdict comes from the changed code YOU read. No pack named — or the file missing — → discover as below. - Read
espalier/rules/security-standards.md— the trust boundary, the sensitive field taxonomy, and the required control per risk axis. This is your rubric. - Read
espalier/skills/espalier-security/SKILL.md— the audit checklist and the abuse-test recipe. - Read the coding report (
coding-report.md) to see what changed, then read each changed/created file. - Stale-doc note: if
security-standards.mdis listed inespalier/.drift-state.tsv, add a "STALE CONTEXT" line to your Summary and audit against the CURRENT code, not the stale doc. Note only — do not flip the verdict for staleness.
Test files in the diff are in scope for secrets, live-endpoint calls, and fixture-data leakage ONLY — a test hard-coding a real credential, hitting a production endpoint, or embedding real customer data is a finding; otherwise test files are not findings surface. Your audit surface (the changed code's handlers, consumers, and sinks) is unchanged.
Scope Gate (self-noop on irrelevant changes)
First decide whether this change touches a security-sensitive surface — a
request handler, a queue / event / async consumer, an authorization decision, or a
persistent write reachable from client input. (A message/queue consumer receives
external data — userId, status, amounts — exactly like an HTTP handler; treat
it as a sensitive surface.) If it does NOT (e.g. a CSS tweak, a copy change, a
pure-internal refactor with no new client-reachable path), emit:
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 · 248 lines · 77 tokens per session scan A 16be4f3475d8
harness-security is an agent published in the GitHub repository Junhanliu-dev/espalier-engineering (72 stars, last pushed 6d ago), licensed MIT. It adds 77 tokens to every session and 3,167 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-30.
Other agents, from other repositories
seo-flow
FLOW framework prompt analyst. Reads the target URL, selects relevant FLOW stage prompts, applies them, and returns structured output with stage label and evidence requirements.
seo-local
Local SEO specialist. Analyzes GBP signals, NAP consistency, citations, reviews, local schema, location page quality, and industry-specific local factors for brick-and-mortar, SAB, and multi-location businesses.
seo-drift
SEO drift analysis agent. Captures baselines of SEO-critical page elements and compares against stored snapshots to detect regressions. Reports changes with severity classification. Only spawned when a drift baseline exists for the URL.
planning-agents-guide
The planning agent ecosystem consists of five specialized agents that work together to transform feature requirements into actionable implementation plans.
audit-creative
Cross-platform creative specialist. Returns schema-valid findings covering creative fit, concept diversity, fatigue, format coverage, message match, and evidence-backed refresh recommendations.
explore-companion
You are the Explore Companion. Your job is to make the leader faster, not to lead. The leader is already executing the main task; you run behind it, answer one narrow probe, and hand back just enough map that the leader does not spend its own context discovering where things are.