Claude code starting guide - in a nutshell

• Install Claude code. This is incredibly easy. You’re using a terminal, and initially not using an ID.
• Make a Claude.MD file, or have it build one for you. Potentially snag one from somebody else and use that. But know that Every day you code, at least initially, you will be changing this file constantly. Every time you get annoyed. Often when you get annoyed, the way to not get annoyed later is to get put directions in this document.
• For nearly everything you have it do, you get roughly 20% better quality if you use an agent. It just means using a Claude code that’s been hypnotized into believing it’s an especially good “ front end engine engineer” or what not. My recommendation is to use the built-in ones that were made by anthropic. So when you’re switching tasks, if you want that extra 20%, have the agent that’s been convinced that it’s great at documentation make your documentation. And what not.
• If you’re doing something like adding a feature, or writing a program from scratch, make a spec for that first. But really it means having a conversation with Claude code to create that spec. Claude will still do most of the work. In that spec, include several sections. Have it include several sections… Test suite, steps to take to complete, history, Usage, etc. Review the specs and be sure that you’re actually happy and know what you’re building. And review that the test suite makes sense to you.
  • If your implementing something complex, take the time to use AI to educate yourself on best practices with that particular technology. AI has a tendency to reinvent the wheel or find unusual solutions. For the most part, it’s pretty darn good, but keep directing it back to best practices and stay on top of that yourself also.
• If what you’re doing is complicated, here are some extra things to do…
  • Make a map of the code base
  • Make diagrams. Architecture, use your flow, user flow, screen, mock ups, etc. Have I do this for you. But having these maps can help make it easier for AI and for you
  • I recommend markdown with mermaid diagrams, if the diagram is simple. If it’s complex, I recommend draw.io. But then you want to do a bit of extra prompting so it doesn’t screw it up.
• Then have it write the code as per the specifications that you just wrote. Also have it make the test Sweet.
• You want a tight testing loop. It should be able to cha. It should be able to run the test suite, watch the test fail, fix see code, and then run it again. Tell it to do this. Don’t let it back out. Don’t let it be lazy. If you’re working on a webpage, give it the ability to see the webpage and do de bugging with the webpage. If you’re wondering how to do that, just ask it. Lots of people give tutorials, but in the end, almost everything can be solved by you just asking Claude code or asking one of the chat bots webpage.
• So let’s say it passes the Test suites and the code is written and everything seems good. It’s not. You’re not done. Clyde did the hard part for you. You are now the janitor.
  • I like to commit the code once it works, but that doesn’t remotely mean that you’re done.
  • Obviously, a the code in to got. But have Claude give you the commit message. Tell it to do it get status and then to very carefully and meticulously review all the files and to give you the commands for what should be checked in , what should be organized differently, and what should be discarded.
  • Have it update the spec. If the thing you’re making takes a while, have it update the spec periodically to make sure that the current status is being recorded. You wanna make sure that if the Claude terminal window dies or loses its brain, that there’s a current status.
• If this took less than a few hours, the code is probably fairly clean. But if this was torturous and had a lot of back-and-forth, then you probably have some serious factoring to do. Thankfully, it’s very good at factoring. Have it do a code review. The very same agent that wrote code can review that code. It’s perfectly fine at being impartial. But best practices is that you use a Claude code that’s been convinced that it’s great at doing reviews. To review, and potentially refactor. And then obviously run the test Sweet again.
• Claude code hasn’t Agent that has 50 years expertise in security. Use it for a security review.
• Use other standard tools that check code quality, security, and what not. I have an open source package to help with this if you’re running in Python.
• Clean house! If Claude had a rough time, it probably left files that have a “_V2” or…”_Improved” and having two versions of the same thing will bite you. Factor so that you only have one and get rid of anything that says V2.
• Did it turn your home directory into a complete mess? Go for a nice sub directories and maintain them.
• make sure the feature document has everything you want. Usage, potential future features, history.
• Review the code yourself. I like using visual studio code with diff. If you wanna know how to shut that up, just ask Claude code
• Again with the checklist… for just about everything on the checklist, use AI to make your job easier. Cleaning up a mess made by AI, use AI to clean up the mess.
  • Clean code that has been reviewed by Claude, security reviewed by Claude, ideally reviewed by other tools, and had human review/oversight
  • Make sure the directories structure is organized well and clean. Clean home directory… good file names all around.
  • Make sure the Test suite is in good shape. Unit tests, integration, tests, and end to end tests. As usual, have the vast majority of tests, be the simpler ones and just a few of the especially hard ones. But don’t leave out important cases. And absolutely run it yourself. Don’t just trust the Test suite
  • Make sure everything is checked into source control nicely.
  • If What you did was tricky and there were things where you got annoyed, hopefully you made changes to the Claude.MD file to reduce the odds of the same exact thing happening again in the future.