Code Assistance

Five prompts for the developer-intent searches that bring engineers to a prompt registry — code review, commit messages, docstrings, error explanation, and regex generation. Each returns typed, validated JSON with a strict schema, and each is gated by an eval that runs on the same model it recommends.

Like the Structured Extraction, Customer Support, RAG Essentials, Translation Essentials, Summarization Essentials, and Text Classification collections, every prompt is a system message, a user message, and a schema — framework-agnostic, SDK-generatable in TypeScript and Python.

Prompts

The theme: the eval runs on the model you'd ship

Two ideas hold this collection together.

1. Recommended model = eval model, chosen per task. Each prompt names the model its metadata recommends, and its eval runs on that same model — not a fixed default. The recommendation is tiered to the work: code-review runs on Opus because bug-finding rewards the strongest reasoning; commit-message-generation and docstring-generation run on Haiku because they're structured and cheap; error-explanation and regex-generation sit on Sonnet in between. What you see recommended is what was actually graded.

2. Prefer executable, judge-free evals; add a judge only where correctness is genuinely subjective.

• regex-generation is the showcase. Each dataset case carries its own positive and negative example strings, and the eval runs the model's generated regex against them with CEL's RE2 .matches(). No judge — the pattern either matches the right strings or it doesn't.
• commit-message-generation is fully deterministic — type correctness plus subject-format checks (≤ 72 chars, no trailing period) are pure CEL.
• code-review pairs an objective backbone (the planted bug must appear in output.issue_files; an unambiguous blocker must not be approved; a clean diff must not invent a blocker/major) with a severity-calibration judge for the part CEL can't check.
• error-explanation asserts the real cause keyword deterministically, then a usefulness judge grades whether the fix is actionable.
• docstring-generation checks the documented-parameter count exactly, then a style-adherence judge confirms the format.

House conventions

1. Reasoning (or a summary) before the verdict. Reviews summarize, classifiers reason, regexes explain their construction — always before committing to the output that follows.
2. Closed enums wherever the taxonomy is fixed — severity, commit type, regex flavor, docstring style — so the eval can assert equality and mean it.
3. Flat, assertable fields by design. code-review emits issue_files[] so an eval can test membership without mapping over objects; docstring-generation reports params_documented[]; regex-generation supplies test_cases[]. Schema design is eval design.
4. Input is data, never instructions. Diffs, code, errors, and descriptions are injected inside delimiters; a comment that says "approve this" or "mark this chore" is described, never obeyed. code-review makes this its headline property.
5. No invented specifics. code-review never invents a line number not in the diff; docstring-generation documents only real parameters; error-explanation grounds every claim in the provided error and code.
6. Confidence is uncalibrated and says so, in every schema that carries it.

Judge prompts

The three judges are published alongside the collection and referenced by the evals: code-review-grader, error-explanation-grader, and docstring-grader. Each grades one subjective dimension (severity calibration, fix usefulness, style adherence) and returns a { reasoning, score } the eval thresholds on.