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 skills/fabriqaai/specs.md/run-executenpx skills add fabriqaai/specs.md --skill run-executegit clone --depth 1 https://github.com/fabriqaai/specs.mdWrote 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/skills/fabriqaai/specs.md/run-execute)<a href="https://agentmods.dev/skills/fabriqaai/specs.md/run-execute"><img src="https://agentmods.dev/badge/skills/fabriqaai/specs.md/run-execute.svg" alt="Measured on agentmods" 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 | $0.00034 | $0.06465 |
| Opus 5 | $0.00017 | $0.03232 |
| Sonnet 5 | $0.00007 | $0.01293 |
| Haiku 4.5 | $0.00003 | $0.00647 |
Grade A, and why
run-execute 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 4d 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 — 715 lines — stays where its author put it; the contents beside it link to each section on GitHub.
<progress_display> Show current position in workflow:
### Run Progress
- [ ] Run initialized (init-run.cjs)
- [ ] Context loaded
- [ ] Plan generated ← {current_step}
- [ ] Implementation
- [ ] Tests passing
- [ ] Code review
- [ ] Run completed (complete-run.cjs)
- [ ] Walkthrough generated
Update markers as you progress: [x] = done, ← current = active step </progress_display>
| Package | Purpose | Install Command |
|---|---|---|
yaml |
Parse/stringify state.yaml | npm install yaml |
<resume_detection critical="true"> Before starting execution, check if resuming an interrupted run:
<check if="runs.active is empty">
<goto step="1">No active run, start fresh</goto>
</check>
<check if="runs.active has entries">
<action>Load active run from state.yaml runs.active[0]</action>
<action>Read scope (single/batch/wide) and work_items array</action>
<substep n="0a" title="Enumerate Work Item Status">
<action>For EACH work item in runs.active[0].work_items, classify by status:</action>
<action>Build status summary from state.yaml (NOT from artifact files):</action>
<format>
[DONE] {item-id} — completed
[WORKING] {item-id} (phase: {current_phase}) — in_progress
[PENDING] {item-id} — pending
</format>
<action>Count: completed={X}, in_progress={Y}, pending={Z}</action>
</substep>
<substep n="0b" title="Determine Resume Point for Current Item">
<action>Get current_item from state.yaml</action>
<action>Read current_phase from the current item's entry in work_items</action>
<determine_resume_point>
Use current_phase from state.yaml to determine resume point:
| current_phase | Resume At |
|---------------|-----------|
| plan (or unset) | Step 3 (Generate Plan) |
| execute | Step 5 (Implementation) |
| test | Step 6 (Run Tests) |
| review | Step 6b (Code Review) |
</determine_resume_point>
</substep>
<llm critical="true">
<mandate>NEVER call --complete-item for items with status "completed" — they are already done</mandate>
<mandate>NEVER re-execute steps (plan, implement, test) for completed items</mandate>
<mandate>ONLY work on the current_item identified in state.yaml</mandate>
<mandate>Use current_phase from state.yaml — do NOT infer phase from artifact file existence</mandate>
</llm>
<output>
Resuming run {run-id} ({scope}) for work item {current_item}.
Mode: {mode}
Phase: {current_phase}
Status: {completed_count} done, {in_progress_count} working, {pending_count} pending
Resuming at: Step {step_number}
</output>
</check>
<degrees_of_freedom> Varies by mode:
- Autopilot: LOW — Execute standard patterns decisively
- Confirm: MEDIUM — Present plan, adjust based on feedback
- Validate: LOW — Follow approved design precisely </degrees_of_freedom>
What ships with it
6 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 4d ago First seen · 715 lines · 34 tokens per session scan A e08f082c2a15
run-execute is a skill published in the GitHub repository fabriqaai/specs.md (205 stars, last pushed 11d ago), licensed MIT. It adds 34 tokens to every session and 6,465 once invoked, about $0.0002 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 skills, from other repositories
stale-sweep
Sweep the googleapis/mcp-toolbox repo for issues and PRs with no real activity in N days (default 60), sort each by whose silence it is (the author's, ours, or nobody's), and draft the nudge or close comment. Use whenever a maintainer asks for a stale sweep, backlog cleanup, or an SLO check, e.g. "stale sweep", "find…
higress-daily-report
生成 Higress 项目每日报告,追踪 issue/PR 动态,沉淀问题处理经验,驱动社区问题闭环。用于生成日报、跟进 issue、记录解决方案。.
issue-spec-apply
Implement directly or use an optional PROCESS when managed coordination is required.
close-task-commit-push-pr
Close the active backlog task (detected from branch name), commit all changes, push to remote, and open a pull request. Use when the user says "close task and ship it", "close task commit push pr", or invokes /close-task-commit-push-pr.
start-task
Create a feature branch for a backlog task, switch to it, and start implementation. Use when the user says "start task-123", "work on task-123", "implement task-123", or invokes /start-task with a task ID.
to-issues
Decompose a PRD and/or SPEC into implementable, vertically-sliced Issues with real blocking edges, then create them in your chosen platform (GitHub or Local). Use after /prd (and optionally /prd-to-spec) to turn requirements into agent-ready tickets. Triggers on: create issues, to-issues, 创建issue, 拆解issue, 生成卡片, 创建卡片…