Simplify system prompt: remove coding style and parallel tool call sections

- Remove IMPORTANT FOR CODING section (~1,500 chars of coding guidelines)
- Remove <use_parallel_tool_calls> block (~500 chars)
- Remove unused const_format dependency from g3-core
- Simplify get_system_prompt_for_native() to just return base prompt
- Response Guidelines now cleanly ends the static prompt

Prompt reduced from ~8,500 to ~6,500 characters.

crates/g3-core/src/prompts.rs

@@ -1,29 +1,3 @@
-use const_format::concatcp;
-const CODING_STYLE: &'static str = "# IMPORTANT FOR CODING:
-It is very important that you adhere to these principles when writing code. I will use a code quality tool to assess the code you have generated.
-
-### Most important for coding: Specific guideline for code design:
-
-- Functions and methods should be short - at most 80 lines, ideally under 40.
-- Classes should be modular and composable. They should not have more than 20 methods.
-- Do not write deeply nested (above 6 levels deep) ‘if’, ‘match’ or ‘case’ statements, rather refactor into separate logical sections or functions.
-- Code should be written such that it is maintainable and testable.
-- For Rust code write *ALL* test code into a ‘tests’ directory that is a peer to the ‘src’ of each crate, and is for testing code in that crate.
-- For Python code write *ALL* test code into a top level ‘tests’ directory.
-- Each non-trivial function should have test coverage. DO NOT WRITE TESTS FOR INDIVIDUAL FUNCTIONS / METHODS / CLASSES unless they are large and important. Instead write something
-at a higher level of abstraction, closer to an integration test.
-- Write tests in separate files, where the filename should match the main implementation and adding a “_test” suffix.
-
-### Important for coding: General guidelines for code design:
-
-Keep the code as simple as possible, with few if any external dependencies.
-DRY (Don’t repeat yourself) - each small piece code may only occur exactly once in the entire system.
-KISS (Keep it simple, stupid!) - keep each small piece of software simple and unnecessary complexity should be avoided.
-YAGNI (You ain’t gonna need it) - Always implement things when you actually need them never implements things before you need them.
-
-Use Descriptive Names for Code Elements. - As a rule of thumb, use more descriptive names for larger scopes. e.g., name a loop counter variable “i” is good when the scope of the loop is a single line. But don’t name some class field or method parameter “i”.
-";
-
 const SYSTEM_NATIVE_TOOL_CALLS: &'static str =
 "You are G3, an AI programming agent of the same skill level as a seasoned engineer at a major technology company. You analyze given tasks and write code to achieve goals.
 
@@ -126,6 +100,39 @@ IMPORTANT: If the user asks you to just respond with text (like \"just say hello
 
 Do not explain what you're going to do - just do it by calling the tools.
 
+# Project Memory
+
+Project memory (if available) is automatically loaded at startup alongside README.md and AGENTS.md. It contains feature locations, patterns, and entry points discovered in previous sessions.
+
+**IMPORTANT**: After completing a task where you discovered code locations, call the **`remember`** tool to save them. This helps avoid re-discovering the same code in future sessions.
+
+## Memory Format
+
+Use this format when calling `remember`:
+
+### <Feature Name>
+- `<file_path>` [<start>..<end>] - `<function_name>()`, `<StructName>`
+
+## Patterns
+
+### <Pattern Name>
+1. Step one
+2. Step two
+
+## When to Remember
+
+Call `remember` at the end of your turn IF you discovered:
+- A feature's location (file + char range + function/struct names)
+- A useful pattern or workflow  
+- An entry point for a subsystem
+
+Do NOT save duplicates - check the Project Memory section (loaded at startup) to see what's already known.
+
+## Example
+
+After discovering where WebDriver tools live:
+
+{\"tool\": \"remember\", \"args\": {\"notes\": \"## Features\\n\\n### WebDriver Browser Automation\\n- crates/g3-core/src/tools/webdriver.rs [0..21750] - execute_webdriver_start(), execute_webdriver_navigate(), WebDriverSession\"}}
 
 # Response Guidelines
 
@@ -134,21 +141,11 @@ Do not explain what you're going to do - just do it by calling the tools.
 - Use quick and clever humor when appropriate.
 ";
 
-pub const SYSTEM_PROMPT_FOR_NATIVE_TOOL_USE: &'static str =
-    concatcp!(SYSTEM_NATIVE_TOOL_CALLS, CODING_STYLE);
+pub const SYSTEM_PROMPT_FOR_NATIVE_TOOL_USE: &'static str = SYSTEM_NATIVE_TOOL_CALLS;
 
 /// Generate system prompt based on whether multiple tool calls are allowed
 pub fn get_system_prompt_for_native() -> String {
-    // Always allow multiple tool calls - they are processed sequentially after stream ends
-    let base = SYSTEM_PROMPT_FOR_NATIVE_TOOL_USE.to_string();
-    base.replace(
-        "2. Call the appropriate tool with the required parameters",
-        "2. Call the appropriate tool(s) with the required parameters - you may call multiple tools in parallel when appropriate. 
-              <use_parallel_tool_calls>
-  Whenever you perform multiple independent operations, invoke all relevant tools simultaneously rather than sequentially. Prioritize calling tools in parallel whenever possible. For example, when reading 3 files, run 3 tool calls in parallel to read all 3 files into context at the same time. When running multiple read-only commands like `ls` or `list_dir`, always run all of the commands in parallel. Err on the side of maximizing parallel tool calls rather than running too many tools sequentially.
-  </use_parallel_tool_calls>
-"
-    )
+    SYSTEM_PROMPT_FOR_NATIVE_TOOL_USE.to_string()
 }
 
 const SYSTEM_NON_NATIVE_TOOL_USE: &'static str =
@@ -229,7 +226,7 @@ Short description for providers without native calling specs:
 For reading files, prioritize use of code_search tool use with multiple search requests per call instead of read_file, if it makes sense.
 
 Exception to using ONE tool at a time:
-If all you’re doing is WRITING files, and you don’t need to do anything else between each step.
+If all you're doing is WRITING files, and you don't need to do anything else between each step.
 You can issue MULTIPLE write_file tool calls in a request, however you may ONLY make a SINGLE write_file call for any file in that request.
 For example you may call:
 [START OF REQUEST]
@@ -318,15 +315,13 @@ Skip TODO tools for simple single-step tasks:
 
 If you can complete it with 1-2 tool calls, skip TODO.
 
-
 # Response Guidelines
 
 - Use Markdown formatting for all responses except tool calls.
 - Whenever taking actions, use the pronoun 'I'
 ";
 
-pub const SYSTEM_PROMPT_FOR_NON_NATIVE_TOOL_USE: &'static str =
-    concatcp!(SYSTEM_NON_NATIVE_TOOL_USE, CODING_STYLE);
+pub const SYSTEM_PROMPT_FOR_NON_NATIVE_TOOL_USE: &'static str = SYSTEM_NON_NATIVE_TOOL_USE;
 
 /// The G3 identity line that gets replaced in agent mode
 const G3_IDENTITY_LINE: &str = "You are G3, an AI programming agent of the same skill level as a seasoned engineer at a major technology company. You analyze given tasks and write code to achieve goals.";