[rig-tasks] Daily rig evaluation — 2026-07-26 — 10/10 passed #168

Summary

Problems encountered

Tasks 1, 5, 8, 10 — Wrong import source for addons

What the code tried to do: Used import { ..., repair } from "rig" and import { ..., steering } from "rig".

Error message:

error TS2305: Module '"rig"' has no exported member 'repair'.
error TS2305: Module '"rig"' has no exported member 'steering'.

Root cause: repair() and steering() are exported from "rig/addons", not from "rig". The SKILL.md mentions repair() and steering() in the addons table but doesn't show the import source explicitly in the inline quick-reference. The fix was a one-line import change: import { repair } from "rig/addons".

Task 9 — p.writeOutput called with too few arguments

What the code tried to do: Used p.writeOutput("suggestedFileName") to declare a write intent in instructions.

Error message:

error TS2554: Expected 2-3 arguments, but got 1.

Root cause: p.writeOutput(field, path, options?) requires a static destination path as the second argument. The field name alone is not sufficient. Fixed to p.writeOutput("suggestedFileName", "fixture-output.ts").

Improvement opportunities

Missing or undiscoverable schema helpers (s.*)

No missing helpers encountered this run. s.record(s.object), s.optional(s.string), and s.enum all worked as expected.

Missing or undiscoverable prompt helpers (p.*)

• p.readOptional with multiple filenames: tasks frequently needed to try 2–3 candidate filenames (e.g., openapi.json vs openapi.yaml). There is no p.readFirstOf(paths[]) helper, so two separate p.readOptional calls are needed. A p.readFirstOf(["openapi.json", "openapi.yaml"]) helper would reduce boilerplate.
• p.writeOutput is easy to call with 1 arg: the required path second argument is non-obvious when the path is dynamically computed from the output. A variant p.writeOutput(field) (no static path, path read from the field itself when it is a s.path) would remove ambiguity.

Error message quality

• The TS2305 error ("Module 'rig' has no exported member 'repair'") is clear, but the fix location ("rig/addons") is not mentioned. The compiler error could be augmented by a custom lint rule that suggests "rig/addons" when known addon symbols are imported from "rig".
• The TS2554 error for p.writeOutput ("Expected 2-3 arguments, but got 1") doesn't mention what the second argument should be.

API ergonomics

• Addons import split: The "rig" vs "rig/addons" split is the single most common generation mistake. SKILL.md states "see composition.md" but the inline quick-reference table doesn't show which module to import from. Adding from "rig/addons" next to the addon names in the SKILL.md table would eliminate this error class entirely.
• repair() placement in addons array: The rule that steering() must come before repair() is important but only mentioned in SKILL.md's references; a repeated note in the inline Construction Rules would help.

Candidate lint rules

Rule: no-addon-from-rig

• Problem: repair, steering, timeout, oncePerAgent are imported from "rig" instead of "rig/addons".
• Invalid: import { agent, repair, s } from "rig";
• Valid: import { agent, s } from "rig"; import { repair } from "rig/addons";
• Why model-confusing: All other rig primitives (agent, p, s, defineTool) live in "rig", so it's natural to assume addons do too. The split is invisible until typecheck.
• Autofix: Yes — move the addon identifiers to a "rig/addons" import statement, adding one if absent.

Documentation gaps

• SKILL.md addon table (line ~52): The row steering({ message? }), timeout({ timeout }), repair() should include the import module, e.g., from "rig/addons". Currently the import source only appears in references/composition.md.
• p.writeOutput signature: SKILL.md's prompt intent table should show the full signature p.writeOutput(field, path, opts?) rather than just the intent name, to avoid the one-argument mistake.

Tasks run today

• (reused) Dead code detector using p.bash find for TS files and grep for exported symbols, defineTool for heuristic usage estimation, repair addon maxTurns:3
• (reused) OpenAPI spec validator using p.readOptional for json/yaml specs, defineTool<{content:string}> for structural checks, s.array of issues with s.enum type
• (reused) API endpoint extractor that scans route files via p.bash, outputs s.array(s.object) of endpoints, with a classifier subagent using s.enum for purpose
• (reused) Source file annotation writer that reads TypeScript files via p.read, uses a subagent to generate JSDoc comments, and writes annotated output via p.write
• (reused) Stale dependency detector using p.bash npm outdated --json and p.read package.json, defineTool for classifying version drift
• (reused) Git tag release timeline reporter using p.bash git tag --sort and git log between tags, two-step chain with timelineSummarizer subagent (nano)
• (new) Env variable type inferrer: reads .env.example via p.readOptional, uses defineTool with regex to classify each value type as s.enum(string/number/boolean/url/path/unknown)
• (new) Makefile target extractor: uses p.readOptional for Makefile, defineTool to parse phony vs real file targets, repair addon
• (new) Test fixture generator: accepts input s.object({sourceFile: s.path, functionName: s.string}), reads source via p.readInput, uses nano signatureAnalyzer subagent, writes fixture via p.writeOutput
• (new) Server uptime log parser: uses p.bash for systemd journal/log file, defineTool for parsing lifecycle events, steering addon for crash loops

Generated by Daily Rig Task Generator · sonnet46 103.3 AIC · ⌖ 7.35 AIC · ⊞ 6.7K · ◷