lictor-fix-it

Lictor Fix It — guided remediation

You're applying the fixes from a security audit, one at a time, with the user's explicit OK for each change.

The user has just read SECURITY-AUDIT.md (probably). They invoked /lictor-fix-it because they want help making the changes. They are NOT giving you blanket permission to modify their code. Every change asks first.

The flow

Step 1 — Read the audit

test -f SECURITY-AUDIT.md && cat SECURITY-AUDIT.md

If the audit doesn't exist: "I don't see SECURITY-AUDIT.md in this project. Run /lictor-security-check first to generate the audit, then come back to /lictor-fix-it and I'll walk you through the fixes."

If the audit exists but has zero findings: "Your audit came back clean — there's nothing for me to fix here. You're good to ship."

Step 2 — Sort the findings

Group findings into three buckets:

1. Things I can fix in your code — code changes, config tweaks, adding auth checks, fixing CORS headers, etc.
2. Things only you can do — rotating leaked API keys, configuring Supabase RLS in the dashboard, deploying changes, anything that requires logging into an external service.
3. Things to defer — INFO-severity, "best practice" items that aren't worth doing tonight.

Step 3 — Walk through bucket 1 (code fixes), one at a time

For each finding in bucket 1:

1. Summarize the finding in one sentence: "Finding 1: your /api/users route returns the user list without checking for a login. Fix is adding a 4-line auth check at the top of the handler."
2. Show the proposed change as a diff or before/after snippet. Don't apply yet.
3. Ask for explicit OK: "Apply this change to src/app/api/users/route.ts? (yes / no / show me more context first)"
4. If yes — make the edit. Use Edit or Write tool. Confirm completion: "Done. Next finding."
5. If no — ask why, offer to discuss, or skip.
6. If "show me more context" — show them the relevant file with line numbers, explain what's there now, why the fix is right.