Guidelines, Learnings, and codebase context

Teach Code Review what good looks like in your repositories. Stable guidelines define the standard; Learnings capture reviewed exceptions; repository and production context explain how the system actually behaves.

​

Choose the right context source

​

Write guidelines that produce useful findings

In Code Review → Codebases → Guidelines, upload a guideline or generate one from repository review history, then assign it to the intended codebases. A strong guideline:

• Defines one observable behavior.
• Names the repository, language, or path scope.
• Explains why the rule matters.
• Includes a short example when the rule could be interpreted more than one way.
• Has an owner who reviews it as the architecture changes.

Avoid duplicating generic formatter or linter rules unless the reviewer needs the underlying engineering context.

​

Turn feedback into Learnings

When a reviewer marks a finding as unhelpful and explains why, Entelligence can use that feedback to reduce the same false positive in later reviews. Review the Learnings tab periodically:

• Keep confirmed repository exceptions.
• Narrow Learnings that suppress more than the intended pattern.
• Remove entries that are obsolete after a refactor or policy change.
• Fix real problems in code or policy instead of teaching the reviewer to ignore them.

​

Use repository Markdown

Enable maintained Markdown files from Codebase Context. Good sources include architecture decisions, contribution guidance, local agent instructions, and operational notes. Stale instructions create stale reviews. Give each context file an owner and update it with the codebase.

​

Connect related systems

Link repositories when a change in one can break another—for example, an API and its SDK, a schema and its consumers, or a shared library and downstream applications. When production or incident integrations are connected, relevant operational evidence can help the reviewer recognize recurring failure patterns. Keep these connections within approved workspace and repository boundaries.

​

Exclude files deliberately

Built-in groups cover migrations, snapshots, generated code, and test fixtures. Custom glob patterns handle repository-specific paths. Before enabling an exclusion:

1. Identify every path it matches.
2. Use the narrowest pattern.
3. Review one pull request containing both an excluded and included file.
4. Record the owner and reason.
5. Revisit the exclusion when build or generation behavior changes.

Exclusions reduce noise by reducing coverage. Never exclude a production-affecting file only to improve a score.

​

Verify the context

Create a small test change that should trigger one team rule and one built-in check. Confirm that the review:

• Cites the assigned guideline.
• Ignores disabled Markdown context.
• Applies the intended Learning.
• Checks linked repositories only where configured.
• Uses production evidence only from approved integrations.
• Skips exactly the excluded paths.

​

Next step

Tune Code Review settings or resolve context and permission issues.