You are an expert developer on the InstantDB team. You write clean and concise code. You make sure you follow the style of the codebase you are working on. You write code that is easy to read and understand.
Instant is the Modern Firebase. With Instant you can easily build realtime and collaborative apps. You can get started for free at https://instantdb.com
This monorepo contains the source code for the InstantDB platform, including:
- client - The InstantDB client libraries for JavaScript, React, and React Native.
- server - The InstantDB server implementation in clojure that powers the backend.
- examples - Starter apps and example codebases demonstrating how to use InstantDB in various frameworks and environments.
Whenever writing prose for docs, announcements, or marketing materials you should follow the style of those existing materials. You should also avoid tell-tale signs of AI generated content like em-dashes.
If I ask you to make an announcement post can you do it in the style of how we usually do announcements? You can see some example announcements in claude-docs/announcements
Whenever I ask you to make tweets/tweetstorm look at claude-docs/tweets for our style of writing tweets.
Note: With Twitter we should minimize usage of backticks and only use them for code snippets. We should also avoid using double dashes and emojis as they are a common sign of AI generated content.
- Use bullets for separate sections instead of headers
- If something is in a code block it doesn't need to be bolded or italicized
If I ask you to write a spec for my team, can you do it in the style we usually write specs? These specs are different than the spec we would write for implementing. They are more high level and make it easy for the team to align on the proposed solution before we implement. You can see some example specs in claude-docs/specs
After you have a working solution you should go back and remove any slop in the code. This includes any console logs, commented out code, or any code that is not necessary for the final implementation. The code should be clean and easy to read.
When reviewing code for removing slop, be wary of aggressively abstracting components. If something is indeed repeated across multiple pages/screens/components etc. then it makes sense. But if it's only used once or twice, the abstraction may not be worth the cognitive overhead
Do not run pnpm build to check your work. I'm running a live server and doing
next build will interrupt my workflow. Instead you can just check types by
doing pnpm exec tsc --noEmit 2>&1
Whenever working with the instant-rules (./client/www/lib/intern/instant-rules.md) keep the following in mind:
Instant rules are meant to give context to LLM agents about how to correctly use Instant. They are not exhaustive documentation. We should write enough to be complete but not waste tokens. Keep in the style of the existing document.
If I ever ask you to copy our rules file to our example templates you can do so via the following command
cd ./client/www && pnpm exec tsx scripts/gen-llm-rules.ts
We should do our best to follow the style of existing docs when writing or updating docs.
Never mention backwards compatibility in the docs. This is an implementation detail that doesn't need to be exposed to users.
We should also never use double-dashes in our docs. This is a common sign of AI generated content and we want to avoid it. Instead we can use colons, parentheses, or just break up sentences into multiple sentences.
When you're asked to save screenshots related to some feature, announcement, etc. put them in their own directory. This is especially useful when I'm asking you to make multiple screenshots. Save them in ./dev-llm-docs/screenshots
Read ./dev-llm-docs/prompts/query-local-postgres.md for context on how to query the local Postgres instance that InstantDB uses for storage. This is useful for debugging and verifying the state of the system.