ToolsConfig Specification: A directory to store your tools' configuration

So a tool that uses ".example" would first check ".toolsconfig/.example"? Why not ".toolsconfig/example" (with one less dot)?

If you change ".toolsconfig" to ".config", then it would be easier to use and you get reuse of ~/.config. This name equally conveys its intent and purpose, as shown by ~/.config's use for tool config. Without having done a survey of projects, I anecdotally believe this shorter name and reuse is worth the potential collision with any existing project with a ".config" directory that is not used for tool config.

PS: I believe a better strategy is for each project to have a directory named "task", "util", "scripts", or any other name. Inside are short executables for each task or utility that needs configuration committed to the repo. Then the user can, at their option, configure their shell to find those programs after they accept the risk of running code from a repository -- there are, for example, popular tools to add directories to PATH upon cd. To be clear, a config file is code for the only example in the ToolsConfig readme (Docker) and also for a large number of developer tools described in the problem statement. These two strategies (well-known config location vs short executables) are not perfectly overlapping and there is room for both, though given my needs, short executables provides so much value that I don't find myself needing more.

PPS: My preferred shell configuration to run project-specific tools starts with a symlink in the project root to the project-specific task directory. Call this symlink ".project-task" to illustrate, though the exact name doesn't matter because I specifically do not want any project's repo to use it. I have a small utility, let's call it "project-task", though it's actually a very short name, which checks the CWD and then parent directories for a ".project-task" directory. If found, the utility first checks (grep -F -x -q) if that full path is in a whitelist -- elsewise it refuses to blindly run programs. To create and add to the whitelist, I have a utility "project-task-enable DIR" which effectively does: "ln -s DIR .project-task && echo $PWD/.project-task >> ~/.config/project-task.allow". Back to project-task: if the found path is allowed, it execs "$that_path/$@". The utility does a little more, but this paragraph describes all major functionality.