file-todos
Manages code review and work items using markdown files in the todos/ directory.
Install
mkdir -p .claude/skills/file-todos-jimmychen-nxp && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/14944" && unzip -o skill.zip -d .claude/skills/file-todos-jimmychen-nxp && rm skill.zipInstalls to .claude/skills/file-todos-jimmychen-nxp
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
This skill should be used when managing the file-based todo tracking system in the todos/ directory. It provides workflows for creating todos, managing status and dependencies, conducting triage, and integrating with slash commands and code review processes.Key capabilities
- →Create new todo items from findings or feedback
- →Manage the lifecycle of todo items (pending, ready, complete)
- →Triage pending items for approval
- →Check and manage dependencies between todos
- →Convert PR comments or code findings into tracked work
- →Update work logs during todo execution
How it works
The skill manages a file-based todo tracking system where each todo is a markdown file with YAML frontmatter and structured sections, supporting lifecycle management and dependency tracking.
Inputs & outputs
When to use file-todos
- →Create todo item
- →Manage work items
- →Triage task status
- →Track code feedback
About this skill
File-Based Todo Tracking Skill
Overview
The todos/ directory contains a file-based tracking system for managing code review feedback, technical debt, feature requests, and work items. Each todo is a markdown file with YAML frontmatter and structured sections.
This skill should be used when:
- Creating new todos from findings or feedback
- Managing todo lifecycle (pending → ready → complete)
- Triaging pending items for approval
- Checking or managing dependencies
- Converting PR comments or code findings into tracked work
- Updating work logs during todo execution
File Naming Convention
Todo files follow this naming pattern:
{issue_id}-{status}-{priority}-{description}.md
Components:
- issue_id: Sequential number (001, 002, 003...) - never reused
- status:
pending(needs triage),ready(approved),complete(done) - priority:
p1(critical),p2(important),p3(nice-to-have) - description: kebab-case, brief description
Examples:
001-pending-p1-mailer-test.md
002-ready-p1-fix-n-plus-1.md
005-complete-p2-refactor-csv.md
File Structure
Each todo is a markdown file with YAML frontmatter and structured sections. Use the template at todo-template.md as a starting point when creating new todos.
Required sections:
- Problem Statement - What is broken, missing, or needs improvement?
- Findings - Investigation results, root cause, key discoveries
- Proposed Solutions - Multiple options with pros/cons, effort, risk
- Recommended Action - Clear plan (filled during triage)
- Acceptance Criteria - Testable checklist items
- Work Log - Chronological record with date, actions, learnings
Optional sections:
- Technical Details - Affected files, related components, DB changes
- Resources - Links to errors, tests, PRs, documentation
- Notes - Additional context or decisions
YAML frontmatter fields:
---
status: ready # pending | ready | complete
priority: p1 # p1 | p2 | p3
issue_id: "002"
tags: [rails, performance, database]
dependencies: ["001"] # Issue IDs this is blocked by
---
Common Workflows
Creating a New Todo
To create a new todo from findings or feedback:
- Determine next issue ID:
ls todos/ | grep -o '^[0-9]\+' | sort -n | tail -1 - Copy template:
cp assets/todo-template.md todos/{NEXT_ID}-pending-{priority}-{description}.md - Edit and fill required sections:
- Problem Statement
- Findings (if from investigation)
- Proposed Solutions (multiple options)
- Acceptance Criteria
- Add initial Work Log entry
- Determine status:
pending(needs triage) orready(pre-approved) - Add relevant tags for filtering
When to create a todo:
- Requires more than 15-20 minutes of work
- Needs research, planning, or multiple approaches considered
- Has dependencies on other work
- Requires manager approval or prioritization
- Part of larger feature or refactor
- Technical debt needing documentation
When to act immediately instead:
- Issue is trivial (< 15 minutes)
- Complete context available now
- No planning needed
- User explicitly requests immediate action
- Simple bug fix with obvious solution
Triaging Pending Items
To triage pending todos:
- List pending items:
ls todos/*-pending-*.md - For each todo:
- Read Problem Statement and Findings
- Review Proposed Solutions
- Make decision: approve, defer, or modify priority
- Update approved todos:
- Rename file:
mv {file}-pending-{pri}-{desc}.md {file}-ready-{pri}-{desc}.md - Update frontmatter:
status: pending→status: ready - Fill "Recommended Action" section with clear plan
- Adjust priority if different from initial assessment
- Rename file:
- Deferred todos stay in
pendingstatus
Use slash command: /triage for interactive approval workflow
Managing Dependencies
To track dependencies:
dependencies: ["002", "005"] # This todo blocked by issues 002 and 005
dependencies: [] # No blockers - can work immediately
To check what blocks a todo:
grep "^dependencies:" todos/003-*.md
To find what a todo blocks:
grep -l 'dependencies:.*"002"' todos/*.md
To verify blockers are complete before starting:
for dep in 001 002 003; do
[ -f "todos/${dep}-complete-*.md" ] || echo "Issue $dep not complete"
done
Updating Work Logs
When working on a todo, always add a work log entry:
### YYYY-MM-DD - Session Title
**By:** Claude Code / Developer Name
**Actions:**
- Specific changes made (include file:line references)
- Commands executed
- Tests run
- Results of investigation
**Learnings:**
- What worked / what didn't
- Patterns discovered
- Key insights for future work
Work logs serve as:
- Historical record of investigation
- Documentation of approaches attempted
- Knowledge sharing for team
- Context for future similar work
Completing a Todo
To mark a todo as complete:
- Verify all acceptance criteria checked off
- Update Work Log with final session and results
- Rename file:
mv {file}-ready-{pri}-{desc}.md {file}-complete-{pri}-{desc}.md - Update frontmatter:
status: ready→status: complete - Check for unblocked work:
grep -l 'dependencies:.*"002"' todos/*-ready-*.md - Commit with issue reference:
feat: resolve issue 002
Integration with Development Workflows
| Trigger | Flow | Tool |
|---|---|---|
| Code review | /ce:review → Findings → /triage → Todos | Review agent + skill |
| PR comments | /resolve_pr_parallel → Individual fixes → Todos | gh CLI + skill |
| Code TODOs | /resolve_todo_parallel → Fixes + Complex todos | Agent + skill |
| Planning | Brainstorm → Create todo → Work → Complete | Skill |
| Feedback | Discussion → Create todo → Triage → Work | Skill + slash |
Quick Reference Commands
Finding work:
# List highest priority unblocked work
grep -l 'dependencies: \[\]' todos/*-ready-p1-*.md
# List all pending items needing triage
ls todos/*-pending-*.md
# Find next issue ID
ls todos/ | grep -o '^[0-9]\+' | sort -n | tail -1 | awk '{printf "%03d", $1+1}'
# Count by status
for status in pending ready complete; do
echo "$status: $(ls -1 todos/*-$status-*.md 2>/dev/null | wc -l)"
done
Dependency management:
# What blocks this todo?
grep "^dependencies:" todos/003-*.md
# What does this todo block?
grep -l 'dependencies:.*"002"' todos/*.md
Searching:
# Search by tag
grep -l "tags:.*rails" todos/*.md
# Search by priority
ls todos/*-p1-*.md
# Full-text search
grep -r "payment" todos/
Key Distinctions
File-todos system (this skill):
- Markdown files in
todos/directory - Development/project tracking
- Standalone markdown files with YAML frontmatter
- Used by humans and agents
Rails Todo model:
- Database model in
app/models/todo.rb - User-facing feature in the application
- Active Record CRUD operations
- Different from this file-based system
TodoWrite tool:
- In-memory task tracking during agent sessions
- Temporary tracking for single conversation
- Not persisted to disk
- Different from both systems above
When not to use it
- →When the issue is trivial and takes less than 15 minutes
- →When complete context is available and no planning is needed
- →When the user explicitly requests immediate action or a simple bug fix
Limitations
- →The skill manages file-based todos, not a Rails Todo model
- →It does not manage in-memory task tracking during agent sessions
- →It does not persist temporary tracking to disk
How it compares
This skill uses a file-based markdown system for tracking work items, distinct from in-memory task tracking or database models.
Compared to similar skills
file-todos side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| file-todos (this skill) | 0 | 5mo | Review | Beginner |
| github-manage | 6 | 9mo | Review | Beginner |
| task-management | 16 | 5mo | No flags | Beginner |
| markdown-task-manager | 1 | 9mo | Review | Beginner |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by JimmyChen-NXP
View all by JimmyChen-NXP →You might also like
github-manage
matteocervelli
Manage operations concerning GitHub on behalf of user
task-management
anthropics
Simple task management using a shared TASKS.md file. Reference this when the user asks about their tasks, wants to add/complete tasks, or needs help tracking commitments.
markdown-task-manager
ioniks
Use when managing tasks, the system is a Kanban task manager based on local Markdown files (`kanban.md` and `archive.md`). It follows a strict format compatible with the task-manager.html web application.
agent-project-board-sync
ruvnet
Agent skill for project-board-sync - invoke with $agent-project-board-sync
nextcloud-cli-deck
NicholaiVogel
Work with the Nextcloud Deck app through Nextcloud CLI. Use when an agent needs to list boards and cards, create boards or stacks, create or update cards, move cards, archive or delete cards safely, validate Deck availability, or perform dry-run protected project-board workflows with nxc.
task-management
rjchien728
管理 ~/tasks/(或使用者指定路徑)下的進行中工作項目資料夾。每個 task 是一個資料夾,README.md 是純狀態 dashboard(status frontmatter + 一句 headline + 一行狀態 + 檔案清單 + 下一步),實際的設計 / 規劃 / 調查文件用獨立 .md 檔,腳本與 reproduce 也存獨立檔。負責命名(YYMMDD-<slug>)、建資料夾、寫 README dashboard、更新狀態、總覽掃描。當使用者說「開新 task」「開個 task」「新增 task」「new task」「記錄到 tasks 下」「把目前設計記下來開個 task