Tips and tricks

Init claude memory inside the project

/init

Claude file roles:

  - .claude/instructions.md — behavioral rules (port conventions)                                     
  - CLAUDE.md — codebase architecture/context for productivity  

Add DIR to workflow:

claude --add-dir /path/to/another/folder

• Don’t parse full logs define specific rules for log grepping (Warning|Error|) etc.
• Better yet : enforce per specific use case, hooks that run commands with those specific regexes ( the patterns will be different for docker, your backend, frontend, or other logs.
• Even better: Implement specific service health check json endpoints (docker) that collect errors and output them as structured JSON. Or write a script or use some log parsing tool that collects and merges them. Then write a single health check hook that is the only source being used, which allows for args like –log backend –log frontend to make it even more constrained per use case.
• Claude supports LSP servers, and export ENABLE_LSP_TOOLS=1 before claude turns it on.
• Install the specific LSP servers from different plugins (main claude marketplace has a bunch for typescript, go, etc). This way, no log parsing is required in many cases. Errors are immediately read by Claude.

Claude is the only one that supports this AFAIK.

• Use MCP servers for things like external libraries (Context7), filesystem (yes, filesystem MCP exists , google), and depending on the frameworks you use (Svelte for frontend has a really good MCP with a highly detailed and extensive tool support : https://svelte.dev/docs/mcp/prompts#svelte-task)

Those are the things you need to look for first, as well as saving per development task/plan to your repo and collect them before work execution. Make sure you keep work plans as condensed as possible and don’t work on two things at the same time in the same branch. That last bit is a real irritating factor for LLMs as they get confused about if they were the ones who did it and how it is related to their work.