todo-workflow
Skill0 starsChanged 5 months agoMITView on GitHub
A structured workflow for tracking multi-step migration and refactoring tasks via a persistable TODOS.md file.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- Willhong/claude_skilltheir own version, first seen Nov 17, 2025
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- Willhong/claude_skill★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository5 other files it gives its agents.
- idea-expansionSkill
- phase-trackingSkill
- project-pulseSkill
- shadcn-ui-migrationSkill
- ui-migrationSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
22 rules. About 0 are common, 11 are distinctive, and 11 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈11
Distinctive · estimate
This author's own choices. Worth a look.
11
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
Use this skill whenever you are performing a sequence of related codebase changes (migrations, refactors, feature builds) that span …
- Very specific: line 16
Before starting a new workflow, any prior completed workflow is archived under artifacts/todo-workflow-<timestamp>/ so the history is …
- Very specific: line 27
Before creating or resetting TODOS.md, check if a previous workflow exists:
- Distinctive: line 35
Create a timestamped archive:
- Very specific: line 62
Every time you call the todowrite tool, immediately update TODOS.md to match.
- Very specific: line 65
When starting a task → in_progress + - [ ] → - [/]
- Very specific: line 66
When completing a task → completed + - [ ] → - [x]
- Distinctive: line 67
When adding new tasks → add to both
- Distinctive: line 68
When reordering → reorder both identically
- Very specific: line 72
After completing each task, log errors encountered in ERRORS.md at the project root.
- Very specific: line 83
If no errors occurred, write No errors encountered and set status to No errors encountered.
- Distinctive: line 93
Add this instruction to the project's AGENTS.md so the agent automatically keeps the file in sync:
- Very specific: line 103
After completing each task (and logging errors to ERRORS.md), make a git commit.
- Very specific: line 106
Run pnpm run build to verify no broken imports
- Distinctive: line 107
Run git status to check all new/edited files are tracked
- Distinctive: line 109
Commit with a descriptive message referencing the task number and title
- Distinctive: line 111
Add this instruction to AGENTS.md under the TODOs section:
- Distinctive: line 126
After completing all tasks, run a reflection pass to identify leftover concerns that the migration may have introduced or ignored.
- Distinctive: line 130
Check these categories systematically:
- Very specific: line 175
Add a new pending task to TODOS.md.
- Very specific: line 176
Add the corresponding section to ERRORS.md with status Pending.
- Distinctive: line 179
If the user declines all considerations, mark the session complete:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
TODO Workflow Skill
A structured workflow for tracking multi-step migration and refactoring tasks via a persistable TODOS.md file.
When to use
Use this skill whenever you are performing a sequence of related codebase changes (migrations, refactors, feature builds) that span multiple steps over multiple sessions. It keeps both the agent and the user aligned on what's done and what's next.
Workflow Artifacts
Before starting a new workflow, any prior completed workflow is archived under artifacts/todo-workflow-<timestamp>/ so the history is preserved. The archive contains:
TODOS.md— final task list snapshotERRORS.md— full error logCOMMITS.md— log of commits made during the workflow
This lets multiple workflow sessions run sequentially without losing the record of what each session accomplished.
Workflow
1. Initialize the list
Before creating or resetting TODOS.md, check if a previous workflow exists:
test -f TODOS.md && grep -q '\[x\]' TODOS.md && echo "Has completed tasks"If a prior completed workflow exists:
- Create a timestamped archive:
ts=$(date +%Y%m%d-%H%M%S) mkdir -p "artifacts/todo-workflow-$ts" cp TODOS.md "artifacts/todo-workflow-$ts/TODOS.md" cp ERRORS.md "artifacts/todo-workflow-$ts/ERRORS.md" git log --oneline -20 -- TODOS.md ERRORS.md > "artifacts/todo-workflow-$ts/COMMITS.md" - Stage and commit the archive:
git add "artifacts/todo-workflow-$ts/" TODOS.md ERRORS.md git commit -m "archive: snapshot completed workflow $ts" - Then reset
TODOS.mdfor the new workflow.
If no prior workflow exists, create TODOS.md fresh:
# Migration Tasks
- [ ] Task one
- [ ] Task two
- [ ] Task three2. Keep both representations in sync
Every time you call the todowrite tool, immediately update TODOS.md to match. The two lists MUST be identical at all times — never let them drift.
Sync rules:
- When starting a task →
in_progress+- [ ]→- [/] - When completing a task →
completed+- [ ]→- [x] - When adding new tasks → add to both
- When reordering → reorder both identically
3. Log errors at task completion
After completing each task, log errors encountered in ERRORS.md at the project root. Use this format:
### Task N: Title
- **Date:** YYYY-MM-DD
- **Error:** Brief description of what went wrong
- **Root cause:** What caused it
- **Resolution:** How it was fixed
- **Status:** Resolved / Workaround / Unresolved / No errors encounteredIf no errors occurred, write No errors encountered and set status to No errors encountered. Add this instruction to AGENTS.md:
## Errors File
The file `ERRORS.md` at the project root logs errors encountered during task execution. After completing each task, the agent MUST record any errors that occurred, including root cause and resolution.4. Reference the files
Add this instruction to the project's AGENTS.md so the agent automatically keeps the file in sync:
## TODOs File
The file `TODOS.md` at the project root tracks all outstanding and completed tasks. The agent MUST keep `TODOS.md` in sync with its in-session todo list whenever tasks progress.5. Commit after every task
After completing each task (and logging errors to ERRORS.md), make a git commit. The commit must include TODOS.md and ERRORS.md alongside the code changes.
Commit workflow:
- Run
pnpm run buildto verify no broken imports - Run
git statusto check all new/edited files are tracked - Stage everything:
git add -A - Commit with a descriptive message referencing the task number and title
Add this instruction to AGENTS.md under the TODOs section:
## Git & Commit Hygiene
Before every commit, the agent MUST run these checks:
1. **`git status`** — Verify all new files (directories, components, mocks) are staged. Untracked files (`??`) that are imported elsewhere will break CI.
2. **`pnpm run build`** — Confirm the production build succeeds with no `Could not resolve` errors. A local build pass guarantees the module graph is complete.
3. **Stage all related artifacts** — When adding a new feature directory (e.g., `features/MyFeature/`), ensure every file inside it is staged, not just the files that import it.
4. **Remove dead code** — If a directory is replaced (e.g., `FeaturesHub` → `FeatureLayout`), delete the old directory so it doesn't linger as untracked dead weight.6. Reflect & generate follow-ups
After completing all tasks, run a reflection pass to identify leftover concerns that the migration may have introduced or ignored.
6a. Survey for post-migration concerns
Check these categories systematically:
| Category | What to look for |
| Stale references | Old path aliases in tsconfig.json / jsconfig.json, outdated README.md docs, aged comments |
| Dead dependencies | Packages in package.json no longer imported anywhere (rg for each dep name across src/) |
| Missing files | Things imported by source code that don't exist (e.g., src/lib/utils.js for shadcn's cn()) |
| Doc/impl gaps | Components documented in AGENTS.md with no backing file, or files with no docs |
| Lint/CI gaps | pnpm run lint fails, missing ESLint config, test runner absent |
| Unused patterns | Packages that conflict with project conventions (e.g., formik installed but convention says react-hook-form) |
| Version mismatches | Deprecated APIs, stale shadcn registries, Tailwind v3 patterns in a v4 project |
Default reflection checks:
# 1. Stale path aliases
rg '@design-system' tsconfig.json 2>/dev/null || echo "Clean"
# 2. Dead deps — quick scan of package.json deps not imported in src/
# (run manually per dep or use a tool like depcheck)
# 3. Missing files imported by source
rg "from ['\"]@/lib/utils['\"]" src/components/ui/ | head -1
test -f src/lib/utils.js && echo "exists" || echo "MISSING"
# 4. Broken lint
pnpm run lint 2>&1 | tail -5
# 5. Build
pnpm run build 2>&1 | tail -56b. Present considerations to the user
For each concern found, present it to the user as a consideration, not a demand. Example:
Consideration:
tsconfig.jsonstill has@design-systempath aliases (lines 32-33). This won't break anything since the directory is gone, but it could mask future import errors.Consideration:
README.mdstill references@design-system/ui/imports. Anyone cloning the template gets wrong docs.Consideration:
formikis installed but the project convention isreact-hook-form.
6c. Translate into new tasks (with user approval)
For each consideration the user wants to act on:
- Add a new pending task to
TODOS.md. - Add the corresponding section to
ERRORS.mdwith statusPending. - Proceed through the workflow again (start → commit → reflect) until the list is empty.
If the user declines all considerations, mark the session complete:
- Produce the terminal archive for the next workflow initialization to pick up:
ts=$(date +%Y%m%d-%H%M%S) mkdir -p "artifacts/todo-workflow-$ts" cp TODOS.md "artifacts/todo-workflow-$ts/TODOS.md" cp ERRORS.md "artifacts/todo-workflow-$ts/ERRORS.md" git log --oneline -999 --skip=1 > "artifacts/todo-workflow-$ts/COMMITS.md" - Stage everything including the archive,
TODOS.md, andERRORS.md. - Commit with a terminal message like
"Migration complete". - The archived
TODOS.mdandERRORS.mdremain as historical records for the next session's artifact check.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

