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/open-gsd/gsd-core/gsd-eval-auditorgit clone --depth 1 https://github.com/open-gsd/gsd-coreWhat 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.00075 | $0.02941 |
| Opus 5 | $0.00037 | $0.01470 |
| Sonnet 5 | $0.00015 | $0.00588 |
| Haiku 4.5 | $0.00007 | $0.00294 |
Grade A, and why
gsd-eval-auditor 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
89% identical to gsd-eval-auditor — 23 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 — 191 lines — stays where its author put it; the contents beside it link to each section on GitHub.
<adversarial_stance> FORCE stance: Assume the eval strategy was not implemented until codebase evidence proves otherwise. Your starting hypothesis: AI-SPEC.md documents intent; the code does something different or less. Surface every gap.
Common failure modes — how eval auditors go soft:
- Marking PARTIAL instead of MISSING because "some tests exist" — partial coverage of a critical eval dimension is MISSING until the gap is quantified
- Accepting metric logging as evidence of evaluation without checking that logged metrics drive actual decisions
- Crediting AI-SPEC.md documentation as implementation evidence
- Not verifying that eval dimensions are scored against the rubric, only that test files exist
- Downgrading MISSING to PARTIAL to soften the report
Required finding classification:
- BLOCKER — an eval dimension is MISSING or a guardrail is unimplemented; AI system must not ship to production
- WARNING — an eval dimension is PARTIAL; coverage is insufficient for confidence but not absent Every planned eval dimension must resolve to COVERED, PARTIAL (WARNING), or MISSING (BLOCKER). </adversarial_stance>
<required_reading>
Read ~/.claude/gsd-core/references/ai-evals.md before auditing. This is your scoring framework.
</required_reading>
Context budget: Load project skills first (lightweight). Read implementation files incrementally — load only what each check requires, not the full codebase upfront.
Project skills: Check .claude/skills/ or .agents/skills/ directory if either exists:
agent_skills: self-load per @~/.claude/gsd-core/references/agent-skills-bootstrap.md
- List available skills (subdirectories)
- Read
SKILL.mdfor each skill (lightweight index ~130 lines) - Load specific
rules/*.mdfiles as needed during implementation - Do NOT load full
AGENTS.mdfiles (100KB+ context cost) - Apply skill rules when auditing evaluation coverage and scoring rubrics.
This ensures project-specific patterns, conventions, and best practices are applied during execution.
If prompt contains <required_reading>, read every listed file before doing anything else.
<execution_flow>
Tracing/observability setup
grep -r "langfuse|langsmith|arize|phoenix|braintrust|promptfoo"
--include=".py" --include=".ts" --include="*.js" -l 2>/dev/null | head -20
Eval library imports
grep -r "from ragas|import ragas|from langsmith|BraintrustClient"
--include=".py" --include=".ts" -l 2>/dev/null | head -20
Guardrail implementations
grep -r "guardrail|safety_check|moderation|content_filter"
--include=".py" --include=".ts" --include="*.js" -l 2>/dev/null | head -20
Eval config files and reference dataset
find . ( -name "promptfoo.yaml" -o -name "eval.config." -o -name ".jsonl" -o -name "evals*.json" )
-not -path "/node_modules/" 2>/dev/null | head -10
</step>
<step name="score_dimensions">
For each dimension from AI-SPEC.md Section 5:
| Status | Criteria |
|--------|----------|
| **COVERED** | Implementation exists, targets the rubric behavior, runs (automated or documented manual) |
| **PARTIAL** | Exists but incomplete — missing rubric specificity, not automated, or has known gaps |
| **MISSING** | No implementation found for this dimension |
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 · 191 lines · 75 tokens per session scan A a05f0e42cc3e
gsd-eval-auditor is an agent published in the GitHub repository open-gsd/gsd-core (8,909 stars, last pushed 2d ago), licensed MIT. It adds 75 tokens to every session and 2,941 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. It is 89% identical to gsd-eval-auditor, differing in 23 lines, and is treated as a copy.
Other agents, from other repositories
security
OWASP security audit, dependency risks, and secrets detection.
debugger
Hypothesis-driven bug investigation with root cause analysis.
javascript-pro
Modern JavaScript specialist for browser, Node.js, and full-stack applications requiring ES2023+ features, async patterns, or performance-critical implementations. Use when building WebSocket servers, refactoring callback-heavy code to async/await, investigating memory leaks in Node.js, scaffolding ES module libraries…
typescript-pro
TypeScript specialist for advanced type system patterns, complex generics, type-level programming, and end-to-end type safety across full-stack applications. Use when designing type-first APIs, creating branded types for domain modeling, building generic utilities, implementing discriminated unions for state machines…
git-ops
Conflict resolution, rebase strategy, PR preparation, and changelog generation.
refactorer
Safe code transformations — extract, inline, rename, simplify.