Grok Build memory: keep conventions verifiable and current
Persistent notes can help continuity, but the repository and current instructions should remain the evidence for commands and decisions.
In brief
Grok Build can retain conventions and decisions across sessions. Treat those notes as useful context that must remain accurate, not an authority that overrides the repository or your current instruction.
This avoids repeatedly applying an old test command or a decision that changed after the note was written.
Store facts a reviewer can check
A useful convention names the supported package manager or the documented test command. Include where that rule comes from. Avoid vague notes such as “everything passed” without a version, command or evidence.
Resolve a conflict with current evidence
If the note and current configuration disagree, inspect the files and ask what changed. Do not repeat the old command simply because it was once successful. Keep explicit current task constraints visible rather than assuming memory contains every requirement.
Keep secrets and permissions separate
Memory is not a secret store or a permanent grant of external access. Use supported credential controls and task authorization. After correcting a note, verify the next action in the actual environment; do not claim its success based on an earlier session.
Before you act
Memory may be incomplete or stale. Do not store credentials in convention notes or assume the assistant verified a remembered statement during the current session.
What to do next
- Inspect the relevant remembered convention before a consequential change.
- Compare it with current project documentation and configuration.
- Correct stale notes and verify the actual command result.
