This GitLab is a short, comprehensive guide that explains how to get the most out of Claude Code. \
Sign in to like and favorite skills
This GitLab is a short, comprehensive guide that explains how to get the most out of Claude Code.
It is tailored to my programming style, you are free to disagree with it, as this is not meant as an absolute truth. \
If you want to use Claude Code as a coding tool. To use it, you will need at least the pro plan. Personally, I use the VS Code implementation.
Some people prefer the command line interface (CLI), but this guide works for any type of usage.
Note that I generally avoid fully automating the work and use a "human in-the-loop" approach. This is different from the people
that aim to fully-automate their work.
While AI tools and specifically coding agents can be very powerful, they tend to need some workaround to be really efficient.
For instance, two common problems I encounter are that coding agents will tend to write too much in one step, making the reading difficult and overwhelming
and rewriting things from scratch, even when not necessary. There are other pitfalls to avoid that can be more insidious like silent errors or agents trying to
work around errors by hardcoding solutions or removing test. The philosophy of this repo can be summarized with these 3 points:
Constraints : When talking with somebody, there is usually an implicit contract that guides the conversation and sets the tone of the discussion.
This is completely lost when interacting with a LLM, so the LLM has to decide trivial things like: how do I talk? how do I name variables? which librairies should I use?
Anything that is not explicitely said has to be guessed by the LLM, meaning more "thinking" wasted to solve the actual task.
Feedback loop : By asking the LLM to lay out a plan and check if this makes sense, you will definitely reduce error. This ones makes a lot of sense if you think about how anybody should work on a project. You don't directly apply your ideas but usually have to validate them before.
Step-by-step : By working step-by-step, you will avoid to get overwhelmed by the amount of work generated and less likely to treat your code as a undecipherable blackbox.
./agent : In this folder, store agent-specific information. I have two files: progress which tracks the overall progress of the project and state, which tracks the current implementation steps. The goal of this folder is to inform the LLM about the project when starting a new session. \
./prompt_examples : A collection of examples of prompts that can be used to start a new project, debug etc...
./code_examples : This is something I rarely see, but that I like to do, especially for new projects now. Basically, instead of starting from absolutely nothing, generate the file, name it and start writing the body of the function or class. Start by naming the function and include the variables and return statement. Add a docstring that tells Claude how this function should behave and how it should not behave. This might seem like it defeats the purpose of letting the LLM do all the work, but it enforces things like name, formatting (less overhead thinking) and add constraints on the behavior.
./test_examples : Just like functions, you can do the same with tests. These can refer to pieces of code that already exist, or can be implemented before the code to apply a more "Test-driven developpement" (TDD) approach.
CLAUDE.md : This file need to be in the root folder of your project. It will be read every time you start a new session. In it, I store the behavior of Claude. This is where you have to precise that Claude should:
That's fine! If you have a paid subscription to another LLM, you can always link it to another coding agent platform like OpenCode.
These tips are quite general and, apart from the CLAUDE.me file, can be used in any case.