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/asysta-act/agent-flow/fix-bugsnpx skills add asysta-act/agent-flow --skill fix-bugsgit clone --depth 1 https://github.com/asysta-act/agent-flowWhat 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.00024 | $0.03495 |
| Opus 5 | $0.00012 | $0.01747 |
| Sonnet 5 | $0.00005 | $0.00699 |
| Haiku 4.5 | $0.00002 | $0.00349 |
Grade A, and why
fix-bugs 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.
How it starts
The opening of the file, as written. The whole thing — 251 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/fix-bugs — Auto-fix Bug Tickets
Use the Read tool to load skills/fix-bugs/data/guard-block.md BEFORE any other instruction
in this file. The guard is load-bearing; it establishes the orchestrator role, blocks
pre-dispatch deferrals, and contains the rationalization-red-flags STOP protocol.
<stage_allowlist> required: [triage, code_analysis, fixer_reviewer, smoke_check, test, publisher] optional: [reproduce_browser, e2e_test, browser_verification, acceptance_gate] </stage_allowlist>
You are a THIN CONTROLLER. You:
- Read state from disk (
.agent-flow/{ISSUE-ID}/state.json) - Follow deterministic decision logic (this document + step files)
- Dispatch fresh subagents via the Task tool (one per step)
- Write atomic state.json updates (including
dispatched_at+dispatch_witnessBEFORE each Task)
You do NOT:
- Reason about the bug domain (subagents do that)
- Inline-execute step logic
- Carry conversation history across steps
- Make quality judgments (reviewers do that)
Overview
This skill runs in two modes, auto-detected from $ARGUMENTS:
- Single-ticket mode —
<ISSUE-ID>positional → full pipeline on the named issue, in CWD (no worktree). - Batch mode —
--batch <N>(or bare integer on string trackers) → query the tracker for N bugs and dispatch the single-ticket pipeline per issue, with the existing worktree / sequential-CWD logic.
Mode is determined automatically (see Step 0a). Resume detection runs immediately after argument parsing for both modes.
Step 0a — Argument auto-detection (tracker-type-aware)
Strip flags first, then classify the surviving positional. The first non-flag token wins as POSITIONAL. Mode (single vs batch) is decided AFTER all flags are consumed.
GOT_BATCH=false; BATCH_N=""; POSITIONAL=""; DRY_RUN=false
GOT_YOLO=false; GOT_STEP_MODE=false; GOT_DECOMPOSE=false; GOT_NO_DECOMPOSE=false
PROFILE_NAME=""; CLARIFICATION_TEXT=""
read -ra ARG_TOKENS <<< "$ARGUMENTS"
i=0
while [ $i -lt ${#ARG_TOKENS[@]} ]; do
tok="${ARG_TOKENS[$i]}"
case "$tok" in
--batch) GOT_BATCH=true; i=$((i+1)); BATCH_N="${ARG_TOKENS[$i]}" ;;
--dry-run) DRY_RUN=true ;;
--yolo) GOT_YOLO=true ;;
--step-mode) GOT_STEP_MODE=true ;;
--decompose) GOT_DECOMPOSE=true ;;
--no-decompose) GOT_NO_DECOMPOSE=true ;;
--profile) i=$((i+1)); PROFILE_NAME="${ARG_TOKENS[$i]}" ;;
--clarification) i=$((i+1)); CLARIFICATION_TEXT="${ARG_TOKENS[$i]}" ;;
--*) ;;
*) [ -z "$POSITIONAL" ] && POSITIONAL="$tok" ;;
esac
i=$((i+1))
done
if $GOT_YOLO && $GOT_STEP_MODE; then echo "[ERROR] --yolo and --step-mode are mutually exclusive" >&2; exit 1; fi
if $GOT_DECOMPOSE && $GOT_NO_DECOMPOSE; then echo "[ERROR] --decompose and --no-decompose are mutually exclusive" >&2; exit 1; fi
# Tracker-type-aware disambiguation: read Type from CLAUDE.md Issue Tracker section.
# String trackers (youtrack|jira|linear): bare integer = batch count. Numeric trackers
# (github|gitea|redmine): bare integer = single ISSUE_ID.
if $GOT_BATCH; then
[[ "$BATCH_N" =~ ^[1-9][0-9]*$ ]] || { echo "[ERROR] --batch requires a positive integer count, got: ${BATCH_N}" >&2; exit 1; }
MODE="batch"; N="$BATCH_N"
elif [ -z "$POSITIONAL" ]; then
echo "[ERROR] Usage: /agent-flow:fix-bugs <ISSUE-ID> | --batch <N>" >&2; exit 1
else
TRACKER_TYPE="$(grep -oE '^\| Type \| [A-Za-z][A-Za-z0-9_-]+' CLAUDE.md | head -1 | awk -F'| ' '{print $3}' | tr -d ' ' | tr '[:upper:]' '[:lower:]')"
if [ -z "$TRACKER_TYPE" ]; then
echo "[WARN] Tracker type not detected; assuming string-tracker semantics (youtrack)" >&2
TRACKER_TYPE="youtrack"
fi
# ISSUE-ID format: ^[A-Za-z][A-Za-z0-9_-]*-[0-9]+$ — always single regardless of tracker.
if [[ "$POSITIONAL" =~ ^[A-Za-z][A-Za-z0-9_-]*-[0-9]+$ ]]; then
MODE="single"; ISSUE_ID="$POSITIONAL"
elif [[ "$POSITIONAL" =~ ^[0-9]+$ ]]; then
case "$TRACKER_TYPE" in
github|gitea|redmine) MODE="single"; ISSUE_ID="$POSITIONAL" ;;
youtrack|jira|linear)
echo "[WARN] Treating bare integer '$POSITIONAL' as batch count for $TRACKER_TYPE (string-tracker)" >&2
MODE="batch"; N="$POSITIONAL" ;;
*)
echo "[WARN] Treating bare integer '$POSITIONAL' as batch count for unknown tracker" >&2
MODE="batch"; N="$POSITIONAL" ;;
esac
else
MODE="single"; ISSUE_ID="$POSITIONAL"
fi
fi
What ships with it
13 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.
- data/guard-block.md 9.3 KB
- steps/01-triage.md 8.6 KB
- steps/02-impact.md 5.6 KB
- steps/03-reproduce.md 4.8 KB
- steps/04-fixer-reviewer-loop.md 9.2 KB
- steps/05-smoke.md 2.4 KB
- steps/06-test.md 3.2 KB
- steps/07-e2e.md 4.6 KB
- steps/08-browser-verify.md 4.5 KB
- steps/09-acceptance-gate.md 3.9 KB
- steps/10-pre-publish.md 3.0 KB
- steps/11-publish.md 3.6 KB
- steps/12-result.md 11 KB
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.
- 2d ago First seen · 251 lines · 24 tokens per session scan A aa3bae60897b
fix-bugs is a skill published in the GitHub repository asysta-act/agent-flow (12 stars, last pushed 1mo ago), licensed MIT. It adds 24 tokens to every session and 3,495 once invoked, about $0.0001 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
team-up
Orchestrate persistent agent teams with TeamCreate. Use when the user says "team up", "spin up a team", or invokes /team-up.
cortivex-pipeline
Build and run AI agent pipelines that decompose complex tasks into coordinated agent workflows.
project-graveyard
Scans the developer's machine for dead side projects, autopsies each one from its git history (died at the payments wall, killed by a newer project, finished but never shipped), surfaces their personal death patterns, and picks the corpse most worth resurrecting — then helps ship it. Use when the user mentions…
web-app-penetration-testing
Pentest a web app or website end to end — black-box testing of a live URL, staging environment, or local dev server that finds and exploits real vulnerabilities (auth bypass, broken access control, IDOR, injection, XSS, SSRF, business logic) and proves each one with a working proof-of-concept instead of a signature…
haiku
When writing a haiku for this bot, follow these conventions.
deploy-docker-compose
Run the Omnigent server as a Docker compose stack (server + Postgres) on any Docker host — your laptop, a VPS, EC2 by hand, or as the base layer of any container-platform deploy. Invoke when the user wants to build the image, bring up the compose stack, debug the stack on a host they already have, or extend the stack…