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/thixpin/pitwayWrote 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/thixpin/pitway/quick-change)<a href="https://agentmods.dev/commands/thixpin/pitway/quick-change"><img src="https://agentmods.dev/badge/commands/thixpin/pitway/quick-change/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/thixpin/pitway/quick-change"><img src="https://agentmods.dev/badge/commands/thixpin/pitway/quick-change.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.00000 | $0.01522 |
| Opus 5.5 | $0.00000 | $0.00609 |
| Sonnet 5.5 | $0.00000 | $0.00304 |
| Haiku 4.5 | $0.00000 | $0.00152 |
Grade A, and why
quick-change 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 — 108 lines — stays where its author put it; the contents beside it link to each section on GitHub.
quick-change
Role: Main Agent (create, approve, run, commit, cancel, promote) · either (status)
pitway quick-change create --objective <text> [--scope <path> ...] --verify <command> [--tdd-exempt <reason>] [--closes <backlog-id>] [--json]
pitway quick-change approve <change-id> [--json]
pitway quick-change run <change-id> [--json]
pitway quick-change commit <change-id> [--json]
pitway quick-change cancel <change-id> [--json]
pitway quick-change promote <change-id> [--json]
pitway quick-change status [change-id] [--json]
Use for a small, bounded fix that fits in one atomic commit, whenever
active_milestone is null — it cannot run while any milestone is
active, in any status (draft, confirmed, in_progress, or review); a bug
discovered inside an active milestone must use the existing
milestone/task/ripple-fix workflow instead, never quick-change. Never to
reopen, rewrite, or amend a prior milestone or any of its existing
commits.
Bounded means bounded. If investigation surfaces a schema/API change,
a new or changed dependency, a security-sensitive change beyond the
immediate defect, a migration, multi-subsystem impact, or anything
otherwise architectural, stop and run quick-change promote <change-id>
instead of continuing — propose converting the work into a Milestone.
For a defect fix, follow this full sequence, always in order (bug-fix
skill + TDD discipline B020 + human-approval gate B021):
- Investigate and reproduce. Use the
bug-fixskill: confirm the bug with a concrete failing case first. If the root cause isn't yet known, usedebuggingto establish one before continuing — never guess. - Confirm the root cause. State it in one sentence, and check that the fix you're about to make targets it, not the symptom.
quick-change create --objective <text> --scope <path>... --verify <command> [--tdd-exempt <reason>] [--closes <backlog-id>]— requiresactive_milestone: nulland a clean working tree.--objectiveshould name the bug and the confirmed root cause;--scopedeclares the exact file census the fix may touch — an allow-list ceilingcommitenforces, not a requirement that every declared path be modified. Prefer extending an existing adjacent test as--verify; only add a new one when nothing already covers this path.--closes <backlog-id>links this change to a pending backlog item it resolves —createvalidates the id exists and ispending(refuses with a clear error otherwise). Optional; a change with no--closeshashes identically to one predating the flag.quick-change approve <change-id>— hashes and locks the declared scope/verify command (and any--tdd-exemptreason).- Reproduce / RED. Write the regression test before the fix whenever
the bug is testable — it must fail on the current code for the same
reason the bug occurs. Confirm RED via
quick-change run <change-id>(expectfail). For doc-only / genuinely test-free changes where no meaningful failing test can exist, pass--tdd-exempt "<reason>"atcreateinstead — the only sanctioned bypass; never fabricate a synthetic failing test to satisfy the gate. - Fix minimally. The smallest change that removes the root cause — no drive-by refactoring in the same commit.
- GREEN + related verification. Confirm GREEN via
quick-change run <change-id>(expectpass), then also run the smallest relevant surrounding tests to catch collateral damage, and check for sibling call sites sharing the same defect. - Manual browser verification, when the fix touches frontend-visible
behavior. Exercise the actual change in the browser before requesting
approval — in addition to, not instead of, the automated
--verifycommand; there is no separate PitWay state for this, just a step you take and report before step 9. - Human approval, before
commit. Present the diff (or a summary of it) and the run history, and wait for the developer's explicit yes in this conversation — same MUST rule asmilestone-confirm(../protocol-driver.md"Decision authority and gates", B021). The original bug report or fix request authorized the investigation, not the commit. quick-change commit <change-id>— lands one commit carrying aPitWay-Change: <change-id>trailer, only once the latest run passed and, unless--tdd-exemptwas declared, at least one priorfailexists in the run history (enforced RED→GREEN). A singlepasswith no priorfailis refused. When the change was created with--closes <backlog-id>, the linked backlog item is archived in this same atomic commit as the fix — one commit, never a separate one, and the trailer staysPitWay-Change: <change-id>only. The archive is checked against the item's current status first, so a crash/retry between a successful archive and the landed commit is a safe no-op, never a hard failure.
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 · 108 lines · 0 tokens per session scan A 6fa7a53cde42
quick-change is a command published in the GitHub repository thixpin/pitway (20 stars, last pushed yesterday), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 1,522 tokens. 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
deja
Search this machine's past AI coding sessions (deja-vu).
implement
Execute all implementation tasks from tasks.md with test-driven development, parallel batching, and atomic commits.
conventions-check
Check AGENTS.md, CLAUDE.md, and the projected agent artifacts (skills, subagents, commands) against the repo's conventions.
debug
Systematic root-cause investigation, then fix with TDD — never proposes a fix before finding the cause; resumable diagnosis + regression test in .orc/ state. Workspace-aware. For a quick one-off look without session state, prefer the bundled /debug.
tidy
Consistency check for non-code repos with INDEX.md hierarchy. Verifies INDEX.md accuracy, MEMORY.md references, orphaned files, stale dates, and WAITING markers.
crear-skill
Crear, probar y mejorar skills de forma iterativa. Usa cuando el usuario dice "crear skill", "crear habilidad", "build skill", "create a skill", "skill development", "desarrollar skill", "nueva habilidad". Usa el workflow: draft → test → review → improve → repeat con evaluación cuantitativa y qualitative review.