菜单
How to add or update a gold-master error-example pair (_grob.txt + _expected.txt) and register the error code, without breaking the negative-test release gate.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Syntax, idioms and conventions for writing .grob programs — sample scripts, integration-test fixtures, error examples. Use this skill whenever you create or edit a .grob file, so the language source is idiomatic and valid against the v1 surface. Covers bindings, the three string forms, nullability, control flow, lambdas, collection pipelines, structs, errors, the stdlib surface and numerics.
The single authoritative procedure for allocating a Grob error code — the pre-declared-budget model with an allocate-and-surface fallback for the unanticipated case. Use whenever an increment needs a diagnostic code: to confirm the budget covers it, to make the fold-into-existing versus register-new judgement, or to register a new code in lockstep. Codes are immutable once shipped (ADR-0017), so this keeps the design judgement explicit while making the mechanics deterministic. writing-an-error-test defers to this skill for the code itself.
Use when an increment introduces, resolves or constructs a Grob type — a `type` declaration, a struct construction, an anonymous struct, a new type-annotation position, a new built-in type, or any feature where a value carries a type the checker must resolve and the VM must represent. Encodes the four failure modes that produced the Sprint 5 post-close interludes (type-reference-grammar gaps, conflated cycle walks, non-uniform redeclaration and lifecycle objects escaping through new containers) as a standing pre-flight and a closing checklist. Reuses, does not replace, `adding-an-opcode` and `tdd-cycle`.
The sanctioned procedure for adding a parser production or an AST node to Grob — the parser/AST analogue of adding-an-opcode. Use when an increment genuinely needs a new surface form or a new node that is not already there (a new construction expression, a new literal, a new annotation position). The front end is built incrementally, so this is a real and expected job — not a wall to route around with an improvised gap-fix. It is deliberate and reviewable, never silent.
Use during a manual PR review to pull SonarQube Cloud (SonarCloud) findings for the pull request straight from the Web API — issues on new code, the quality-gate verdict and the new-code coverage against the floor — without the Docker-based Sonar MCP server. Produces a compact findings block for the reviewer to fold into its PR comment. It does not post anything; the human composes and posts the comment. Assumes the PR's Sonar scan has already completed (the reviewer is triggered manually after all scans).
The procedure for compiling and executing closures in Grob — the four-category variable resolution, upvalue capture of enclosing-function locals, the open/closed upvalue lifecycle, the close-on-return hand-off and per-call capture independence. Use when implementing or reviewing lambda capture (Sprint 5 Increment D), not for top-level-only lambdas.
| name | Writing an Error Test |
| description | How to add or update a gold-master error-example pair (_grob.txt + _expected.txt) and register the error code, without breaking the negative-test release gate. |
Grob's diagnostics are part of the product. The error-examples library is the negative-
test release gate: each case is a pair — a *_grob.txt source file that should fail,
and a *_expected.txt gold-master holding the exact stderr diagnostic. This skill
covers adding a case and, crucially, the discipline around regenerating expected output
when a message changes.
Every diagnostic maps to a code in docs/design/grob-error-codes.md (Exxxx). This
skill owns the gold-master pair, not the code allocation — for the code itself, defer to
allocating-an-error-code, which is the single authoritative procedure.
allocating-an-error-code ladder: confirm
nothing fits, surface the fold-versus-new judgement, get the D-###, then register in
the correct category range (Type E0xxx, Name resolution E1xxx, Syntax E2xxx,
Module E3xxx, Param/decorator E4xxx, Runtime E5xxx) at the next free number from
the live registry, in three-location lockstep with the ErrorCatalog descriptor. Codes
are immutable once shipped (ADR-0017) — the judgement is the slow part, the
mechanics are deterministic.Never emit a diagnostic with no code.
*_grob.txt)Write the smallest .grob source that triggers exactly this error and nothing else. It
follows the Grob language rules — Windows paths in backticks, := bindings, the v1
surface. A fixture that triggers three errors tests none of them cleanly. Name it for
the error: nullable_interpolation_grob.txt, not test3_grob.txt.
*_expected.txt)Run the source through the compiler/VM and capture stderr verbatim. The gold master is byte-for-byte: file, line, column, the message, and the suggestion when there is one. Do not hand-write it from memory — generate it from the actual implementation, then read it to confirm it is the diagnostic you intend.
The expected output must meet the quality bar: clear statement of what went wrong, exact location, and a suggested fix where the fix is obvious. No emoji. British English. If the generated diagnostic is poor, the fix is to improve the diagnostic in the compiler, then regenerate — not to bless poor output as the gold master.
When a diagnostic's wording changes, every gold master that includes that wording is
now stale. Do not hand-edit individual _expected.txt files to make tests pass — that
hides which cases actually changed and erodes the gold master's value.
D-### if a decision drove the wording.Make sure the new pair is picked up by the negative-test suite (the
errors-examples-README.md convention). The release gate requires the gold masters to
match; a drifting master is a release-gate fail, the same status as a failing positive
script.
*_grob.txt triggers exactly one error, minimal, idiomatic, named for the error*_expected.txt generated from the implementation, not hand-written