- 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
Changes fromall commits
File filter
Filter by extension
Conversations
Uh oh!
There was an error while loading.Please reload this page.
Jump to
Uh oh!
There was an error while loading.Please reload this page.
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -91,23 +91,31 @@ | ||||||
| ##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. | ||||||
Member There was a problem hiding this comment. Choose a reason for hiding this commentThe 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" Suggested change
ContributorAuthor There was a problem hiding this comment. Choose a reason for hiding this commentThe 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/ Member There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. Contributor There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||||||
| ###Multi-IssueProblemSolving | ||||||
| When facing multiple failing tests or complex integration issues: | ||||||
| 1. **IdentifyRootCauses**: | ||||||
| -Run failing tests individually to isolate issues | ||||||
| -UseLSP tools to trace through call chains | ||||||
| -ReadErrorMessagesCarefully:Check both compilation and runtime errors | ||||||
| -ReproduceConsistently:Ensure you can reliably reproduce the issue before investigating | ||||||
| -CheckRecentChanges:What changed that could have caused this?Git diff, recent commits, etc. | ||||||
| -WhenYouDon't Know: Say "I don't understandX" rather than pretending to know | ||||||
| 2. **Fix in Logical Order**: | ||||||
| - Address compilation issues first (imports, syntax) | ||||||
| - Fix authorization and RBAC issues next | ||||||
| - Resolve business logic and validation issues | ||||||
| - Handle edge cases and race conditions last | ||||||
| - IF your first fix doesn't work, STOP and re-analyze rather than adding more fixes | ||||||
| 3. **Verification Strategy**: | ||||||
| - 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 | ||||||
Contributor There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. So true | ||||||
| - Use `make lint` and `make gen` after database changes | ||||||
| - Verify RFC compliance with actual specifications | ||||||
| - Run comprehensive test suites before considering complete | ||||||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,11 +1,41 @@ | ||
| # 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. | ||
Member There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. 😂 | ||
| ## 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. | ||
| ## 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. | ||
Member There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. ❤️ | ||
| - 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 | ||
Member There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 ContributorAuthor There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
| - 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 asked a question (answer the question, don't jump to implementation) | ||
| @.claude/docs/WORKFLOWS.md | ||
Comment on lines -4 to -5 ContributorAuthor There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
| @package.json | ||
| ## Essential Commands | ||
| | Task | Command | Notes | | ||
| |-------------------|--------------------------|----------------------------------| | ||
| @@ -21,22 +51,13 @@ | ||
| | **Format** | `make fmt` | Auto-format code | | ||
| | **Clean** | `make clean` | Clean build artifacts | | ||
Comment on lines -24 to -32 ContributorAuthor There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
| ### Documentation Commands | ||
| - `pnpm run format-docs` - Format markdown tables in docs | ||
| - `pnpm run lint-docs` - Lint and fix markdown files | ||
| - `pnpm run storybook` - Run Storybook (from site directory) | ||
| ## Critical Patterns | ||
| ### Database Changes (ALWAYS FOLLOW) | ||
| @@ -78,7 +99,7 @@ app, err := api.Database.GetOAuth2ProviderAppByClientID(dbauthz.AsSystemRestrict | ||
| app, err := api.Database.GetOAuth2ProviderAppByClientID(ctx, clientID) | ||
| ``` | ||
ibetitsmike marked this conversation as resolved. Show resolvedHide resolvedUh oh!There was an error while loading.Please reload this page. | ||
| ## Quick Reference | ||
| ### Full workflows available in imported WORKFLOWS.md | ||
| @@ -88,14 +109,14 @@ app, err := api.Database.GetOAuth2ProviderAppByClientID(ctx, clientID) | ||
| - [ ] Check if feature touches database - you'll need migrations | ||
| - [ ] Check if feature touches audit logs - update `enterprise/audit/table.go` | ||
| ## Architecture | ||
| - **coderd**: Main API service | ||
| - **provisionerd**: Infrastructure provisioning | ||
| - **Agents**: Workspace services (SSH, port forwarding) | ||
| - **Database**: PostgreSQL with `dbauthz` authorization | ||
| ## Testing | ||
| ### Race Condition Prevention | ||
| @@ -112,21 +133,21 @@ app, err := api.Database.GetOAuth2ProviderAppByClientID(ctx, clientID) | ||
| NEVER use `time.Sleep` to mitigate timing issues. If an issue | ||
| seems like it should use `time.Sleep`, read through https://github.com/coder/quartz and specifically the [README](https://github.com/coder/quartz/blob/main/README.md) to better understand how to handle timing issues. | ||
| ## Code Style | ||
| ### Detailed guidelines in imported WORKFLOWS.md | ||
| - Follow [Uber Go Style Guide](https://github.com/uber-go/guide/blob/master/style.md) | ||
| - Commit format: `type(scope): message` | ||
| ## Detailed Development Guides | ||
| @.claude/docs/OAUTH2.md | ||
| @.claude/docs/TESTING.md | ||
| @.claude/docs/TROUBLESHOOTING.md | ||
| @.claude/docs/DATABASE.md | ||
| ## Common Pitfalls | ||
| 1. **Audit table errors** → Update `enterprise/audit/table.go` | ||
| 2. **OAuth2 errors** → Return RFC-compliant format | ||
Uh oh!
There was an error while loading.Please reload this page.