Summary
| Task |
Description |
Typecheck |
Key finding |
| 1 |
Dead code detector (reused: deadcod6) |
✅ pass |
s.optional(s.int) for line numbers works cleanly |
| 2 |
Git blame hotspot analyzer (reused: githtsp1) |
✅ pass |
s.record(s.object(...)) for file map works but needed a wrapper files field — root s.record output shape works |
| 3 |
Code complexity scorer with subagents (reused: cmplxsc2) |
✅ pass |
p.readInput("filePath") required for dynamic paths in subagents — not obvious from docs |
| 4 |
Build log analyzer with repair (new: bldlog3y) |
✅ pass |
repair addon mentioned but not exported from "rig" — users must implement custom AgentAddon |
| 5 |
TypeScript type alias mapper with defineTool (new: tstype4z) |
✅ pass |
defineTool with s.object parameters + s.record(s.object) root output composes cleanly |
Problems encountered
repair and steering are documented but not exported
The SKILL.md references repair and steering as first-class addons:
"Add a repair addon with maxTurns: 3"
But neither is exported from "rig". The built-in repair behavior is triggered by maxTurns on the spec itself, not via an addon. When a generator (or user) tries:
import { agent, repair, s } from "rig"; // type error: 'repair' is not exported
The correct idiom is just maxTurns: 3 in the spec, but this is never stated explicitly alongside the addon documentation. Users are left confused about what addons are for vs. maxTurns.
Reproduction sketch:
// What docs imply is possible:
const a = agent({ addons: [repair()], maxTurns: 3, ... });
// Actual: repair is not a named export; maxTurns on spec is the repair knob
const a = agent({ maxTurns: 3, ... }); // correct
rig-expander subagent produced no output
When used as a background agent in this evaluation workflow, the rig-expander subagent completed (status: idle) but returned empty turn content. All 5 programs had to be written manually. This may be a runtime/transport issue with background agent invocation, but surfacing this as a known limitation or adding a health-check mechanism would help.
p.readInput discoverability
When generating code for a subagent that accepts a file path as input, the natural instinct is to use p.read(input.path) — which is a type error since p.read requires a literal string. p.readInput("fieldName") is the correct approach but is documented in a subsection that's easy to miss. A brief note in the agent({ input }) docs would help.
Improvement opportunities
Missing schema helpers (s.*)
s.path — a string schema variant with semantic meaning "file path"; would improve readability and could hint to the runtime about path-based context resolution.
s.int in record values — s.record(s.int) is documented but s.record(s.object(...)) as a root output schema lacks an explicit example showing how to give the whole agent output a record shape. An example in the Schema section would help.
Missing prompt helpers (p.*)
p.repair(customPrompt) — an exported addon factory that wraps the built-in repair logic with a user-supplied fallback message. Currently the user must write a full AgentAddon function to customize repair prompts.
p.steering(fn) — an exported addon factory for steering (mentioned in SKILL.md but not exported). Even a thin wrapper would be more ergonomic than raw AgentAddon.
Error message quality
- When
addons receives a non-function value, the error is "Agent addon entries must be functions." — this is clear, but doesn't say which addon index failed or what value was passed. Including the value's type/shape would help debug mistakes like addons: [repair] where repair is undefined.
API ergonomics
maxTurns vs repair addon: The relationship is confusing. maxTurns controls built-in repair retries, but addons exists for custom logic. The docs should explicitly state: "For built-in repair, set maxTurns in the spec. The addons array is for custom turn-level middleware — not for configuring built-in repair."
- Root-level
s.record(...) output: Works correctly, but many patterns want a mixed output with both a record of results and a summary string. This forces a wrapper s.object({ files: s.record(...), summary: s.string }). A note acknowledging this pattern would help.
- Subagent
agents field naming: Subagent keys in agents: { fileAnalyzer } must match the variable name exactly. There's no runtime validation error if the key is wrong — the harness silently ignores it. A check or clearer docs on naming conventions would reduce confusion.
Documentation gaps
p.readInput placement: Currently in a dedicated subsection far from the p.read docs. Should be mentioned inline next to p.read with a note: "Use p.readInput(field) when the path is supplied by the caller as an input field."
- Built-in repair behavior: The section on
maxTurns should clarify that repair (re-prompting on JSON/schema failure) is automatic when maxTurns > 1 — no addon needed.
tools field in agent(spec): The tools field in AgentSpec is not mentioned in SKILL.md at all. The defineTool section jumps straight to passing tools via agent({ tools: [...] }) without listing tools in the spec fields table.
Tasks run today
- (reused) Task 1: Dead code detector that finds potentially unused exported symbols using p.bash grep and s.optional fields in output schema
- (reused) Task 2: Git blame hotspot analyzer using p.bash git log with stat, s.record output keyed by file path with changeCount/lastAuthor/risk s.enum, repair addon maxTurns:3
- (reused) Task 3: Code complexity scorer with subagent delegation: coordinator uses p.bash find + p.read per file via fileAnalyzer subagent, aggregates scores with s.enum verdict
- (new) Task 4: Build log analyzer using p.bash npm run build, repair addon maxTurns:3, outputs s.object with s.array of error objects having s.enum severity (error/warning/info), s.optional file, and s.boolean buildSucceeded flag
- (new) Task 5: TypeScript type alias mapper using p.bash find + file content scan, defineTool for regex-based categorization, outputs s.record(s.object) with s.enum kind (primitive/union/intersection/mapped/other) and s.boolean exported per alias
Generated by Daily Rig Task Generator · sonnet46 59.6 AIC · ⌖ 7.5 AIC · ⊞ 5.5K · ◷
Summary
deadcod6)s.optional(s.int)for line numbers works cleanlygithtsp1)s.record(s.object(...))for file map works but needed a wrapperfilesfield — roots.recordoutput shape workscmplxsc2)p.readInput("filePath")required for dynamic paths in subagents — not obvious from docsbldlog3y)repairaddon mentioned but not exported from"rig"— users must implement customAgentAddondefineTool(new:tstype4z)defineToolwiths.objectparameters +s.record(s.object)root output composes cleanlyProblems encountered
repairandsteeringare documented but not exportedThe SKILL.md references
repairandsteeringas first-class addons:But neither is exported from
"rig". The built-in repair behavior is triggered bymaxTurnson the spec itself, not via an addon. When a generator (or user) tries:The correct idiom is just
maxTurns: 3in the spec, but this is never stated explicitly alongside the addon documentation. Users are left confused about whataddonsare for vs.maxTurns.Reproduction sketch:
rig-expandersubagent produced no outputWhen used as a background agent in this evaluation workflow, the
rig-expandersubagent completed (status: idle) but returned empty turn content. All 5 programs had to be written manually. This may be a runtime/transport issue with background agent invocation, but surfacing this as a known limitation or adding a health-check mechanism would help.p.readInputdiscoverabilityWhen generating code for a subagent that accepts a file path as input, the natural instinct is to use
p.read(input.path)— which is a type error sincep.readrequires a literal string.p.readInput("fieldName")is the correct approach but is documented in a subsection that's easy to miss. A brief note in theagent({ input })docs would help.Improvement opportunities
Missing schema helpers (
s.*)s.path— a string schema variant with semantic meaning "file path"; would improve readability and could hint to the runtime about path-based context resolution.s.intin record values —s.record(s.int)is documented buts.record(s.object(...))as a root output schema lacks an explicit example showing how to give the whole agent output a record shape. An example in the Schema section would help.Missing prompt helpers (
p.*)p.repair(customPrompt)— an exported addon factory that wraps the built-in repair logic with a user-supplied fallback message. Currently the user must write a fullAgentAddonfunction to customize repair prompts.p.steering(fn)— an exported addon factory for steering (mentioned in SKILL.md but not exported). Even a thin wrapper would be more ergonomic than rawAgentAddon.Error message quality
addonsreceives a non-function value, the error is"Agent addon entries must be functions."— this is clear, but doesn't say which addon index failed or what value was passed. Including the value's type/shape would help debug mistakes likeaddons: [repair]whererepairis undefined.API ergonomics
maxTurnsvsrepairaddon: The relationship is confusing.maxTurnscontrols built-in repair retries, butaddonsexists for custom logic. The docs should explicitly state: "For built-in repair, setmaxTurnsin the spec. Theaddonsarray is for custom turn-level middleware — not for configuring built-in repair."s.record(...)output: Works correctly, but many patterns want a mixed output with both arecordof results and asummarystring. This forces a wrappers.object({ files: s.record(...), summary: s.string }). A note acknowledging this pattern would help.agentsfield naming: Subagent keys inagents: { fileAnalyzer }must match the variable name exactly. There's no runtime validation error if the key is wrong — the harness silently ignores it. A check or clearer docs on naming conventions would reduce confusion.Documentation gaps
p.readInputplacement: Currently in a dedicated subsection far from thep.readdocs. Should be mentioned inline next top.readwith a note: "Usep.readInput(field)when the path is supplied by the caller as an input field."maxTurnsshould clarify that repair (re-prompting on JSON/schema failure) is automatic whenmaxTurns > 1— no addon needed.toolsfield inagent(spec): Thetoolsfield inAgentSpecis not mentioned in SKILL.md at all. ThedefineToolsection jumps straight to passing tools viaagent({ tools: [...] })without listingtoolsin the spec fields table.Tasks run today