Summary
| Task |
Description |
Typecheck |
Key finding |
| 1 (reused) |
Git tag annotation summarizer (gittagx1) |
✅ pass |
Clean s.record(s.object) + s.enum pattern; no issues |
| 2 (reused) |
JSON config merger with defineTool (cfgmrg5x) |
✅ pass |
Dynamic input.files in prompt requires string-literal workaround; p.readAll cannot use input fields |
| 3 (reused) |
npm audit reporter with repair() + steering() (npmaud7b) |
✅ pass |
Straightforward; addon array form works cleanly |
| 4 (new) |
Env var documentation generator with p.readOptional + defineTool |
✅ pass |
p.readOptional fallback text ergonomics are good |
| 5 (new) |
Dead code detector with p.bash + defineTool + repair() |
✅ pass |
s.record(s.object) for dynamic symbol maps works well |
Problems encountered
Task 2 — Dynamic input arrays cannot be injected into p.readAll
The JSON config merger task requires reading a caller-supplied list of file paths. The natural expression would be:
// Desired but not supported:
instructions: p`Review ${p.readAll(input.files)} and merge.`
p.readAll only accepts a known static path list. The workaround is to reference input.files as a prose description:
instructions: p`You are given a list of JSON config file paths: ${"input.files"}\nRead and merge them.`
This string-literal interpolation (${"input.files"}) is not obviously documented and produces a literal string in the prompt rather than injecting the value. It works at runtime because the harness substitutes input fields, but the mechanism is not surfaced in SKILL.md's prompt-intents table and is easy to confuse with a no-op string literal.
rig-expander custom subagent returned empty responses
When delegating to the rig-expander background agent via the task tool, all 5 agents completed with total_turns: 1 but [Turn 0] contained no content. The agents appear to have consumed the prompt silently without emitting the expected TypeScript program. This forced manual authoring of all 5 programs.
Improvement opportunities
Missing schema helpers (s.*)
s.record(s.object(...)) is the correct pattern for dynamic keyed maps but its interaction with s.nonEmptyRecord is not documented. A s.recordOf(value, description?) alias would improve readability.
- No helper for discriminated unions (e.g.,
s.union([s.object({type: s.literal("a"), ...}), s.object({type: s.literal("b"), ...})])). Tasks that need sum types currently use s.unknown or s.enum with separate fields, reducing schema precision.
Missing prompt helpers (p.*)
p.readInput(field) exists for single path fields, but there is no p.readAllInput(field) for reading an array of paths supplied by the caller. This is a common pattern (batch-process a list of files) that currently requires awkward prose workarounds.
p.json(value) could be more prominently documented as the way to inject structured caller input into prompt context without requiring a file read.
Error message quality
- No issues encountered in this run. All typecheck errors from prior authoring experience are clear.
API ergonomics
- Referencing input fields in
p\...`template literals uses the syntax${"input.fieldName"}(a plain string interpolation), which is indistinguishable from a static string literal. It works at runtime but has no type-safety, no autocomplete, and no documentation in SKILL.md. A dedicated helper likep.inputField("files")` would make this pattern explicit, type-safe, and discoverable.
- The
tools field on agent({...}) and the defineTool API are clean, but there is no guidance in SKILL.md on when to prefer a tool vs. embedding logic in p.bash. A short decision table would help.
Documentation gaps
- SKILL.md's prompt-intents table shows
p.readInput(field) but does not explain that it reads a single path. The limitation (no support for array fields) should be called out explicitly.
- The interaction between
repair() and maxTurns is explained ("its maxTurns budget belongs on the agent spec") but it is unclear whether maxTurns counts both initial turns and repair retries, or only retries. A concrete example (e.g., maxTurns: 3 = 1 initial + 2 repair attempts) would remove ambiguity.
- The
rig-expander custom agent protocol (what format it expects its prompt in, what fence markers it produces) is not documented in SKILL.md or AGENTS.md. When the agent silently fails, there is no fallback guidance.
Tasks run today
- (reused) Task 1: Git tag annotation summarizer using
p.bash git for-each-ref, s.record, s.enum stability
- (reused) Task 2: JSON config merger reading multiple files,
defineTool for JSON validation, s.record merged keys, s.array conflicts
- (reused) Task 3: npm audit vulnerability reporter using
p.bash npm audit --json, repair() + steering() addons, s.enum recommendation
- (new) Task 4: Environment variable documentation generator using
p.readOptional for .env.example, defineTool for category/sensitivity classification, deeply nested s.object output
- (new) Task 5: Dead code detector using
p.bash find + grep, defineTool for heuristic usage estimation, repair() addon, s.record(s.object) per symbol with s.enum status
Generated by Daily Rig Task Generator · sonnet46 48.5 AIC · ⌖ 4.65 AIC · ⊞ 5.6K · ◷
Summary
gittagx1)s.record(s.object)+s.enumpattern; no issuesdefineTool(cfgmrg5x)input.filesin prompt requires string-literal workaround;p.readAllcannot use input fieldsrepair()+steering()(npmaud7b)p.readOptional+defineToolp.readOptionalfallback text ergonomics are goodp.bash+defineTool+repair()s.record(s.object)for dynamic symbol maps works wellProblems encountered
Task 2 — Dynamic input arrays cannot be injected into
p.readAllThe JSON config merger task requires reading a caller-supplied list of file paths. The natural expression would be:
p.readAllonly accepts a known static path list. The workaround is to referenceinput.filesas a prose description:This string-literal interpolation (
${"input.files"}) is not obviously documented and produces a literal string in the prompt rather than injecting the value. It works at runtime because the harness substitutes input fields, but the mechanism is not surfaced in SKILL.md's prompt-intents table and is easy to confuse with a no-op string literal.rig-expandercustom subagent returned empty responsesWhen delegating to the
rig-expanderbackground agent via thetasktool, all 5 agents completed withtotal_turns: 1but[Turn 0]contained no content. The agents appear to have consumed the prompt silently without emitting the expected TypeScript program. This forced manual authoring of all 5 programs.Improvement opportunities
Missing schema helpers (
s.*)s.record(s.object(...))is the correct pattern for dynamic keyed maps but its interaction withs.nonEmptyRecordis not documented. As.recordOf(value, description?)alias would improve readability.s.union([s.object({type: s.literal("a"), ...}), s.object({type: s.literal("b"), ...})])). Tasks that need sum types currently uses.unknownors.enumwith separate fields, reducing schema precision.Missing prompt helpers (
p.*)p.readInput(field)exists for single path fields, but there is nop.readAllInput(field)for reading an array of paths supplied by the caller. This is a common pattern (batch-process a list of files) that currently requires awkward prose workarounds.p.json(value)could be more prominently documented as the way to inject structured caller input into prompt context without requiring a file read.Error message quality
API ergonomics
p\...`template literals uses the syntax${"input.fieldName"}(a plain string interpolation), which is indistinguishable from a static string literal. It works at runtime but has no type-safety, no autocomplete, and no documentation in SKILL.md. A dedicated helper likep.inputField("files")` would make this pattern explicit, type-safe, and discoverable.toolsfield onagent({...})and thedefineToolAPI are clean, but there is no guidance in SKILL.md on when to prefer a tool vs. embedding logic inp.bash. A short decision table would help.Documentation gaps
p.readInput(field)but does not explain that it reads a single path. The limitation (no support for array fields) should be called out explicitly.repair()andmaxTurnsis explained ("itsmaxTurnsbudget belongs on the agent spec") but it is unclear whethermaxTurnscounts both initial turns and repair retries, or only retries. A concrete example (e.g.,maxTurns: 3= 1 initial + 2 repair attempts) would remove ambiguity.rig-expandercustom agent protocol (what format it expects its prompt in, what fence markers it produces) is not documented in SKILL.md or AGENTS.md. When the agent silently fails, there is no fallback guidance.Tasks run today
p.bash git for-each-ref,s.record,s.enumstabilitydefineToolfor JSON validation,s.recordmerged keys,s.arrayconflictsp.bash npm audit --json,repair()+steering()addons,s.enumrecommendationp.readOptionalfor.env.example,defineToolfor category/sensitivity classification, deeply nesteds.objectoutputp.bash find+grep,defineToolfor heuristic usage estimation,repair()addon,s.record(s.object)per symbol withs.enumstatus