Hatch3r Ai Feature

---
id: hatch3r-ai-feature
name: hatch3r-ai-feature
type: skill
description: Eval-driven development workflow for shipping AI features — write eval before prompt, measure, iterate, ship with caching + cost telemetry + model fallback + hallucination SLI
tags: [implementation, ai]
quality_charter: agents/shared/quality-charter.md
efficiency_patterns: agents/shared/efficiency-patterns.md
cache_friendly: true
---
# AI Feature Workflow (Eval-Driven)

## Quick Start

**Applies when:** the project ships an LLM/AI feature. On a project with no AI feature, skip — do not scaffold AI machinery pre-emptively (per `rules/hatch3r-right-sizing.md`).

Run this skill before shipping any LLM-driven feature. It defines the canonical eval-driven loop (write eval, write prompt, measure, iterate) and the production-readiness gates. Skipping any of the 9 steps = the feature is not done.

This skill is the implementation counterpart to `rules/hatch3r-ai-evals.md` (backend governance) and `rules/hatch3r-ai-ux-patterns.md` (UI governance). The rules define the bar; this skill defines the route to clearing the bar.

## Step 0 — Detect Ambiguity (P8 B1)

Before any work, scan the invocation for unresolved questions in scope, intent, acceptance criteria, target environment, or irreversibility. If any are found, ask the user via the platform-native question tool per `agents/shared/user-question-protocol.md`. Do not proceed under silent assumption. Default path, not an exception. Triggers for THIS skill: task class (classification vs open-ended vs RAG vs agentic), model pin (Sonnet vs Opus vs Haiku), eval threshold values, budget per request (cost cap), and fallback policy (graceful degrade vs hard fail).

## Fan-out Discipline (P8 B2)

Fan-out scales with task size; token cost never justifies serializing independent work (`rules/hatch3r-fan-out-discipline.md` P8 B2; `agents/shared/efficiency-patterns.md`). Emit `sub_agents_spawned: { count, rationale, task_structure }` in your output.

## Step 1: Define the task and success criteria

- Write down what "right" looks like in one paragraph — the user input class, the expected output shape, the failure modes you want to catch.
- Hand-author 20+ golden examples in `evals/<feature>/golden.jsonl` with `input` + `expected_output` (or a graded rubric when the task is open-ended).
- Save the threshold per metric in `evals/<feature>/thresholds.json`. Without an explicit threshold, "passing the eval" is undefined.
- Cross-reference `rules/hatch3r-ai-evals.md` Golden Dataset Versioning for filename and refresh policy.
- Source diversity matters more than count beyond 20 — include adversarial inputs, edge cases from prior incidents, and at least 3 examples per known input class.
- Label every example with the input class so per-class accuracy is computable in Step 4.

## Step 2: Pick eval tool and metric

Match the task class to the tool:

- Classification → promptfoo with exact-match assertions.
- Open-ended generation → DeepEval or braintrust with LLM-as-judge + a 50-example human-labeled calibration set.
- Retrieval/RAG → RAGAS (context_precision, context_recall, faithfulness, answer_relevance).
- Tool-use / agentic → Inspect or BFCL-style harness.
- Safety/red-team → Garak or PyRIT scheduled weekly.

Pin the choice in `evals/README.md` so the next agent run picks the same tool.

## Step 3: Write the prompt

