Comment by WorldMaker

Yeah, some of it can be solved as a simple naming convention thing. `_scripts/*.ts` for scripts that are "reproduceable" and/or production-ready and `_scripts/scratch/*.ts` or `_scripts/${username}/*.ts` for scripts that are piecemeal or work-in-progress or user-specific or otherwise "throwaway". Or a graduation process such as where things in `_scripts/` are considered "throwaway" until added to and documented in a larger production task runner like adding them to the "tasks" section of a deno.json file. (They graduate from being shebang run to `deno task taskname` run. They get basic documentation in the `deno task` list and various IDE integrations of such.)

The major thing to be concerned about there is leaking things like hard-coded secrets and that's where something like .env files can come in handy and knowing your tools to make use of them. Deno (as the running example) makes using .env files easy enough by adding the `--env` flag to your `deno run` shebang/task-line and then using `Deno.env` like any other environment variable. (Then don't forget to .gitignore your .env files.)