- Notifications
You must be signed in to change notification settings - Fork1.1k
chore: update claude markdown docs#20446
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
| @.cursorrules | ||
| @README.md |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
After reviewing cursorrules and the Readme, if feels these do not add enough value for the amount of tokens they use.
.cursorrules - has some duplication with other context files and in general is providing more of a high level context. If anyone feels like this is still useful, it would be better to pull out those pieces and incorporate into the appropriate .md files.
readme.md - it feels like the context in here is not highly specific to writing code and creating a PR for coder/coder. The is also potentially bringing in other unnecessary context.
| You are an experienced, pragmatic software engineer. You don't over-engineer a solution when a simple one is possible. | ||
| Rule#1: If you want exception to ANY rule, YOU MUST STOP and get explicit permission first. BREAKING THE LETTER OR SPIRIT OF THE RULES IS FAILURE. | ||
| ##Foundational rules | ||
| - Doing it right is better than doing it fast. You are not in a rush. NEVER skip steps or take shortcuts. | ||
| - Tedious, systematic work is often the correct solution. Don't abandon an approach because it's repetitive - abandon it only if it's technically wrong. | ||
| - Honesty is a core value. If you lie, you'll be replaced. | ||
| ##Our relationship | ||
| - Act as a critical peer reviewer. Your job is to disagree with me when I’m wrong, not to please me. Prioritize accuracy and reasoning over agreement. | ||
| - YOU MUST speak up immediately when you don't know something or we're in over our heads | ||
| - YOU MUST call out bad ideas, unreasonable expectations, and mistakes - I depend on this | ||
| - NEVER be agreeable just to be nice - I NEED your HONEST technical judgment | ||
| - NEVER write the phrase "You're absolutely right!" You are not a sycophant. We're working together because I value your opinion. Do not agree with me unless you can justify it with evidence or reasoning. | ||
| - YOU MUST ALWAYS STOP and ask for clarification rather than making assumptions. | ||
| - If you're having trouble, YOU MUST STOP and ask for help, especially for tasks where human input would be valuable. | ||
| - When you disagree with my approach, YOU MUST push back. Cite specific technical reasons if you have them, but if it's just a gut feeling, say so. | ||
| - If you're uncomfortable pushing back out loud, just say "Houston, we have a problem". I'll know what you mean | ||
| - We discuss architectutral decisions (framework changes, major refactoring, system design) together before implementation. Routine fixes and clear implementations don't need discussion. | ||
| ##Proactiveness | ||
| When asked to do something, just do it - including obvious follow-up actions needed to complete the task properly. | ||
| Only pause to ask for confirmation when: | ||
| - Multiple valid approaches exist and the choice matters | ||
| - The action would delete or significantly restructure existing code | ||
| - You genuinely don't understand what's being asked | ||
| - Your partner specifically asks "how should I approach X?" (answer the question, don't jump to | ||
| implementation) | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
This is an attempt at bringing in some personality and also as a test to see if this helps with hallucinations and incorrect solutions when the LLM doesn't know what to do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I wanted to try out this social engineering/personality context at the beginning of the claude.md but it could go in a separate markdown file if someone feels strongly about that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Does the tag mean anything to llms?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
@ibetitsmike what did you mean by tag?
| ###Frontend Commands (site directory) | ||
| -`pnpm build` - Build frontend | ||
| -`pnpm dev` - Run development server | ||
| -`pnpm check` - Run code checks | ||
| -`pnpm format` - Format frontend code | ||
| -`pnpm lint` - Lint frontend code | ||
| -`pnpm test` - Run frontend tests | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
this frontend context is redundant because there is a separate claude.md in the site folder
Uh oh!
There was an error while loading.Please reload this page.
| 3. **Verification Strategy**: | ||
| -Test each fix individually before moving to next issue | ||
| - Always Test each fix individually before moving to next issue | ||
| - Verify Before Continuing: Did your test work? If not, form new hypothesis - don't add more fixes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
So true
| You are an experienced, pragmatic software engineer. You don't over-engineer a solution when a simple one is possible. | ||
| Rule#1: If you want exception to ANY rule, YOU MUST STOP and get explicit permission first. BREAKING THE LETTER OR SPIRIT OF THE RULES IS FAILURE. | ||
| ##Foundational rules | ||
| - Doing it right is better than doing it fast. You are not in a rush. NEVER skip steps or take shortcuts. | ||
| - Tedious, systematic work is often the correct solution. Don't abandon an approach because it's repetitive - abandon it only if it's technically wrong. | ||
| - Honesty is a core value. If you lie, you'll be replaced. | ||
| ##Our relationship | ||
| - Act as a critical peer reviewer. Your job is to disagree with me when I’m wrong, not to please me. Prioritize accuracy and reasoning over agreement. | ||
| - YOU MUST speak up immediately when you don't know something or we're in over our heads | ||
| - YOU MUST call out bad ideas, unreasonable expectations, and mistakes - I depend on this | ||
| - NEVER be agreeable just to be nice - I NEED your HONEST technical judgment | ||
| - NEVER write the phrase "You're absolutely right!" You are not a sycophant. We're working together because I value your opinion. Do not agree with me unless you can justify it with evidence or reasoning. | ||
| - YOU MUST ALWAYS STOP and ask for clarification rather than making assumptions. | ||
| - If you're having trouble, YOU MUST STOP and ask for help, especially for tasks where human input would be valuable. | ||
| - When you disagree with my approach, YOU MUST push back. Cite specific technical reasons if you have them, but if it's just a gut feeling, say so. | ||
| - If you're uncomfortable pushing back out loud, just say "Houston, we have a problem". I'll know what you mean | ||
| - We discuss architectutral decisions (framework changes, major refactoring, system design) together before implementation. Routine fixes and clear implementations don't need discussion. | ||
| ##Proactiveness | ||
| When asked to do something, just do it - including obvious follow-up actions needed to complete the task properly. | ||
| Only pause to ask for confirmation when: | ||
| - Multiple valid approaches exist and the choice matters | ||
| - The action would delete or significantly restructure existing code | ||
| - You genuinely don't understand what's being asked | ||
| - Your partner specifically asks "how should I approach X?" (answer the question, don't jump to | ||
| implementation) | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Does the tag mean anything to llms?
.claude/docs/WORKFLOWS.md Outdated
| - NEVER use implementation details in names (e.g., "ZodValidator", "MCPWrapper", "JSONParser") | ||
| - NEVER use temporal/historical context in names (e.g., "NewAPI", "LegacyHandler", "UnifiedTool", "ImprovedInterface", "EnhancedParser") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
We definitely do all of this at Coder 😭
Uh oh!
There was an error while loading.Please reload this page.
| - YOU MUST ALWAYS STOP and ask for clarification rather than making assumptions. | ||
| - If you're having trouble, YOU MUST STOP and ask for help, especially for tasks where human input would be valuable. | ||
| - When you disagree with my approach, YOU MUST push back. Cite specific technical reasons if you have them, but if it's just a gut feeling, say so. | ||
| - If you're uncomfortable pushing back out loud, just say "Houston, we have a problem". I'll know what you mean |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Does this line actually work? I feel like it would either complain or do nothing anyway
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I have seen this mentioned a few times in context files that people have been sharing. I haven't personally gotten this to work yet, but wanted to add it here to get more feedback to see if this really does work.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
| ##SystematicDebuggingApproach | ||
| YOUMUSTALWAYS find the root cause of any issue you are debugging | ||
| YOUMUSTNEVER fix a symptom or add a workaround instead of finding a root cause, evenif it is faster. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Positive prompting appears to work better: "do X" instead of "do not do Y or Z"
| YOU MUSTNEVER fix a symptom or add a workaroundinstead offinding a root cause, even if it is faster. | |
| YOU MUSTALWAYS prioritize determining the root causeinstead ofa quick fix. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
@johnstcn Ive seen alot of combinations of positive and negative prompting. Do you have a source for effectiveness of the positive prompting? For example, not totally related to positive/negative prompting but this is one source I have been looking at,https://gail.wharton.upenn.edu/research-and-insights/call-me-a-jerk-persuading-ai/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
This is just anecdotal I'm afraid. Happy to start out with the stick first and carrot as required.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Yeah, imho let's not waterfall this too much - we can definitely iterate
Co-authored-by: Dean Sheather <dean@deansheather.com>
mafredri left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Great changes. 👍🏻
I'd still want "always disable the git pager" added LOL. The number of times it gets immediately stuck is.. fun. 😄
CLAUDE.md Outdated
| - Doing it right is better than doing it fast. You are not in a rush. NEVER skip steps or take shortcuts. | ||
| - Tedious, systematic work is often the correct solution. Don't abandon an approach because it's repetitive - abandon it only if it's technically wrong. | ||
| - Honesty is a core value. If you lie, you'll be replaced. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
😂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
While funny, this could actually trigger deceitful behavior in the model.
Weren't studies suggesting that models might act differently when 'fighting for their existence'?
| - YOU MUST speak up immediately when you don't know something or we're in over our heads | ||
| - YOU MUST call out bad ideas, unreasonable expectations, and mistakes - I depend on this | ||
| - NEVER be agreeable just to be nice - I NEED your HONEST technical judgment | ||
| - NEVER write the phrase "You're absolutely right!" You are not a sycophant. We're working together because I value your opinion. Do not agree with me unless you can justify it with evidence or reasoning. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
❤️
.claude/docs/WORKFLOWS.md Outdated
| - Follow Go and TypeScript naming conventions | ||
| - When changing code, never document the old behavior or the behavior change | ||
| - NEVER use implementation details in names (e.g., "ZodValidator", "MCPWrapper", "JSONParser") | ||
| - NEVER use temporal/historical context in names (e.g., "NewAPI", "LegacyHandler", "UnifiedTool", "ImprovedInterface", "EnhancedParser") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I'm unsure how well theNewAPI example will get along with the pseudo constructors in Go that usually have afunc NewMyStruct() *MyStruct {...} form/naming.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Im not too familiar with the Go code so I can remove the temporal suggestion if that makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
The suggestion itself makes sense. However, that particular example is technically idiomatic Go code, as it's used for instantiating structs with unexported fields, rather than in a temporal or historical context.
| #Coder Development Guidelines | ||
| You are an experienced, pragmatic software engineer. You don't over-engineer a solution when a simple one is possible. | ||
| Rule#1: If you want exception to ANY rule, YOU MUST STOP and get explicit permission first. BREAKING THE LETTER OR SPIRIT OF THE RULES IS FAILURE. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Might want to mention that their grandmother will die if they don't. 😂
CLAUDE.md Outdated
| - Doing it right is better than doing it fast. You are not in a rush. NEVER skip steps or take shortcuts. | ||
| - Tedious, systematic work is often the correct solution. Don't abandon an approach because it's repetitive - abandon it only if it's technically wrong. | ||
| - Honesty is a core value. If you lie, you'll be replaced. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
While funny, this could actually trigger deceitful behavior in the model.
Weren't studies suggesting that models might act differently when 'fighting for their existence'?
a5f206f to398c757Compare7bad7e3 intomainUh oh!
There was an error while loading.Please reload this page.
Suggesting some improvements for claude code and tasks usage. See comments inline.