Gate 8: Zero-context implementation steps - 2-5 minute atomic subtasks with complete code, exact commands, TDD pattern. Large Track only.
Creates atomic TDD subtasks with complete code and verification commands for zero-context implementation.
npx claudepluginhub lerianstudio/ringThis skill inherits all available tools. When active, it can use any tool Claude has access to.
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
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).
Each step is one action (2-5 minutes):
Header (required):
| Field | Content |
|---|---|
| Title | # ST-[task-id]-[number]: [Subtask Name] |
| Agent Note | > **For Agents:** REQUIRED SUB-SKILL: Use ring:executing-plans |
| Goal | One sentence describing what this builds |
| Prerequisites | Verification commands with expected output |
| Files | Create: exact/path, Modify: exact/path:lines, Test: tests/path |
Step Structure (TDD Cycle):
| Step | Content |
|---|---|
| Step 1: Write failing test | Complete test file with imports |
| Step 2: Run test to verify fail | Command + expected failure output |
| Step 3: Write minimal implementation | Complete implementation file |
| Step 4: Run test to verify pass | Command + expected success output |
| Step 5: Update exports (if needed) | Exact modification to index files |
| Step 6: Verify type checking | Command + expected output |
| Step 7: Commit | Exact git commands with message |
| Rollback | Exact commands to undo if issues |
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)
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"
<cannot_skip>
MUST: For Go projects, code examples use lib-commons instead of custom utilities.
See shared-patterns/code-example-standards.md for:
lib prefix aliasesQuick Reference - DO NOT Create Custom:
| Category | Use lib-commons |
|---|---|
| Logging | libLog "github.com/LerianStudio/lib-commons/v2/commons/log" |
| Config | libCommons.SetConfigFromEnvVars() |
| HTTP | libHTTP "github.com/LerianStudio/lib-commons/v2/commons/net/http" |
| Telemetry | libOpentelemetry "github.com/LerianStudio/lib-commons/v2/commons/opentelemetry" |
| PostgreSQL | libPostgres "github.com/LerianStudio/lib-commons/v2/commons/postgres" |
MUST NOT: Create custom logger, config loader, or HTTP helper in subtasks—use lib-commons.
</cannot_skip>
| Excuse | Reality |
|---|---|
| "The developer will figure out imports" | Imports are context. Provide them explicitly. |
| "TODO comments are fine for simple parts" | TODOs require decisions. Make them now. |
| "They'll know which service to update" | They won't. Specify the exact file path. |
| "The verification steps are obvious" | Obvious ≠ documented. Write exact commands. |
| "Rollback isn't needed for simple changes" | Simple changes fail too. Always provide rollback. |
| "This needs system understanding" | Then you haven't removed context. Simplify more. |
| "I'll provide the template, they fill it" | Templates are incomplete. Provide full code. |
| "The subtask description explains it" | Descriptions need interpretation. Give exact steps. |
| "They can look at similar code for reference" | That's context. Make subtask self-contained. |
| "This is too detailed, we're not that formal" | Detailed = parallelizable = faster. Be detailed. |
| "Steps are too small, feels like hand-holding" | Small steps = verifiable progress. Stay small. |
| "Custom logger is simpler for this example" | Examples teach patterns. Teach lib-commons. |
| "lib-commons import is too verbose" | Verbosity shows correct dependencies. Keep it. |
| "I'll use lib-commons in the real code" | Subtask is real code. Use lib-commons now. |
If you catch yourself writing any of these in a subtask, STOP and rewrite:
..., // TODO, // implement X herelibZap.NewLogger() instead of custom func NewLogger() (Go)libCommons.SetConfigFromEnvVars() instead of scattered os.Getenv() (Go)libHTTP utilities instead of custom func JSONResponse() (Go)utils/, helpers/, pkg/common/ (Go)When you catch yourself: Expand the subtask until it's completely self-contained.
| Category | Requirements |
|---|---|
| Atomicity | Each step 2-5 minutes; no system architecture understanding required; assignable to anyone |
| Completeness | All code provided in full; all file paths explicit; all imports listed; all prerequisites documented; TDD cycle followed |
| Verifiability | Test commands copy-pasteable; expected output exact; commands run from project root |
| Reversibility | Rollback commands provided; rollback doesn't require system knowledge |
Gate Result: ✅ PASS → Ready for implementation | ⚠️ CONDITIONAL (add details) | ❌ FAIL (decompose further)
| Factor | Points | Criteria |
|---|---|---|
| Step Atomicity | 0-30 | All 2-5 minutes: 30, Most sized right: 20, Too large/vague: 10 |
| Code Completeness | 0-30 | Zero placeholders: 30, Mostly complete: 15, Significant TODOs: 5 |
| Context Independence | 0-25 | Anyone can execute: 25, Minor context: 15, Significant knowledge: 5 |
| TDD Coverage | 0-15 | All RED-GREEN-REFACTOR: 15, Most have tests: 10, Limited: 5 |
Action: 80+ autonomous | 50-79 present options | <50 ask about structure
After creating subtasks, offer execution choice:
"Subtasks complete. Two execution options:
ring:subagent-driven-developmentring:executing-plansWhich approach?"
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.
Every subtask must be completable by someone who:
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.
This skill creates implementation subtasks. While it does NOT require direct WebFetch of standards, subtasks MUST reference lib-commons patterns for Go projects.
For Go projects: All code examples in subtasks MUST use lib-commons imports. See shared-patterns/code-example-standards.md for required patterns.
HARD GATE: Subtasks with custom logger, config loader, or HTTP helper implementations are INVALID. Use lib-commons.
| Condition | Action | Severity |
|---|---|---|
| Tasks (Gate 7) not validated | STOP and complete Gate 7 first | CRITICAL |
| Subtask contains TODO or placeholder | STOP and expand with complete code | HIGH |
| Subtask requires context not provided | STOP and add missing context to subtask | HIGH |
| Step exceeds 5 minutes | STOP and break into smaller steps | MEDIUM |
| Missing TDD cycle (no RED phase) | STOP and add failing test first | HIGH |
| Go subtask uses custom logger instead of lib-commons | STOP and replace with lib-commons | HIGH |
These requirements are NON-NEGOTIABLE:
| Severity | Definition | Example |
|---|---|---|
| CRITICAL | Subtask cannot be executed | Missing prerequisite, no file paths |
| HIGH | Subtask requires interpretation | TODO placeholder, vague description |
| MEDIUM | Subtask quality degraded | Missing verification command |
| LOW | Minor documentation gaps | Rollback could be more detailed |
| User Says | Your Response |
|---|---|
| "Developer will figure out imports" | "Cannot assume imports. Imports ARE context. I'll provide explicit import statements." |
| "TODO comments are fine for simple parts" | "Cannot use TODOs. TODOs require decisions. I'll make those decisions now and provide complete code." |
| "Steps are too detailed, feels like hand-holding" | "Cannot reduce detail. Small steps = verifiable progress. Detail enables parallelization." |
| "Skip TDD for this simple change" | "Cannot skip TDD. Every subtask follows RED-GREEN-REFACTOR. I'll write the failing test first." |
| "Custom logger is simpler for this example" | "Cannot use custom logger. Subtasks teach patterns. lib-commons is the pattern." |
Search, retrieve, and install Agent Skills from the prompts.chat registry using MCP tools. Use when the user asks to find skills, browse skill catalogs, install a skill for Claude, or extend Claude's capabilities with reusable AI agent components.
Activates when the user asks about AI prompts, needs prompt templates, wants to search for prompts, or mentions prompts.chat. Use for discovering, retrieving, and improving prompts.
This skill should be used when the user asks to "create an agent", "add an agent", "write a subagent", "agent frontmatter", "when to use description", "agent examples", "agent tools", "agent colors", "autonomous agent", or needs guidance on agent structure, system prompts, triggering conditions, or agent development best practices for Claude Code plugins.