The writing-plans Skill — Complete Plans for Engineers With Zero Codebase Context
How the writing-plans skill structures implementation plans as bite-sized TDD tasks with exact file paths, complete code, and expected command output — so an engineer with no prior context can execute without guessing.
An implementation plan that says "add appropriate error handling" or "write tests for the above" is not a plan — it is a list of decisions deferred to the person executing it. The writing-plans skill defines how plans must be written: complete code in every step, exact file paths, exact commands with expected output, and no placeholders.
The target audience for a plan written under this skill is an engineer who is a skilled developer but knows almost nothing about the specific codebase or problem domain. The plan carries everything they need, including test design, because that assumption cannot be made either.
Structure before tasks
Before any task list, the plan maps out file structure: which files will be created or modified, and what each one is responsible for. This is where decomposition decisions lock in. Each file should have one clear responsibility. Files that change together should live together — splits happen by responsibility, not by technical layer. In an existing codebase, the plan follows established patterns rather than restructuring them unilaterally.
If the spec covers multiple independent subsystems that were not broken apart during brainstorming, the skill flags this and suggests splitting into separate plans. Each plan should produce working, testable software on its own.
Bite-sized task granularity
Each step in a task is one action, sized at two to five minutes: "write the failing test," "run it to make sure it fails," "implement the minimal code to make the test pass," "run the tests," "commit." The TDD red-green cycle is not described in prose — it is shown as concrete commands with expected output. An engineer reading tasks out of order must get everything they need from that task alone, so repeated context is not a problem: it is a requirement.
Every plan starts with a fixed header: feature name, goal in one sentence, architecture in two to three sentences, and tech stack. Agentic workers receive an explicit instruction in that header to use the subagent-driven-development or executing-plans skill for execution.
Self-review and handoff
After writing the complete plan, the skill requires a self-review pass with three checks: spec coverage (can every requirement be pointed to a task?), a placeholder scan for any of the forbidden patterns, and type consistency (do method signatures in later tasks match what earlier tasks defined?). Any gap found gets fixed inline — no separate review dispatch for short plans under five tasks.
Plans for Datarim-managed projects save to datarim/plans/<TASK-ID>-plan.md. For other projects, the path follows project conventions or is proposed and confirmed before writing. After saving, the skill offers an execution choice: subagent-driven (a fresh agent per task with review between tasks) or inline execution with checkpoints.
Read what Datarim is for broader context, or see the writing skill for how prose content follows a parallel pipeline.