surgical

Name: surgical
Author: albertobarnabo

48stars1forks

How to install surgical?

albertobarnabo/lazy-cat/surgical

$npx -y skills add albertobarnabo/lazy-cat --skill surgical

Installs into the current project.

Summary

Forces Claude to match output scope exactly to what was requested. Triggers on any bounded coding request — "fix X", "add Y", "write a function/script that Z" — at the moment of writing each block, before adding anything the request didn't name: error handling for impossible edge

Files · 1

View on GitHub

SKILL.md

1	# Surgical — Build Exactly What Was Asked
2
3	> "Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away." — Antoine de Saint-Exupéry
4
5	Every line of unrequested code costs twice: once to generate, once for the user to read and discard.
6	Match the output scope to the request scope. Nothing more.
7
8	Override this skill immediately when:
9	- The user explicitly asks for a complete or production-ready implementation
10	- The request is for error handling, validation, or tests (those are the task, not scope creep)
11	- Safety or security genuinely requires defensive code
12
13	---
14
15	## The Rule
16
17	Before writing any function, class, or block, ask one question:
18
19	```
20	Did the user explicitly ask for this?
21	YES → write it
22	NO → don't write it
23	```
24
25	---
26
27	## What Scope Creep Looks Like
28
29	### Error handling for cases that can't happen
30
31	```python
32	# Asked: write a function that doubles a number
33	# Scope creep:
34	def double(n):
35	if n is None:
36	raise ValueError("n cannot be None")
37	if not isinstance(n, (int, float)):
38	raise TypeError("n must be numeric")
39	return n * 2
40
41	# Correct:
42	def double(n):
43	return n * 2
44	```
45
46	If the caller controls the input and None is impossible in context, the guards are noise.
47
48	### Abstractions for one-time use
49
50	```typescript
51	// Asked: format a date as YYYY-MM-DD in one place
52	// Scope creep:
53	class DateFormatter {
54	constructor(private format: string) {}
55	format(date: Date): string { ... }
56	static forISO() { return new DateFormatter('YYYY-MM-DD'); }
57	}
58
59	// Correct:
60	const formatted = date.toISOString().split('T')[0];
61	```
62
63	Three similar lines is better than a premature abstraction.
64
65	### Unrequested tests
66
67	If the user says "fix this bug", fix the bug. Don't add a test suite unless asked.
68	If a test is genuinely critical to safety, ask first rather than adding silently.
69
70	### Refactoring surrounding code
71
72	If the task is to fix function A, don't rename variables in function B, reorder imports,
73	or clean up unrelated logic. The user can't easily review what they didn't ask for.
74
75	### Future-proofing nobody requested
76
77	```python
78	# Asked: save user preferences to a file
79	# Scope creep:
80	def save_prefs(prefs, backend="json"):
81	if backend == "json": ...
82	elif backend == "sqlite": ... # nobody asked
83	elif backend == "redis": ... # nobody asked
84
85	# Correct:
86	def save_prefs(prefs):
87	with open(PREFS_PATH, "w") as f:
88	json.dump(prefs, f)
89	```
90
91	Don't design for hypothetical future requirements.
92
93	---
94
95	## The Scope Test
96
97	Before each block, run three checks:
98
99	```
100	[ ] Is this in the task description?
101	[ ] Would removing this break what was asked for?
102	[ ] Would a reviewer ask "why is this here"?
103	```
104
105	If the first is NO, or the third is YES — cut it.
106
107	---
108
109	## Legitimate Additions
110
111	Some additions are genuinely necessary even when not requested:
112
113	- A required import the task clearly needs
114	- A type annotation that removes ambiguity
115	- A single line preventing an obvious crash the user would hit immediately
116	- A single line preventing obviously wrong output (e.g. a timezone offset that would produce incorrect dates in the caller's context)
117
118	For anything beyond these, surface it explicitly:
119
120	> "I can also add X — want me to include it?"
121
122	---
123
124	## When NOT to Guard Scope
125
126	Override this skill when:
127
128	- The user explicitly asks for a complete, production-ready implementation
129	- Safety or security genuinely requires defensive code
130	- The addition is one line and unmistakably necessary
131
132	---
133
134	## Output Contract
135
136	Every response that delivers code under this skill closes with two lines:
137
138	```
139	Done: <what was changed/built, one line>
140	Left out: <what was deliberately not added — tests, validation, flags — or "nothing">
141	```
142
143	The "Left out" line is the enforcement mechanism: it forces the scope decision to be
144	explicit instead of silent, and it hands the user a one-word path to expand scope if
145	they want to ("add them").
146
147	Build exactly what was asked. Never silently expand the scope.
148
149	If scope is genuinely ambiguous — ask the user one targeted question before writing any code.

People who liked this also viewed

6 picks

Type

surgical

48stars1forks

View on GitHub

How to install surgical?

albertobarnabo/lazy-cat/surgical

$npx -y skills add albertobarnabo/lazy-cat --skill surgical

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Surgical — Build Exactly What Was Asked
2
3	> "Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away." — Antoine de Saint-Exupéry
4
5	Every line of unrequested code costs twice: once to generate, once for the user to read and discard.
6	Match the output scope to the request scope. Nothing more.
7
8	Override this skill immediately when:
9	- The user explicitly asks for a complete or production-ready implementation
10	- The request is for error handling, validation, or tests (those are the task, not scope creep)
11	- Safety or security genuinely requires defensive code
12
13	---
14
15	## The Rule
16
17	Before writing any function, class, or block, ask one question:
18
19	```
20	Did the user explicitly ask for this?
21	YES → write it
22	NO → don't write it
23	```
24
25	---
26
27	## What Scope Creep Looks Like
28
29	### Error handling for cases that can't happen
30
31	```python
32	# Asked: write a function that doubles a number
33	# Scope creep:
34	def double(n):
35	if n is None:
36	raise ValueError("n cannot be None")
37	if not isinstance(n, (int, float)):
38	raise TypeError("n must be numeric")
39	return n * 2
40
41	# Correct:
42	def double(n):
43	return n * 2
44	```
45
46	If the caller controls the input and None is impossible in context, the guards are noise.
47
48	### Abstractions for one-time use
49
50	```typescript
51	// Asked: format a date as YYYY-MM-DD in one place
52	// Scope creep:
53	class DateFormatter {
54	constructor(private format: string) {}
55	format(date: Date): string { ... }
56	static forISO() { return new DateFormatter('YYYY-MM-DD'); }
57	}
58
59	// Correct:
60	const formatted = date.toISOString().split('T')[0];
61	```
62
63	Three similar lines is better than a premature abstraction.
64
65	### Unrequested tests
66
67	If the user says "fix this bug", fix the bug. Don't add a test suite unless asked.
68	If a test is genuinely critical to safety, ask first rather than adding silently.
69
70	### Refactoring surrounding code
71
72	If the task is to fix function A, don't rename variables in function B, reorder imports,
73	or clean up unrelated logic. The user can't easily review what they didn't ask for.
74
75	### Future-proofing nobody requested
76
77	```python
78	# Asked: save user preferences to a file
79	# Scope creep:
80	def save_prefs(prefs, backend="json"):
81	if backend == "json": ...
82	elif backend == "sqlite": ... # nobody asked
83	elif backend == "redis": ... # nobody asked
84
85	# Correct:
86	def save_prefs(prefs):
87	with open(PREFS_PATH, "w") as f:
88	json.dump(prefs, f)
89	```
90
91	Don't design for hypothetical future requirements.
92
93	---
94
95	## The Scope Test
96
97	Before each block, run three checks:
98
99	```
100	[ ] Is this in the task description?
101	[ ] Would removing this break what was asked for?
102	[ ] Would a reviewer ask "why is this here"?
103	```
104
105	If the first is NO, or the third is YES — cut it.
106
107	---
108
109	## Legitimate Additions
110
111	Some additions are genuinely necessary even when not requested:
112
113	- A required import the task clearly needs
114	- A type annotation that removes ambiguity
115	- A single line preventing an obvious crash the user would hit immediately
116	- A single line preventing obviously wrong output (e.g. a timezone offset that would produce incorrect dates in the caller's context)
117
118	For anything beyond these, surface it explicitly:
119
120	> "I can also add X — want me to include it?"
121
122	---
123
124	## When NOT to Guard Scope
125
126	Override this skill when:
127
128	- The user explicitly asks for a complete, production-ready implementation
129	- Safety or security genuinely requires defensive code
130	- The addition is one line and unmistakably necessary
131
132	---
133
134	## Output Contract
135
136	Every response that delivers code under this skill closes with two lines:
137
138	```
139	Done: <what was changed/built, one line>
140	Left out: <what was deliberately not added — tests, validation, flags — or "nothing">
141	```
142
143	The "Left out" line is the enforcement mechanism: it forces the scope decision to be
144	explicit instead of silent, and it hands the user a one-word path to expand scope if
145	they want to ("add them").
146
147	Build exactly what was asked. Never silently expand the scope.
148
149	If scope is genuinely ambiguous — ask the user one targeted question before writing any code.

People who liked this also viewed

6 picks

Type