todo

Generates test-driven development task lists with test-first workflow and per-task commits.

Updated Nov 7, 2024
One-click install
npx skills add https://github.com/jeremysball/dotfiles --skill todo-jeremysball
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: todo
Source: https://github.com/jeremysball/dotfiles/tree/main/.pi/skills-archive/todo
Command: npx skills add https://github.com/jeremysball/dotfiles --skill todo-jeremysball

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It prevents developers from skipping tests by enforcing a test-first workflow, breaking feature work into small verifiable tasks where each test is written before its implementation and committed immediately after passing. ## Core Features & Use Cases - TDD Task List Format: Structures work as markdown checklists pairing each test task with its minimal implementation task. - Red-Green-Commit Workflow: Enforces the cycle of writing a failing test, implementing just enough to pass, then committing each green task. - Granularity Guidance: Provides examples distinguishing overly broad tasks from appropriately scoped ones, plus recovery steps when test-first was skipped. - Use Case: When building a new UI component like a loading throbber, use this Skill to produce a task list covering initialization tests, increment behavior tests, and animation state tests, each followed by its minimal implementation. ## Quick Start Ask the AI to create a test-first todo task list for the feature you are about to implement.

Frequently Asked Questions about todo

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

FAQPage Schema
How do I create a test-driven development task list?

Structure each component as markdown checkboxes pairing a test task with its implementation task. Write the test first, implement minimally to make it pass, then commit before moving to the next pair.

How to break down a feature into TDD tasks?

Split the feature into single-behavior units like initialization, increments, or state handling. Each task should verify one thing, so you know exactly when it is done, rather than broad items like add feature or fix bugs.

When is it acceptable to skip test-first development?

Exceptions are rare and limited to time-boxed spike explorations, pure refactors where tests already exist, and genuinely trivial wiring. Each deviation should have an explicit reason documented.

What should I do if I forgot to write the test first?

Write a test covering the existing behavior, verify it passes, and commit it with a message like test: verify existing behavior of X. Then resume the normal test-first cycle for remaining work.

How granular should TDD tasks be?

Each task should target one verifiable behavior, such as initializing a counter at zero or handling empty input by returning None. Broad tasks like add throbber or fix bugs are too vague to know when they are complete.