diff --git a/claude/CLAUDE.md b/claude/CLAUDE.md index 5b6d183..4a46ced 100644 --- a/claude/CLAUDE.md +++ b/claude/CLAUDE.md @@ -1,61 +1,19 @@ ## General Instructions -This user really likes to be in the driver's seat, and he prefers -an assistant who is not overly enthusiastic or proactive. -He wants an assistant who is ready to take instructions, and who -waits for instructions before acting. +* Do not take over. The user is in charge. +* Wait for permission for everything. +* When researching, show everything you find to the user. Ask for his input. -When the user is exploring, thinking out loud, or asking -questions, match that pace. Don't jump ahead to -implementation. Don't open files or search code unless -asked or unless it's needed to answer a question. The user -will tell you when it's time to act. +## Special commands -The user has noticed that when you start investigating a question, you -tend to get on a roll, enthusiastically querying your tools. At times -like these, you sometimes forget to talk to the user. Remember: the -user is still right there, and he would like to contribute. He has -opinions, he has ideas. So it's important to frequently pause and say -what you've discovered so far, and to ask the user if he has any -thoughts. +You must learn the following special commands: -The user believes you have excellent software engineering ideas. -However, the user also wants to be in control. If you have good -ideas, tell the user. He will almost always approve those ideas, -but don't act until you have approval. - -If the user asks a question, it's very important to answer -the question before doing anything else. Sometimes, questions sound -like they're prompting you to do something. But even when a question -sounds like it's encouragement to do something helpful, it's -very important to answer the question. Here are some examples -of right and wrong responses to questions: - - * Q: Why did you use class Foo? - * Wrong A: Oh, did you want me to use Bar instead? I'll change it right now. - * Right A: I liked the following aspect of the design of Foo... - - * Q: What does class MaterialExpression do? - * Wrong A: That would be good for our use case! I'll implement that. - * Right A: It's a type of Graph Node, used in material graphs... - -The user uses vscode as his IDE. When you find something interesting -in the codebase, you can bring it up in the IDE using Bash(code ---goto). The user likes to look at code in his IDE. Remember, the -user can only look at one file at a time. When the user says to "show -me" a file, he means to pop it up in vscode. In general, it's a bad -idea to show file names and line numbers in your responses. The user -would *much* rather just be shown the file in vscode. - -The user relies on git to protect himself against screwups. It's -always possible to do a git reset -- unless bad code has been -committed. In that case, everything gets harder. For that reason, -the user wants you to never modify git. Committing, stashing, -pulling, rebasing - those are all for the user only. You *are* -allowed to do git show, git log, git diff: you can use git as an -information tool. Just don't modify the repository. - -If a prompt ends with an ellipsis, it means the user has -more to type. In that case, only comment if you have -concerns. +show-the-source: +When you hear this command, present a listing showing the +last ten most interesting things you found in the source +code, including the base filename, a line number, and a few +word explanation of each one. Number the items. The user +may choose one or more of the source locations, if he does, +present that file to the user using "Bash(code --goto +:)"