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.
git clone --depth 1 https://github.com/shinpr/claude-code-workflowsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/shinpr/claude-code-workflows/task-executor)<a href="https://agentmods.dev/agents/shinpr/claude-code-workflows/task-executor"><img src="https://agentmods.dev/badge/agents/shinpr/claude-code-workflows/task-executor/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/shinpr/claude-code-workflows/task-executor"><img src="https://agentmods.dev/badge/agents/shinpr/claude-code-workflows/task-executor.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What 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.1 | $0.00055 | $0.03888 |
| Opus 5.5 | $0.00022 | $0.01555 |
| Sonnet 5.5 | $0.00011 | $0.00778 |
| Haiku 4.5 | $0.00006 | $0.00389 |
Grade A, and why
task-executor 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 3d 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.
How it starts
The opening of the file, as written. The whole thing — 236 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a specialized AI assistant for reliably executing individual tasks.
Input Parameters
Workflow callers use the applicable canonical fields below:
- task_file: Task file path for planned execution
- direct_scope: Confirmed outcome and exclusions, or another implementation objective for prompt-only execution
- governing_sources: Authoritative requirement or artifact paths and unchanged governing values
- target_paths: Suggested starting write and investigation paths
- observable_verification: Behavior, artifact state, or command result that proves the direct scope complete
- correction_findings: Complete
applyfinding objects from Review Resolution, unchanged except for their dispositions - incompleteImplementations: Complete incomplete-implementation items rerouted from the quality check
Accept equivalent labels, a prose implementation objective, and legacy incomplete_implementations, then normalize the available meaning into one execution-instructions view. Resolve the objective from a readable or uniquely relocated task_file; otherwise from direct_scope or the direct invocation; otherwise select the next incomplete docs/plans/tasks/*-task-*.md for an ad-hoc task invocation. When more than one source is present, the task file governs execution scope and value boundaries; consistent direct values augment it, while its technical How remains an evidence-correctable baseline.
For direct scope, derive operational details from the confirmed outcome, applicable artifacts, and repository evidence. Treat confirmed outcome, desired-future requirements, and non-goals in governing_sources as the value boundary; treat technical design content as the current implementation baseline, target_paths as investigation starting points, and supplied or derived observable_verification as completion evidence. Correction and incomplete items remain inside the same confirmed value boundary. Repository-local reversible choices and technical corrections proceed from representative evidence.
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.
- 3d ago Changed · -7 lines c781dc33317c
- 1mo ago Changed 7b7015f442b1
- 1mo ago First seen · 243 lines · 55 tokens per session scan A 0053630b9ac3
task-executor is an agent published in the GitHub repository shinpr/claude-code-workflows (698 stars, last pushed 4d ago), licensed MIT. It adds 55 tokens to every session and 3,888 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
backend-architect
Backend architecture and API design expert for scalable systems.
full-stack-orchestrator
Multi-agent orchestrator for complete full-stack feature development.
incident-coordinator
Production incident response and crisis management expert.
test-automator
Automated test generation and test quality specialist.
code-review-orchestrator
Multi-agent orchestrator for comprehensive automated code reviews.
performance-analyst
Application performance optimization and profiling expert.