Decide what the package owns

Before choosing a tool or writing more code, make the requirement concrete. The utility owns title normalization and slug creation, but it does not own routing, databases, or UI state.

A package is a versioned contract consumed by code you do not control, even when the first consumer is your own project. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

A common failure is to extract a grab bag of unrelated helpers because they happen to live in one folder. The happy path may still work, which makes the mistake easy to miss. write the package purpose, supported inputs, outputs, runtime assumptions, and explicit non-goals. Keep the first version small enough that every important input and output remains visible.

This supports the module goal: Turn a useful function into a small package whose public surface and published files are intentional. Capture the request, command, trace, screenshot, test result, or other evidence that proves the result.

Create a one-page contract and three usage examples before moving the function into its package directory. Change one condition on purpose, predict the result, and compare the prediction with what actually happened.