writing-plans

Generates bite-sized TDD implementation plans from specs for multi-step coding tasks.

Updated Aug 26, 2026
One-click install
npx skills add https://github.com/danieliudi/trackforge-os --skill writing-plans-danieliudi
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: writing-plans
Source: https://github.com/danieliudi/trackforge-os/tree/main/.cursor/skills/writing-plans
Command: npx skills add https://github.com/danieliudi/trackforge-os --skill writing-plans-danieliudi

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Turning a spec or requirements document into working code often fails because engineers jump in without a structured plan, producing vague tasks, missing requirements, and inconsistent interfaces. This Skill converts a spec into a complete implementation plan with exact file paths, test code, and commit steps that an engineer with zero codebase context can follow. ## Core Features & Use Cases - Spec-to-Plan Conversion: Transforms requirements into a structured plan with a mandatory header, global constraints, and per-task file/interface declarations. - Bite-Sized TDD Tasks: Breaks work into 2-5 minute steps following the failing-test, implement, pass, commit cycle, with no placeholders allowed. - Self-Review and Handoff: Runs a spec-coverage, placeholder, and type-consistency check, then offers subagent-driven or inline execution. - Use Case: Given a feature spec for a new API endpoint, produce a plan saved to docs/superpowers/plans/ that lists every file to create or modify, exact test code, run commands, and commit messages for each task. ## Quick Start Ask the AI to use the writing-plans skill to create an implementation plan from your spec document before writing any code.

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 spec before coding?

Map the file structure first, then decompose the spec into tasks where each task has exact files to create or modify, interface contracts, and TDD steps with real test code. Save the plan to docs/superpowers/plans/ with a dated filename.

What makes a good task breakdown for a coding plan?

Each task should be the smallest unit carrying its own test cycle, with steps of 2-5 minutes each: write the failing test, run it, implement minimally, verify it passes, and commit. Fold setup and scaffolding into the task whose deliverable needs them.

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 reviewable and executable independently.

Why do implementation plans fail during execution?

Plans fail when they contain placeholders like TODO or vague steps such as add error handling, when task boundaries are unclear, or when type and function names drift between tasks. A self-review for spec coverage, placeholders, and type consistency catches these before execution.

Can the plan be executed automatically after it is written?

Yes. After saving, the plan offers two execution modes: subagent-driven development, which dispatches a fresh subagent per task with review between tasks, or inline execution with batched tasks and checkpoints.