It could be as simple as one-liner scripts, or as complex as a complete programming language with parser and debugger.
But there’s the well-known danger of creating a labor-saving tool, that takes more labor to create than the original task (unless you can it amortize it over several projects).
I’m concerned about getting carried away with this secondary project, trying to make it perfect, and extending it… while the primary project languishes (eg: Knuth taking years away from writing ‘The Art of Computer Programming’ to create TeX to help him typeset it).
I’m not thinking of standard support/dev tools, like build tools, test systems, bug-trackers and source control, but ones that you create for a specific project, to support your own development, that only developers will ever use (i.e. it’s not a deliverable of the project).
It’s so easy to get caught up in the fun of tool creation. We try to manage it by looking at the tools we need to write, spending some decent time looking for opensource that we can use or bend to our will, and only then resort to rolling are own. We also do this as an iteration zero, exercise, with sprints and scrum – if a tool takes more than one sprint (2 weeks) it’s far too big.