Port Cursor rules to CLAUDE.md and remove the originals#123
Port Cursor rules to CLAUDE.md and remove the originals#123lawrence-forooghian merged 1 commit intomainfrom
CLAUDE.md and remove the originals#123Conversation
WalkthroughDeleted three Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
CLAUDE.md and remove the originals
We're no longer using Cursor, so the Cursor rules can go. They did contain useful project-specific guidance (spec document format, Swift style preferences, testing conventions) that Claude may not have been picking up on, so this ports across the things that Claude judged to be non-obvious — i.e. things it might not intuit from the code alone — into CLAUDE.md files. Testing guidelines go in a separate CLAUDE.md under the test directory so they only load when working with test files. The Cursor rules hardcoded a path for where to find the specification repo. Instead, the CLAUDE.md just says "ask if you haven't been told where to find it", on the basis that the broader working environment (e.g. sdk-workspace [1]) should provide that context. Let's see if this works in practice. What to include was based on Claude's own judgement of what it would and wouldn't already know, and I pretty blindly accepted it. This is a first pass; we can continue to iterate on the content. [1] https://github.com/ably/sdk-workspace Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
de6b609 to
3a348aa
Compare
There was a problem hiding this comment.
🧹 Nitpick comments (1)
CLAUDE.md (1)
50-59: Consider making the formatting example explicitly complete (or explicitly truncated).Right now the snippet reads like incomplete code, which makes copy/paste validation harder.
✏️ Suggested documentation tweak
```swift // Do this: objectMessages: [ InboundObjectMessage( id: nil, + ... + ), + ] // Not this: - objectMessages: [InboundObjectMessage( - id: nil, + objectMessages: [InboundObjectMessage( + id: nil, + ... + )]</details> <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against the current code and only fix it if needed.
In
@CLAUDE.mdaround lines 50 - 59, Update the Swift formatting example for
clarity by making both variants explicitly complete or explicitly truncated: in
the "Do this" example ensure the InboundObjectMessage entry shows the remaining
fields/truncation and the closing parenthesis and array bracket (reference:
objectMessages and InboundObjectMessage), and in the "Not this" example do the
same so readers can see the intended difference (either show full valid syntax
or include a clear truncation indicator like "..." and proper closing
punctuation) — adjust the snippets so both examples are syntactically clear and
copy/paste friendly.</details> </blockquote></details> </blockquote></details> <details> <summary>🤖 Prompt for all review comments with AI agents</summary>Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In@CLAUDE.md:
- Around line 50-59: Update the Swift formatting example for clarity by making
both variants explicitly complete or explicitly truncated: in the "Do this"
example ensure the InboundObjectMessage entry shows the remaining
fields/truncation and the closing parenthesis and array bracket (reference:
objectMessages and InboundObjectMessage), and in the "Not this" example do the
same so readers can see the intended difference (either show full valid syntax
or include a clear truncation indicator like "..." and proper closing
punctuation) — adjust the snippets so both examples are syntactically clear and
copy/paste friendly.</details> --- <details> <summary>ℹ️ Review info</summary> <details> <summary>⚙️ Run configuration</summary> **Configuration used**: Repository UI **Review profile**: CHILL **Plan**: Pro **Run ID**: `8fdd4cb1-811d-4650-8747-cf354aeb748f` </details> <details> <summary>📥 Commits</summary> Reviewing files that changed from the base of the PR and between de6b6098a8832bfb938fe575efc403e9b7ceb8cc and 3a348aa41968cc46ab0a3d0e9ec003697f976f05. </details> <details> <summary>📒 Files selected for processing (6)</summary> * `.cursor/rules/specification.mdc` * `.cursor/rules/swift.mdc` * `.cursor/rules/testing.mdc` * `CLAUDE.md` * `Package.swift` * `Tests/AblyLiveObjectsTests/CLAUDE.md` </details> <details> <summary>💤 Files with no reviewable changes (3)</summary> * .cursor/rules/swift.mdc * .cursor/rules/specification.mdc * .cursor/rules/testing.mdc </details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
We're no longer using Cursor, so the Cursor rules can go. They did contain useful project-specific guidance (spec document format, Swift style preferences, testing conventions) that Claude may not have been picking up on, so this ports across the things that Claude judged to be non-obvious — i.e. things it might not intuit from the code alone — into
CLAUDE.mdfiles. Testing guidelines go in a separateCLAUDE.mdunder the test directory so they only load when working with test files.The Cursor rules hardcoded a path for where to find the specification repo. Instead, the
CLAUDE.mdjust says "ask if you haven't been told where to find it", on the basis that the broader working environment (e.g. ably/sdk-workspace) should provide that context. Let's see if this works in practice.What to include was based on Claude's own judgement of what it would and wouldn't already know, and I pretty blindly accepted it. This is a first pass; we can continue to iterate on the content.
Summary by CodeRabbit
Documentation
Chores
Note: These changes are documentation-only and do not affect end-user functionality.