I’ve been working on a utility called pt-cli, a tool built to streamline the way I kick off new work/experiments by recording directory structures as reusable templates. A bit more about that here.
The tool is designed for functional utility – specifically for those who frequently jump between different project types and want to maintain structural consistency. It also includes a dedicated Agent Skill so your agent can directly manage project initialization and directory recording within your workflow.
At a glance:
Record: Capture existing directory structures as templates.
Initialize: Rapidly scaffold new projects from your recorded library.
Agent Integration: A pre-configured Agent Skill for seamless CLI-agent interaction.
One of those things I will never understand. If you have a project that is yours, why do you need an agent to structure that project? If somebody(or something) else structures a complex project for you, it means you no longer know the structure of your own project, doesn’t it? So that’s a tool to cause confusion for you with your own projects?.. I mean, maybe I don’t need to understand everything in this world… It just seems like a good way to get confused and make mistakes…
Using the included skill is not a requirement and can be safely ignored. It’s another way of interfacing with the cli. Since there’s a limited API, having an agent initialize a new project structure will get you similar results to you using it directly.
To be honest, I haven’t used the skill available with the CLI as I’m still getting used to initializing new projects with it – and finding new improvements to add along the way.
In any case, I’ve replaced my old bash script and had fun creating something new in the process. I’m happy to be the only user but I am curious to know if there’s similar thinking out there.
I only have some limited experience of working in a small team of people and helping them manage interior design projects. As a technical guy, I also had many ideas of automation, but in my story at the end it turned out that having a bunch of empty folders in a project was helping no one and apparently if a person knows what they are working on, they usually know where to save their files and if not, it’s an amazing idea to consult another team member and decide what is needed for the project. The worst things used to happen if any lack of communication existed anywhere really and that communication between team members turned out to be absolutely the main thing in successfully managing projects. Folders just sort themselves out when people know what they are doing and it turns out it’s a really really great idea to make sure people know what they are doing anyway.
Martin, within your interior design team did you have a basic set of rules for naming files? Without that foundation simple automation can be difficult.
Some time ago I worked with a small team of architects and researchers to determine what files and folder structures were important to them. I think having the basics down can be important for removing friction within a multi-disciplinary team. Later I found these principles helped with my own freelance work. For example:
Rendering frames, from applications like Blender, do you save them to:
A. RENDER/
B. frames/
C. animation/
D. All of the above
The correct answer is what’s right for you or your team. The wrong answer is D. In projects requiring tight collaboration between members you do not want a “choose your own adventure” style of file/folder naming.
pt-cli doesn’t impose an opinion but I think it can be used to surface patterns. Of course, as you mentioned, the best method is communication – followed by documenting what was agreed. It will make onboarding team-mates a little easier. Simple automations are now possible, too.
Lots of empty folders annoy me also. Before project types I used a make simplify command that removed folders that were unused. That was more fun than manually deleting folders and I was learning some shell scripting in the process. Over the years my scraps of regex and bash one-liners – and opinions grew. My semi-tidy digital hoard.
Of course. Not only basic. We had loads of rules for everything.
If you asked me about it, I came to a few conclusions of my own:
Software doesn’t help - it’s a people problem, must be solved by people. Documentation is OK, but at the end of the day the place this should exist in is the mind of the person working with it.
Tailor the structure to the work, not the work to the structure
If something makes sense, do that.
If something needs to change, change it, deal with the consequences(like restructure archives if consistency is needed).
Complexity must be avoided, the goal is to make it simple.
Abbreviations and codes add complexity so should be avoided, natural language should be used instead (unless there is a good reason). It’s counterproductive to make people learn useless information that you can do without and write pointless documentation that everyone will hate to read. It’s the most terrible idea to obscure meaning with codes.
If you need to write something down, it’s probably a bad idea.
Additional “productivity” tools add complexity, avoid at all costs if possible(unless it makes sense ).
Don’t duplicate information. For example: a file has a date, no need to write it in the filename, computer is tracking that for you(unless there is a good reason ).
Certain words like “final”, “latest”,“current”,“approved” and so on should be strictly forbidden (obviously)
…I think I could carry on for a while… but those are probably the main points I personally learned sometimes the hard way.
There are obviously exceptions. If you work with a bunch of computer nerds on programming projects, obviously software will help, because everyone in the team has the skillset to use it efficiently. Doesn’t work at all for a team of designers… But that’s covered by the point “If something makes sense, do that.” But at the same time I think most programmers have a lot to learn from a few of my points
Git is the only tool I use from command line sometimes. I don’t know how you define “in your day-to-day work”. It happens I guess that I use various terminals and consoles for various hard to define reasons I guess. Why?
You must be a hacker . I’m a hack but no matter what project I’m working on I’ll have a terminal and VScodium open. Terminal is mostly for makefile commands or scripts. I prefer to use git through VScodium for the simple stuff.
I ask because I found that I prefer to do certain things through a GUI vs CLI. That’s why I created pt-gui shortly after using the cli for a bit. I use it mostly for changing settings and adding new post-config (setup) commands but the drag and drop is nice, too.
Could this potentually be a replacement for Unity Hub? I have two projects I jump between multiple times an hour in Unity and I hate dealing with the Hub, which is slow as frozen molasses
TL;DR: No, pt isn’t a launcher. It’s simply a project structure replicator.
Great question. I use Unity Hub to get the apps and sometimes launch them from there but I do not like managing projects there – mainly because I’m not used to that.
In my last Unity project I used this “launcher” script to deal with UI scale issues but it looks like launching a specific version can still be tricky:
In terms of folder structure I use a similar layout to the pt_godot template previously shared except there will be a UNITY folder with the engine stuff. On larger projects this would be a git submodule (or turn into one along the way).
$ pt
Usage: pt [options] [command]
Project Template CLI - Learn project structures and initialize new ones
Options:
-v output the version number
-h, --help display help for command
Commands:
learn [options] [path] Learn a project structure from an existing directory
update [options] <templateName> [sourcePath] Update an existing template with new structure/files
init [options] [templateName] [destPath] Initialize a new project from a learned template
config [options] [templateName] Show current config location and list templates, or export a specific template
ignore [options] [patterns] View or set global ignore patterns (comma-separated)
variables [options] [pairs] View or set global variables (comma-separated key=value)
default-post-config [options] View or set default post-config tasks
add [options] <name> [json] Import/add a template from a JSON string or file
remove|rm [options] <template> Remove a learned template from the config
security-response <response> Handle security response from GUI
help [command] display help for command
I think I’m getting close to a 1.0 release for the free CLI. There’s been some recent fixes as I find issues when bootstrapping new projects.
There is at least one UX flow that needs to be improved, one that makes me launch the GUI: Revising an existing template (update). This still feels tedious to do with the cli.
pt-cli updated with improved UX. Learn → Init → Update: Update now only shows what would be added to a template. This streamlined approach mimics what my project closedown typically includes: a task to improve the template with new tools and processes (documentation.)
npm i @garyr/pt-cli to install
And for the GUI I’m working on a deploy pattern where you can list templates available to be learned. No more blank screen with a fresh install.
PT-GUI now “ships” with example templates and the new “deploy” feature could be useful for teams by listing available remote templates in a deploy.yaml|json file.
).
. I’m a hack but no matter what project I’m working on I’ll have a terminal and VScodium open. Terminal is mostly for makefile commands or scripts. I prefer to use git through VScodium for the simple stuff.
