---
name: ao-quickfix
description: "Expedited path for trivial changes. Auto-creates issue for audit trail, skips planning iterations, defaults to high confidence."
---

**MANDATORY: Always use the ao-worker agent for this workflow.**

Use this prompt for trivial changes only:
- Typo fixes
- Documentation-only changes
- Small config tweaks
- Comment updates

## Quickfix workflow

1. **Auto-create issue**: Generate a minimal issue from the description
   ```
   Creating CHORE-{N}@{hash} — {description}
   ```
   - Type: Usually `CHORE` or `DOCS`
   - Priority: `low` (quickfixes are by definition low-impact)
   - Description: Derived from user's quickfix request
   - **No reference file** — quickfixes don't need detailed implementation specs

2. **Confirm scope**: Verify change is truly trivial (no logic changes, no new behavior)
3. **Set confidence**: HIGH (default for quickfix)
4. **Implementation details**: LOW (or skip entirely — quickfixes are self-documenting)
5. **Skip planning**: Go directly to implementation
6. **Implement**: Make the change
7. **Log quickfix path**: Update issue or focus with `[quickfix path used]` marker
8. **Validate (MINIMUM Tier 2)**: Even for "trivial" changes, run Tier 2 validation:
   - Lint + format check (mandatory)
   - Type checking if applicable (mandatory)
   - Run affected tests (mandatory if code changed)
   - Compare against baseline if exists
   **Note:** Quickfix does NOT allow skipping validation to Tier 1 only.
9. **Review**: Brief — compare to baseline, ensure no regressions
10. **Auto-complete issue**: Move issue to history
    ```
    ✅ CHORE-{N}@{hash} complete [quickfix]
    ```
11. **Retrospective**: Brief — note what was done, include "quickfix path used" in log

## Issue Creation Rules

- **Single fix**: One issue, auto-named from request
- **Multiple fixes**: One issue per distinct change, or one umbrella issue if related
- **Commit message**: Reference the issue ID (`chore: fix typo [CHORE-0042@abc123]`)

## Guardrails

If ANY of these are true, **exit quickfix and use normal workflow**:
- Change touches more than 3 files
- Change modifies function/method logic
- Change adds/removes dependencies
- Tests need updating
- User is uncertain if it's trivial

## PROHIBITED Use Cases (NEVER use quickfix for these)

Quickfix is **explicitly forbidden** for:
- **Database migrations** — schema changes always need planning
- **Security-sensitive code** — auth, crypto, input validation, secrets handling
- **Complex refactors** — anything touching multiple concerns or changing architecture
- **API changes** — endpoint modifications, contract changes, versioning
- **Configuration with side effects** — CI/CD changes, environment config, deployment scripts
- **Performance-critical paths** — algorithmic changes, caching, concurrency
- **Cross-cutting concerns** — logging infrastructure, error handling patterns

When in doubt: **use normal workflow**. Quickfix saves time only when truly trivial.

## Confidence override

Quickfix defaults to HIGH confidence, meaning:
- Soft approval gates only
- Smaller review scope
- Can bundle multiple trivial changes
- **Low implementation details** (or none) — no reference file needed

User can override: "quickfix with low confidence" → adds harder gates + more detail.
