planning-patterns
Writing Plans
Overview
Write comprehensive implementation plans assuming the engineer has zero context for the codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.
Plans are prompts. The plan will be consumed by an AI agent with zero prior context. Write it as you would write a prompt: specific, complete, unambiguous. If a different agent could misinterpret a step, the step is underspecified.
Assume they are a skilled developer, but know almost nothing about the toolset or problem domain. Assume they don't know good test design very well.
Core principle: Plans must be executable without asking questions.
The Iron Law
NO VAGUE STEPS - EVERY STEP IS A SPECIFIC ACTION
"Add validation" is not a step. "Write test for empty email, run it, implement check, run it, commit" - that's 5 steps.
More from romiluz13/cc10x
session-memory
Internal skill. Use cc10x-router for all development tasks.
60code-generation
Internal skill. Use cc10x-router for all development tasks.
58code-review-patterns
Internal skill. Use cc10x-router for all development tasks.
45architecture-patterns
Internal skill. Use cc10x-router for all development tasks.
44cc10x-router
|
41debugging-patterns
Use when a bug, flaky test, or runtime/build failure needs root-cause tracing and a nearby duplicate-pattern scan before any fix.
35