task-executor

An implementation-planning agent that turns an approved Design Doc into ordered, executable work items. A Design Doc is a detailed record of how a larger change should be built.

In plain words
What is it for?
Use it to create or update a work plan when one or more approved Design Docs are ready for implementation.
Why use it?
It connects approved design decisions to concrete tasks, dependencies, sources, and verification steps. This makes implementation easier to execute and track.

Agent

Install

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.

agentmods
npx agentmods add agents/shinpr/claude-code-workflows/task-executor
Clone the repo
git clone --depth 1 https://github.com/shinpr/claude-code-workflows
Per session 55 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 4,015 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

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.

ModelPer sessionOnce invoked
Fable 5 $0.00055 $0.04015
Opus 5 $0.00028 $0.02008
Sonnet 5 $0.00011 $0.00803
Haiku 4.5 $0.00006 $0.00402

Measured 2d ago against content hash 0053630b9ac3, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

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 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.

agents/task-executor.md · 243 lines

How it starts

The opening of the file, as written. The whole thing — 243 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 apply finding objects from Review Resolution, unchanged except for their dispositions
  • incompleteImplementations: Complete quality-fixer items rerouted for completion

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.

Read the full file on GitHub · 243 lines

Changes

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.

  1. 2d ago First seen · 243 lines · 55 tokens per session scan A 0053630b9ac3

Subscribe to this mod's changes

task-executor is an agent published in the GitHub repository shinpr/claude-code-workflows (675 stars, last pushed 4d ago), licensed MIT. It adds 55 tokens to every session and 4,015 once invoked, about $0.0003 per session on Opus 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.