ringpre-dev-subtask-creation

Subtask Creation - Bite-Sized, Zero-Context Steps

Overview

Write comprehensive implementation subtasks assuming the engineer has zero context for our codebase. Each subtask breaks down into 2-5 minute steps following RED-GREEN-REFACTOR. Complete code, exact commands, explicit verification. DRY. YAGNI. TDD. Frequent commits.

Save subtasks to: docs/pre-dev/{feature-name}/subtasks/T-[task-id]/ST-[task-id]-[number]-[description].md

Foundational Principle

Every subtask must be completable by anyone with zero context about the system.

Requiring context creates bottlenecks, onboarding friction, and integration failures.

Subtasks answer: Exactly what to create/modify, with complete code and verification. Subtasks never answer: Why the system works this way (context is removed).

Bite-Sized Step Granularity

Each step is one action (2-5 minutes):

• "Write the failing test" - step
• "Run it to make sure it fails" - step
• "Implement the minimal code to make the test pass" - step
• "Run the tests and make sure they pass" - step
• "Commit" - step

Subtask Document Structure

Header (required):

Step Structure (TDD Cycle):

Explicit Rules

✅ DO Include in Subtasks

Exact file paths (absolute or from root), complete file contents (if creating), complete code snippets (if modifying), all imports and dependencies, step-by-step TDD cycle (numbered), verification commands (copy-pasteable), expected output (exact), rollback procedures (exact commands), prerequisites (what must exist first)

❌ NEVER Include in Subtasks

Placeholders: "...", "TODO", "implement here"; vague instructions: "update the service", "add validation"; assumptions: "assuming setup is done"; context requirements: "you need to understand X first"; incomplete code: "add the rest yourself"; missing imports: "import necessary packages"; undefined success: "make sure it works"; no verification: "test it manually"

Rationalization Table

Red Flags - STOP

If you catch yourself writing any of these in a subtask, STOP and rewrite:

• Code placeholders: ..., // TODO, // implement X here
• Vague file references: "the user service", "the auth module"
• Assumption phrases: "assuming you have", "make sure you"
• Incomplete imports: "import required packages"
• Missing paths: Not specifying where files go
• Undefined verification: "test that it works"
• Steps longer than 5 minutes
• Context dependencies: "you need to understand X"
• No TDD cycle in implementation steps

When you catch yourself: Expand the subtask until it's completely self-contained.

Gate 8 Validation Checklist

Gate Result: ✅ PASS → Ready for implementation | ⚠️ CONDITIONAL (add details) | ❌ FAIL (decompose further)

Confidence Scoring

Action: 80+ autonomous | 50-79 present options | <50 ask about structure

Execution Handoff

After creating subtasks, offer execution choice:

"Subtasks complete. Two execution options:

1. Subagent-Driven - Fresh subagent per subtask, review between, fast iteration → Use ring:subagent-driven-development
2. Parallel Session - New session with ring:executing-plans, batch with checkpoints → Use ring:executing-plans

Which approach?"

The Bottom Line

If you wrote a subtask with "TODO" or "..." or "add necessary imports", delete it and rewrite with complete code.

Subtasks are not instructions. Subtasks are complete, copy-pasteable implementations following TDD.

• "Add validation" is not a step. [Complete validation code with test] is a step.
• "Update the service" is not a step. [Exact file path + exact code changes with test] is a step.
• "Import necessary packages" is not a step. [Complete list of imports] is a step.

Every subtask must be completable by someone who:

• Just joined the team yesterday
• Has never seen the codebase before
• Doesn't know the business domain
• Won't ask questions (you're unavailable)
• Follows TDD religiously

If they can't complete it with zero questions while following RED-GREEN-REFACTOR, it's not atomic enough.

Remember: DRY. YAGNI. TDD. Frequent commits.