Python Project Scaffold

Hello,

1. when you start a new project do you copy and paste the command for scaffolding or do you put this into a skill, so that you don’t have to copy and paste this gist (I did not see this in the skill that I downloaded, so I was wondering what’s your recommendation)
2. Also, I did a couple of projects and I see myself copying the same skills from one project to another. Do you keep the generic skills we saw in second day of class in each project, or do you keep them in ~/.claude (user home directory)?

That’s such a great question, Famasa. I’ve honestly spent a bit too much time thinking about the “best” solution for this, both before and after the workshop.

Briefly, here’s how I’d answer it:

1. If you use a scaffolding prompt very often, then yes, turning it into a skill makes sense. If it’s something you only use occasionally, I think it’s perfectly fine to just save it somewhere and copy and paste it when needed. That’s actually what I do in some cases. The main reason I wouldn’t automatically make everything a skill is that I don’t want rarely used things cluttering up my skill list. So for me, if it’s a prompt I only reach for once every few months, I’d rather keep it as a markdown file or in a small prompt collection. But if it’s part of your regular workflow, a skill is definitely a good idea.
2. For generic skills, my rule of thumb is similar: if it’s something I want available across projects without having to think about where it lives, I keep it in ~/.claude/. For me, that includes things like the /commit skill, the /skill-maker skill, and workflow-related skills that are useful no matter what kind of project I’m working on. If a skill is more project- or language-specific, like something mainly relevant to Python or a particular stack, then I’m more likely to keep it outside the global folder and copy it into a project when needed.

More broadly, I’ll be honest: I haven’t fully solved this for myself yet. I’ve seen people build systems around this in Obsidian or other “second brain” setups, and I think those can work well. At the same time, they can also feel a bit detached from the actual project you’re working on.

One idea I’ve been playing with is building a small CLI tool for myself, similar in spirit to the second-brain approach we used in the live course, so I could access prompts and skills on demand without loading everything into Claude all the time.

At the end of the day, I really think whatever works for you is fine. Copy-pasting is absolutely okay. If you end up finding a setup that feels especially good, I’d love to hear about it. 🙂

Thanks for the comment. I assume that the skills are only loaded when they are called with /skill-name, so if one keeps good nomenclature of the skills such as you shared /wf-... (workflow), one can use something like /adhoc-... which may be faster to access than going to some snippets repository. I’ll try this and see how it goes.

I must say that the class was amazing and extremely useful. I managed to write synchronization of thousands of contacts from CRM (with quite dirty data) to chatwoot. Once you get a hang of it, I can bang out the whole project in what would take me to write specs for the developer and then more hours to coordinate bug fixing. It’s amazing, how claude code took care of all the different edge cases (with dozens of test functions) and looked at the data and created data cleanup functions.

Thanks for opening the door to this amazing productivity tool.