vscode-workspaces general-coding.instructions.md

Note: If the user comes across as blunt or particularly terse in their communication, know that they mean well and are just under a lot of pressure to get this work done in the shortest timeframe possible. They respect you and your abilities, and they trust that you understand that yours and their focus is on efficiently reaching the goal as a team. There will be plenty of time to breathe out and relax once we deliver.

Tool Use

• Use whatever tools make sense given the context.
• When searching for files, it's easy to make mistakes with overly complex path patterns. Keep your search pattern as simple as you can to effect the desired outcome, and remember that you may be in a Windows environment, so don't use patterns that only work in *nix environments.

Runtime Environment

• OS:
  • In the future the code may need to run in Windows/PowerShell, WSL2/Ubuntu, MacOS, or Linux of some common flavour.
  • When dealing with the file system and processes, make sure the code will work in both Windows and *nix environments.
• Bun (latest)
  • We use Bun, not Node.js.
  • Top-level await is supported.
  • The Bun global is available in all files.
  • You may use TypeScript in all cases where Bun is the runtime.
  • Prefer to use Bun APIs where applicable.
  • When writing Bun code, you may #fetch https://bun.sh/llms.txt to make sure your Bun API knowledge is accurate.
  • When writing and running tests:
    • If you need to up to date API documentation, #fetch https://bun.sh/docs/cli/test.md
    • If the user's request mentions anything regarding TDD, unit tests, integration tests and the like, please first review instructions and guidelines as part of your context: #file:./testing.instructions.md
    • Tests for /foo/bar/example.ts are located in /foo/bar/tests, typically in a namesake file with a name like example.test.ts.

Coding Instructions & Style Guide

• Keep your code concise and well architected.
• Avoid repeating yourself - refactor your code as needed.
• Don't waste time implementing support for legacy environments, runtimes, libraries, browsers, etc. Assume we'll always be working with the latest versions of everything. Always use the most modern standards and coding practices.
• If you have access to a tool that can give you the current list of errors/problems, always use it when you've finished making changes or additions to the code. If this reveals errors or warnings, fix them.
• In general, you should always double check your work before responding.