メニュー
How to add a function or method to one of the thirteen core modules — registration, type registry, the one-way principle, formatAs boundaries, tests.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | Adding a Stdlib Function |
| description | How to add a function or method to one of the thirteen core modules — registration, type registry, the one-way principle, formatAs boundaries, tests. |
The thirteen core modules (fs, strings, json, csv, env, process, date,
math, log, regex, path, formatAs, guid) are implemented in Grob.Stdlib as
IGrobPlugin implementations — one plugin class per module — and auto-registered at VM
startup by Grob.Cli. They are not hardwired into the VM. This skill covers adding a
function to a module or a method to a built-in type.
Grob deliberately splits these:
strings.join(...), math.log10(...),
path.join(...), fs.list(...).n.round(2), d.format("MM-MMMM"),
s.replace(a, b), file.moveTo(dst).The dividing line matters. Most string operations are methods on string;
strings.join() is the lone module function because it operates across a collection.
Scalar formatting is instance methods (n.round, d.format), not the formatAs
module — formatAs is narrowed to collection-to-string terminators only:
formatAs.table(), formatAs.list(), formatAs.csv() (D-282). Putting a scalar
formatter on formatAs is a design regression; do not do it.
There must be no two ways to do the same thing. Before adding, check the type registry
(docs/design/grob-type-registry.md) and the stdlib reference
(docs/design/grob-stdlib-reference.md) for an existing operation that covers it.
.select() superseded .map(); do not reintroduce a synonym. If your new function
overlaps an existing one, the question is which one wins, and that is a design decision
(D-###), not an additive implementation.
In the module's plugin Register method, register the function with a full
FunctionSignature — typed parameters and return type. Use named-argument-friendly
parameter names: optional and boolean parameters are idiomatically called by name in
Grob (recursive: true, overwrite: true), so the parameter names are part of the
public API. Choose them deliberately.
For an instance method, register it against the type in the TypeRegistry so the type
checker knows the receiver type exposes it.
Add the function or method to the canonical reference — grob-stdlib-reference.md for
module functions, grob-type-registry.md for instance methods — with its signature and
a one-line description. The module's documented member count must stay accurate; an
off-by-one between the doc and the implementation is exactly the kind of finding a
consistency review catches. Cite the D-### that authorised the addition.
Wrap failures as the appropriate GrobError leaf (IoError, JsonError,
ProcessError, etc.) with a quality message. Results to stdout, errors to stderr, no
emoji, British English. Windows path conventions throughout.
In Grob.Stdlib.Tests, register the module's plugin into a VM instance and assert the
function's output, including error paths. If the function appears in any of the thirteen
release-gate sample scripts, make sure that script still compiles and runs.
formatAs used only for collection terminators; scalar formatting is a methodFunctionSignature; parameter names chosen as public APITypeRegistryD-### citedGrobError leafSyntax, 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.
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.
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).