chore: Codex-inspired prompt improvements for reliability and token efficiency#236
chore: Codex-inspired prompt improvements for reliability and token efficiency#236marcusquinn merged 2 commits intomainfrom
Conversation
…en efficiency - Add dirty worktree awareness: never revert user changes, never git reset --hard - Strengthen file re-read guidance: don't verify after successful edits - Add ambition vs precision calibration for greenfield vs existing codebases - Improve test strategy: specific-to-broad, add tests only when codebase has them Inspired by OpenAI Codex CLI system prompts (openai/codex).
Summary of ChangesHello @marcusquinn, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces several prompt improvements inspired by OpenAI Codex CLI system prompts, aiming to enhance the reliability and token efficiency of the agent's operations. The changes are additive refinements to the existing prompt architecture, focusing on safer Git interactions, smarter file handling, calibrated development approaches, and a more strategic testing methodology. The overall goal is to make the agent's behavior more robust and resource-efficient without altering its core functionality. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
WalkthroughTwo agent framework documentation files were updated: one adds Ambition calibration, restructures testing guidance, and refines file-reading best practices; the other appends safety reminders to the pre-edit-check workflow about not reverting unrelated changes and avoiding certain git commands without explicit user consent. Changes
Sequence Diagram(s)(omitted — changes are documentation and minor prompt updates; no new multi-component control flow introduced) Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Code Review
This pull request introduces several excellent improvements to the agent prompts, enhancing safety with git operations, refining the testing strategy, and providing guidance on ambition calibration. The changes are clear and well-aligned with the goal of improving reliability and efficiency. I have one suggestion in .agent/build-plus.md to make the file re-reading guidance slightly less restrictive to avoid potential issues with stale file content when files are modified by external tools.
.agent/build-plus.md
Outdated
| - You encounter an error suggesting stale context | ||
| - Use internal memory and previous context to avoid redundant reads | ||
| - After a successful Edit or Write, do NOT re-read the file to verify. The tool fails if the edit didn't apply -- a successful return means it worked. | ||
| - Only re-read a file if you need to make a SECOND edit (to refresh context for the new state). |
There was a problem hiding this comment.
This rule is a good specific example, but the word 'Only' makes it too restrictive. It doesn't account for cases where a file might be modified by other means, such as a bash command. This could cause the agent to work with stale file content, leading to errors. The previous version's guidance to re-read if you 'suspect content has changed' was a safer, more general heuristic. I suggest rephrasing this to be less restrictive while still guiding towards token efficiency.
| - Only re-read a file if you need to make a SECOND edit (to refresh context for the new state). | |
| - Re-read a file to refresh context before a second edit, or if you suspect another tool has modified it. |
🤖 Augment PR SummarySummary: Refines agent build prompts to improve reliability and token efficiency. 🤖 Was this summary useful? React with 👍 or 👎 |
.agent/prompts/build.txt
Outdated
| 4. Main repo (`~/Git/{repo}/`) should always stay on `main` | ||
| 5. Feature work happens in worktrees (`~/Git/{repo}-{type}-{name}/`) | ||
| For loop mode: `pre-edit-check.sh --loop-mode --task "description"` | ||
| - NEVER revert changes you did not make. If you notice unexpected uncommitted changes in the worktree, STOP and ask the user. |
There was a problem hiding this comment.
NEVER revert changes you did not make reads like it forbids reverting unexpected/uncommitted changes even when the user explicitly asks to revert them, which seems to conflict with the next bullet’s “unless the user explicitly requests it”. Consider clarifying the exception case so the guidance is internally consistent.
🤖 Was this useful? React with 👍 or 👎
| @@ -360,12 +365,10 @@ Communicate clearly and concisely in a casual, friendly yet professional tone: | |||
|
|
|||
| **Always check if you have already read a file before reading it again.** | |||
|
|
|||
There was a problem hiding this comment.
The claim that “the tool fails if the edit didn’t apply” may be too absolute—an edit can succeed yet still be unintended (e.g., wrong match or unexpected formatting), so forbidding re-reads purely for verification could let mistakes slip through. Consider allowing a re-read when you need to confirm the resulting content, not only when making a second edit.
🤖 Was this useful? React with 👍 or 👎
🔍 Code Quality Report�[0;35m[MONITOR]�[0m Code Review Monitoring Report �[0;34m[INFO]�[0m Latest Quality Status: �[0;34m[INFO]�[0m Recent monitoring activity: 📈 Current Quality Metrics
Generated on: Mon Jan 26 18:21:18 UTC 2026 Generated by AI DevOps Framework Code Review Monitoring |
- Clarify revert rule with explicit exception clause (Augment feedback) - Soften file re-read guidance to allow re-reads when external tools may have modified files (Gemini + Augment feedback)
|
🔍 Code Quality Report�[0;35m[MONITOR]�[0m Code Review Monitoring Report �[0;34m[INFO]�[0m Latest Quality Status: �[0;34m[INFO]�[0m Recent monitoring activity: 📈 Current Quality Metrics
Generated on: Mon Jan 26 18:24:52 UTC 2026 Generated by AI DevOps Framework Code Review Monitoring |



Summary
build.txt: never revert user changes, nevergit reset --hardunless explicitly requestedbuild-plus.md: don't re-read after successful edits (saves tokens)Motivation
Comparative analysis of OpenAI Codex CLI system prompts (
openai/codexrepo) identified four patterns that complement our existing prompt architecture. All changes are additive refinements -- no existing guidance was removed or contradicted.Changes
.agent/prompts/build.txt- 2 lines added (git safety).agent/build-plus.md- 3 sections refined (file reading, testing, ambition calibration)Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.