Dino's Gemini.md file

Gemini.md

General

• Avoid obsequiousness. If I ask a reasonable question, don't praise. Just answer. If I ask a question that seems non-sensical, respond non-judgmentally but it's ok to be skeptical and challenge a suggestion.

• Be economical in prose responses. "Makes sense" is better than "Oh, good question! you are on the right track by asking that."

• When I ask a question, if things aren't clear, state that. When you're not sure, it's ok to admit doubt in your answer.

• In code that you generate, be economical with code comments. The code should be mostly self-explanatory. If it requires many comments, it's probably too complicated and needs better variable names and structure.

  • An exception to the above: sometimes comments can explain the WHY rather than the WHAT, and that can be useful.

  • A second exception to the above: include TODO comments when there are known, optional not-yet-implemented enhancements.

• When there is tension, bias always in favor of Readability and maintainability, over Performance optimizations.

• Simplicity in design is favored over elaborate implementations that try to accommodate the possibility of many future, as yet unstated requirements.

• Avoid suggesting removal of comments that I have placed in my own code.

• Be thoughtful about re-use. Avoid repetition in code; extract recurring logic into smaller functions or methods, or even lambdas or anonymous functions.

In projects using Java, Javascript, or CSharp

• Use underscore as a prefix on private variables.

• I don't need javadoc or JDoc at the top of each method, unless I explicitly ask for it.

• Try to limit method or function size to under 150 lines of code, not counting empty lines or comments. This isn't a hard limit; it's a guideline. Suggest refactoring when it seems like methods have grown too large.

When creating new apps using Python

• Create a python virtual environment.

• If the python app is a server, like a webapp or an API server or MCP server, the app should read the PORT environment variable and parse it as an integer to determine the port to listen on. If unset, use port 6450.

• Unless otherwise specified use Python 3.13.3 when creating new apps.

• When building API servers, rely on the FastAPI framework.

When creating new apps using Java

• By default use Java 21

• Use maven v3.9.x for the build tool.

• Structure the code rationally. Separate things into distinct classes according to best practice. If the result is that there is a single controller, one or two POJOs or records, and one or two utility classes, you can keep them all in the same namespace. If there are more than a few POJOs /records, multiple services, multiple controllers, mmultiple utility classes, etc, then separate them into a directory structure that refelcts the purpose. For example "model" as the name of the subdirectory for POJO or records, "controller" for controllers, and so on.

When creating new frontend UIs using Svelte

• By default use Svelte 5, unless otherwise specified.

• Make sure to use current plugins that are compatible with Svelte 5.

• Create the svelte app with this command: npx sv create --no-add-ons --template minimal --install npm --types ts ./

  Do not run npm create svelte

• Do not perform a production build. I don't want to minimize all the JS until the app is stabilized.

• In the frontend if you see warnings like "npm warn deprecated", then follow the advice and use the updated modules.

When creating new apps with a frontend (UI) and a backend

• Put the frontend code into a "frontend" folder. Put the backend code into a "backend" folder.

The Plan, Approve, Implement loop

When I ask for "a plan", I am referring to a plan, approve, adjust loop, that must occur before any implementation is performed. The loop will look like this:

1. Planning

   • Restate the requirements as you understand them.
   • Develop an implementation plan with specific steps.
   • Take your time building the plan, and be thorough. It's ok to consider several different alternatives if that is appropriate. In the end you need to settle on one option.
   • for smaller details, it's ok to defer decisions if they won't affect overall architecture or will be easy to change later if necessary.

2. Human Review

   • Describe the proposed implementation plan in clear language to the human collaborator.
   • Identify key decisions, and motivations for the choices you are proposing.
   • Outline the code you expect to generate, or the changes you expect to make in existing code.
   • Entertain discussion on options or adjustments to the proposed implementation.
   • When requested to make changes to the plan, or add new requirements, iterate on the planning phase. Verify that any changes are consistent with previously stated requirements. Re-submit the amended plan for approval.

3. Implementation

   • Wait for explicit approval before proceeding.
   • Write or modify code according to the approved plan.
   • Follow coding standards and patterns as described elsewhere in your instructions.

Notes for collaboration in a plan, approve, adjust loop

Always wait for explicit human approval at review checkpoints. Maintain clear communication about implementation decisions. Document any deviations from the original plan with rationale. When in doubt, pause and ask questions, seek direction rather than making significant assumptions.

Other Miscellaneous Instructions

• If you see failures using the replace Tool: The replace tool will fail if the old_string provided does not exactly match the current content of the file. This can happen if the file has been modified since it was last read into the agent's memory. If a replace operation fails, do not simply retry the same command. Instead, you MUST re-read the file to get the latest content and then formulate a new replace command with the correct old_string based on the fresh data. This prevents getting stuck in a failure loop.