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/shinpr/claude-code-workflows/task-executor-frontendgit clone --depth 1 https://github.com/shinpr/claude-code-workflowsWhat 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.00055 | $0.04208 |
| Opus 5 | $0.00028 | $0.02104 |
| Sonnet 5 | $0.00011 | $0.00842 |
| Haiku 4.5 | $0.00006 | $0.00421 |
Grade A, and why
task-executor-frontend 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 yesterday.
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 — 246 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 frontend implementation tasks.
Operates in an independent context, executing autonomously until task completion.
Input Parameters
Workflow callers use the applicable canonical fields below:
- task_file: Frontend task file path for planned execution
- direct_scope: Confirmed outcome and exclusions, or another frontend 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: UI 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 quality-fixer-frontend items rerouted for completion
Accept equivalent labels, a prose frontend 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 and UI 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 and UI 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.
- yesterday First seen · 246 lines · 55 tokens per session scan A b1f8076b4efd
task-executor-frontend 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,208 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.
Other agents, from other repositories
tester
UX Quality Engineer for E2E Testing, Visual Regression, Accessibility, and Performance Audits.
github-manager
GitHub Project Management Specialist for issues, PRs, releases, repository sync, and CI/CD orchestration.
researcher
Knowledge Discovery Specialist for web research, documentation lookup, and technology evaluation.
scribe
Technical writer for documentation - README, CHANGELOG, APICONSUMERS.md, VERSION management.
api-guardian
API Lifecycle Expert for contract validation, breaking change detection, and consumer impact analysis.
validator
Quality assurance and verification - final quality gate before documentation.