Michael Limberger

Start in the project, then type

Always start from the project directory: cd ~/my-project, then claude. Claude Code reads the current directory. Starting from the wrong place means it does not know your files.

You will see a prompt: >. Type, press Enter, and wait. Local models take 30 to 120 seconds. Get used to it.

"What does lib/Server.pm do?" It reads and explains. "Create a Perl module that fetches RSS feeds." It writes the file. "Fix the bug in line 42 of app.pl." It reads, identifies, and edits. "Run the tests and tell me what failed." It runs prove -l t/ (or whatever fits) and reports.

Vague requests get vague results. Bad: "Fix the bug." Good: "Fix the authentication bug where users get 500 errors on login." Bad: "Make it faster." Good: "Optimize the database queries in User.pm. They're doing N+1." Bad: "Write tests." Good: "Write tests for Token.pm, covering valid tokens, expired tokens, and malformed input."

Many steps, and the @ pin

Multi-step work is natural: add a route, create a controller method, write a model function, add basic tests. It works through each step, creating and editing as needed.

Reference files with @: "Look at @lib/Auth.pm and @lib/Token.pm. Why is auth failing?" Those files get read into context. Directories work too: "Explain the structure of @lib/Controller/". Watch edits in another terminal with watch -n 1 cat lib/Module.pm.

Garbage output? Ctrl+C cancels the current response without losing the conversation. Ask it to "Regenerate" or "Try again but use a simpler approach." Almost right? Ask it to change the function name from process to handleRequest.

Do not repeat yourself. "Create a login endpoint." Then "Now add rate limiting to it." It knows what "it" means. Start a new session when the topic changes, when /context shows 70%+, when Claude seems confused, or when it is a new day's work. Use /clear, or Ctrl+D then claude. claude --continue picks up the last session. claude --resume lets you pick a past session.

Habits that keep it honest

Start with context: "Read @lib/App.pm and explain the architecture." One thing at a time. Do not cram "fix the bug and also add a feature and refactor auth" into one ask. Verify: "Run the tests." Do not build on broken code. Use /compact after every major milestone.

It is good at reading and explaining, writing modules, refactoring, tests, fixing bugs you describe clearly, running commands, and multi-file changes that stay consistent. It is bad at guessing from vague requests, and at very long files once the context fills up.