[rig-tasks] Add 10 rig samples — 2026-07-30 - #311
Conversation
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
🧠 Matt Pocock Skills Reviewer has completed the skills-based review. ✅ |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Skills-Based Review 🧠
Applied /grill-with-docs — requesting changes on three correctness issues in sample code.
📋 Key Themes & Highlights
Issues found
p.bash+ runtime inputs mismatch (320, 328): Two samples use a staticp.bashhint referencing a hard-coded path instead ofinput.*fields — teaching an incorrect pattern.p.bashstrings are resolved at prompt-build time and cannot reference runtime inputs.p.writeInputoutput field mismatch (324):p.writeInput("outputFile", "patch")references a field"patch"that does not exist in the output schema; the write intent will silently no-op at runtime.- JSON Schema
"integer"vs JStypeof(329):typeof 42 === "number"not"integer", so any schema field typed"integer"will always report a false type error in the validator tool.
Positive highlights
- ✅ Excellent variety of patterns across 10 samples (async tools, glob, readOptional, readInput, multi-addon)
- ✅ All samples pass typecheck
- ✅ Consistent use of
s.*helpers andmodel: "small"throughout - ✅ 325-release-note-enricher correctly combines
[steering(), repair()]addons - ✅ 326-ssh-config-host-parser has clean idiomatic regex parsing in the tool handler
🧠 Reviewed using Matt Pocock's skills by Matt Pocock Skills Reviewer · sonnet46 46.8 AIC · ⌖ 4.53 AIC · ⊞ 6.3K
Comment /matt to run again
| model: "small", | ||
| input: s.object({ filePath: s.path, revision: s.string }), | ||
| instructions: p`Retrieve the file content at the given git revision. | ||
| File content: ${p.bash("git show HEAD:README.md 2>/dev/null | head -3 || echo 'example'")} |
There was a problem hiding this comment.
[/grill-with-docs] The p.bash command hard-codes HEAD:README.md instead of using the agent's input.filePath and input.revision inputs — so the sample misleads readers about how to wire runtime inputs into prompt intents.
💡 Suggestion
p.bash is a static string resolved at prompt-build time; it cannot reference runtime input.* values. A cleaner approach: omit the inline bash hint and let the LLM construct git show <revision>:<path> itself from the declared input schema. This is consistent with the p.bash invariant (INV:prompt-intents: p.* are declarative placeholders, never executed in-process).
| } | ||
| for (const [field, propSchema] of Object.entries(properties)) { | ||
| if (field in dataObj && propSchema.type) { | ||
| const actual = typeof dataObj[field]; |
There was a problem hiding this comment.
[/grill-with-docs] typeof returns "number" for both integers and floats, but JSON Schema distinguishes "integer" from "number". A data field declared as {"type":"integer"} in the schema will always fail this check even if the value is a valid integer like 42.
💡 Suggestion
Map "integer" to the JS typeof result "number" before comparing:
const expectedType = propSchema.type === "integer" ? "number" : propSchema.type;
if (actual !== expectedType) {
errors.push({ field, expected: propSchema.type, actual });
}This makes the sample an accurate validator and avoids teaching readers a subtle JSON Schema vs JS type mismatch.
| instructions: p`Compare the baseline config file against the active config file. | ||
| Baseline: ${p.readInput("baseFile")} | ||
| Active: ${p.readInput("activeFile")} | ||
| Identify keys that have drifted (changed values). Write a corrected patch to the output file: ${p.writeInput("outputFile", "patch")} |
There was a problem hiding this comment.
[/grill-with-docs] p.writeInput("outputFile", "patch") uses "patch" as the contentOutputField name, but the output schema has no field named patch — it has changedKeys and summary. The write intent will silently find nothing to write at runtime.
💡 Suggestion
Either rename the output field to patch and give it a s.string type, or change the intent to reference an actual output field:
// Option A: add a patch field to the output schema
output: s.object({
patch: s.string,
changedKeys: s.record(...),
summary: s.object(...),
}),
// then reference it correctly:
${p.writeInput("outputFile", "patch")}Without a matching output field, this sample incorrectly demonstrates p.writeInput.
| model: "small", | ||
| input: s.object({ filePath: s.string }), | ||
| instructions: p`Analyze git blame for the file at input.filePath. | ||
| Run: ${p.bash("git blame --line-porcelain HEAD -- . 2>/dev/null | head -5 || echo 'no git'")} |
There was a problem hiding this comment.
[/grill-with-docs] The p.bash probe runs git blame --line-porcelain HEAD -- . (the whole repo) as a static example hint, but the agent's input supplies filePath. A reader following this sample would expect the bash intent to target the specific file — but p.bash strings are static and cannot reference input.* values at build time.
💡 Suggestion
Make the limitation explicit: either add a comment noting that the bash hint is illustrative only, or remove it and rely on the parseBlameOutput tool receiving the blame text from the LLM (which will construct the real git blame command from the declared input.filePath). Mixing a static glob-level bash hint with a per-file input creates a conceptual mismatch for readers.
1 participant
Summary
Added 10 new rig sample files to
skills/rig/samples/.defineTool+steering()defineTool+repair()defineTool+steering()p.bash+p.readOptional+repair()p.readInput/p.writeInput[steering(), repair()]addonsp.readOptional+defineTool+repair()p.glob+ asyncdefineTool+steering()p.bash+defineTool+repair()p.readInput+defineTool+repair()Typecheck failures
None — all 10 samples passed typecheck.
Tasks run