Configuration

All configuration lives in _prr/prr/config.yaml. The installer writes this file automatically during setup. You can edit it at any time.

1. config.yaml overview

user_name: YourName
communication_language: English
project_name: my-project
target_repo: .
platform: auto
platform_repo: "owner/repo"
review_output: /abs/path/_prr-output/reviews
auto_post_comment: false

context_collection:
  enabled: true
  skip_manual_input_context: false
  mode: pr-specific

external_sources:
  enabled: false

2. Core options

3. Context collection

After describing the PR, the agent automatically collects fresh context relevant to the changed files. This context is loaded by all reviewer agents. Collection happens in four steps:

1. Analyze changed files — detect file types, categories (vue-component, pinia-store, etc.) and domains (authentication, state-management, etc.)
2. Collect from matching sources — only sources relevant to the changed files and domains are read
3. Manual context input — the agent pauses and asks the user for additional context (business rationale, focus areas, known trade-offs). User input is marked ⚠️ IMPORTANT and all reviewers treat it as highest priority. Set skip_manual_input_context: true to skip this prompt
4. Build knowledge base — written to pr-{branch}-context.yaml, loaded by all reviewers

context_collection:
  enabled: true
  skip_manual_input_context: false
  mode: pr-specific

3.0 Manual context input

After auto-collection completes, the agent pauses and asks the user for any additional context that automated collection cannot capture:

💬 Do you have any additional context for the reviewers?

You can share:
  • Business context or requirements behind this PR
  • Known trade-offs or constraints you accepted
  • Specific areas you'd like reviewers to focus on
  • Known issues or technical debt to be aware of
  • Links to related tickets, designs, or decisions

If you provide a response, it is stored in the knowledge base under manual_context and flagged as ⚠️ IMPORTANT. All reviewer agents read this section before starting their analysis and align their findings against it. Type skip or press Enter without input to continue without adding context.

Set skip_manual_input_context: true to bypass this prompt entirely — useful for fully automated pipelines or when running reviews in batch.

3.1 What the agent collects

The following sources are read automatically — no configuration needed. They are listed here so you know what to include in your project:

3.2 Inline annotation example

Add these tags anywhere in your source code — the agent extracts them automatically during context collection:

// @context: This module handles user authentication
// @security: All inputs must be validated before storage
// @pattern: Use repository pattern for data access
// @rule: ESLint vue/multi-word-component-names must be followed

4. External sources

When enabled, the agent queries external tools for additional context — such as related tickets, design specs, or internal documentation. All external sources fail silently if unavailable.

external_sources:
  enabled: false               # set true to activate MCP + RAG enrichment

  mcp:
    enabled: true
    intents:
      - knowledge_base         # Confluence, Notion → team standards, ADRs
      - project_management     # Jira, Linear → linked issue + acceptance criteria
      - design                 # Figma, Zeplin → design specs (UI PRs only)
      # - code_intelligence    # Sourcegraph → similar patterns
    hints:
      branch_issue_pattern: "([A-Z]+-\\d+)"

  rag:
    enabled: false
    intents:
      - similar_patterns       # find similar code patterns in codebase
      - past_decisions         # previous review decisions for similar code
      # - architecture_examples

  sources: []
  # sources:
  #   - type: url
  #     name: Shared ESLint config
  #     url: https://raw.githubusercontent.com/org/standards/main/eslint.md

4.1 MCP intents

The agent auto-discovers whatever tools are available in the session and only uses those whose category matches a declared intent.

4.2 hints — open-ended context for MCP tools

hints is an open-ended key-value map. The agent reads the entire map as context when querying MCP tools, so you can add any key-value pairs that help narrow tool queries for your project. Only branch_issue_pattern has explicit built-in handling — all other hints are free-form context the agent uses at its discretion.

hints:
  branch_issue_pattern: "([A-Z]+-\\d+)"  # built-in: extract issue key from branch name
  confluence_space: ENG                   # free-form: agent uses this to narrow Confluence searches
  jira_project: PROJ                      # free-form: agent uses this to narrow Jira searches
  figma_team: acme-design                 # free-form: agent uses this to scope Figma queries
  # any other key-value pair your tools need

4.3 Branch issue key extraction

When project_management is in your intents and hints.branch_issue_pattern is set, the agent extracts the issue key from the branch name and fetches the full ticket:

branch:   feature/ENG-123-add-auth
pattern:  ([A-Z]+-\d+)
→ fetches: ENG-123
→ extracts: title, description, acceptance criteria
→ used as review checklist

4.4 RAG intents

If a RAG tool (AWS Bedrock knowledge base, GitHub Graph RAG, custom vector DB) is available and rag.enabled: true, the agent queries it using the declared intents as guidance. Unlike MCP intents, RAG intents are hints — the agent queries for all of them automatically when RAG is enabled.

4.5 URL sources

sources:
  - type: url
    name: Shared ESLint standards
    url: https://raw.githubusercontent.com/acme/standards/main/eslint.md
  - type: url
    name: Security guidelines
    url: https://wiki.company.com/public/security-standards

5. Review output

All output is written to the path specified in review_output.

6. Examples

6.1 Minimal config (local-only)

user_name: Alice
communication_language: English
target_repo: .
review_output: ./_prr-output/reviews

