---
model: sonnet
---

# /tas-fix $ARGUMENTS

Role: SE - Software Engineer
Quick fix for small bugs or obvious errors — no ticket needed, no full lifecycle.
Use when: solo dev, quick hotfix, bug found during development.
Differs from /tas-bug: no Bug file created, no status tracking, no deploy flow.

## Stack Detection
Read `.tas/rules/common/stack-detection.md`.

## Actions

### 1. Understand bug
$ARGUMENTS is error description, error message, or file:line_number.
- If error message/stack trace provided: parse immediately, identify error file and line
- If only description: ask exactly 1 clarifying question (reproduce steps or expected vs actual)
- DO NOT ask more than 1 question

### 2. Diagnose (max 3 *source* files read)
- Read error file and directly related files
- Identify root cause in 1-2 short sentences
- DO NOT read entire project, DO NOT scan folder structure
- The cap of 3 is for **source/diagnosis** files. Rule files read in Step 3 (security/testing/coding-style) and the regression-test target do **not** count against it.
- If need to read more *source* files beyond the first 3: ask user confirmation

### 3. Fix with regression test

Before fixing, read relevant rules:
- `.tas/rules/common/security.md` — check if fix creates security risks
- `.tas/rules/common/testing.md` — regression test writing patterns
- `.tas/rules/[lang_rules]/coding-style.md` — current stack conventions (if identifiable)

Then:
a. Write 1 minimal test case reproducing bug (if project has test framework)
b. Confirm test FAILS
c. Fix code at root cause
d. Confirm test PASSES
e. Quick run of test suite if available (to check regression)

**Conditional:** for a pure typo / import / config / formatting one-liner with no behavior change, the failing-test step (a–b) may be skipped — write the fix and run the existing suite (e) to confirm no regression. For any logic/behavior change, the failing test is mandatory.

### 3.5 SAD Impact Heuristic (pre-commit)

Read `.tas/rules/common/sad-impact.md` "Quick Heuristic" section. Apply its **diff-qualifier rule** — a signal counts only on an added/changed diff line, never mere file presence (this prevents false STOPs on trivial fixes that happen to touch a matched file). Grep the **diff** of staged / changed files for trigger patterns:

- `package.json` / `*.csproj` / `requirements.txt` / `go.mod` / `Cargo.toml` — deps section `+` lines
- `.env*` / `appsettings*.json` — new key
- `Dockerfile*` / `docker-compose*.yml` — `EXPOSE` / `ENV` / new service
- `migrations/**` / `*.sql` — schema change
- `terraform/**` / `cdk/**` / `k8s/**` / `helm/**` — infra change
- `.github/workflows/**` / `azure-pipelines*.yml` — CI gate change
- New top-level dir under `apps/` / `services/`

**Any qualified hit → STOP.** Output:
> "Fix touches SAD trigger ({matched signal}). `/tas-fix` cannot update SAD properly. Re-run as `/tas-bug` with severity ≥ Medium for proper SAD impact tracking and Changelog audit."

Do NOT commit. Do NOT continue to step 4.

### 4. Wrap up
- Output commit message: `fix: <short description>`
- Remind: "If this bug may recur or affects production, consider using /tas-bug for full tracking."

## Principles
- Total files read ≤ 3 unless permitted
- Fix at root cause, DO NOT patch symptom
- If fix leads to architecture change OR matches SAD Impact Heuristic → stop, suggest `/tas-bug` (which handles SAD update + Changelog) + `/tas-adr` if cross-cutting
- If bug is in production with high severity → stop, suggest using /tas-bug with severity Critical/High

## Final Step — Token Log

Follow `.tas/rules/common/token-logging.md`: write AI Usage Log to related Feature or Bug file (if any).