Skip to content

[rig-tasks] Daily rig evaluation — 2026-07-23 — 5/5 passed #72

Description

@github-actions

Summary

Task Description Typecheck Key finding
1 Package health checker (reused: pkghlth4) ✅ pass (after fix) Initial expansion declared helper agents that were never invoked, causing TS6133 unused-variable errors
2 TODO/FIXME/HACK tracker (reused: todotrk5) ✅ pass Clean first-pass; p.write in instructions with placeholder content works but may mislead LLM into thinking write already happened
3 Dead code detector (reused: deadcod6) ✅ pass s.optional(s.string) for recommendation field compiled correctly and was ergonomic
4 PR readiness checker (new: prrdns3x) ✅ pass Multiple p.bash + p.read in a single p`` template composed naturally
5 Changelog generator with defineTool (new: chnglog4) ✅ pass defineTool with s.object parameters and inferred handler args worked without explicit generics

Problems encountered

Task 1 — Unused helper agents cause TS6133 errors

What happened: When a two-agent chaining task is described, the natural implementation declares both agents (extractor and assessor) as top-level constants, but only one is exported as default. The extractor agent — intended to be called and its result passed to the assessor — ends up as an unused variable from TypeScript's perspective since rig programs in "inline skill mode" cannot call agents imperatively (they are declared as pipelines, not scripts).

Error message:

/tmp/gh-aw/agent/rig-task-1.ts(4,7): error TS6133: 'extractor' is declared but its value is never read.
/tmp/gh-aw/agent/rig-task-1.ts(21,7): error TS6133: 'assessor' is declared but its value is never read.

Root cause: The SKILL.md "inline markdown skill mode" constraint (export exactly one default root agent with no input and do not call it directly) conflicts with multi-agent chaining patterns. There is no supported way to chain two agents declaratively within a single program file without one of them becoming an unused variable.

Fix applied: Collapsed the two-agent chain into a single agent whose p`` instructions embed all context directly.

Minimal reproduction sketch:

import { agent, p, s } from "rig";

const extractor = agent({ model: "mini", output: s.object({ name: s.string }) }); // TS6133
const assessor = agent({ model: "nano", input: s.object({ name: s.string }), output: s.string }); // TS6133

export default assessor; // only this is exported; extractor is dead

Task 2 — p.write placeholder content in instructions

What happened: Using p.write("todo-report.md", "# TODO Report\n\n...") inside a p`` instruction block emits a write-instruction to the LLM. This is semantically correct per SKILL.md, but the placeholder content passed to p.write is a static string. There is no way to tell p.write to write the LLM-generated content — the model must include the actual file content elsewhere in its response, and the harness must wire that output to the write intent. The current API shape makes this ambiguous.


Improvement opportunities

Missing schema helpers (s.*)

  • s.int vs s.number clarity: No compile-time hint when s.number is used for a count field that should be integer. A linter/warning would help.
  • s.nonEmptyObject: For cases where an empty {} output should be rejected at validation time.

Missing prompt helpers (p.*)

  • p.writeOutput(fieldName): A declared intent that tells the harness "write the value of output field X to this path". This would solve the p.write ambiguity above — e.g., p.writeOutput("report", "todo-report.md") would wire the report output field to the file path automatically.
  • p.glob used in task-pool entries but not tested today: No blocking issue found, but worth confirming p.glob patterns with --include equivalents work correctly when the glob returns many paths.

Error message quality

  • TS6133 on unused agents is correct but confusing: The error points to the agent declaration, not the chaining pattern. A targeted diagnostic like "rig: subagents must be exported or referenced via agents: spec field" would make the issue immediately actionable.

API ergonomics

  • Two-agent chaining requires collapsing to one agent in inline mode: The SKILL.md constraint that "export exactly one default root agent" prevents true declarative multi-agent pipelines. The agents: spec field enables subagent delegation from within the LLM, but there is no way to express "call A, then call B with A's output" purely in the TypeScript declaration layer.
    • Suggestion: A pipeline(agentA, agentB) combinator or a chain helper that connects two agents' input/output schemas at the TypeScript level and exports as a single runnable unit.
  • defineTool inference with s.* schemas: Worked perfectly with no explicit generics required — this is a strong ergonomic win worth highlighting in SKILL.md examples.

Documentation gaps

  • SKILL.md does not clarify what p.write does with its second argument at runtime: The docs say it is a "write-file instruction; does NOT return the path" but do not explain how the actual written content is determined. Is the second arg a template? A static value? Does the LLM replace it?
  • Two-agent chaining pattern is underdocumented: The SKILL.md checklist says agents is "optional named subagents exposed to the harness" but gives no example of how the LLM invokes them or how results flow back. Sample 36 (subagent-delegation) exists but is not linked from the relevant checklist item.

Tasks run today

  • (reused) Task 1: Package health checker with two-agent chaining — pkghlth4
  • (reused) Task 2: TODO/FIXME/HACK comment tracker using p.bash grep scan and p.write — todotrk5
  • (reused) Task 3: Dead code detector using p.bash grep and s.optional fields — deadcod6
  • (new) Task 4: Multi-step PR readiness checker with p.read + p.bash + s.enum verdict — prrdns3x
  • (new) Task 5: Changelog entry generator with defineTool semver validation and p.write — chnglog4

Generated by Daily Rig Task Generator · sonnet46 57 AIC · ⌖ 7.47 AIC · ⊞ 5.5K ·

Metadata

Metadata

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions