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 skills add ffroliva/gflow-cli --skill issue-resolvegit clone --depth 1 https://github.com/ffroliva/gflow-cliWrote 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/ffroliva/gflow-cli/issue-resolve)<a href="https://agentmods.dev/skills/ffroliva/gflow-cli/issue-resolve"><img src="https://agentmods.dev/badge/skills/ffroliva/gflow-cli/issue-resolve/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/skills/ffroliva/gflow-cli/issue-resolve"><img src="https://agentmods.dev/badge/skills/ffroliva/gflow-cli/issue-resolve.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium Excessive Agency · line 43 Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.Fix: Add human-in-the-loop confirmation for destructive, irreversible, or high-impact operations. Never auto-execute commands that modify files, send data, or alter system state.
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.00097 | $0.03657 |
| Opus 5.5 | $0.00039 | $0.01463 |
| Sonnet 5.5 | $0.00019 | $0.00731 |
| Haiku 4.5 | $0.00010 | $0.00366 |
Grade A, and why
issue-resolve 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 — 266 lines — stays where its author put it; the contents beside it link to each section on GitHub.
issue-resolve — drive an assessed issue to a draft PR
Takes a verdict from issue-assessment and produces a reviewable fix. The
terminal state is a draft PR a human promotes — never an autonomous merge.
Core principle: the agent's job is to get the problem review-ready, not
to declare victory. A fix is "verified" only after it runs green on the
affected surface; when that surface can't be reached here (headed Flow
browser, macOS-only, credits), say so in the PR and stop. (Memory:
done-means-e2e-verified, pr-must-verify-on-affected-surface.)
The Bug Lane — canonical here, cited everywhere
This is the chain a bug travels in gflow-cli. It is written out once, in this
file. AGENTS.md, skills/spike, skills/scenario and docs/E2E_TESTING.md all
point here — none of them restate it, because a duplicated checklist drifts.
0 SPIKE measure the live surface ── only when a claim about Flow is in play
1 DEBUG systematic-debugging → ROOT CAUSE ── the symptom is never the finding
2 SCENARIO BDD Gherkin written at the ROOT ── the reproduction, in Given/When/Then
3 TDD that Gherkin RED before any fix ── red for the right reason
4 FIX minimal change, at the root ── grep every caller before editing one
5 FORMALIZE UI/Flow surface ⇒ it is an E2E test ── a browser-free proxy does not discharge it
The surface gate — steps 0–2 are conditional, 3–5 never are
Run 0 SPIKE when the bug's explanation involves what Flow does — a selector, a wire response, a host behaviour, any claim of absence. Skip it when the cause is already proven or lives entirely in our own code.
Run 1 DEBUG and 2 SCENARIO whenever the bug touches a Flow surface, a
transport, auth, selectors, or the cause is not yet proven. Skip both for a
fix whose cause is self-evident and whose blast radius is one line — a typo, an
exit-code string, a doc correction. A skip is a claim; say it out loud ("cause
proven at <file>:<line>, skipping the debug step") so the skip is reviewable.
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 Changed · +129 lines f747f6ce63d8
- 1mo ago First seen · 137 lines · 97 tokens per session scan A ae8d42ea8fcf
issue-resolve is a skill published in the GitHub repository ffroliva/gflow-cli (299 stars, last pushed today), licensed MIT. It adds 97 tokens to every session and 3,657 once invoked, about $0.0004 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 skills, from other repositories
test-failure-explorer
Import and query an existing Vitest 3.2 JSON report to explore test failures, file-level errors and original diagnostic evidence.
hatch3r-bug-fix
Step-by-step bug fix workflow. Diagnose root cause, implement minimal fix, write regression test. Use when fixing bugs, working on bug report issues, or when the user mentions a bug.
hatch3r-logical-refactor
Workflow for changing behavior or logic flow without adding new features or overhauling UI. Use when modifying business logic, data flows, behavioral rules, or working on logical refactor issues.
fix-bug
Investigates and fixes a reported bug. Reads relevant code, identifies the root cause, proposes a fix, and adds or updates tests to prevent regression. Invoked when the user describes unexpected behavior, an error, a crash, or a failing test.
terraform-risk-playbook
Diagnoses Terraform/OpenTofu risk before generating changes. Defines the response contract, failure-mode routing, version/runtime guards, validation commands, and rollback expectations for modules, tests, CI, and state work.
codegraph
Analyze indexed codebases via graph database (neug) and vector index (zvec). Covers call graphs, dependencies, dead code, hotspots, module coupling, architecture reports, semantic search, impact analysis, bug root cause from GitHub issues, class diagrams (UML), and PR review (risk scoring, conflict detection…