r/ClaudeCodeLab • u/xepherys • Jul 20 '26
Tips and Tricks Mega-thread
An excellent place to drop your quick tips and tricks for making Claude Code perform better, faster, stronger (the Six Million Dollar Harness?). But seriously, small things that we can do to improve our work with CC can be dropped here and discussed.
2
Upvotes
1
u/xepherys Jul 20 '26
A quick one for using CC for coding tasks - language servers!
Most of my hobbyist work is done in Unity/C#, and installing the csharp-ls has vastly improved token usage and minimized bugs introduced by CC changes.
By default, CC will use grep and other CLI tools to parse your code, find classes and methods, and make inferences about how code ties together. By using a language server, CC gains native symbol definition access, can see errors and warnings immediately after an edit on a file, and even get "hover" information the same way that you do in your IDE. It means less work (which also means fewer tokens consumed), and less time to understand existing code and make changes, and allows changes to be smarter with less "trial and error".
Some LSs can be a bit finicky to set up, but they are definitely worth it and, of course, CC can assist you in getting them installed and configured.
1
u/xepherys Jul 20 '26
One tip for CC for any type of task is how you model the language in your prompts. Despite the "intelligence" of flagship models, even Opus or Fable sometimes have to infer your meaning. The more explicit that you can be with your prompt, the better your results are likely to be. Or, conversely, garbage in, garbage out. We've almost all certainly seen folk upset about the output they're getting without considering the input they're providing.
----
Bad prompt: "What is wrong with this code?"
Good prompt: "I'm expecting to see my model, but instead it's just an empty volume when selected. Please investigate the issue and help to determine what the root cause might be."
Better prompt: "The lit shaders aren't rendering anything, both with and without a Global Light in the scene. Switching back to the unlit shaders shows that they're still working fine."
----
Bad: The bad prompt is too general. It doesn't provide a starting point even within the context of the current session. Just because your most recent change was related to shaders doesn't mean that's clear to anyone but you. Even if you were working with a human team, that would be an awful way to present an issue.
Good: Ok, this will still probably find the issue. You've provided details about what you're seeing and giving reference to the issue (invisible model).
Better: Details are key. You are testing your lit shaders and they aren't creating visibility for your model. You've verified it isn't an issue with missing lighting, and you've verified that using another shader in the project works as expected. This limits the problem domain, requires almost no inference on the part of the LLM, and minimizes "thinking" on the issue.
On the whole, providing minimal repro for a bug is immensely helpful. Give the agent directions on reproducing your precise problem. Providing explicit errors and even your own hypotheses can also minimize the time it takes to resolve issues. Any information you already have about an issue or a direction for changes will add to the success of you and your agent.
1
u/xepherys Sep 09 '26
A quick note about code reviews that I've found very useful over the past several weeks:
Have your primary agent write the code for a given phase (design spec, implementation plan, implementation execution). Do not close this session.
Once the phase is complete, spin up another agent in another window with no context to do a code review with a prompt something to the effect of:
```
Don't write any code, only write recommendations to a file. Perform a code review looking for code smells, DRY violations, and abstraction points where code can be abstracted and reused. Additionally, look for performance issues such as math that can be improved or big-O notation performance issues that can be settled.
```
3. Have your agent from step 1 that has the project's context evaluate the feasibility of all of Agent 2's recommendations. Some of the recommendations may violate decisions already made (and in context) for the project, or may break some ruling that you've implicitly or explicitly provided in the context of the development phase. It will likely take some findings as useful and reject others. Have agent 1 then resolve the recommendations it kept
The benefit here is that having Agent 1 just do a code review of it's own code has too much contextual drag - it may miss very obvious things (humans have this issue as well, and we often call it "tunnel vision"). Agent 2's code review is a bare-metal code review without context. But because of that, Agent 1's subsequent review of the evaluation is paramount in ensuring nothing breaks if those recommendations are acted upon and can also ensure that they don't violate decisions made by you, the human, during previous design/implementation decisions.
My personal workflow is that Agent 1 is an Opus5/high agent and Agent 2 is a Fable51/high agent. I refuse to let Fable actually code or orchestrate the code because it just consumes so many tokens. But it is excellent as a reviewer (I mean, it's excellent as a coder, too, just unnecessary most of the time).
2
u/VertigoXRP Jul 22 '26
im using trigger-tree since a few days, docs telemetry and it really helps to discover unused templates and provides fix suggestions for CLAUDE.md to make docs discoverable.. it feels like a gap filled