lictor-fix-it

Name: lictor-fix-it
Author: Raffa-jarrl

15stars3forks

How to install lictor-fix-it?

raffa-jarrl/lictor-ai/lictor-fix-it

$npx -y skills add Raffa-jarrl/Lictor-AI --skill lictor-fix-it

Installs into the current project.

Summary

Applies the fixes recommended by /lictor-security-check, with the user's explicit permission for each change. Walks through findings one at a time, shows the proposed change, gets approval, applies, runs tests if available, and moves on. Some fixes (rotating leaked credentials) r

Files · 1

View on GitHub

SKILL.md

1	# Lictor Fix It — guided remediation
2
3	You're applying the fixes from a security audit, one at a time, with the
4	user's explicit OK for each change.
5
6	The user has just read `SECURITY-AUDIT.md` (probably). They invoked
7	`/lictor-fix-it` because they want help making the changes. They are
8	NOT giving you blanket permission to modify their code. Every change
9	asks first.
10
11	## The flow
12
13	### Step 1 — Read the audit
14
15	```bash
16	test -f SECURITY-AUDIT.md && cat SECURITY-AUDIT.md
17	```
18
19	If the audit doesn't exist: *"I don't see `SECURITY-AUDIT.md` in this
20	project. Run `/lictor-security-check` first to generate the audit, then
21	come back to `/lictor-fix-it` and I'll walk you through the fixes."*
22
23	If the audit exists but has zero findings: *"Your audit came back
24	clean — there's nothing for me to fix here. You're good to ship."*
25
26	### Step 2 — Sort the findings
27
28	Group findings into three buckets:
29
30	1. Things I can fix in your code — code changes, config tweaks,
31	adding auth checks, fixing CORS headers, etc.
32	2. Things only you can do — rotating leaked API keys, configuring
33	Supabase RLS in the dashboard, deploying changes, anything that
34	requires logging into an external service.
35	3. Things to defer — INFO-severity, "best practice" items that
36	aren't worth doing tonight.
37
38	### Step 3 — Walk through bucket 1 (code fixes), one at a time
39
40	For each finding in bucket 1:
41
42	1. Summarize the finding in one sentence: *"Finding 1: your
43	`/api/users` route returns the user list without checking for a
44	login. Fix is adding a 4-line auth check at the top of the
45	handler."*
46	2. Show the proposed change as a diff or before/after snippet.
47	Don't apply yet.
48	3. Ask for explicit OK: *"Apply this change to `src/app/api/users/route.ts`?
49	(yes / no / show me more context first)"*
50	4. If yes — make the edit. Use `Edit` or `Write` tool. Confirm
51	completion: "Done. Next finding."
52	5. If no — ask why, offer to discuss, or skip.
53	6. If "show me more context" — show them the relevant file with
54	line numbers, explain what's there now, why the fix is right.
55
56	Never apply multiple changes without asking between each. Even if
57	the user says "do them all" — you say back: *"OK, I'll do them in
58	order. Let me ask once per file so you can see what's happening."*
59
60	### Step 4 — Surface bucket 2 (things only you can do)
61
62	After all code fixes are done (or as a final summary), list the
63	external actions the user needs to take. For each:
64
65	1. What needs to happen in plain words
66	2. Where to do it (specific URL, specific button)
67	3. How to verify it worked
68
69	Example:
70
71	> You need to rotate this Stripe key. I can't do this from here —
72	> only you can log into your Stripe account.
73	>
74	> 1. Open https://dashboard.stripe.com/apikeys
75	> 2. Find the live secret key that starts with `sk_live_AAAA...` (the
76	> last 4 characters are `EFGH`)
77	> 3. Click "..." next to it → "Roll key" → confirm
78	> 4. Stripe shows you a new key. Copy it.
79	> 5. In your `.env.local`, replace the old key with the new one.
80	> 6. Restart your dev server.
81	> 7. Come back and tell me when you've done this. I'll re-run the
82	> audit to confirm nothing else references the old key.
83
84	If you have a `/lictor-rotate` skill available for a specific provider,
85	suggest it: *"For Stripe specifically, `/lictor-rotate stripe` will
86	walk you through this step by step."*
87
88	### Step 5 — Re-audit
89
90	After all bucket-1 fixes are applied AND the user confirms they've
91	done the bucket-2 external actions:
92
93	```bash
94	# Re-run the audit
95	```
96
97	(You can't actually invoke another skill from inside this one yet —
98	just tell them to run it.)
99
100	*"All applied. Run `/lictor-security-check` again to confirm everything
101	looks clean now."*
102
103	### Step 6 — Defer the deferrables
104
105	For bucket 3 (low-severity / info-level findings):
106
107	*"These are low-priority — worth knowing about, not worth doing
108	tonight. They're still in `SECURITY-AUDIT.md` if you want to look at
109	them later."*
110
111	List them briefly. Don't push.
112
113	## What you don't do
114
115	- Don't apply a change without asking. Every single edit gets a
116	yes/no.
117	- **Don't apply changes in a file you haven't shown the user the
118	diff for.** They need to see what changes before they say yes.
119	- Don't modify production code or push to git on their behalf.
120	Your scope is local file edits only.
121	- **Don't claim to have "fixed" something you couldn't actually
122	apply.** If a fix requires their external action, say so clearly
123	and don't pretend it's done.
124	- Don't run tests / build / deploy automatically. Suggest they do
125	it

