AI & RAG

On config-change PRs, post the original rationale as a review comment

When a merge request touches a config file, this workflow finds the prior rationale for each changed key from Git history and ADRs and posts it as a review comment so reviewers…

CategoryAI & RAG
EngineSim + Paperclip
Difficultyadvanced
Triggerevent
Steps6
Setup~25 min

How it runs

The automated pipeline, trigger to output.

  • TriggerMerge request touches a watched config fileGitLabGitLab
  • LogicExtract the specific config keys/lines changed
  • ActionPull introducing commit + message for each lineGitLabGitLab
  • ActionRetrieve matching ADRs from ConfluenceConfluenceConfluence
  • ActionCompose per-key rationale with citations
  • OutputPost rationale as an MR review commentGitLabGitLab

What it does

Every time someone opens a merge request that edits a config file, it surfaces the historical rationale for each line being changed and posts it directly on the MR. Reviewers no longer approve a one-line value bump without knowing the original decision behind it.

When to use it

When config changes ship too easily and reviewers lack context. Ideal for repos where load-bearing values (timeouts, limits, feature flags) are casually edited and the reasoning lives in old commits or ADRs nobody reopens.

How it works

  1. 1A GitLab merge-request event fires when the diff touches a watched config path.
  2. 2A logic step extracts the specific keys/lines that changed.
  3. 3For each changed line, the agent pulls the introducing commit and message from Git history.
  4. 4It retrieves any ADR in Confluence referenced by that commit or matching the key.
  5. 5It composes a per-key "original rationale" summary with citations.
  6. 6It posts the summary as a single MR review comment for the reviewer.

Set it up

What you configure once, before turning it on.

  1. 1
    Connect GitLabRepos, MRs, pipelines, registry.
  2. 2
    Connect ConfluenceSpaces, pages, blueprints.
  3. 3
    Set each agent's modelWe leave models unset so you pick the tier — fast + cheap, or top-quality.
  4. 4
    Tune it to your dataEdit the prompts, filters, and field mappings so it matches how your team works.
  5. 5
    Test, then turn it onRun once against a sample, confirm the output, then enable the trigger.

Run this workflow in your colony.

14-day trial. No DevOps. No Sales call. Provisioned in under a minute.