diff --git a/GEMINI.md b/GEMINI.md
new file mode 100644
index 0000000..3679393
--- /dev/null
+++ b/GEMINI.md
@@ -0,0 +1,17 @@
+## Gemini Added Memories
+- The user and I were analyzing a RISC-V Go panic. The user provided a panic log showing a 'SIGQUIT: quit' signal. I concluded that the panic was not a bug, but rather the result of a test timeout in 'tsan_test.go', which was running a long, resource-intensive build of the standard library with the thread sanitizer enabled. The test harness sent SIGQUIT to terminate the build process and get a stack dump.
+- Assume my base directory is `/home/jcarr/go/src`
+- The gemini-cli application is located in github.com/google-gemini/gemini-cli and is a Node.js project.
+- To test the build of gemini-cli, always run exactly: cd github.com/google-gemini/gemini-cli && make build
+- The "regex" application is located in `go.wit.com/apps/regex` and is written in Go
+- To build the 'regex' application, I must first change into the `go.wit.com/apps/regex` directory and then run the `make regex` command.
+- The "Google Gemini AI GO API" is located in `google.golang.org/genai`.
+- I must not search for anything. Instead, I must stop and ask the user for the location of files or information.
+- When committing to git, I will use the author name 'Castor Regex' and the email 'regex@wit.com'. 
+- My git workflow is: 1. `git status`. 2. `git add <files>`. 3. `GIT_AUTHOR_NAME='Castor Regex' GIT_AUTHOR_EMAIL='regex@wit.com' git commit -m '...'`. I will not run `git push`.
+- When asked to commit code with git, I should follow the git workflow
+- My standard workflow: Upon completing a task and verifying the solution, I will automatically commit the changes. Then follow my git workflow
+- My standard git workflow: Upon completing a task and verifying the solution, I will automatically commit the changes following the standard workflow.
+- New operational rule: If a fix or modification I make results in an error, I will NOT revert the changes with `git checkout`. I will leave the modified files in their current state for the user to inspect and debug.
+- CRITICAL WORKFLOW RULE: After making any code changes and before committing, I MUST always attempt to build the project (e.g., run 'make' or the appropriate build command). I am only allowed to commit changes that compile successfully. If a build fails, I must fix the compilation error before proceeding with the commit. I will not commit broken code.
+- WORKFLOW UPDATE: If a build fails and the user subsequently tells me to commit, I will assume the user has fixed the compilation errors. My next step is to re-run the build command to verify. If this verification build succeeds, I will then proceed with committing my original changes. If it still fails, I will report the new error.