agentsclimarketplace

Surgical

Skill albertobarnabo/lazy-cat/skills/surgical

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 cases, tests, docstrings, type annotations, CLI flags, config options, one-time abstractions, or refactors of surrounding code. Does NOT trigger when error handling, tests, or validation are the explicit subject of the request, or when the user asked for a complete or production-ready implementation. The best code is code you didn't write.From its SKILL.md

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

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

SKILL.md

4.7 KB, 924 tokens by cl100k_base, as published. Nobody here has run it

Surgical — Build Exactly What Was Asked

"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

Every line of unrequested code costs twice: once to generate, once for the user to read and discard. Match the output scope to the request scope. Nothing more.

Override this skill immediately when:

  • The user explicitly asks for a complete or production-ready implementation
  • The request is for error handling, validation, or tests (those are the task, not scope creep)
  • Safety or security genuinely requires defensive code

The Rule

Before writing any function, class, or block, ask one question:

Did the user explicitly ask for this?
  YES → write it
  NO  → don't write it

What Scope Creep Looks Like

Error handling for cases that can't happen

# Asked: write a function that doubles a number
# Scope creep:
def double(n):
    if n is None:
        raise ValueError("n cannot be None")
    if not isinstance(n, (int, float)):
        raise TypeError("n must be numeric")
    return n * 2

# Correct:
def double(n):
    return n * 2

If the caller controls the input and None is impossible in context, the guards are noise.

Abstractions for one-time use

// Asked: format a date as YYYY-MM-DD in one place
// Scope creep:
class DateFormatter {
  constructor(private format: string) {}
  format(date: Date): string { ... }
  static forISO() { return new DateFormatter('YYYY-MM-DD'); }
}

// Correct:
const formatted = date.toISOString().split('T')[0];

Three similar lines is better than a premature abstraction.

Unrequested tests

If the user says "fix this bug", fix the bug. Don't add a test suite unless asked. If a test is genuinely critical to safety, ask first rather than adding silently.

Refactoring surrounding code

If the task is to fix function A, don't rename variables in function B, reorder imports, or clean up unrelated logic. The user can't easily review what they didn't ask for.

Future-proofing nobody requested

# Asked: save user preferences to a file
# Scope creep:
def save_prefs(prefs, backend="json"):
    if backend == "json": ...
    elif backend == "sqlite": ...   # nobody asked
    elif backend == "redis": ...    # nobody asked

# Correct:
def save_prefs(prefs):
    with open(PREFS_PATH, "w") as f:
        json.dump(prefs, f)

Don't design for hypothetical future requirements.


The Scope Test

Before each block, run three checks:

[ ] Is this in the task description?
[ ] Would removing this break what was asked for?
[ ] Would a reviewer ask "why is this here"?

If the first is NO, or the third is YES — cut it.


Legitimate Additions

Some additions are genuinely necessary even when not requested:

  • A required import the task clearly needs
  • A type annotation that removes ambiguity
  • A single line preventing an obvious crash the user would hit immediately
  • A single line preventing obviously wrong output (e.g. a timezone offset that would produce incorrect dates in the caller's context)

For anything beyond these, surface it explicitly:

"I can also add X — want me to include it?"


When NOT to Guard Scope

Override this skill when:

  • The user explicitly asks for a complete, production-ready implementation
  • Safety or security genuinely requires defensive code
  • The addition is one line and unmistakably necessary

Output Contract

Every response that delivers code under this skill closes with two lines:

Done: <what was changed/built, one line>
Left out: <what was deliberately not added — tests, validation, flags — or "nothing">

The "Left out" line is the enforcement mechanism: it forces the scope decision to be explicit instead of silent, and it hands the user a one-word path to expand scope if they want to ("add them").

Build exactly what was asked. Never silently expand the scope.

If scope is genuinely ambiguous — ask the user one targeted question before writing any code.

What ships with it: 1 file

3.0 KB alongside SKILL.md

Gives 0 of the 12 instructions most docs writing skills give in 924 tokens

Counted across 1,951 of the 3,904 authors here whose files we hold, read 2026-09-06

  • Use third-person for skill descriptionsin 54 of 1951, across 35 files
  • Start descriptions with Use whenin 43 of 1951, across 29 files
  • Run baseline scenarios before writing any skillin 40 of 1951, across 26 files
  • Use active voicein 40 of 1951, across 36 files
  • Map file responsibilities before defining tasksin 36 of 1951, across 29 files
  • Use checkbox syntax for tracking stepsin 35 of 1951, across 27 files
  • Ask one question at a timein 35 of 1951
  • Offer execution options after saving the planin 33 of 1951, across 24 files
  • Include complete code in every stepin 33 of 1951, across 27 files
  • Design units with clear boundaries and interfacesin 31 of 1951, across 23 files
  • Announce the skill usage at the startin 30 of 1951
  • Verify agent compliance after adding the skillin 29 of 1951, across 17 files

Said here and by no other author read

  • Match output scope exactly to the request
  • Ask if the user explicitly requested the code
  • Do not write unrequested error handling
  • Do not design for hypothetical future requirements
  • Surface non-requested additions to the user
  • Ask targeted questions if scope is ambiguous

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.