feat: add batch task creation to TaskCreate tool

[v2nic]

Summary

Extend TaskCreate to support batch creation via an optional batch array parameter. The existing subject/description scalar parameters remain fully backward-compatible. Creates multiple tasks in a single atomic tool call — no new tool definition added to the LLM's context window.

Motivation

When an LLM needs to create several tasks upfront, calling TaskCreate N times means N sequential tool-use round-trips, wasting context and time. A batch primitive solves this — Claude Code ships batch creation for exactly this reason.

Rather than adding a new TaskCreateMany tool (which would bloat the context with an 8th tool definition), this PR adds a batch array parameter to the existing TaskCreate tool. The LLM only needs one tool for creating tasks, regardless of count.

See PR #18 (separate TaskCreateMany tool, open) and PR #16 (batch mutations, closed without merge) for prior approaches. No maintainer comments on either.

Changes

• src/task-store.ts — Add createMany(items) method: creates multiple tasks inside a single withLock call, assigning sequential IDs
• src/index.ts — Add batch array parameter to TaskCreate (mutually exclusive with subject/description). Make subject and description optional. Add prompt guideline for batch preference. Add validation for mixed-mode and missing-field errors.
• README.md — Updated TaskCreate section with expanded parameter tables for single and batch modes, example JSON, and output format
• test/task-store.test.ts — 6 new tests for createMany (sequential IDs, pending status, metadata, ID counter continuation, empty array, file persistence)
• test/subagent-integration.test.ts — 10 new tests for TaskCreate batch mode (batch creation, TaskList integration, agentType, backward compat, mixed-mode rejection, missing-field rejection, singular wording, atomic appearance)

Design decisions

1. Modify existing tool vs. add new tool — Modifying TaskCreate avoids adding an 8th tool definition to the LLM's context window. The tool description already says "create a structured task list" which naturally encompasses batch creation.

2. batch instead of tasks — The parameter is named batch rather than tasks for discoverability and searchability. tasks is too generic and easy to confuse with the concept of tasks; batch clearly signals the batch-creation feature.

3. Mutual exclusivity — Using both batch and subject/description together returns an error. This keeps the schema unambiguous.

4. Atomic creation — Batch tasks are created inside a single withLock call, ensuring consistency in file-backed mode (no partial writes when multiple sessions create tasks concurrently).

5. No dependency wiring in create — Dependencies should be wired up via TaskUpdate after creation. Keeping TaskCreate focused on creation only keeps the tool schema simple.

[v2nic]

👋 CI shows action_required — this is the default GitHub policy for first-time external contributors. Could you approve the workflow run so CI can execute? All checks pass locally (164 tests, typecheck, lint clean).

[tintinweb]

starting a discussion here: #25 (comment)

[v2nic]

Rebased this branch onto tintinweb master (v0.8.0, 86a559c) — merge conflicts resolved and the branch now fast-forwards cleanly. Verified locally: typecheck clean, lint clean, 362 tests passing, build clean. CI shows action_required (first-time contributor policy); please approve the workflow run when you get a chance.

[v2nic]

Closing this in favor of a simpler approach: instead of a batch parameter on TaskCreate, the tool description will steer the model to issue multiple TaskCreate calls in a single response — pi already executes independent tool calls in parallel (verified empirically), so the model can batch-create tasks without any API change. A replacement PR with the description-only change is coming.