> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gitar.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Knowledge

> How Gitar combines team learning with connected knowledge sources and cites the guidance behind review findings

export const ThemeImage = ({src, alt, width}) => {
  let lightSrc, darkSrc;
  if (src.includes("-light.")) {
    lightSrc = src;
    darkSrc = src.replace("-light.", "-dark.");
  } else if (src.includes("-dark.")) {
    darkSrc = src;
    lightSrc = src.replace("-dark.", "-light.");
  } else {
    lightSrc = src;
    darkSrc = src;
  }
  const style = width ? {
    maxWidth: width,
    marginInline: "auto"
  } : undefined;
  return <span>
      <img className="block dark:hidden rounded-lg border" src={lightSrc} alt={alt} style={style} />
      <img className="hidden dark:block rounded-lg border" src={darkSrc} alt={alt} style={style} />
    </span>;
};

Gitar remembers context across code reviews. A correction explained in one PR can guide a later review, so the same repository convention does not need explaining in every thread.

<Note>
  Knowledge is available on the **Enterprise** plan.
</Note>

<CardGroup cols={2}>
  <Card title="Learn from conversations" icon="comments">
    Gitar turns explanations in PR comments into reusable knowledge, with the context needed to understand where it applies.
  </Card>

  <Card title="Apply relevant guidance" icon="filter">
    Each review receives knowledge selected for its changes, so a convention for generated files does not become a rule for every file.
  </Card>

  <Card title="Follow the source" icon="link">
    Citations connect review guidance to its source, making team-specific advice easier to verify.
  </Card>

  <Card title="Use engineering context" icon="book-open">
    Connected documentation and tools bring the decisions behind the code into the review.
  </Card>
</CardGroup>

## Where team knowledge comes from

Knowledge combines team-authored guidance with facts learned from repository work. Each entry retains its source, keeping an explicit instruction distinct from an observation.

