git:20260619.f71b368 to git:20260807.dd89e45

31 added, 33 removed. Audit A to A.

---

name: clud-fix-quick

- description: Local-first speed mode. Edits in place on the current branch, runs lint + targeted test + /clud-review on source-code changes only, skips all three for docs/config/SKILL.md. Pushes direct; falls back to PR + admin-merge without waiting for CI when the branch is protected. Sibling of /clud-fix; trades rigor for iteration speed.

+ description: Local-first speed mode. Edits in place on the current branch, runs lint + targeted test + /clud-review on source-code changes only, skips all three for docs/config/SKILL.md. Pushes direct; falls back to PR + admin-merge without waiting for CI when the branch is protected. Trades rigor for iteration speed; escalate to /goal when the change is large or risky.

triggers:

- When the user says "/clud-fix-quick <issue-or-task>"

- When the user asks to "quickly fix" / "just push" / "iterate fast" / "speed mode"

- When the user wants a small, well-understood change shipped without the full worktree/CI scaffold

- When iterating on docs, SKILL.md, README, or other non-source files

---

# /clud-fix-quick

- Speed-mode sibling of [[clud-fix]]. Edits files in place on the current

+ Speed mode for small, well-understood changes. Edits files in place on the current

branch (no disposable worktree), runs the smallest set of gates that

still catches regressions, then pushes — directly when the branch

allows, or via a PR that gets admin-merged immediately when the branch

is protected. The targeted-test step (when source files change) is the

GREEN signal that the change works; this skill delegates the RED ->

GREEN cycle to that focused test rather than running a full ritual,

trading some rigor for iteration speed.

- Not a replacement for `/clud-fix` — that's the right tool when the

- change matters or when the user wants paper trail through CI. Use

+ Not a replacement for `/goal` — lock in a deliverable and drive to it

+ when the change matters or when the user wants a paper trail through

+ CI. Use

`/clud-fix-quick` when you already know what to change and want it on

main / your branch in seconds.

## Input

- A GitHub issue URL or number — the task to implement.

- A bare description of a small fix when no issue exists (e.g.

`/clud-fix-quick fix the typo in docs/architecture/crash-reports.md

line 27`).

- Optional flags:

- `--no-review` skips the `/clud-review` step on source changes

