writing-plans

Generates detailed multi-step implementation plans with exact file paths, code, and test commands.

Updated Apr 4, 2026
One-click install
npx skills add https://github.com/SleyiW/iWana-neXt --skill writing-plans-sleyiw
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: writing-plans
Source: https://github.com/SleyiW/iWana-neXt/tree/main/.agents/skills/writing-plans
Command: npx skills add https://github.com/SleyiW/iWana-neXt --skill writing-plans-sleyiw

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Engineers often start coding from a spec without a clear roadmap, leading to missed requirements, inconsistent types, and vague tasks. This Skill turns a spec or requirements document into a complete, bite-sized implementation plan that an engineer with zero codebase context can execute task by task. ## Core Features & Use Cases - Bite-Sized Task Decomposition: Breaks work into 2-5 minute steps following TDD: write failing test, verify failure, implement, verify pass, commit. - No-Placeholder Enforcement: Every step includes exact file paths, complete code blocks, exact commands, and expected output — no TODOs or vague instructions. - Self-Review Checklist: Validates spec coverage, scans for placeholder patterns, and checks type/name consistency across tasks before saving. - Use Case: Given a feature spec for a new API endpoint, produce a plan saved to docs/plans/ with checkbox-tracked tasks, then hand off to subagent-driven or inline execution. ## Quick Start Use the writing-plans skill to turn this feature spec into a step-by-step implementation plan saved under docs/plans.

Frequently Asked Questions about writing-plans

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write an implementation plan from a feature spec?

Map out the file structure first, then decompose work into tasks with exact file paths, complete code blocks, and test commands. Each step should take 2-5 minutes and follow a TDD cycle: failing test, minimal implementation, passing test, commit.

What makes a good task breakdown for coding plans?

Each task should be self-contained with one clear responsibility, listing files to create or modify with exact paths. Steps must include actual code and expected command output, never placeholders like TODO or 'add error handling'.

When should a spec be split into multiple implementation plans?

Split when the spec covers multiple independent subsystems. Each plan should produce working, testable software on its own, so one plan per subsystem keeps scope manageable and execution verifiable.

How do I verify an implementation plan covers the whole spec?

Run a self-review: check each spec requirement maps to a task, scan for placeholder patterns, and confirm type and method names stay consistent across tasks. Fix issues inline and add tasks for any uncovered requirements.

What are the limitations of plan-driven development?

Plans assume the spec is complete and well-scoped; vague or multi-subsystem specs produce poor plans. They also require discipline to keep code snippets and type names consistent, and very small tasks may not justify a full plan document.