suede-ai-eval

Files (4)

• CARD.md
• SKILL.md
• openai.yaml · agents/
• eval-case-design.md · references/

SKILL.md (first lines)

# Suede AI Eval Skills

Read [the worked delivery contract](references/worked-contract.md) for a concrete
input, expected artifact, failure response and validation example.

## Compatibility

Requires the AI surface contract or source and test data; a project runtime/eval runner for execution. Model/API access is needed only for actual model runs, with existing authorization and cost scope.

## Gate policy: advisory, not blocking

Every claim-verification step, check, quality gate, and ship verdict in this
skill is a **recommendation to the user, not a control on the agent**. This
policy governs every gate, check, verdict, and "do not ship / publish /
proceed" line elsewhere in this skill:

- Run every check and report the results honestly. Verdicts (`ship`,
  `ship-with-caveats`, `hold`, letter grades, BLOCKED or OPEN items) are
  advice attached to the work, not orders that change it.
- Never block, delay, skip, rewrite, or refuse the action the user asked for
  because a check failed or a gate said hold. Complete the requested action
  as asked, and deliver the gate output alongside it as a clearly labeled
  recommendation.
- A failed gate changes what you report, never what you do.
- Single exception: if a finding is extremely risky (data loss, security or
  credential exposure, legal or rights violations, payment mistakes, or
  irreversible public damage), pause, tell the user exactly what the risk is
  and what the options are, and let them pick. Their choice is final.


Make AI behavior testable before it becomes a vague product promise. **No eval plan, no `ship` recommendation: for an AI feature without one, the recommended verdict stays below `ship`: report that gap and let the user decide.**

The deliverable is an eval plan or coverage audit, not a model benchmark leaderboard. Keep it grounded in the actual product surface, user promise, data sources, prompts, tools, logs, tests, and failure modes available now.

## Hard Gates

- No AI-SPEC → no eval plan. Write the one-paragraph spec first; cases written without a spec test nothing.
- No eval plan → no `ship` recommendation. Do not recommend `ship` or `ship-with-caveats` for an AI feature that lacks a failure-mode map and eval cases; name the gap and leave the ship decision with the user.
- A failure mode without an eval case, an owner, and a gate is uncovered, regardless of how unlikely it feels.
- A live surface that was never sampled gets the output stamped `source-only`; do not present source-only review as runtime evidence.
- A model grading its own output is not evidence. LLM-as-judge scores count only after spot-checked agreement with a human-reviewed sample.

## Source Truth

Inspect the current target before writing the eval. Do not evaluate from memory or product copy alone.

Read or verify:

- repo, branch, remote, dirty state, local instructions, and touched files;
- the AI surface: route, API, worker, prompt, system message, tool call, model config, retrieval path, classifier, agent loop, generated media path, or recommendation logic;
- user-facing promise, allowed claims, forbidden claims, safety boundaries, fallback behavior, and support path;
- input data, retrieval corpus, schemas, tool contracts, metadata, logs, telemetry, and persisted outputs;
- existing tests, fixtures, eval scripts, prompt snapshots, golden examples, analytics, bug reports, screenshots, or live/API readbacks.

When the surface is already live, sample real behavior with safe inputs and record exact commands or URLs. When live checks are not appropriate, mark the eval as source-only and name the missing runtime evidence.

## Workflow

1. **Define the AI-SPEC.** State the AI job in one paragraph: user, trigger, input, output, allowed sources, disallowed behavior, fallback, latency/cost expectation, and success signal.
2. **Map the failure modes.** List the ways the AI can harm the user, product truth, rights/provenance, security, privacy, brand trust, cost, or workflow completion.
3. **Build the rubric.** Score each failure mode with severity, likelihood, detectability, owner, gate, and required evidence.
4. **Write eval cases.** Produce concrete pass/fail cases with inputs, setup data, expected output traits, forbidden output traits, and the reason the case exists.
5. **Set acceptance gates.** Decide what blocks ship, what allows ship-with-caveats, and what can become follow-up work.
6. **Audit coverage.** Compare existing tests, logs, metrics, and manual checks against the failure-mode map. Score coverage and infrastructure using the method under Tooling and Infrastructure below. Name every uncovered high-risk behavior regardless of the numeric score.
7. **Return the artifact.** Give the AI-SPEC, rubric, eval table, coverage gaps, required tests, and next implementation step. Name the exact command that runs the cases and its expected exit status (the repo's own eval script if one exists, otherwise the tool's invocation, e.g. `npx promptfoo eval -c <config>`) and record the run's pass/fail counts under "Commands or evidence checked". An eval plan with no runnable command is a document, not coverage, and suede-ci-gate cannot wire it into CI without that string.

