home / skills / mosif16 / codex-skills / writing-plans

writing-plans skill

/skills/writing-plans

This skill generates comprehensive implementation plans with exact file paths, code samples, tests, and verification steps for engineers with zero context.

npx playbooks add skill mosif16/codex-skills --skill writing-plans

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
3.4 KB
---
name: writing-plans
description: Use when design is complete and you need detailed implementation tasks for engineers with zero codebase context - creates comprehensive implementation plans with exact file paths, complete code examples, and verification steps assuming engineer has minimal domain knowledge
---

# Writing Plans

## Overview

Write comprehensive implementation plans assuming the engineer has zero context for our 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.

Assume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.

**Announce at start:** "I'm using the writing-plans skill to create the implementation plan."

**Context:** This should be run in a dedicated worktree (created by brainstorming skill).

**Save plans to:** `docs/plans/YYYY-MM-DD-<feature-name>.md`

## Bite-Sized Task 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

## Plan Document Header

**Every plan MUST start with this header:**

```markdown
# [Feature Name] Implementation Plan

> **For Claude:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task.

**Goal:** [One sentence describing what this builds]

**Architecture:** [2-3 sentences about approach]

**Tech Stack:** [Key technologies/libraries]

---
```

## Task Structure

```markdown
### Task N: [Component Name]

**Files:**
- Create: `exact/path/to/file.py`
- Modify: `exact/path/to/existing.py:123-145`
- Test: `tests/exact/path/to/test.py`

**Step 1: Write the failing test**

```python
def test_specific_behavior():
    result = function(input)
    assert result == expected
```

**Step 2: Run test to verify it fails**

Run: `pytest tests/path/test.py::test_name -v`
Expected: FAIL with "function not defined"

**Step 3: Write minimal implementation**

```python
def function(input):
    return expected
```

**Step 4: Run test to verify it passes**

Run: `pytest tests/path/test.py::test_name -v`
Expected: PASS

**Step 5: Commit**

```bash
git add tests/path/test.py src/path/file.py
git commit -m "feat: add specific feature"
```
```

## Remember
- Exact file paths always
- Complete code in plan (not "add validation")
- Exact commands with expected output
- Reference relevant skills with @ syntax
- DRY, YAGNI, TDD, frequent commits

## Execution Handoff

After saving the plan, offer execution choice:

**"Plan complete and saved to `docs/plans/<filename>.md`. Two execution options:**

**1. Subagent-Driven (this session)** - I dispatch fresh subagent per task, review between tasks, fast iteration

**2. Parallel Session (separate)** - Open new session with executing-plans, batch execution with checkpoints

**Which approach?"**

**If Subagent-Driven chosen:**
- **REQUIRED SUB-SKILL:** Use superpowers:subagent-driven-development
- Stay in this session
- Fresh subagent per task + code review

**If Parallel Session chosen:**
- Guide them to open new session in worktree
- **REQUIRED SUB-SKILL:** New session uses superpowers:executing-plans

Overview

This skill creates complete, bite-sized implementation plans for engineers who have zero context about the codebase. It produces step-by-step tasks with exact file paths, full code examples, test commands, and expected outputs so an engineer can implement features safely. Plans are tailored for Rust projects and saved to docs/plans/YYYY-MM-DD-<feature-name>.md.

How this skill works

I'm using the writing-plans skill to create the implementation plan. The skill breaks a feature into tiny TDD-driven tasks (2–5 minutes each), lists which files to create or modify, supplies complete code snippets, test commands with expected results, and exact git commit commands. It assumes the implementer knows programming but not the toolset or domain; instructions avoid assumptions and include verification steps and doc locations.

When to use it

  • Design is finished and you need executable implementation steps for engineers with no repo context
  • Hiring contractors or rotating team members into a feature quickly
  • Preparing a handoff to an engineer unfamiliar with Rust or the project
  • When you want strict TDD, small commits, and reproducible verification
  • Creating audit-ready development plans for critical features

Best practices

  • Start the plan with the required header and save to docs/plans/YYYY-MM-DD-<feature-name>.md
  • Make each step one atomic action: write failing test, run, implement minimal code, run, commit
  • Always include exact file paths (create/modify/test) and full code examples — no placeholders
  • Prefer minimal implementations (YAGNI) and repeatable test commands with expected output
  • DRY task descriptions and reference required sub-skills (e.g., superpowers:executing-plans) when handing off execution

Example use cases

  • Add a new serialization layer: plan includes src/serial/mod.rs, tests/serial/test_basic.rs, and cargo test commands with expected output
  • Implement feature flag evaluation: tasks create src/flags.rs, unit tests, example config file, and stepwise commits
  • Migrate a struct to serde derive: specify exact file edits, full before/after code, tests to run, and git history steps
  • Introduce an API endpoint in a Rust service: list handler file, integration test, cargo run instructions, and verification curl commands

FAQ

Where is the plan file saved?

Plans are saved to docs/plans/YYYY-MM-DD-<feature-name>.md using the exact filename you declare at plan creation.

Must I follow TDD order?

Yes. Each task must be written as a failing test first, then minimal implementation, then verification and commit.

How granular should tasks be?

Each task should be a single action that takes ~2–5 minutes: write one test, run it, implement minimal code, run tests, commit.