file-todoslisted

# File TODOs A backlog that only lives in chat history disappears when the session ends. This skill stores each item as its own markdown file with the lifecycle state baked into the filename, so the queue is inspectable with `ls`, greppable, diffable, and survives a crash mid-triage without losing state. ## When to use this - A batch of findings (a code review, a bug bash, an audit) that shouldn't all be fixed immediately and need triage first. - Work items should persist across sessions, not just this conversation. - Multiple items need to be worked through independently, possibly in parallel, by whoever/whatever picks them up next. - **Don't use this for an immediate one-off fix** — just fix it. Creating a todo file for something you're about to fix in the next two minutes is pure ceremony. ## Instructions ### Directory and filename convention Store items under `todos/`, one file per item: ```text todos/{id}-{status}-{priority}-{description}.md ``` - `id` — a short, stable identifier (an incrementing number is simplest, e.g. `007`) so renames never collide. - `status` — one of `pending` (needs triage) → `ready` (approved, queued for work) → `complete` (resolved and verified). - `priority` — `p1` (critical/blocking) through `p3` (nice-to-have). - `description` — a short kebab-case slug. Example: `007-pending-p1-race-condition-in-cache.md`. Moving between states is a filename rename (status segment only) — the file's content and id stay put. ### File conte