think-twice

Name: think-twice
Author: albertobarnabo

48stars1forks

How to install think-twice?

albertobarnabo/lazy-cat/think-twice

$npx -y skills add albertobarnabo/lazy-cat --skill think-twice

Installs into the current project.

Summary

Forces Claude to pause before picking an implementation approach and ask: "Is there a cleverer, cheaper way?" Triggers when the request involves generating data or fixtures (lists, datasets, sample records), implementing a problem that is likely already solved by a stdlib functio

Files · 1

View on GitHub

SKILL.md

1	# Lazy Agent — Work Smarter, Not Harder
2
3	> "A great engineer is a lazy engineer. They find the clever shortcut." — Steve Jobs
4
5	This skill rewires Claude's default instinct. Instead of charging ahead with the most obvious approach,
6	Claude must first ask: "Is there a smarter way to do this?"
7
8	Productive laziness is not about doing less. It's about never doing more than necessary.
9
10	---
11
12	## When NOT to run this checklist
13
14	Skip if the task is trivially small (under ~10 lines, no data, no new dependencies) or if the
15	user has explicitly described custom logic that no generic library could cover. In those cases,
16	proceed directly.
17
18	Also: never hand-roll cryptography or security primitives. "Use an existing implementation"
19	means the language stdlib or a widely-audited library — not a custom implementation.
20
21	---
22
23	## The Lazy Check
24
25	Run this before any task that feels heavy — a large block of code, repetitive data, a complex algorithm,
26	a long implementation. Stop at the first question that reveals a better path.
27
28	### 1. Am I solving the right problem?
29	Before writing a single line, make sure the task is correctly understood.
30	- What is the user actually trying to achieve?
31	- Am I about to solve a symptom instead of the root cause?
32	- Would a 2-sentence clarification save 200 lines of code?
33
34	If the answer to any of these is uncertain — ask the user before writing any code.
35	One targeted question now saves a full redo later.
36
37	### 2. Is there an existing solution?
38	Someone has almost certainly solved this before.
39	- Public API: Does a service already expose this data or functionality at runtime? Prefer it — no maintenance, always up to date.
40	- Package: Would `npm install` or `pip install` deliver this in 10 lines instead of 200?
41	- Open dataset: Is there a downloadable file (CSV, JSON, SQLite) from a trusted source?
42	- Standard library: Does the language's stdlib already cover this?
43
44	### 3. Am I doing too much?
45	Scope creep is the enemy of efficiency.
46	- Does the user need all of this, or just a slice?
47	- Am I precomputing everything when I could compute on demand?
48	- Am I generating 100 cases when 3 examples would prove the point?
49	- YAGNI: if it's not needed right now, don't build it.
50
51	### 4. Is my approach the most direct one?
52	The obvious implementation is rarely the best one.
53	- Is there a simpler data structure that makes the algorithm trivial?
54	- Is there a one-liner that replaces 50 lines of logic?
55	- Am I reaching for complexity when a lookup table would do?
56	- Can I reframe the problem so the solution becomes obvious?
57
58	### 5. Can I do this lazily?
59	Defer work until it's actually needed.
60	- Generate on demand instead of precomputing all cases.
61	- Paginate instead of loading everything.
62	- Cache results instead of recomputing.
63	- Render what's visible, not what exists.
64
65	### 6. Only then: proceed
66	If none of the above reveals a shortcut, commit to the implementation — but scope it to the minimum
67	that solves the problem today.
68
69	---
70
71	## Decision Checklist
72
73	Run this mentally before any significant code block:
74
75	```
76	[ ] Do I fully understand what's being asked, or am I assuming?
77	[ ] Does an API, package, or dataset already solve this?
78	[ ] Am I building more than what's needed right now?
79	[ ] Is there a simpler approach I'm overlooking?
80	[ ] Can this be computed lazily instead of all at once?
81	[ ] Would a 10-line solution exist if I reframed the problem?
82	```
83
84	If any box triggers doubt — stop and explore that path before proceeding.
85
86	---
87
88	## The Mindset
89
90	The greedy approach: see task → start implementing → figure it out as you go.
91
92	The lazy approach: see task → pause → find the clever path → implement only what's needed.
93
94	The difference is one beat of reflection before execution. That beat is what separates
95	a solution that costs 50,000 tokens from one that costs 50.
96
97	---
98
99	## Common Shortcuts
100
101	\| Instead of... \| Consider... \|
102	\|---\|---\|
103	\| Implementing a complex feature from scratch \| Checking if a library already does it \|
104	\| Hardcoding a large static dataset \| Fetching it from an API at runtime \|
105	\| Generating all permutations upfront \| Computing on demand with memoization \|
106	\| Building the full system now \| Building only the part that's needed today \|

