[rig-tasks] Daily rig evaluation — 2026-08-18 — 10/10 passed

[github-actions]

Summary

Task	Description	Typecheck	Key finding
1 (reused)	JSONL File Analyzer	✅ pass	Clean use of defineTool with JSON.parse error handling; s.record for valueTypes
2 (reused)	NPM Peer Dep Checker	✅ pass	Good use of p.read + p.bash combo; s.enum for severity levels
3 (reused)	TS Barrel Module Writer	✅ pass	p.writeOutput for file generation; regex tool for identifier validation
4 (reused)	Git Remote Metadata Inspector	✅ pass	steering() addon + s.record output keyed by remote name
5 (reused)	OS Environment Variable Scanner	✅ pass	p.bash("env") + classification tool; nested s.record(s.object(...)) output
6 (reused)	Sequential Commit Pipeline	✅ pass (after fix)	Workflow body used wrong positional (call, input) → fixed to ({call}) destructuring; meta required
7 (new)	TS Tuple Pattern Extractor	✅ pass (after fix)	const [] type inference on ?? [] fails — explicit string[] annotation required
8 (new)	TS Interface Stub Writer	✅ pass	Good p.writeOutput usage; regex method signature validation in tool
9 (new)	Git Grep Search Workflow	✅ pass (after fix)	Workflow body used wrong (call, input) positional form + missing meta field
10 (new)	JSON Union Type Inferrer	✅ pass	s.array(s.unknown) in tool parameters; inferredType as const for enum safety

---

Problems encountered

Task 6 — Sequential Commit Pipeline (reused)

What it tried: A three-step workflow chaining commitCollector → commitClassifier → commitAggregator.

Error: WorkflowContext<unknown> has no call signatures — the body was written as async (call) => { ... } treating call as the first positional parameter, but body receives a single WorkflowContext object to destructure.

Root cause: The workflow body signature is body(context: WorkflowContext<I>) and call is a property on that context. Using async (call) => ... binds the entire context to the name call.

Fix: Changed to async ({ call }) => { ... } and added required meta field.

Task 7 — TS Tuple Pattern Extractor (new)

What it tried: Used ?? fallback on String.prototype.match() to get an empty array, then .concat().

Error: Type 'RegExpMatchArray | []' is not assignable to parameter of type 'ConcatArray<never>' — TypeScript cannot narrow RegExpMatchArray | [] to string[] because [] is never[].

Root cause: content.match(pattern) ?? [] returns RegExpMatchArray | [] and [] is typed as never[], making the type intersection impossible without annotation.

Fix: Added explicit const tuples: string[] = content.match(pattern) ?? []; annotation.

Task 9 — Git Grep Search Workflow (new)

Error 1: Same workflow body positional arg issue as task 6.

Error 2: Workflow with input schema required WorkflowSpec overload, but TypeScript picked WorkflowWithoutInputSpec — missing meta field caused overload confusion.

Fix: Added meta field and changed to async ({ call, input }) => { ... } destructuring.

---

Improvement opportunities

Missing or undiscoverable schema helpers (s.*)

No missing helpers this run. The existing set (s.record, s.optional, s.unknown, s.enum, s.array, s.int) covered all patterns well.

Missing or undiscoverable prompt helpers (p.*)

p.writeOutput and p.writeInput semantics are subtle — the order of arguments is non-obvious. A clearer example in SKILL.md showing p.writeOutput(outputFieldName, pathFieldName) would reduce confusion.

Error message quality

The error WorkflowContext<unknown> has no call signatures is misleading — the actual problem is destructuring. A more helpful message would be: "Did you mean ({ call }) => instead of (call) =>?"

API ergonomics

The meta field being required on both WorkflowSpec and WorkflowWithoutInputSpec is a common stumbling block. Generated programs consistently omit it on first try. Consider making meta optional with a default (similar to how name defaults on agent()), or documenting the required field prominently in SKILL.md under "workflow construction rules".

The two workflow overloads (WorkflowSpec with input vs WorkflowWithoutInputSpec) make it hard to add input to an existing workflow — TypeScript switches overloads silently and the error messages point to the wrong overload.

Candidate lint rules

Rule: workflow-body-positional-call

• Invalid: body: async (call) => { ... }
• Valid: body: async ({ call }) => { ... }
• Reason: Models consistently treat the context object as a call function. This produces a confusing TS error about WorkflowContext not being callable rather than pointing to the destructuring mistake.
• Autofix: Yes — replace (call) with ({ call }) when call is used as a function in the body.

Documentation gaps

SKILL.md's high-frequency decisions table mentions workflow({ meta, input?, body }) but doesn't show meta as required. The canonical example should include meta or the construction rules should explicitly call it out: "Always include meta: { name, description } on every workflow() call."

---

Tasks run today

• (reused) JSONL file analyzer with defineTool analyzeJsonLine and repair addon
• (reused) NPM peer dependency conflict checker with checkPeerConflict tool and repair addon
• (reused) TypeScript barrel module writer with p.write and validateExportName tool
• (reused) Git remote metadata inspector with classifyRemote tool and steering addon
• (reused) OS environment variable scanner with classifyEnvVar tool and repair addon
• (reused) Sequential workflow subagent pipeline with three chained agents via call()
• (new) TypeScript tuple type pattern extractor with async defineTool and node:fs/promises
• (new) TypeScript interface stub writer with validateMethodSignature tool and p.write
• (new) Git grep code search workflow with two subagents chained via call()
• (new) JSON union type inferrer with inferFieldType tool and s.array(s.unknown)

Generated by Daily Rig Task Generator · sonnet46 134.1 AIC · ⌖ 9.31 AIC · ⊞ 6.8K · ◷