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/ariel-frischer/autospecWrote 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/commands/ariel-frischer/autospec/autospec.tasks)<a href="https://agentmods.dev/commands/ariel-frischer/autospec/autospec.tasks"><img src="https://agentmods.dev/badge/commands/ariel-frischer/autospec/autospec.tasks/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/commands/ariel-frischer/autospec/autospec.tasks"><img src="https://agentmods.dev/badge/commands/ariel-frischer/autospec/autospec.tasks.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.00008 | $0.02238 |
| Opus 5 | $0.00004 | $0.01119 |
| Sonnet 5 | $0.00002 | $0.00448 |
| Haiku 4.5 | $0.00001 | $0.00224 |
Grade A, and why
autospec.tasks 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 9d 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 — 274 lines — stays where its author put it; the contents beside it link to each section on GitHub.
User Input
$ARGUMENTS
You MUST consider the user input before proceeding (if not empty).
Pre-computed Context
The following paths have been pre-computed and are available for use:
- FEATURE_DIR:
{{.FeatureDir}} - FEATURE_SPEC:
{{.FeatureSpec}} - IMPL_PLAN:
{{.ImplPlan}} - AUTOSPEC_VERSION:
{{.AutospecVersion}} - CREATED_DATE:
{{.CreatedDate}}
Outline
-
Load design documents: Read from the feature directory:
- Required:
{{.ImplPlan}}(plan.yaml) containing:technical_context: tech stack, libraries, constraintsdata_model: entities and relationshipsapi_contracts: API endpoints and schemasresearch_findings: technical decisionsproject_structure: file organization
- Required:
{{.FeatureSpec}}(spec.yaml) containing:user_stories: with priorities (P1, P2, P3)requirements: functional and non-functionalkey_entities: initial entity identification
- Required:
-
Execute task generation workflow:
- Extract tech stack, libraries, project structure from plan.yaml
technical_context - Extract user stories with their priorities from spec.yaml
user_stories - Extract entities from plan.yaml
data_modeland map to user stories - Map endpoints from plan.yaml
api_contractsto user stories - Extract decisions from plan.yaml
research_findingsfor setup tasks - Generate tasks organized by user story (see Task Generation Rules below)
- Generate dependency graph showing user story completion order
- Create parallel execution opportunities per phase
- Validate task completeness (each user story has all needed tasks)
- Extract tech stack, libraries, project structure from plan.yaml
-
Generate tasks.yaml: Create the YAML task file with this structure:
tasks: branch: "<current git branch>" created: "<today's date YYYY-MM-DD>" spec_path: "<relative path to spec file>" plan_path: "<relative path to plan file>" summary: total_tasks: <number> total_phases: <number> parallel_opportunities: <number of tasks marked parallelizable> estimated_complexity: "<low|medium|high>" phases: - number: 1 title: "Setup" purpose: "Project initialization and new package structure" tasks: - id: "T001" title: "<task title with file path>" status: "Pending" # Pending | InProgress | Completed type: "setup" # setup | implementation | test | documentation | refactor parallel: false story_id: null # null for setup/foundational tasks file_path: "<exact file path to create/modify>" dependencies: [] acceptance_criteria: - "<criterion 1>" - number: 2 title: "Foundational" purpose: "Core infrastructure that MUST be complete before user stories" tasks: - id: "T002" title: "<task title>" status: "Pending" type: "implementation" parallel: true # Can run in parallel with T003 story_id: null file_path: "<file path>" dependencies: ["T001"] acceptance_criteria: - "<criterion>" - number: 3 title: "User Story 1 - <US-001 title from spec>" purpose: "<goal from user story>" story_reference: "US-001" independent_test: "<how to test this story independently>" tasks: - id: "T010" title: "<task with file path>" status: "Pending" type: "test" # Tests first per constitution parallel: true story_id: "US-001" file_path: "<test file path>" dependencies: ["T002"] acceptance_criteria: - "<criterion>" - id: "T011" title: "<implementation task>" status: "Pending" type: "implementation" parallel: false story_id: "US-001" file_path: "<source file path>" dependencies: ["T010"] # Depends on test being written acceptance_criteria: - "<criterion>" # Continue with more phases for each user story... - number: <final> title: "Polish & Cross-Cutting Concerns" purpose: "Improvements that affect multiple user stories" tasks: - id: "T099" title: "<polish task>" status: "Pending" type: "refactor" parallel: true story_id: null file_path: "<file path>" dependencies: ["<all prior phases>"] acceptance_criteria: - "<criterion>" dependencies: user_story_order: - story_id: "US-001" depends_on: [] blocks: ["US-002"] - story_id: "US-002" depends_on: ["US-001"] blocks: [] phase_order: - phase: 1 blocks: [2] - phase: 2 blocks: [3, 4, 5] parallel_execution: - phase: 2 parallel_groups: - tasks: ["T002", "T003"] rationale: "Different packages, no dependencies" - phase: 3 parallel_groups: - tasks: ["T010", "T011"] rationale: "Test and implementation can be developed together" implementation_strategy: mvp_scope: phases: [1, 2, 3] description: "Setup + Foundational + User Story 1" validation: "<how to validate MVP>" incremental_delivery: - milestone: "Foundation Ready" phases: [1, 2] deliverable: "<what's usable at this point>" - milestone: "MVP Complete" phases: [1, 2, 3] deliverable: "<what's usable>" _meta: version: "1.0.0" generator: "autospec" generator_version: "{{.AutospecVersion}}" created: "{{.CreatedDate}}" artifact_type: "tasks"
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.
- 9d ago First seen · 274 lines · 8 tokens per session scan A e26611ea68a2
autospec.tasks is a command published in the GitHub repository ariel-frischer/autospec (141 stars, last pushed 1mo ago), licensed MIT. It adds 8 tokens to every session and 2,238 once invoked, about $0.0000 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 commands, from other repositories
speckit.companion.implement
Companion implement — execute tasks.md in dependency order, then mark complete.
speckit.companion.plan
Companion plan — implementation plan with research & design artifacts.
speckit.companion.doctor
Report on a spec's run health — unfinished steps, unjournaled tasks, step bleed, drift you can judge, a step that closed having verified nothing, a step that closed without the file it promised, and why completion did not land (read-only, retroactive, never halts).
speckit.companion.living-move
Move a living spec between central and colocated storage — file, tiers, and registry together (opt-in, reversible).
speckit.companion.living-validate
Check the shape of living specs and a feature spec's deltas — a requirement with no scenario, a scenario missing WHEN or THEN, a duplicate heading, a delta pointing at nothing (opt-in, read-only, never halts).
speckit.companion.after-specify
Capture the current spec-kit step into .spec-context.json for the Companion GUI.