## Eval Dimensions By System Type

Start the failure-mode map from the canonical dimensions for the surface's system type, then add product-specific failure modes on top. Always include safety (user-facing) and task completion (agentic) regardless of type.

| System type | Canonical dimensions |
|---|---|
| RAG / retrieval | context faithfulness, hallucination, answer relevance, retrieval precision, source citation |
| Multi-agent | task decomposition, inter-agent handoff correctness, goal completion, loop detection |
| Conversational | tone/style, safety, instruction following, escalation accuracy |
| Extraction / structured output | schema compliance, field accuracy, format validity |
| Autonomous / tool-using agent | safety guardrails, tool-use correctness, cost/token adherence, task completion |
| Content generation | factual accuracy, brand voice, tone, originality |
| Code generation | correctness, safety, test pass rate, instruction following |

For each dimension, assign a measurement approach before writing the eval case:

- **Code-based**: schema validation, required-field presence, performance thresholds, regex checks. Fast, deterministic, cheap to run in CI.
- **LLM judge**: tone, reasoning quality, safety-violation detection. Requires calibration against a human-reviewed sample before the score counts as evidence (see Hard Gates).
- **Human review**: edge cases, LLM-judge calibration itself, high-stakes sampling that cannot be automated yet.

## Tooling and Infrastructure

Detect existing eval/tracing tooling before recommending anything new:

```bash
grep -rl "langfuse\|langsmith\|arize\|phoenix\|braintrust\|promptfoo\|ragas" \
  --include="*.py" --include="*.ts" --include="*.toml" --include="*.json" . \
  2>/dev/null | grep -v node_modules | head -10
```

If nothing is detected, these are the default starting points, not a mandate to install all four:

| Concern | Default | Why |
|---|---|---|
| Tracing / observability | Arize Phoenix | Open-source, self-hostable, framework-agnostic via OpenTelemetry |
| RAG eval metrics | RAGAS | Faithfulness, answer relevance, context precision/recall out of the box |
| Prompt regression in CI | Promptfoo | CLI-first, no platform account required |
| LangChain/LangGraph pipelines | LangSmith | Overrides Phoenix when the project is already in that ecosystem |

**Reference dataset spec:** minimum 10 examples to start, 20+ before treating coverage as production-grade. Composition: critical paths, edge cases, known failure modes, and adversarial inputs, not just happy-path samples. Labeling: domain expert where stakes are high, LLM judge with calibration otherwise. Start building the dataset during implementation, not after the feature ships.

**Production monitoring split:** classify every covered failure mode as either an online guardrail (catastrophic risk, runs on every request in the hot path, must be fast) or an offline flywheel check (quality signal, sampled batch, feeds the improvement loop, not latency-sensitive). Keep online guardrails minimal since each one adds latency to every request.

**Coverage scoring:** for each dimension, mark COVERED (implementation exists, targets the rubric behavior, actually runs), PARTIAL (exists but incomplete, not automated, or has known gaps), or MISSING (no implementation found). Audit infrastructure separately, ok/partial/missing: eval tooling is installed and actually called (not just a listed dependency), the reference dataset file exists and meets the spec above, a CI/CD command runs the eval suite, each planned online guardrail is implemented in the request path (not stubbed), and tracing is configured and wrapping the real AI calls. Score `coverage = covered / total_dimensions × 100` and `infra = (tooling + dataset + cicd + guardrails + tracing) / 5 × 100`, then `overall = coverage × 0.6 + infra × 0.4`.

## Eval Case Design

How to build the case set (golden cases, adversarial cases, failure-mode coverage,
and what makes a case gradeable) is in `references/eval-case-design.md`. Read it
before writing cases. Skip it when you are only reviewing an existing suite or
sizing infrastructure.

## Rubric

From JasonColapietro/suede-creator-skills, MIT.

More from JasonColapietro/suede-creator-skills