Start at the intended repository root
Change into the project you mean to inspect and launch the grok TUI with no arguments. The current working directory shapes rule discovery, sessions, project configuration, and tool scope.
Before requesting edits, ask for a map of entry points, build commands, tests, and risky boundaries. Use file mentions such as @src/main.rs when one file must anchor the explanation.
cd your-project
grokInspect the context before trusting it
Run the discovery report to see the rules, configuration, skills, plugins, hooks, and MCP servers Grok found for this directory. Missing instructions are a repository problem to fix, not a reason to repeat hidden assumptions in every prompt.
Use /context during a long session and /session-info when you need the session identity. A clean context boundary makes later resumption and audit easier.
- Confirm the working directory.
- Read discovered rules and extension origins.
- Disable or remove integrations the task does not need.
grok inspectAsk for proof, not confidence
State the user-visible outcome, constraints, files that must remain untouched, and the exact checks required before completion. Ask Grok to report failed checks and unresolved risk instead of smoothing them over.
Review diffs and test output before accepting the work. End by exporting or naming a useful session when the reasoning will matter later; start a new session when the task boundary changes.
- Define acceptance criteria in the prompt.
- Require focused tests plus the relevant full suite.
- Treat tool output and repository state as evidence.