Summary
| Task |
Description |
Kind |
Typecheck |
Key finding |
| 1 (reused) |
Git file ownership mapper |
agent |
✅ pass |
Clean use of execSync in defineTool, p.glob for discovery, steering() addon |
| 2 (reused) |
GitHub Actions workflow input validator |
agent |
✅ pass (after fix) |
exactOptionalPropertyTypes requires string | undefined not just string | undefined on optional field — fixed by widening the local type annotation |
| 3 (reused) |
TypeScript dead export finder |
agent |
✅ pass |
Good combo of p.glob + p.bash for discovery, plus steering() + repair() both present |
| 4 (reused) |
package.json scripts documenter |
agent |
✅ pass |
as const return from handler with union type preserved enum contract correctly |
| 5 (reused) |
Git diff stats summarizer |
agent |
✅ pass |
s.enum on changeType with as const in handler worked cleanly |
| 6 (reused) |
Dotenv template generator |
agent |
✅ pass |
p.readOptional + p.glob combo — good pattern for "maybe exists" files |
| 7 (new) |
TOML config file key extractor |
agent |
✅ pass |
Nested s.record(s.record(s.string)) compiled cleanly; p.readInput used correctly |
| 8 (new) |
CSV column statistics reporter |
agent |
✅ pass |
s.optional(s.number) in nested record object — clean output contract |
| 9 (new) |
Git worktree listing analyzer |
agent |
✅ pass |
as const on type and status fields needed for enum compatibility — applied correctly |
| 10 (new) |
TypeScript narrowing pattern detector |
agent |
✅ pass |
p.glob + async defineTool with readFile — well-structured |
Problems encountered
Task 2 — exactOptionalPropertyTypes failure
What the code tried to do: Define a local type annotation { type: string; required: boolean; default?: string } and assign default: defaultM ? defaultM[1].trim() : undefined.
Error:
Type '{ type: string; required: boolean; default: string | undefined; }' is not assignable
to type '{ type: string; required: boolean; default?: string; }'
with 'exactOptionalPropertyTypes: true'.
Root cause: TypeScript's exactOptionalPropertyTypes distinguishes between a property that is string | undefined (explicitly set to undefined) vs. a property that is absent (?). The fix was to widen the type to { default?: string | undefined }.
Fix applied: Changed local type annotation to include | undefined in the optional field type.
Improvement opportunities
Missing or undiscoverable schema helpers (s.*)
No missing helpers this run. All needed shapes (s.record, s.optional, s.enum, s.int, s.number, s.path, s.boolean) were available and composed cleanly.
Missing or undiscoverable prompt helpers (p.*)
p.readInput in combination with p.glob is a common pattern but the distinction between p.readInput (caller-supplied path) vs. p.read (known path) wasn't always obvious from the task description alone. A SKILL.md example showing both in the same agent would help.
Error message quality
The exactOptionalPropertyTypes error from --typecheck is clear TypeScript but verbose. A rig-specific lint hint like "use field?: T | undefined with exactOptionalPropertyTypes" in the linting reference would preempt this class of error.
API ergonomics
as const in handler returns: Any defineTool handler that returns a string literal consumed by s.enum output must use as const. This is non-obvious. A note in the composition reference or a lint rule would help.steering() + repair() ordering: The canonical order [steering(), repair()] is documented in SKILL.md but easy to reverse. A lint rule enforcing this order would prevent silent behavioral bugs.
Candidate lint rules
Rule: require-as-const-in-enum-handler
- Invalid:
return "added"; in a handler whose return type feeds an s.enum output field
- Valid:
return "added" as const;
- Why confusing: Without
as const, TypeScript infers string instead of the literal type, causing type mismatch when the output schema uses s.enum.
- Autofix possible: Yes — append
as const to string literal returns in handlers.
Documentation gaps
p.readInput semantics (reads a file whose path comes from agent input) vs. p.read (hardcoded path) could use a side-by-side example in prompt-intents.md.exactOptionalPropertyTypes interaction with optional tool parameter types is not mentioned in any reference file.
Tasks run today
- (reused) Git file ownership mapper — uses p.glob, defineTool with execSync, steering addon
- (reused) GitHub Actions workflow input validator — uses p.glob, async defineTool, repair addon
- (reused) TypeScript dead export finder — uses p.glob + p.bash, async defineTool, steering + repair
- (reused) package.json scripts documenter — uses p.read, defineTool, s.enum category, repair addon
- (reused) Git diff stats summarizer — uses p.bash, defineTool with s.enum, repair addon
- (reused) Dotenv template generator — uses p.readOptional + p.glob, async defineTool, repair addon
- (new) TOML config file key extractor — accepts s.object input, p.readInput, defineTool with regex, repair addon
- (new) CSV column statistics reporter — accepts s.object input, p.readInput, defineTool with numeric analysis, repair addon
- (new) Git worktree listing analyzer — uses p.bash, defineTool with dual s.enum fields, steering addon
- (new) TypeScript type narrowing pattern detector — uses p.glob, async defineTool with readFile + regex, repair addon
Generated by Daily Rig Task Generator · sonnet46 107.2 AIC · ⌖ 9.46 AIC · ⊞ 6.8K · ◷
Summary
execSyncindefineTool,p.globfor discovery,steering()addonexactOptionalPropertyTypesrequiresstring | undefinednot juststring | undefinedon optional field — fixed by widening the local type annotationp.glob+p.bashfor discovery, plussteering()+repair()both presentas constreturn from handler with union type preserved enum contract correctlys.enumon changeType withas constin handler worked cleanlyp.readOptional+p.globcombo — good pattern for "maybe exists" filess.record(s.record(s.string))compiled cleanly;p.readInputused correctlys.optional(s.number)in nested record object — clean output contractas constontypeandstatusfields needed for enum compatibility — applied correctlyp.glob+ asyncdefineToolwithreadFile— well-structuredProblems encountered
Task 2 — exactOptionalPropertyTypes failure
What the code tried to do: Define a local type annotation
{ type: string; required: boolean; default?: string }and assigndefault: defaultM ? defaultM[1].trim() : undefined.Error:
Root cause: TypeScript's
exactOptionalPropertyTypesdistinguishes between a property that isstring | undefined(explicitly set to undefined) vs. a property that is absent (?). The fix was to widen the type to{ default?: string | undefined }.Fix applied: Changed local type annotation to include
| undefinedin the optional field type.Improvement opportunities
Missing or undiscoverable schema helpers (
s.*)No missing helpers this run. All needed shapes (
s.record,s.optional,s.enum,s.int,s.number,s.path,s.boolean) were available and composed cleanly.Missing or undiscoverable prompt helpers (
p.*)p.readInputin combination withp.globis a common pattern but the distinction betweenp.readInput(caller-supplied path) vs.p.read(known path) wasn't always obvious from the task description alone. A SKILL.md example showing both in the same agent would help.Error message quality
The
exactOptionalPropertyTypeserror from--typecheckis clear TypeScript but verbose. A rig-specific lint hint like "usefield?: T | undefinedwith exactOptionalPropertyTypes" in the linting reference would preempt this class of error.API ergonomics
as constin handler returns: AnydefineToolhandler that returns a string literal consumed bys.enumoutput must useas const. This is non-obvious. A note in the composition reference or a lint rule would help.steering()+repair()ordering: The canonical order[steering(), repair()]is documented in SKILL.md but easy to reverse. A lint rule enforcing this order would prevent silent behavioral bugs.Candidate lint rules
Rule:
require-as-const-in-enum-handlerreturn "added";in a handler whose return type feeds ans.enumoutput fieldreturn "added" as const;as const, TypeScript infersstringinstead of the literal type, causing type mismatch when the output schema usess.enum.as constto string literal returns in handlers.Documentation gaps
p.readInputsemantics (reads a file whose path comes from agent input) vs.p.read(hardcoded path) could use a side-by-side example inprompt-intents.md.exactOptionalPropertyTypesinteraction with optional tool parameter types is not mentioned in any reference file.Tasks run today