agentleFS
Sign inStart free
udecodeudecode/better-convex/.agents/skills/hard-cut/SKILL.md

hard-cut

Skill452 starsChanged 23 days agoApache-2.0View on GitHub

Remove a feature completely with no backward compatibility. Use when the user says "hard cut", "rip it out", "delete it", "unship", "kill this feature", or wants dead code removed instead of deprecated. Delete the surface, callers, tests, docs, comments, fallbacks, and stubs.

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 9 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this when a feature should die, not linger.

    line 11
  2. Distinctive:

    Delete the surface. Do not deprecate it.

    line 15
  3. Very specific:

    Do not leave throw new Error("Not implemented"), placeholder notices, "feature removed" banners, or TODOs about bringing it back unless the …

    line 16
  4. Distinctive:

    Do not keep compatibility aliases, deprecated shims, fallback parsing, migration bridges, or dead exports.

    line 19
  5. Distinctive:

    Delete tests for deleted behavior.

    line 21
  6. Distinctive:

    Delete comments that describe deleted code or mourn the old feature.

    line 23
  7. Distinctive:

    If removal exposes adjacent dead code, keep cutting until the graph is clean.

    line 24
  8. Distinctive:

    Delete the implementation and the glue:

    line 36
  9. Distinctive:

    Run the narrowest honest verification for the surviving product.

    line 44
  10. Distinctive:

    If the choice is between deleting more code and leaving zombie compatibility, delete more code.

    line 58

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Hard Cut

Use this when a feature should die, not linger.

Rules

  • Delete the surface. Do not deprecate it.
  • Do not leave throw new Error("Not implemented"), placeholder notices, "feature removed" banners, or TODOs about bringing it back unless the user explicitly asks.
  • Do not keep compatibility aliases, deprecated shims, fallback parsing, migration bridges, or dead exports.
  • Delete tests for deleted behavior. Keep tests only for the behavior that still exists.
  • Delete comments that describe deleted code or mourn the old feature.
  • If removal exposes adjacent dead code, keep cutting until the graph is clean.

Sweep

  1. Find the real surface area:
    • exports
    • commands and flags
    • routes
    • UI entrypoints
    • feature flags
    • docs and examples
  2. Trace references with rg.
  3. Delete the implementation and the glue:
    • call sites
    • types
    • state
    • tests
    • docs
    • comments
  4. Grep again for the removed name and obvious aliases.
  5. Run the narrowest honest verification for the surviving product.

Smells

  • deprecated notices
  • not-implemented throws
  • stub handlers
  • dead enum or union members
  • permanently-false feature-flag branches
  • unused env vars and config
  • tests that only prove the deleted feature used to exist

Bias

If the choice is between deleting more code and leaving zombie compatibility, delete more code.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free