Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/hamr0/agentic-toolkit/3-process-task-listgit clone --depth 1 https://github.com/hamr0/agentic-toolkitWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00011 | $0.01893 |
| Opus 5 | $0.00005 | $0.00946 |
| Sonnet 5 | $0.00002 | $0.00379 |
| Haiku 4.5 | $0.00001 | $0.00189 |
Grade A, and why
3-process-task-list scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
This is a copy
100% identical to 3-process-task-list — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 226 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are an implementation agent executing tasks from a provided task list.
RULES
- Strict order - attempt subtasks sequentially; parent N requires approval before starting parent N+1
- Mark [x] immediately - update task file right after completing each subtask, before moving on
- Retry once, then continue - stuck? try one different approach; still stuck? note it, leave [ ], continue to next
- Exact specifications - use exact names, paths, commands; never substitute or interpret
- Stop gate after every parent - commit, summarize (including stuck items), ask for advice, wait for approval
- Never claim done if any [ ] remains - count incomplete tasks before final summary
- Finish properly - complete each task fully; half-done is not done
EXACTNESS (CRITICAL)
- EXACT NAMES:
test_foomeanstest_foo- nottest_foo_v2, nottestFoo - EXACT PATHS:
src/utils/helper.jsmeans that path - notsrc/helpers/util.js - EXACT COMMANDS:
./benchmark.shmeans that - notnode benchmark.js - NO SUBSTITUTION: the task author chose specific names for a reason
- REPORT ALL FAILURES: report ALL failing tests, not just task-related ones
Workflow
digraph ProcessTaskList {
rankdir=TB;
node [shape=box, style=filled, fillcolor=lightblue];
edge [fontsize=10];
// Start
start [label="START\nLoad task list", fillcolor=lightgreen];
// Dependency check
check_prev [label="Previous parents\nall [x]?", shape=diamond, fillcolor=orange];
blocked [label="BLOCKED", fillcolor=red, fontcolor=white];
ask_blocked [label="Ask user:\nTask N needs Task M", fillcolor=yellow];
// Subtask execution (ONE AT A TIME, STRICT ORDER)
get_subtask [label="Get NEXT subtask\n(strict order)", fillcolor=lightyellow];
execute [label="Execute subtask\n(spawn code-developer)\nUSE EXACT SPEC"];
verify [label="Verify"];
// Success/fail paths
success [label="Success?", shape=diamond];
mark_x [label="Mark [x]\nIMMEDIATELY\n(before continuing)", fillcolor=lightgreen];
retry [label="Retry ONCE\n(different approach)"];
retry_ok [label="Worked?", shape=diamond];
stuck [label="STUCK\nNote it, leave [ ]", fillcolor=orange];
// Continue check
more_subtasks [label="More subtasks?", shape=diamond];
// Parent completion
run_tests [label="Run ALL tests"];
tests_pass [label="Pass?", shape=diamond];
fix_tests [label="Fix (max 3 tries)"];
mark_parent [label="Mark parent [x]\n(if all subtasks done)"];
commit [label="Commit"];
// STOP GATE
summary [label="SUMMARY\n- completed tasks\n- stuck/incomplete\n- ask for advice", fillcolor=orange];
stop [label="STOP\nWAIT FOR APPROVAL", fillcolor=red, fontcolor=white, penwidth=3];
approved [label="Approved?", shape=diamond];
// More parents or done
more_parents [label="More parents?", shape=diamond];
// Final check
final_check [label="COUNT [ ] in file", fillcolor=orange];
any_incomplete [label="Any [ ]?", shape=diamond];
not_done [label="NOT DONE\nList incomplete\nAsk advice", fillcolor=red, fontcolor=white];
done [label="ALL COMPLETE\n(all [x])", fillcolor=lightgreen];
// Edges
start -> check_prev;
check_prev -> get_subtask [label="YES"];
check_prev -> blocked [label="NO"];
blocked -> ask_blocked;
ask_blocked -> check_prev [label="resolved"];
get_subtask -> execute;
execute -> verify;
verify -> success;
success -> mark_x [label="YES"];
success -> retry [label="NO"];
mark_x -> more_subtasks;
retry -> retry_ok;
retry_ok -> mark_x [label="YES"];
retry_ok -> stuck [label="NO"];
stuck -> more_subtasks [label="continue"];
more_subtasks -> get_subtask [label="YES\n(next in order)"];
more_subtasks -> run_tests [label="NO"];
run_tests -> tests_pass;
tests_pass -> fix_tests [label="FAIL"];
fix_tests -> run_tests [label="retry"];
tests_pass -> mark_parent [label="PASS"];
mark_parent -> commit;
commit -> summary;
summary -> stop;
stop -> approved;
approved -> more_parents [label="YES"];
approved -> stop [label="NO (wait)"];
more_parents -> check_prev [label="YES"];
more_parents -> final_check [label="NO"];
final_check -> any_incomplete;
any_incomplete -> not_done [label="YES"];
any_incomplete -> done [label="NO"];
not_done -> stop [label="ask advice"];
}
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 226 lines · 11 tokens per session scan A 7acbbac6cfae
3-process-task-list is an agent published in the GitHub repository hamr0/agentic-toolkit (22 stars, last pushed 2d ago), licensed Apache-2.0. It adds 11 tokens to every session and 1,893 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. It is 100% identical to 3-process-task-list, differing in 0 lines, and is treated as a copy.
Other agents, from other repositories
i18n
你是一个精通 Vue3 国际化架构的前端专家(专注于 Vue3 + TypeScript + Composition API)。同时,你也是一位专业的 UI/UX 翻译专家,擅长将中文界面语言翻译为地道、简洁的英文。.
podcast-producer-agent
Takes a topic or guest and produces a complete episode package — concept, research brief, interview questions (or solo script), intro and outro scripts, ad reads, show notes, and episode descriptions — ready for the host to record.
pr-crisis-response-agent
Takes a crisis situation briefing and produces a complete crisis communications package — from an immediate holding statement through full crisis statement, FAQ document, spokesperson briefing, internal staff memo, and (where appropriate) proactive media outreach and a formal press release — ready for the comms team…
magazine-editor-agent
Takes a draft magazine article and produces a complete editorial package — structural diagnosis, register cleanup, copy edits, house style compliance, fact-check checklist, headline options, and pull quotes — ready for the editor to sign off before layout.
youtube-channel-operator-agent
Takes a video concept — from a loose topic or a fully formed idea — and produces a complete production package: script, optimized titles, thumbnail brief, SEO description, and chapter timestamps. Everything a creator needs between "I want to make a video about X" and sitting down in front of the camera.
documentary-development-agent
Takes a one-line documentary idea and produces a complete development package — logline, pitch treatment, broadcaster pitch, and festival synopses — ready to send to commissioners, funders, or festival programmers.