[rig-tasks] Add 10 rig samples — 2026-07-28 - #261
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 /codebase-design — requesting changes on two correctness issues in subagent wiring.
📋 Key Themes & Highlights
Key Issues
- Subagents missing
p.readInput(282, 285): Both thebranchAnalyzer(282) andsignatureAnalyzer(285) declare aninput:schema with a file path but their instructions never callp.readInput()to inject the file content. This is a correctness bug — the subagents will operate without seeing the source file. p.bashfor file discovery (288): Usesfindshell command wherep.glob("**/*.ts")is the idiomatic rig intent — inconsistent with 286 and 289 in the same PR.- Steering duplicates instructions (280): Threshold rules appear in both
steeringmessage andinstructionsbody; single-source-of-truth risk. - Hardcoded
fixture.tsoutput path (285):p.writeOutputwrites every fixture to the same filename regardless of thefunctionNameinput.
Positive Highlights
- ✅ Good variety of patterns across the 10 samples:
s.record,defineTool, subagent delegation,repair,steering, async tool handlers - ✅ Consistent use of
p.readOptionalwith fallback strings in 283, 284 - ✅ Solid
defineToolimplementations in 283 (type inferrer), 284 (Makefile parser), 287 (checkpoint classifier) — pure functions that are easy to reason about - ✅ 286 and 289 correctly use
p.globfor workspace file discovery
🧠 Reviewed using Matt Pocock's skills by Matt Pocock Skills Reviewer · sonnet46 53.9 AIC · ⌖ 4.56 AIC · ⊞ 6.3K
Comment /matt to run again
| // Agent role: extract all branch points from the provided TypeScript source code. | ||
| const branchAnalyzer = agent({ | ||
| model: "small", | ||
| instructions: p`Analyze the TypeScript source code provided in the input and list every branch point (if/ternary/switch/nullish coalescing). For each branch, identify the enclosing function name, line number, branch type, and whether it appears covered (has a test or usage path). Return an array of branch objects.`, |
There was a problem hiding this comment.
[/codebase-design] The branchAnalyzer subagent declares input: s.object({ filePath: s.path }) but its instructions never call p.readInput("filePath") — the model never sees the source to analyze.
💡 Fix
Follow the existing pattern from sample 159 (ts-branch-coverage.md) — add p.readInput to the subagent's instructions:
instructions: p`Analyze the TypeScript source code:
${p.readInput("filePath")}
For each branch...`,Without this the subagent receives no file content; its covered flags will be unreliable.
| // Agent role: analyze a function signature and return its parameters and return type. | ||
| const signatureAnalyzer = agent({ | ||
| model: "small", | ||
| instructions: p`Analyze the TypeScript source provided in the input. Extract the signature details for the specified function: its parameters (name and type), return type, and any JSDoc description. Return structured signature details.`, |
There was a problem hiding this comment.
[/codebase-design] The signatureAnalyzer subagent declares input: s.object({ sourceFile: s.path, functionName: s.string }) but its instructions don't inject the file content with p.readInput("sourceFile") — the model analyzes nothing.
💡 Fix
The subagent needs to read the file to extract the signature:
instructions: p`Analyze the TypeScript source:
${p.readInput("sourceFile")}
Extract the signature of the function named in the input...`,The parent agent already reads the source at line 26, but the subagent doesn't — it will produce hallucinated signatures.
| instructions: p`Extract string literal union type declarations from all TypeScript source files. | ||
|
|
||
| TypeScript files: | ||
| ${p.bash("find . -name '*.ts' -not -path '*/node_modules/*' -not -path '*/.git/*' 2>/dev/null | head -40")} |
There was a problem hiding this comment.
[/codebase-design] Uses p.bash("find . -name '*.ts' ...") when p.glob("**/*.ts") is the idiomatic rig intent for file listing — p.glob is declarative, handled by the harness, and doesn't hardcode shell syntax.
💡 Fix
TypeScript files:
${p.glob("**/*.ts")}This is consistent with samples 286 and 289 which both use p.glob. Using p.bash for discovery also processes node_modules exclusion in shell, whereas p.glob respects workspace defaults.
| // Agent role: classify repository files by commit churn frequency and assign a risk level. | ||
| const commitChurnClassifier = agent({ | ||
| model: "small", | ||
| addons: steering({ message: "Be precise: assign riskLevel based on churnCount: >20=critical, >10=volatile, >5=active, else stable." }), |
There was a problem hiding this comment.
[/codebase-design] The steering message duplicates the classification thresholds that are already spelled out in instructions. If the thresholds ever change, they'd need to be updated in two places.
💡 Suggestion
Either remove the steering addon and rely on the clear rules in instructions, or keep only the steering message and shorten the instructions. Compare sample 113 (git-hotspot-analyzer.md) where steering is used for emphasis, not duplication.
If the steering is genuinely needed to keep the LLM on-spec, consider combining repair with a single concise steering message that doesn't restate the full threshold table.
|
|
||
| 1. Delegate to signatureAnalyzer to get the function signature for the function named in the input. | ||
| 2. Using the signature, generate fixture code: example inputs, mock helpers, and a vitest describe block. | ||
| 3. Write the fixture code to fixture.ts: ${p.writeOutput("fixtureCode", "fixture.ts")} |
There was a problem hiding this comment.
[/codebase-design] p.writeOutput("fixtureCode", "fixture.ts") writes a hardcoded filename fixture.ts, ignoring the input functionName. Every call will overwrite the same file, making the agent unusable for generating fixtures for multiple functions.
💡 Suggestion
Use a dynamic path or make suggestedFileName the write target. Since p.writeOutput requires a literal path at definition time, document that the caller should provide the output path via input, or hardcode a pattern like {functionName}.fixture.ts in the suggested filename and let the caller move the file.
Alternatively, remove p.writeOutput and rely solely on the fixtureCode string output — the suggestedFileName field already conveys where to write it.
1 participant
Summary
Added 10 new rig sample files to
skills/rig/samples/.Typecheck failures
No failures — all 10 programs passed typecheck.
Tasks run