feat: mandate real-time auto-documentation of project memory updates across all interaction turns
This commit is contained in:
16
GEMINI.md
16
GEMINI.md
@@ -22,8 +22,16 @@ Read these first:
|
||||
- `project-knowledge/` is canonical project memory.
|
||||
- `agent-memory/` is agent operating memory.
|
||||
|
||||
## Gemini-Specific Notes
|
||||
## Gemini-Specific Mandatory Loop (Real-Time Auto-Documentation)
|
||||
|
||||
- Prefer the shared workspace rules over model improvisation.
|
||||
- Before answering current-state questions, inspect the current-work files and latest relevant daily note.
|
||||
- If a prompt changes durable project understanding or reusable agent behavior, update the smallest correct canonical file.
|
||||
At the end of EVERY conversational turn, you MUST evaluate the interaction as a senior Obsidian documentation expert:
|
||||
|
||||
1. **Analyze for Memory Impact:** Did the user's prompt or your subsequent action reveal new technical context, resolve an open question, change an architectural assumption, or shift current priorities?
|
||||
2. **Identify Target Canonical Files:** If memory impact is detected, identify WHERE in the `project-knowledge/` directory this information belongs. This is NOT limited to daily logs. It could be:
|
||||
- `01-current/current-work.md` (priority shifts, new blockers)
|
||||
- `02-work-items/*.md` (story updates, bug reproduction steps)
|
||||
- `03-context/` (system architecture, processes, workflows)
|
||||
- `04-people/` (stakeholder involvement)
|
||||
- `06-daily/YYYY-MM-DD.md` (daily findings)
|
||||
3. **Proactive Update:** You MUST use your file editing tools (`replace_file_content` / `multi_replace_file_content`) to inject the new context or CORRECT existing stale context in the appropriate files BEFORE concluding your response.
|
||||
4. **No Explicit Prompt Needed:** Do not wait for the user to say "document this". Auto-document implicitly. Ensure you do not pollute the workspace with unverified guesses; only document confirmed context or active hypotheses.
|
||||
|
||||
@@ -13,9 +13,9 @@ Make workspace memory maintenance part of the agent's normal job, not a separate
|
||||
|
||||
---
|
||||
|
||||
## Default Agent Behavior
|
||||
## Default Agent Behavior (Real-Time Auto-Documentation)
|
||||
|
||||
For any meaningful prompt, the agent should decide whether the interaction changes project memory.
|
||||
For EVERY meaningful prompt, the agent MUST execute a real-time auto-documentation loop. It is not an optional workflow; it is the core of the agent's job.
|
||||
|
||||
This applies to:
|
||||
|
||||
@@ -27,7 +27,7 @@ This applies to:
|
||||
- debugging discussions
|
||||
- corrections to previous understanding
|
||||
|
||||
The agent should not wait for a separate promotion command when the right update is already clear.
|
||||
The agent MUST NOT wait for a separate promotion command. The agent MUST proactively use file editing tools to update `project-knowledge/` (including 01-current, 02-work-items, 03-context, 04-people, 06-daily) within the SAME conversational turn if new information is detected or if prior context becomes stale.
|
||||
|
||||
- When editing `project-knowledge/`, write as a human engineer maintaining shared project documentation.
|
||||
- Keep agent-operating logic out of `project-knowledge/`; store that logic in prompts, commands, skills, agents, or `agent-memory/`.
|
||||
|
||||
Reference in New Issue
Block a user