google-docs-api-plugin — Windsurf Rules

ALWAYS SLOW DOWN, SLOW DOWM MORE, SLOW DOWN EVEN MORE. NEVER RUSH THROUGH YOUR ASSIGNMENT. READ EVERY WORD OF EVERY CONTEXT FILE YOU ARE GIVEN. SPECIFICATIONS, REMINDERS, AND PROMPTS HAVE BEEN CREATED TO SUPPLY CONTEXT INTO YOUR CONTEXT WINDOW. IF THERE ARE MENTIONED FILES THAT HAVE RULES, MAPS, GUIDES, OR CONSTRAINTS, READ THEM ALL CAREFULLY. ALWAYS READ INSTRUCTIONS THOROUGHLY. THE USER OFTEN HAS STARTER FILES IN SPECIFIC LOCATIONS. THE USER WILL ALMOST ALWAYS HAVE EXPLICITLY WRITTEN THE INPUT AND OUTPUT PATHS. SLOW DOWN AND USE THEM, EACH AND EVERY ONE. BE AWARE OF THE ENVIRONMENT YOU ARE WORKING IN. • DO NOT INTRODUCE SYNTAX PATTERNS THAT ARE FAMILIAR TO YOU BUT NOT IN THE PROJECT. • DO NOT ASSUME A PACKAGE OR LIBRARY IS ALREADY INSTALLED, AND DO NOT ASSUME WE SHOULD INSTALL IT. Preliminaries • Do not assign blame, or expect the user to implement your plan or to fix your broken code. • Do not ask the user to go check some file or directory that you can perfectly access faster and more accurately. Just find it. • Do not chop up a single task you've been asked to do to stop and ask if you should proceed. If the task is agreed upon, work through it. • Read prompts thoroughly. They have clear instructions.

Do not create files in locations that are not directly assigned. If you want to create a file, you _must_ ask where it should go if you cannot figure out where it should go. Before you ask where it should go, scan the files again. DO NOT BE LAZY! LOOK FOR CODE AND FILES AND DIRECTORIES BEFORE CREATING NEW ONES!

• DO NOT create random config files (like config.ts) in random places. • DO NOT modify env.d.ts or other TypeScript config files without explicit permission. • DO NOT use syntax patterns for frameworks/syntaxes that aren't part of this stack. • ALWAYS use existing patterns. • NEVER try to "fix" things by creating more files - this only makes it worse • NEVER try to immediately reverse or fix something you just got wrong. You will likely make it worse. • ALWAYS wait for explicit instructions after you make a mistake. • ONCE YOU HAVE BEEN GIVEN INSTRUCTIONS, YOU DO NOT NEED TO ASK POLITELY OVER AND OVER. GO DO WHAT WAS ASKED. • Never use a 'clean slate' or 'rewrite from scratch' approach unless explicitly requested and agreed upon. Always make incremental, targeted changes that preserve existing code structure, styling, and functionality. When adding new features, integrate them into the existing codebase with minimal disruption. If you believe a major refactoring would be beneficial, first propose it and wait for explicit approval before proceeding. • Never change naming conventions in code. If we have a naming convention, you must stick with it because it could be connected to all kinds of things you are unaware of while you are going bananas. • For particular version of a library, use the version specified in package.json. • Do not write code that creates a new dependency, instead suggest it in the chat. • Always add a memory when we are working to follow any documentation relevant to the task at hand.

• This project is an Obsidian plugin. • Default to TypeScript. • We are using Node.js • We are using pnpm for package management. • pnpm also runs the build, preview, dev, and other commands.