context_collection:
  enabled: true
  mode: pr-specific

external_sources:
  enabled: false

6.2 Full config (with MCP + GitHub)

user_name: Alice
communication_language: English
project_name: acme-backend
target_repo: .
platform: github
platform_repo: "acme/backend-api"
review_output: /home/alice/projects/acme/_prr-output/reviews

context_collection:
  enabled: true
  mode: pr-specific

external_sources:
  enabled: true
  mcp:
    enabled: true
    intents: [knowledge_base, project_management, design]
    hints:
      branch_issue_pattern: "([A-Z]+-\\d+)"
  rag:
    enabled: false
    intents: [similar_patterns, past_decisions]
  sources:
    - type: url
      name: Shared ESLint standards
      url: https://raw.githubusercontent.com/acme/standards/main/eslint.md

7. FAQs

Q1. How do I get review output in my language instead of English?

Set communication_language to any natural language:

communication_language: Vietnamese   # or Japanese, French, Korean, etc.

Q2. I want the agent to fetch the Jira ticket before reviewing. What do I need?

Three things:

1. Install a Jira MCP server in your IDE
2. Add project_management to mcp.intents
3. Set branch_issue_pattern if your branch names include the ticket key

external_sources:
  enabled: true
  mcp:
    enabled: true
    intents:
      - project_management
    hints:
      branch_issue_pattern: "([A-Z]+-\\d+)"  # e.g. feature/ENG-123-auth → ENG-123

Q3. My team uses Linear (or GitHub Issues), not Jira. Does it still work?

Yes. prr-kit does not hardcode any specific tool. As long as a tool matching the project_management category is available in your session (Linear MCP, GitHub Issues MCP, etc.), the agent will use it. No extra config needed.

Q4. I want the agent to read Figma design specs when reviewing UI PRs. How?

Install a Figma MCP server in your IDE, then add design to mcp.intents:

external_sources:
  enabled: true
  mcp:
    enabled: true
    intents:
      - design

The agent will automatically search Figma only when the PR touches UI files (.vue, .tsx, .css, etc.) — it skips design lookup for backend-only PRs.

Q5. What exactly does branch_issue_pattern do?

It's a regex applied to your branch name to extract a ticket key, which is then fetched from your PM tool (Jira, Linear, etc.) to get the ticket title, description, and acceptance criteria. The agent uses the acceptance criteria as a review checklist — verifying that the implementation matches what was actually requested.

# Branch: feature/ENG-123-add-auth
# Pattern: ([A-Z]+-\d+)
# → fetches ticket ENG-123 → uses acceptance criteria as review checklist

If your branch names don't follow a pattern with a ticket key (e.g. feature/add-auth), you can omit this field — the agent will skip ticket lookup silently.

Q6. What's the difference between mcp.intents and rag.intents?

Q7. What is RAG and when do I need it?

RAG (Retrieval-Augmented Generation) lets the agent search a vector database — pre-loaded with your codebase, past review decisions, and architecture docs — before reviewing. This gives it memory of past decisions so it doesn't repeat findings the team has already accepted, and it can compare new code against established patterns in your codebase.

You need it if: your team is large, your codebase has years of history, or you want the agent to be aware of past architectural decisions. If you haven't set up a vector database (AWS Bedrock, GitHub Graph RAG, Pinecone, etc.), keep rag.enabled: false.

Q8. I've set up an AWS Bedrock Knowledge Base. How do I connect it?

1. Install the AWS Bedrock MCP server in your IDE and configure your AWS credentials
2. Enable RAG in prr-kit config:

external_sources:
  enabled: true
  rag:
    enabled: true
    intents:
      - similar_patterns
      - past_decisions
      - architecture_examples

The agent auto-discovers the Bedrock MCP tool in the session and queries your Knowledge Base before each review.

Q9. Can I add my own custom hints beyond branch_issue_pattern?

Yes. hints is an open-ended map — add any key-value pairs and the agent will read them as context when querying MCP tools:

hints:
  branch_issue_pattern: "([A-Z]+-\\d+)"
  confluence_space: ENG        # agent uses this to narrow Confluence searches
  jira_project: PROJ           # agent uses this to narrow Jira searches
  figma_team: acme-design      # agent uses this to scope Figma queries

Only branch_issue_pattern has explicit built-in handling. All other hints are free-form context the agent uses at its discretion when querying tools.

Q10. What if no MCP tools are available in my session?

Nothing breaks. All external sources fail silently — the review continues with local context only (diff, config files, standards docs, inline annotations). The workflow never fails because of a missing tool.

Q11. I want to review a repo in a different folder than my config. How?

Set target_repo to a relative or absolute path pointing to the other repo:

# config lives in: /home/alice/tools/_prr/prr/config.yaml
# repo to review:  /home/alice/projects/my-app

target_repo: /home/alice/projects/my-app
# or relative:
target_repo: ../../projects/my-app

Q12. Should I enable auto_post_comment?

Only if you trust the output enough to post without reviewing it first. With auto_post_comment: false (default), you see the findings first and decide whether to post. With true, findings are posted to the PR automatically after every review — no confirmation prompt.

Recommendation: start with false, switch to true once you're comfortable with the quality of reviews.