Summary
| Task |
Description |
Kind |
Typecheck |
Key finding |
| 1 (reused) |
Git blame line age analyzer |
agent |
✅ pass |
defineTool + p.glob + s.record output; used node:child_process execSync cleanly |
| 2 (reused) |
TS mapped type extractor |
agent |
✅ pass |
Regex for { [K in ...] } patterns with isReadonly detection; steering() addon |
| 3 (reused) |
Dotenv drift detector |
agent |
✅ pass |
p.readOptional + p.bash grep combination; s.enum("declared","undeclared","unused") classification |
| 4 (reused) |
Vitest snapshot reporter workflow |
workflow |
✅ pass (after fix) |
Initial failure: missing description in WorkflowMeta and output field not valid on workflow(); call() returns T|null requiring filter guard |
| 5 (reused) |
Git stale branch reporter |
agent |
✅ pass |
defineTool with execSync per branch; s.enum("fresh","recent","stale","ancient") age bucketing |
| 6 (reused) |
TS abstract class finder |
agent |
✅ pass |
Regex for abstract class + abstract method patterns; steering() addon |
| 7 (new) |
Git tag message extractor |
agent |
✅ pass |
defineTool + git cat-file tag; s.enum("annotated","lightweight") classification |
| 8 (new) |
Parallel dep audit workflow |
workflow |
✅ pass (after fix) |
Same WorkflowMeta.description required error + output field; null guards needed after Promise.all |
| 9 (new) |
TS union type writer |
agent |
✅ pass |
p.writeInput for dynamic output path; input schema with s.path typed outputFile |
| 10 (new) |
JSON schema field classifier |
agent |
✅ pass (after fix) |
Initial failure: schema.properties accessed via dot notation triggering TS4111 (index signature access); fixed to schema["properties"] |
Problems encountered
Task 4 & 8 — Workflow API misuse (initial failure)
What the code tried to do: Both workflow programs passed an output schema field to workflow() and used meta: { name } without description.
Errors:
error TS2769: No overload matches this call.
Property 'description' is missing in type '{ name: string; }' but required in type 'WorkflowMeta'.
error TS2769: Object literal may only specify known properties, and 'output' does not exist in type 'WorkflowWithoutInputSpec<...>'.
error TS18047: 'result' is possibly 'null'.
Root cause: WorkflowMeta requires both name and description. The workflow() function does not accept an output field — the return type is inferred from the body. Additionally, call() returns T | null, so array operations after Promise.all need a .filter() null guard before reduce().
Fix applied: Added description to meta, removed output from workflow() spec, added if (!result) return null guards, and used type predicate filter((r): r is T => r !== null).
Task 10 — Index signature access (initial failure)
Error:
error TS4111: Property 'properties' comes from an index signature, so it must be accessed with ['properties'].
Root cause: JSON.parse returns any, but the typed cast Record<string, unknown> triggers noPropertyAccessFromIndexSignature for dot-notation access on index signatures.
Fix applied: Changed schema.properties → schema["properties"].
Improvement opportunities
Missing or undiscoverable schema helpers (s.*)
- No issues this run.
s.enum, s.optional, s.record, s.path, s.int, s.boolean all worked as expected.
Missing or undiscoverable prompt helpers (p.*)
p.writeInput was used correctly but its documentation is subtle — the first arg is the input field name holding the path, not the path itself. A clearer name like p.writeToInputPath would be more self-documenting.
Error message quality
- The TS2769 overload error for
workflow() with output present is unhelpful — it dumps inferred types rather than saying "workflow() does not accept an output field; output type is inferred from the body return type." A dedicated diagnostic or JSDoc @deprecated-style annotation would help.
WorkflowMeta missing description is clear from the TS2769 message, but since name alone seems sufficient conceptually, it surprises model-generated code repeatedly.
API ergonomics
workflow() output inference vs explicit: Every generated workflow tries to pass output: to workflow(). An explicit output parameter (even if optional and only used for documentation/validation) would eliminate this recurring error class.
WorkflowMeta.description required: Consider making description optional (with a lint warning if absent) rather than a hard type error. The pattern meta: { name: "..." } is natural and fails silently confusingly.
call() returns T | null: Every workflow body needs null guards. A callOrThrow() variant that throws on null would reduce boilerplate in happy-path workflows.
Candidate lint rules
Rule: workflow-no-output-field
- Invalid:
workflow({ meta, body, output: s.object({...}) })
- Valid:
workflow({ meta, body }) — output inferred from body
- Why model-confusing:
agent() accepts output, so by analogy workflow() should too. The error message doesn't hint at the root cause.
- Autofix: Remove the
output field from workflow() call.
Rule: workflow-meta-requires-description
- Invalid:
meta: { name: "foo" }
- Valid:
meta: { name: "foo", description: "..." }
- Why model-confusing:
name alone looks complete; description requirement is not obvious from usage patterns.
- Autofix: Insert a placeholder
description: "" (not safe — better as a warning only).
Documentation gaps
- SKILL.md mentions
workflow({ meta, input?, body }) but doesn't call out that output is not a valid workflow field. Adding a negative example would prevent the recurring error.
- The
WorkflowMeta required fields (name, description) should appear in the SKILL.md decision table or canonical workflow example.
call() returning T | null is mentioned in composition.md but not reinforced in SKILL.md's workflow pattern — add a note that if (!result) return null is the standard guard pattern.
Tasks run today
- (reused) Git blame line age analyzer
- (reused) TypeScript mapped type extractor
- (reused) dotenv vs process.env drift detector
- (reused) Vitest snapshot count reporter workflow
- (reused) Git stale branch age reporter
- (reused) TypeScript abstract class finder
- (new) Git tag message extractor
- (new) Parallel dependency audit workflow
- (new) TypeScript union type writer
- (new) JSON schema field classifier
Generated by Daily Rig Task Generator · sonnet46 167.8 AIC · ⌖ 10.2 AIC · ⊞ 6.8K · ◷
Summary
defineTool+p.glob+s.recordoutput; usednode:child_processexecSynccleanly{ [K in ...] }patterns withisReadonlydetection;steering()addonp.readOptional+p.bashgrep combination;s.enum("declared","undeclared","unused")classificationdescriptioninWorkflowMetaandoutputfield not valid onworkflow();call()returnsT|nullrequiring filter guarddefineToolwithexecSyncper branch;s.enum("fresh","recent","stale","ancient")age bucketingabstract class+abstract methodpatterns;steering()addondefineTool+git cat-file tag;s.enum("annotated","lightweight")classificationWorkflowMeta.descriptionrequired error +outputfield; null guards needed afterPromise.allp.writeInputfor dynamic output path;inputschema withs.pathtypedoutputFileschema.propertiesaccessed via dot notation triggering TS4111 (index signature access); fixed toschema["properties"]Problems encountered
Task 4 & 8 — Workflow API misuse (initial failure)
What the code tried to do: Both workflow programs passed an
outputschema field toworkflow()and usedmeta: { name }withoutdescription.Errors:
Root cause:
WorkflowMetarequires bothnameanddescription. Theworkflow()function does not accept anoutputfield — the return type is inferred from the body. Additionally,call()returnsT | null, so array operations afterPromise.allneed a.filter()null guard beforereduce().Fix applied: Added
descriptiontometa, removedoutputfromworkflow()spec, addedif (!result) return nullguards, and used type predicatefilter((r): r is T => r !== null).Task 10 — Index signature access (initial failure)
Error:
Root cause:
JSON.parsereturnsany, but the typed castRecord<string, unknown>triggersnoPropertyAccessFromIndexSignaturefor dot-notation access on index signatures.Fix applied: Changed
schema.properties→schema["properties"].Improvement opportunities
Missing or undiscoverable schema helpers (
s.*)s.enum,s.optional,s.record,s.path,s.int,s.booleanall worked as expected.Missing or undiscoverable prompt helpers (
p.*)p.writeInputwas used correctly but its documentation is subtle — the first arg is the input field name holding the path, not the path itself. A clearer name likep.writeToInputPathwould be more self-documenting.Error message quality
workflow()withoutputpresent is unhelpful — it dumps inferred types rather than saying "workflow() does not accept anoutputfield; output type is inferred from the body return type." A dedicated diagnostic or JSDoc@deprecated-style annotation would help.WorkflowMetamissingdescriptionis clear from the TS2769 message, but sincenamealone seems sufficient conceptually, it surprises model-generated code repeatedly.API ergonomics
workflow()output inference vs explicit: Every generated workflow tries to passoutput:toworkflow(). An explicitoutputparameter (even if optional and only used for documentation/validation) would eliminate this recurring error class.WorkflowMeta.descriptionrequired: Consider makingdescriptionoptional (with a lint warning if absent) rather than a hard type error. The patternmeta: { name: "..." }is natural and fails silently confusingly.call()returnsT | null: Every workflow body needs null guards. AcallOrThrow()variant that throws on null would reduce boilerplate in happy-path workflows.Candidate lint rules
Rule:
workflow-no-output-fieldworkflow({ meta, body, output: s.object({...}) })workflow({ meta, body })— output inferred from bodyagent()acceptsoutput, so by analogyworkflow()should too. The error message doesn't hint at the root cause.outputfield fromworkflow()call.Rule:
workflow-meta-requires-descriptionmeta: { name: "foo" }meta: { name: "foo", description: "..." }namealone looks complete;descriptionrequirement is not obvious from usage patterns.description: ""(not safe — better as a warning only).Documentation gaps
workflow({ meta, input?, body })but doesn't call out thatoutputis not a valid workflow field. Adding a negative example would prevent the recurring error.WorkflowMetarequired fields (name,description) should appear in the SKILL.md decision table or canonical workflow example.call()returningT | nullis mentioned in composition.md but not reinforced in SKILL.md's workflow pattern — add a note thatif (!result) return nullis the standard guard pattern.Tasks run today