(use sparingly — for mass typo fixes, generated-code updates,

revert-style commits where review can't help).

- `--no-test` skips the targeted test (use even more sparingly —

only for changes that genuinely have no exercisable test).

- For multi-forge inputs, the same forge-recognition rules from

- [[clud-fix]] / [[clud-pr]] / [[clud-do]] apply — read the URL prefix

+ For multi-forge inputs, the same forge-recognition rules used

+ elsewhere apply — read the URL prefix

or infer from `git remote get-url origin` for bare-number inputs.

## Hard Rules

1. **Current-branch warning is non-skippable.** If the active branch

(`git rev-parse --abbrev-ref HEAD`) is not the repo's default

branch, print the following warning verbatim in ALL CAPS at the

top of the run, before any edit:

```

⚠ WARNING: COMMITTING DIRECTLY TO FEATURE BRANCH `<branch-name>`.

THIS IS NOT A DISPOSABLE WORKTREE — A BAD EDIT WILL LIVE ON YOUR

BRANCH. PROCEED ONLY IF YOU ARE SOLE AUTHOR OF THIS BRANCH.

```

Continue the run; the warning is a heads-up, not a gate.

2. **No full test suite.** Run only the targeted test that exercises

the change. Targeted-test selection rules per language:

- **Rust**: `soldr cargo test -p <crate> --lib <module>::<test-name>`

or `--test <file>` matching the changed file.

- **Python**: `pytest -k <pattern>` matching the changed file or

test name.

- **JS/TS**: `npm test -- -t <pattern>` matching the changed file

or test name.

- **Shell**: no test framework standard; skip with a one-line

notice and continue.

If no targeted test exists for the changed file, print

`no targeted test found for <file>; proceeding without regression

check` and continue. Do NOT fall back to the full suite — that

would defeat the whole point of this skill.

3. **Lint scoped to the touched files.** Use `bash lint --files

<changed-files>` if the script supports per-file linting;

otherwise run the project's default lint and accept the time cost.

Lint failure blocks the push.

4. **`/clud-review` runs on source-code changes only.** Skip for

- docs/config/SKILL.md/markdown. When it runs, use the same

- delegated-mode contract as `/clud-fix` does — [[clud-review]]

+ docs/config/SKILL.md/markdown. When it runs, use

+ [[clud-review]]'s delegated-mode contract — it

returns structured findings and the agent decides whether to

address CRITICAL/HIGH ones before pushing. MEDIUM/LOW are

advisory.

5. **No worktree, no `/goal`, no Stop hook installation.** This skill

doesn't own a goal; it just does the work in the current checkout

and reports.

6. **Direct push first, PR + admin-merge fallback second.** Try

`git push origin <current-branch>`. If it succeeds, surface the

commit SHA and stop. If it fails with `protected branch` / `remote

rejected`, open a PR (`gh pr create --base <default-branch>`),

then `gh pr merge <num> --admin --squash --delete-branch`

immediately — no `--auto`, no waiting for CI. The skill trusts

the local gates that already passed (lint + targeted test +

`/clud-review`).

- 7. **Never `--no-verify`, never skip hooks.** Same as [[clud-fix]] and

- [[clud-pr]]. Hook failures are real signals; fix them, don't

- bypass them.

+ 7. **Never `--no-verify`, never skip hooks.** Hook failures are real

+ signals; fix them, don't bypass them.

8. **No force-push.** If the local branch has diverged from the

remote, surface the divergence and stop. Speed mode doesn't mean

destructive.

## Target Classification

The skill classifies the touched files and runs the matching gates.

Mixed-class changes run the union (so any source file in the diff

triggers all three source gates).

|---|---|---|---|---|

| `.rs`, `.py`, `.ts`, `.tsx`, `.js`, `.jsx`, `.go`, `.c`, `.cpp`, `.h`, `.hpp`, `.java`, `.kt`, `.swift` | source | yes | yes | yes |

| `.md`, `.txt`, `.rst`, `.adoc` | docs | no | no | no |

| `.yaml`, `.yml`, `.toml`, `.json`, `.ini` (NOT package manifests) | config | no | no | no |

- | `SKILL.md`, `CLAUDE.md`, `AGENTS.md`, `README.md` | docs (skill/guidance) | no — but RUN the bundled-skill guardrail tests (`skills::` and `skill_install::`) if any `crates/clud-bin/assets/skills/*/SKILL.md` was touched | bundled-skill guardrails | no |

+ | `SKILL.md`, `CLAUDE.md`, `AGENTS.md`, `README.md` | docs (skill/guidance) | no — but RUN the bundled-skill guardrail tests (`skills::`) if any `crates/clud-bin/assets/skills/*/SKILL.md` was touched | bundled-skill guardrails | no |

| `.github/workflows/*.yml`, `.github/instructions/*.md` | CI / instructions | no | no | no |

| everything else | other | no | no | no |

A polyglot change touching `.rs` and `.md` files is a source change

for review purposes; run the source gates.

## Workflow

1. **Branch check + warning.** Run `git rev-parse --abbrev-ref HEAD`.

Compare against the default branch (`gh repo view --json

defaultBranchRef --jq .defaultBranchRef.name`). If they differ,

print the ALL CAPS warning from Hard Rule 1.

2. **Read the task.** Resolve the issue URL/number via `gh issue

view` (or the equivalent native CLI per the forge-recognition

rules), or use the freeform sentence directly.

3. **Implement in place.** Edit files directly in the current

checkout — no worktree, no branch creation, no `.claude/`

directory work.

4. **Classify the touched files.** Use the table above. Compute the

set of gates to run as the union across all touched files.

5. **Lint** (if any source file in the diff). Block on failure.

6. **Targeted test** (if any source file in the diff). Block on

failure. If `--no-test` was passed AND the change set is small

AND no targeted test exists, skip with the documented one-line

notice.

7. **`/clud-review`** (if any source file in the diff, unless

`--no-review` was passed). Address CRITICAL/HIGH findings before

push; surface MEDIUM/LOW as advisory.

8. **Commit.** Conventional commit message. Reference the issue

when one exists (`Closes #<num>` in the commit body so auto-close

fires after the merge).

9. **Push.** Try direct push to the current branch

(`git push origin <current-branch>`). On `protected branch` /

`remote rejected` / `non-fast-forward` (for a protected branch),

fall back to the PR path: `gh pr create --base

<default-branch>` then `gh pr merge <num> --admin --squash

--delete-branch` immediately. Do NOT use `--auto` and do NOT wait

for CI — the local gates already validated.

10. **Surface result.** One-line summary: commit SHA on the target

branch, push mode (`direct` or `pr-admin-merged-<pr-num>`), and

any non-default test/lint/review notes.

For code changes specifically, the targeted-test step IS the

RED -> GREEN signal: identify or write the smallest test that

exercises the change (RED before the edit if one didn't exist),

make the change, then rerun that focused test until it passes

- (GREEN). The full-suite version of RED -> GREEN belongs to

- [[clud-fix]]; this skill's targeted-only variant trades coverage

+ (GREEN). The full-suite version of RED -> GREEN belongs to a

+ `/goal`-driven run; this skill's targeted-only variant trades coverage

breadth for iteration speed.

## Failure Modes To Avoid

- **Editing files outside the user's stated scope.** Speed mode

doesn't license drive-by refactoring.

- **Suppressing lint or test failures to "just push it."** That

defeats the purpose of running them at all.

- **Calling a SKILL.md change "docs" and skipping the bundled-skill

guardrails.** A SKILL.md edit IS a guardrail-tested change — run

- `soldr cargo test -p clud --lib skills::` and `skill_install::`.

+ `soldr cargo test -p clud --lib skills::`.

- **Force-pushing the current branch to win a race with another

contributor.** If your push is rejected for non-fast-forward

reasons unrelated to branch protection, that's a real conflict;

stop and surface it.

- **Admin-merging a PR with failing local gates.** The PR-fallback

path only fires when direct push is rejected for protection

reasons; lint / test / review must already be green.

- **Mis-classifying a polyglot change.** A PR touching `.rs` and

`.md` files is a source-code change for review purposes; run the

source gates.

- **Falling back to the full test suite when no targeted test

exists.** Print the documented notice and continue; if the change

- is risky enough that "no test" feels wrong, use [[clud-fix]]

+ is risky enough that "no test" feels wrong, use `/goal`

instead.

## When NOT to use

- - **The change is large or risky.** Use [[clud-fix]] (full rigor:

- worktree, RED -> GREEN, full suite, CI).

- - **The change touches code paths you don't fully understand.** Use

- [[clud-fix]]'s investigation-report branch first.

+ - **The change is large or risky.** Use `/goal` — lock in the

+ deliverable and drive to it with full rigor (worktree,

+ RED -> GREEN, full suite, CI).

+ - **The change touches code paths you don't fully understand.**

+ Investigate first under `/goal`.

- **You're not the sole author of the current feature branch.** Use

- [[clud-pr]] (creates a fresh disposable worktree, opens a PR for

- review).

+ `/goal` and ship through a PR on a fresh disposable worktree so the

+ work gets reviewed.

- **You're on a third-party repo where admin-merge isn't allowed.**

- Use [[clud-pr]] (lets CI do its job; merges only after green).

- - **You need to drive an existing open PR to merge.** Use [[clud-pr]]

- PR Drive Mode (#395).

+ Use `/goal` and let CI do its job; merge only after green.

+ - **You need to drive an existing open PR to merge.** Use `/goal`

+ with the merge as the locked-in deliverable.

## Related

- - [[clud-fix]] — the rigor sibling. Use when the change matters or

- when the user wants the paper trail of full CI + a separate

- worktree.

- - [[clud-pr]] — handles the PR + worktree path; also owns PR Drive

- Mode for actively driving open PRs to merge.

+ - `/goal` — locks in a deliverable and blocks stopping until it's

+ met. The escalation path whenever this skill's speed tradeoffs are

+ the wrong call.

- [[clud-review]] — invoked on source-code changes by Hard Rule 4

and Workflow step 7.

- - [[clud-do]] — could route to `/clud-fix-quick` when the user's

- invocation hints at speed mode (out of scope for this skill's

- introduction; potential follow-up).

+ - [[clud-git]] — worktree / branch / process-audit playbook when a

+ push or teardown gets messy.