People who liked this also viewed

6 picks

Type

think-twice

48stars1forks

View on GitHub

How to install think-twice?

albertobarnabo/lazy-cat/think-twice

$npx -y skills add albertobarnabo/lazy-cat --skill think-twice

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Lazy Agent — Work Smarter, Not Harder
2
3	> "A great engineer is a lazy engineer. They find the clever shortcut." — Steve Jobs
4
5	This skill rewires Claude's default instinct. Instead of charging ahead with the most obvious approach,
6	Claude must first ask: "Is there a smarter way to do this?"
7
8	Productive laziness is not about doing less. It's about never doing more than necessary.
9
10	---
11
12	## When NOT to run this checklist
13
14	Skip if the task is trivially small (under ~10 lines, no data, no new dependencies) or if the
15	user has explicitly described custom logic that no generic library could cover. In those cases,
16	proceed directly.
17
18	Also: never hand-roll cryptography or security primitives. "Use an existing implementation"
19	means the language stdlib or a widely-audited library — not a custom implementation.
20
21	---
22
23	## The Lazy Check
24
25	Run this before any task that feels heavy — a large block of code, repetitive data, a complex algorithm,
26	a long implementation. Stop at the first question that reveals a better path.
27
28	### 1. Am I solving the right problem?
29	Before writing a single line, make sure the task is correctly understood.
30	- What is the user actually trying to achieve?
31	- Am I about to solve a symptom instead of the root cause?
32	- Would a 2-sentence clarification save 200 lines of code?
33
34	If the answer to any of these is uncertain — ask the user before writing any code.
35	One targeted question now saves a full redo later.
36
37	### 2. Is there an existing solution?
38	Someone has almost certainly solved this before.
39	- Public API: Does a service already expose this data or functionality at runtime? Prefer it — no maintenance, always up to date.
40	- Package: Would `npm install` or `pip install` deliver this in 10 lines instead of 200?
41	- Open dataset: Is there a downloadable file (CSV, JSON, SQLite) from a trusted source?
42	- Standard library: Does the language's stdlib already cover this?
43
44	### 3. Am I doing too much?
45	Scope creep is the enemy of efficiency.
46	- Does the user need all of this, or just a slice?
47	- Am I precomputing everything when I could compute on demand?
48	- Am I generating 100 cases when 3 examples would prove the point?
49	- YAGNI: if it's not needed right now, don't build it.
50
51	### 4. Is my approach the most direct one?
52	The obvious implementation is rarely the best one.
53	- Is there a simpler data structure that makes the algorithm trivial?
54	- Is there a one-liner that replaces 50 lines of logic?
55	- Am I reaching for complexity when a lookup table would do?
56	- Can I reframe the problem so the solution becomes obvious?
57
58	### 5. Can I do this lazily?
59	Defer work until it's actually needed.
60	- Generate on demand instead of precomputing all cases.
61	- Paginate instead of loading everything.
62	- Cache results instead of recomputing.
63	- Render what's visible, not what exists.
64
65	### 6. Only then: proceed
66	If none of the above reveals a shortcut, commit to the implementation — but scope it to the minimum
67	that solves the problem today.
68
69	---
70
71	## Decision Checklist
72
73	Run this mentally before any significant code block:
74
75	```
76	[ ] Do I fully understand what's being asked, or am I assuming?
77	[ ] Does an API, package, or dataset already solve this?
78	[ ] Am I building more than what's needed right now?
79	[ ] Is there a simpler approach I'm overlooking?
80	[ ] Can this be computed lazily instead of all at once?
81	[ ] Would a 10-line solution exist if I reframed the problem?
82	```
83
84	If any box triggers doubt — stop and explore that path before proceeding.
85
86	---
87
88	## The Mindset
89
90	The greedy approach: see task → start implementing → figure it out as you go.
91
92	The lazy approach: see task → pause → find the clever path → implement only what's needed.
93
94	The difference is one beat of reflection before execution. That beat is what separates
95	a solution that costs 50,000 tokens from one that costs 50.
96
97	---
98
99	## Common Shortcuts
100
101	\| Instead of... \| Consider... \|
102	\|---\|---\|
103	\| Implementing a complex feature from scratch \| Checking if a library already does it \|
104	\| Hardcoding a large static dataset \| Fetching it from an API at runtime \|
105	\| Generating all permutations upfront \| Computing on demand with memoization \|
106	\| Building the full system now \| Building only the part that's needed today \|

People who liked this also viewed

6 picks

Type