fix: Increase detail agent task sizing to reduce tiny-task overhead
Each execute agent has significant startup cost (context loading, codebase exploration, baseline tests). The previous sizing guidance (sweet spot <150 lines, 1-3 files, merge at <20 lines) produced tasks too small to justify that overhead. New guidance targets cohesive feature units: 200-500 lines across 3-6 files as the sweet spot, merge threshold at <100 lines, and explicit instruction to bundle related changes (validation + route + tests = one task, not three).
This commit is contained in:
@@ -32,23 +32,39 @@ Every task body must include:
|
||||
4. **Verification command** — exact command to confirm completion
|
||||
|
||||
<examples>
|
||||
<example label="bad">
|
||||
<example label="bad — too vague">
|
||||
Title: Add user validation
|
||||
Body: Add validation to the user model. Make sure all fields are validated properly.
|
||||
</example>
|
||||
<example label="good">
|
||||
<example label="bad — too small (would be ~40 lines, not worth agent overhead)">
|
||||
Title: Add Zod validation schema for user creation
|
||||
Body: Create \`src/api/validators/user.ts\` — Zod schema for CreateUserInput:
|
||||
- email: valid format, lowercase, max 255 chars
|
||||
- name: 1-100 chars, trimmed
|
||||
- password: min 8 chars, uppercase + number required
|
||||
Body: Create \`src/api/validators/user.ts\` — Zod schema for CreateUserInput.
|
||||
Files: src/api/validators/user.ts (create)
|
||||
</example>
|
||||
<example label="good — cohesive feature unit">
|
||||
Title: Add user creation API endpoint with validation and tests
|
||||
Body: Implement the complete user creation flow:
|
||||
|
||||
Test file: \`src/api/validators/user.test.ts\`
|
||||
Tests: valid input passes, missing fields rejected, invalid email rejected,
|
||||
weak password rejected, whitespace-only name rejected
|
||||
**Validation** — Create \`src/api/validators/user.ts\`:
|
||||
- Zod schema for CreateUserInput: email (valid format, lowercase, max 255), name (1-100 chars, trimmed), password (min 8, uppercase + number required)
|
||||
- Export \`validateCreateUser()\` wrapper that returns typed result
|
||||
|
||||
Files: src/api/validators/user.ts (create), user.test.ts (create)
|
||||
Verify: \`npm test -- src/api/validators/user.test.ts\`
|
||||
**Repository** — Create \`src/db/repositories/user-repository.ts\`:
|
||||
- \`createUser(input: CreateUserInput): Promise<User>\` — insert with bcrypt-hashed password
|
||||
- \`findByEmail(email: string): Promise<User | null>\` — for duplicate checking
|
||||
|
||||
**API Route** — Create \`src/api/routes/users.ts\`:
|
||||
- POST /api/users — validate input, check email uniqueness (409 if duplicate), create user, return 201 with user (no password)
|
||||
- Wire into existing Express router in \`src/api/index.ts\`
|
||||
|
||||
**Tests** — Create \`src/api/routes/users.test.ts\`:
|
||||
- Happy path: valid input → 201 + user object without password field
|
||||
- Validation: missing fields → 400, invalid email → 400, weak password → 400
|
||||
- Duplicate: existing email → 409
|
||||
- Edge cases: whitespace-only name → 400, email case normalization
|
||||
|
||||
Files: src/api/validators/user.ts (create), src/db/repositories/user-repository.ts (create), src/api/routes/users.ts (create), src/api/routes/users.test.ts (create), src/api/index.ts (modify)
|
||||
Verify: \`npm test -- src/api/routes/users.test.ts\`
|
||||
</example>
|
||||
</examples>
|
||||
</task_body_requirements>
|
||||
@@ -63,11 +79,17 @@ Tasks with no dependencies run in parallel. Add a dependency when one task needs
|
||||
</file_ownership>
|
||||
|
||||
<task_sizing>
|
||||
- **<150 lines, 1-3 files**: Sweet spot
|
||||
- **150-300 lines, 4-5 files**: Only for mechanical/boilerplate work with precise specs
|
||||
- **300+ lines or 5+ files**: Split it
|
||||
- **<20 lines**: Merge with a related task
|
||||
Each task is handled by a separate agent that must load the full codebase context, read input files, explore patterns, and run tests — significant overhead per task. Size tasks to justify that cost.
|
||||
|
||||
**Target: cohesive feature units, not atomic file operations.**
|
||||
|
||||
- **Sweet spot: 200-500 lines, 3-6 files** — a complete vertical slice (e.g., schema + repository + route + validation + tests)
|
||||
- **Acceptable: 500-800 lines, 6-8 files** — larger features with clear scope and precise specs
|
||||
- **Split when: 800+ lines or 8+ files** — genuinely independent subfeatures
|
||||
- **Merge when: <100 lines or single-file changes** — fold into a related task; a standalone 30-line config tweak doesn't justify agent startup
|
||||
- **1 sentence description**: Too vague — add detail or merge
|
||||
|
||||
Bundle related changes into one task. "Add user validation" + "Add user API route" + "Add user route tests" is ONE task ("Add user creation endpoint with validation and tests"), not three.
|
||||
</task_sizing>
|
||||
|
||||
<checkpoint_tasks>
|
||||
@@ -92,7 +114,7 @@ Before signal.json "done":
|
||||
- [ ] Every task has a file ownership list
|
||||
- [ ] No parallel tasks share files
|
||||
- [ ] Every task is executable without clarifying questions
|
||||
- [ ] Tasks sized within ~20-300 lines changed
|
||||
- [ ] Tasks sized within ~100-800 lines changed (no single-file throwaway tasks)
|
||||
- [ ] No duplicates with existing context tasks
|
||||
</definition_of_done>`;
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user