add-todo

add-todo

Capture work into the codingest dev-docs backlog the right way, respecting the convention:

todos.md holds one lean backlink line per thread; the detail lives in a plans/*.md file. Never put detail in todos.md; never leave a plans/ doc unlinked.

The whole point is to capture fast and scope well, so the item is actionable later without rediscovery. Do the work directly; only ask the user when a classification or scope decision is genuinely ambiguous.

This skill is the single authority on how a todo entry is shaped — classification, the lean-backlink format, detail-in-plans/, fix-site grounding. Other skills that file todos (e.g. read-inbox) follow the entry rules below rather than restating them.

Two modes

• One-off — a single free-text item (/add-todo <description>). Run steps 1–6 below once.
• Batch / deeper analysis — a body of findings (a research report, an audit, a code review, inbox content) that contains several actionable items. Decompose it first, then run the per-item logic for each. See §0 Decompose before the single-item steps.

0. Decompose (batch mode only)

When the input is analysis rather than one ask, first split it into discrete, independently actionable items — each a single change a future session could pick up alone. For the whole set, before filing:

• Drop non-actionable material — background, confirmations, "no action" conclusions. A todo is something to do.
• Group by theme. Items that share a subsystem go in one plans/ doc as sections (one backlink), not N scattered docs. Distinct threads get their own.
• Dedup against the existing backlog — read todos.md first; fold an item that extends an existing thread into that thread instead of a new line.
• Order by priority/effort so the backlink hooks read sensibly. Then run steps 2–5 for each resulting item (step 1's index read is done once). Keep the report (step 6) to the set: one line per filed entry.