- Author the prompt at `prompts/<feature>/v1.md` with frontmatter `{ id, version: 1, model_pinned, eval_set }`.
- Commit; record SHA-256 hash in `evals/<feature>/thresholds.json`.
- If the system prompt + tool definitions + RAG context exceed 1024 tokens, apply Anthropic `cache_control` breakpoints (or rely on OpenAI's automatic prefix cache for ≥1024-token deterministic prefixes). Longest-TTL block first.

## Step 4: Run eval; iterate prompt

- Run `npx promptfoo eval` (or the chosen tool's CLI) against the golden set.
- Read the per-metric report. If below threshold, modify the prompt, bump to `v2.md`, re-hash, re-run.
- Treat each prompt revision like a code commit — small, named, testable.
- Stop iterating when every metric clears its threshold in `thresholds.json` and the pairwise win-rate vs the prior version is >=55%.
- Capture the eval report artifact in CI so the PR reviewer can read per-case pass/fail without re-running the suite locally.
- If iteration count exceeds 10 versions without convergence, escalate — the task may need decomposition (one sub-prompt per input class) or a retrieval-grounded approach.

## Step 5: Wire production telemetry

- Per-request log line emits `model`, `tokens_in`, `tokens_out`, `cache_hit`, `cached_tokens`, `cost_usd`, `latency_ms`, `prompt_version`, `prompt_hash`, `cost_center`.
- Per-request OpenTelemetry span follows the OTel GenAI semantic conventions (`gen_ai.*` attributes).
- Aggregate dashboards: cost-per-request, hallucination_rate, citation_precision, refusal_rate, cache_hit_ratio.
- Cross-reference `skills/hatch3r-observability-verify` for the per-feature dashboard checklist.

## Step 6: Wire fallback chain

- Primary model (e.g. Sonnet 4.7) → secondary (cheaper/faster, e.g. Haiku 4.5) → static fallback (cached or canned).
- Wrap in circuit-breaker + retry-with-decorrelated-jitter — cross-reference `rules/hatch3r-resilience-patterns.md` (Slice 8) for the primitives.
- Run the eval suite against the secondary path too — a silent quality cliff between primary and secondary is a regression.
- Static fallback text names the failure mode in user-readable language ("AI is briefly unavailable — retry in a minute") rather than dumping a stack trace into the UI.

## Step 7: Add CI gate

- Eval runs on every PR that touches `**/prompts/**`, `**/rag/**`, `**/ai/**`, `**/llm/**`.
- PR blocks when any metric drops below the threshold in `evals/<feature>/thresholds.json`.
- Model-version upgrade (Sonnet to Opus, 4.6 to 4.7) triggers a full eval with a 5% accuracy budget; cross over 5% requires a named-reviewer sign-off + 24-hour canary at 5% traffic.

## Step 8: Production verification

First 24 hours after deploy, monitor:

- `ai.hallucination_rate` — SLO <5% on golden set; alert if 7-day rolling rate >5%.
- `ai.refusal_rate` — track false-positive refusal rate separately.
- `ai.cost_per_request_usd` — p50/p95/p99 vs feature budget; alert at 50%/75%/90% of monthly budget.
- `ai.latency_ms` — first-token-latency p95 + total-response-latency p99.
- `ai.cache_hit_ratio` — should match the dev-environment baseline within 10%; a drop indicates prefix drift.
- `ai.tokens_per_request` — p95 should be within 20% of the eval-time distribution; a spike signals retrieval growth or prompt drift.

Cross-reference `skills/hatch3r-observability-verify`.

## Step 9: Feedback loop

- Wire user thumbs-down to a feedback queue per response.
- Monthly triage job promotes thumbs-down examples into regression fixtures in `evals/<feature>/edge.jsonl`.
- Promotion is a manual review step — raw user feedback contains noise and adversarial labels.
- Capture an optional free-text comment with each thumbs-down; the comment is the highest-signal feature for triage clustering.
- Track feedback volume per response surface — a sudden spike in thumbs-down rate signals an upstream prompt or retrieval regression and gates a rollback.

## Verdict

All 9 steps complete = the AI feature is "done". Anything less = not done. The orchestrator running this skill emits a single-line verdict per step (`STEP_N: PASS|FAIL <evidence-path>`) and aggregates them. One FAIL on any step blocks release.

Evidence paths point at concrete artifacts: the golden set (`evals/<feature>/golden.jsonl`), the prompt version (`prompts/<feature>/v<N>.md`), the eval report (`evals/<feature>/report-<run-id>.json`), and the dashboard URL for production SLI verification. Verdicts without evidence paths are not accepted by the gate.

## When this skill runs

- After `hatch3r-implementer` finishes the surrounding non-AI feature code, before `hatch3r-qa-validation`.
- On every PR that introduces a new LLM call or modifies an existing prompt, model, or retrieval pipeline.
- Step 8 (production verification) executes against the post-deploy environment, not the PR branch.

## Cross-References

- `rules/hatch3r-ai-evals.md` — backend governance (eval, cost, caching, fallback, SLI).
- `rules/hatch3r-ai-ux-patterns.md` — frontend UX patterns (streaming, tool-call cards, citations).
- `skills/hatch3r-ui-ux-verify/SKILL.md` — UI verification gate for AI surfaces.
- `skills/hatch3r-observability-verify` — observability wiring checklist.
- `rules/hatch3r-resilience-patterns.md` (Slice 8) — circuit-breaker + retry primitives reused in the fallback chain.

## References

- promptfoo — `promptfoo.dev`
- DeepEval — `github.com/confident-ai/deepeval`
- RAGAS — `docs.ragas.io`
- Inspect (UK AISI) — `github.com/UKGovernmentBEIS/inspect_ai`
- Anthropic prompt caching guide — `docs.anthropic.com/en/docs/build-with-claude/prompt-caching`
- OpenTelemetry GenAI semantic conventions — `opentelemetry.io/docs/specs/semconv/gen-ai/`
- Berkeley Function Calling Leaderboard (BFCL v4) — `gorilla.cs.berkeley.edu/leaderboard.html`