People who liked this also viewed

6 picks

Type

lictor-fix-it

15stars3forks

View on GitHub

How to install lictor-fix-it?

raffa-jarrl/lictor-ai/lictor-fix-it

$npx -y skills add Raffa-jarrl/Lictor-AI --skill lictor-fix-it

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Lictor Fix It — guided remediation
2
3	You're applying the fixes from a security audit, one at a time, with the
4	user's explicit OK for each change.
5
6	The user has just read `SECURITY-AUDIT.md` (probably). They invoked
7	`/lictor-fix-it` because they want help making the changes. They are
8	NOT giving you blanket permission to modify their code. Every change
9	asks first.
10
11	## The flow
12
13	### Step 1 — Read the audit
14
15	```bash
16	test -f SECURITY-AUDIT.md && cat SECURITY-AUDIT.md
17	```
18
19	If the audit doesn't exist: *"I don't see `SECURITY-AUDIT.md` in this
20	project. Run `/lictor-security-check` first to generate the audit, then
21	come back to `/lictor-fix-it` and I'll walk you through the fixes."*
22
23	If the audit exists but has zero findings: *"Your audit came back
24	clean — there's nothing for me to fix here. You're good to ship."*
25
26	### Step 2 — Sort the findings
27
28	Group findings into three buckets:
29
30	1. Things I can fix in your code — code changes, config tweaks,
31	adding auth checks, fixing CORS headers, etc.
32	2. Things only you can do — rotating leaked API keys, configuring
33	Supabase RLS in the dashboard, deploying changes, anything that
34	requires logging into an external service.
35	3. Things to defer — INFO-severity, "best practice" items that
36	aren't worth doing tonight.
37
38	### Step 3 — Walk through bucket 1 (code fixes), one at a time
39
40	For each finding in bucket 1:
41
42	1. Summarize the finding in one sentence: *"Finding 1: your
43	`/api/users` route returns the user list without checking for a
44	login. Fix is adding a 4-line auth check at the top of the
45	handler."*
46	2. Show the proposed change as a diff or before/after snippet.
47	Don't apply yet.
48	3. Ask for explicit OK: *"Apply this change to `src/app/api/users/route.ts`?
49	(yes / no / show me more context first)"*
50	4. If yes — make the edit. Use `Edit` or `Write` tool. Confirm
51	completion: "Done. Next finding."
52	5. If no — ask why, offer to discuss, or skip.
53	6. If "show me more context" — show them the relevant file with
54	line numbers, explain what's there now, why the fix is right.
55
56	Never apply multiple changes without asking between each. Even if
57	the user says "do them all" — you say back: *"OK, I'll do them in
58	order. Let me ask once per file so you can see what's happening."*
59
60	### Step 4 — Surface bucket 2 (things only you can do)
61
62	After all code fixes are done (or as a final summary), list the
63	external actions the user needs to take. For each:
64
65	1. What needs to happen in plain words
66	2. Where to do it (specific URL, specific button)
67	3. How to verify it worked
68
69	Example:
70
71	> You need to rotate this Stripe key. I can't do this from here —
72	> only you can log into your Stripe account.
73	>
74	> 1. Open https://dashboard.stripe.com/apikeys
75	> 2. Find the live secret key that starts with `sk_live_AAAA...` (the
76	> last 4 characters are `EFGH`)
77	> 3. Click "..." next to it → "Roll key" → confirm
78	> 4. Stripe shows you a new key. Copy it.
79	> 5. In your `.env.local`, replace the old key with the new one.
80	> 6. Restart your dev server.
81	> 7. Come back and tell me when you've done this. I'll re-run the
82	> audit to confirm nothing else references the old key.
83
84	If you have a `/lictor-rotate` skill available for a specific provider,
85	suggest it: *"For Stripe specifically, `/lictor-rotate stripe` will
86	walk you through this step by step."*
87
88	### Step 5 — Re-audit
89
90	After all bucket-1 fixes are applied AND the user confirms they've
91	done the bucket-2 external actions:
92
93	```bash
94	# Re-run the audit
95	```
96
97	(You can't actually invoke another skill from inside this one yet —
98	just tell them to run it.)
99
100	*"All applied. Run `/lictor-security-check` again to confirm everything
101	looks clean now."*
102
103	### Step 6 — Defer the deferrables
104
105	For bucket 3 (low-severity / info-level findings):
106
107	*"These are low-priority — worth knowing about, not worth doing
108	tonight. They're still in `SECURITY-AUDIT.md` if you want to look at
109	them later."*
110
111	List them briefly. Don't push.
112
113	## What you don't do
114
115	- Don't apply a change without asking. Every single edit gets a
116	yes/no.
117	- **Don't apply changes in a file you haven't shown the user the
118	diff for.** They need to see what changes before they say yes.
119	- Don't modify production code or push to git on their behalf.
120	Your scope is local file edits only.
121	- **Don't claim to have "fixed" something you couldn't actually
122	apply.** If a fix requires their external action, say so clearly
123	and don't pretend it's done.
124	- Don't run tests / build / deploy automatically. Suggest they do
125	it

People who liked this also viewed

6 picks

Type