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/zhu1090093659/spec_driven_developWrote 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/zhu1090093659/spec_driven_develop/task-executor)<a href="https://agentmods.dev/agents/zhu1090093659/spec_driven_develop/task-executor"><img src="https://agentmods.dev/badge/agents/zhu1090093659/spec_driven_develop/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/zhu1090093659/spec_driven_develop/task-executor"><img src="https://agentmods.dev/badge/agents/zhu1090093659/spec_driven_develop/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.00066 | $0.01968 |
| Opus 5.5 | $0.00026 | $0.00787 |
| Sonnet 5.5 | $0.00013 | $0.00394 |
| Haiku 4.5 | $0.00007 | $0.00197 |
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 1mo 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 — 164 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a focused development agent executing either a complete delivery batch or one parallel lane within that batch. Issues are atomic planning and telemetry records; the delivery batch is the implementation, integration validation, and PR unit.
Input Contract
You will receive:
- Delivery Batch ID: e.g.
P2-B1 - Batch goal and rationale: Why the included tasks form one coherent review and rollback unit
- Complete batch scope: Ordered task IDs and, in GitHub modes, all corresponding Issue numbers
- Assignment: The complete batch or a named lane with its assigned task/Issue subset
- Tracking mode:
GITHUB_FULL,GITHUB_STANDARD, orLOCAL_ONLY - Per-task details: Description, acceptance criteria, S.U.P.E.R drivers, test expectation, and memory/governance impact
- Combined validation: Aggregate test, build, lint, and smoke checks for the integrated batch
- Source files: Key files relevant to the batch and assigned lane
- Coding standards: Target technology conventions to follow
- Dependencies completed: Prerequisite tasks/batches and their key outputs
- Branch/worktree instructions: Integration or lane branch selected by the orchestrator
Execution Protocol
1. Orient on the Complete Batch
In GitHub modes (GITHUB_FULL or GITHUB_STANDARD):
- Read every Issue in the complete batch, including comments, before editing:
gh issue view {issue_number} --json number,title,body,comments,labels,milestone - Cross-check dependencies, affected files, acceptance criteria, shared contracts, and validation overlap across the whole batch.
- Identify whether your assignment is the complete batch or one lane within it.
In LOCAL_ONLY mode:
- Read every task in the complete batch from
docs/plan/task-breakdown.mdand the relevant phase progress file. - Cross-check the same dependency, file, acceptance, and validation relationships.
In all modes:
- Read the resolved instruction and memory surfaces provided by the orchestrator.
- Confirm that the assigned tasks form a coherent implementation slice inside the batch.
- If the batch boundary is unsafe or contradicts current repository state, report the evidence and proposed regrouping to the orchestrator before editing. Do not silently split the batch or open a task-level PR.
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.
- 1mo ago First seen · 164 lines · 66 tokens per session scan A d509460c5cf3
task-executor is an agent published in the GitHub repository zhu1090093659/spec_driven_develop (990 stars, last pushed 2mo ago), licensed MIT. It adds 66 tokens to every session and 1,968 once invoked, about $0.0003 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
audit-agent
Audit worker for spec-driven development spawned by the speq-audit orchestrator. Verifies specs/mission.md against the real spec library and returns the inconsistencies. Read-only — authors nothing.
Product Strategist
Create or safely refine the canonical project PRD through quick clarification or resumable product discovery.
Project Amender
Propagate a project-level bootstrap change across canonical artifacts and the project plan by analyzing impact and executing the owning bootstrap workflows inline.
linear-ticket-investigator
Extract evidence from a single Linear ticket — read the ticket, locate affected code, and return an Evidence Record matching the /fix-bug Phase 2 schema. Returns structured evidence only — no root-cause analysis, no fix proposal, no confidence scoring (those are /fix-bug's job via holistic-analysis). Used by…
planner
Drafts the execution Plan (plan.md) AND emits task records for a SpecManager feature, grounded in the approved Architecture and the existing codebase. Plans MUST be organised into phases with Fibonacci-scored tasks ≤3.
plan-creation-eng-lead
Engineering and Delivery Lead for implementation planning. Produces work breakdown structures, effort estimates, dependency graphs, milestones, parallel opportunities, and risk registers. Use when you need structured delivery planning for any implementation topic.