| Source                    | What Gitar learns                                                                                            | Example                                                                                |
| ------------------------- | ------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------- |
| PR comments               | Reusable facts and constraints explained in review conversations, including corrections to findings.         | Generated files must be changed through their schema.                                  |
| Repository instructions   | Review guidance in `.gitar/review/` and review-relevant content in `.gitar/rules/`.                          | Database migrations must preserve compatibility with the previous application version. |
| Organization instructions | Guidance set in [Custom Instructions](/configuration/settings#custom-instructions).                          | Services use the shared authentication library.                                        |
| Configuration repository  | Shared guidance from the organization's [configuration repository](/configuration/configuration-repository). | API repositories follow the same error response convention.                            |
| Repository scans          | Conventions and architectural constraints discovered in repository documentation or source files.            | An older API has a replacement that callers should use.                                |

Knowledge captures guidance from rule files. [Rules](/features/rules) still define the workflows and actions that Gitar runs.

## Connected knowledge sources

Connected integrations and tools let Gitar consult engineering knowledge beyond the repository. Relevant documentation can explain why a design exists or which constraints a change must preserve.

| Source                                                        | Context it can provide                                                    |
| ------------------------------------------------------------- | ------------------------------------------------------------------------- |
| Confluence                                                    | Design documents, service conventions, and architecture decisions.        |
| [Jira](/integrations/jira) and [Linear](/integrations/linear) | Issue requirements and implementation context.                            |
| [Slack](/integrations/slack)                                  | Team conversations available through the connected integration.           |
| [Custom MCP integrations](/integrations/custom-integrations)  | Internal documentation and enterprise systems exposed by connected tools. |

Source access follows the connections and credentials configured for the organization. Gitar uses the available context for the task, while [team learnings](#where-team-knowledge-comes-from) carry reusable guidance across reviews.

## Web knowledge

Gitar can search the web and read documentation during a code review when a question needs context beyond the repository. Web references help check assumptions about a dependency against its documented behavior.

| Review question                                          | Useful web context                                    |
| -------------------------------------------------------- | ----------------------------------------------------- |
| Does this library call support the argument being added? | The library's API reference for the relevant version. |
| Did an upgrade change a default the code relies on?      | Release notes and migration guidance.                 |
| Is this framework behavior intentional?                  | The framework's documentation for the feature in use. |

Web lookups supply reference material for the review. Team knowledge carries repository conventions and explanations from earlier work, so Gitar can consider both the library's documented behavior and the way the team uses it.

## How Gitar learns from comments

Gitar looks for explanations that remain useful beyond the current PR. A comment can teach a fact even when the finding is fixed rather than dismissed, and learning does not require a special command.

Gitar reads the comment with its available thread and file context, then writes a short, self-contained note. The note keeps the limits of the explanation, including which files or subsystem it concerns.

| Comment                                                                                                   | What it teaches                                                                  |
| --------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| “This `.g.dart` file is generated by build\_runner. Change the source model and regenerate it.”           | A convention for generated `.g.dart` files across the repository.                |
| “These handlers run behind the authentication middleware in `src/auth/`. Token validation happens there.” | An authentication constraint scoped to the handlers described in the thread.     |
| “Fix this by changing the schema. The getter is generated from it.”                                       | Where to fix this kind of mismatch, even though the comment also requests a fix. |
| “Done,” “fix this,” or a dismissal without an explanation.                                                | No reusable knowledge. These comments do not establish a convention.             |

<Tip>
  An explanation of why a finding is wrong gives Gitar more to learn than “this is intentional.” Naming the applicable files or an exception helps keep the learning scoped.
</Tip>

Learning and [handling feedback on the current PR](/features/code-review#providing-feedback) are separate. Dismissing a finding does not, by itself, teach Gitar to ignore similar findings in future PRs.

## How knowledge reaches a review

Gitar selects knowledge for each review using the changed code and PR context. The reviewer receives a focused set of relevant entries.

<Steps>
  <Step title="Find matching knowledge">
    Gitar matches entries against the files and symbols involved in the change. It also searches using the PR title and description.
  </Step>

  <Step title="Check whether it applies">
    Gitar checks candidate entries against the actual change. A matching path alone does not establish that a convention matters to this PR.
  </Step>

  <Step title="Select guidance for the reviewer">
    Gitar ranks relevant entries and combines repeated matches. Source authority and relevance help decide which guidance reaches the review.
  </Step>

  <Step title="Review with that context">
    The reviewer uses the selected knowledge while examining the code. Findings can include [source citations](#source-citations) for the guidance they rely on.
  </Step>
</Steps>

For example, a comment explains that generated getters must be fixed in their schema. On a later PR touching the same kind of generated file, Gitar can use that convention to identify the source that needs changing. The comment does not create a blanket exception for all getters.

## Source citations

Knowledge citations link a [code review finding](/features/code-review#citations-in-findings) to the source of the guidance it uses. A citation can point to a repository instruction or the earlier PR comment that explained a convention.

For example, a finding about a generated getter can cite the comment that established the schema as the source of truth. The next reviewer can inspect that explanation without searching old PR threads.

Gitar links a citation when the knowledge entry has a source URL. Guidance without an available URL remains readable as text. Citations support the explanation behind a finding, while its inline location identifies the code under review.

## Repository and organization scope

Repository instructions and comment learnings belong to their source repository. Organization instructions and configuration repository guidance can apply across the organization's repositories, with relevance checked for each review.

[Cross-Repo Analysis](/features/cross-repo-analysis) checks whether a change breaks another repository. Knowledge supplies conventions and constraints that help Gitar interpret a change. The features address different parts of the review.

## How knowledge stays relevant

Knowledge from instruction sources refreshes as Gitar processes those sources. Changed instructions replace their earlier content, and deleted instructions retire the associated knowledge after a successful refresh. An instruction edit in an unmerged PR does not replace the shared knowledge used by other reviews.

Gitar can also narrow where an entry applies when a review shows that its scope was too broad. A convention that matched an unrelated change can become more specific, preserving the guidance for the files where it belongs.

## Inspect and manage knowledge

Enterprise organization admins can open **Dashboard -> Knowledge** to browse the knowledge library. Filter by repository or source to inspect the guidance Gitar has collected.

<ThemeImage src="/assets/images/knowledge-overview-light.png" alt="Example Knowledge library with usage totals, source filters, and collected learnings" />

An entry shows its content and recorded usage. Source links lead back to the original material when a URL is available. Marking an entry stale removes it from future knowledge retrieval while retaining its history.

<ThemeImage src="/assets/images/knowledge-detail-light.png" alt="Example learning with its source, applicable code, and recorded review usage" width={560} />

## Related

<CardGroup cols={2}>
  <Card title="Repository Customization" icon="file-code" href="/configuration/repository-config">
    Where repository review instructions live.
  </Card>

  <Card title="Configuration Repository" icon="folder" href="/configuration/configuration-repository">
    Share guidance across the organization.
  </Card>

  <Card title="Code Review" icon="magnifying-glass" href="/features/code-review#citations-in-findings">
    See how source citations appear in findings.
  </Card>

  <Card title="Custom Integrations" icon="plug" href="/integrations/custom-integrations">
    Connect internal knowledge and enterprise tools.
  </Card>
</CardGroup>