Add PR Merge Conflict Repair daemon

[charliecreates]

Summary

This PR installs the pr-merge-conflict-repair Charlie daemon to .agents/daemons/pr-merge-conflict-repair/DAEMON.md. It was generated by Charlie from the pr-merge-conflict-repair example.

The daemon won't start working until it's merged to the repo's default branch.

What Charlie daemons are

Charlie is an async engineering teammate that works in the tools your team already uses. In GitHub, Charlie can inspect code, review changes, propose patches, open PRs, and comment with findings. With connected integrations, Charlie can also use Linear, Slack, and Sentry context to understand issues, conversations, alerts, and follow-up work.

A daemon is a recurring role for Charlie. Instead of waiting for someone to mention Charlie every time the same kind of maintenance work appears, the repo contains a small role definition that tells Charlie when to wake up and what job to do.

This PR adds that role at .agents/daemons/pr-merge-conflict-repair/DAEMON.md. The file controls:

• when Charlie can activate, through watch conditions or a schedule
• what work Charlie should perform, through purpose and routines
• what Charlie should avoid, through deny rules and body guidance

After this PR is merged and Charlie ingests the default-branch version, the daemon can start handling that recurring work inside the limits defined in DAEMON.md.

Learn more: https://docs.charlielabs.ai/daemons

What this daemon does

DAEMON.md purpose:

Resolve merge conflicts on non-draft pull requests found after repository branch changes.

This daemon’s configured routines are:

• Run bun .agents/daemons/pr-merge-conflict-repair/scripts/find-conflicted-pulls.ts to find open non-draft PRs with mergeability state CONFLICTING.
• Re-fetch the current remote PR head and the PR's current base branch before editing each conflicted PR.
• Resolve the conflict and push to the existing PR branch when repo context, tests, and PR intent make the resolution clear.
• Run focused verification after conflict resolution when feasible.

When this daemon can activate

This PR only installs daemon files. The daemon becomes eligible for live activations after both are true:

1. this PR is merged to the repo's default branch
2. Charlie ingests the merged default-branch version of DAEMON.md

Watch conditions

Charlie may wake this daemon when these watch conditions match:

• A GitHub push updates the repository default branch.

Integrations and setup

This daemon requires these integrations to work as intended:

• github

Set up or configure integrations here:

https://dash.charlielabs.ai/organizations/chrisdoc/integrations

Review and iterate before merging

Before merging, review the installed DAEMON.md and confirm that:

• the purpose matches the recurring work you want Charlie to own
• the watch conditions and/or schedule are narrow enough for initial rollout
• the routines are concrete and bounded
• the deny rules cover actions Charlie should not take
• any required integrations above are connected for this organization

You can ask Charlie on this PR to adjust the daemon before merging. Just leave a comment mentioning @CharlieHelps.

For rollout and iteration guidance:

https://docs.charlielabs.ai/daemons/testing-and-iterating-on-daemons

Activity and future tuning

After this daemon is merged and ingested, you can review daemon activity here:

https://dash.charlielabs.ai/organizations/chrisdoc/activity?daemonId=pr-merge-conflict-repair

To browse more daemon examples:

https://github.com/charlie-labs/daemons/blob/master/README.md

✨ PR Description

Purpose: Introduce PR merge conflict detection daemon with discovery script to identify and track conflicted pull requests across repository branches.

Main changes:

• Created find-conflicted-pulls.ts script querying GitHub GraphQL API to fetch open non-draft PRs with mergeable status tracking
• Added DAEMON.md defining conflict repair workflow, discovery policies, repair decision logic, and commenting constraints for maintainer automation

Generated by LinearB AI and added by gitStream.
_{AI-generated content may contain inaccuracies. Please verify before using.
💡 Tip: You can customize your AI Description using Guidelines Learn how}

[gitstream-cm]

✨ PR Review

LGTM

Generated by LinearB AI and added by gitStream.
_{AI-generated content may contain inaccuracies. Please verify before using.
💡 Tip: You can customize your AI Review using Guidelines Learn how}

[greptile-apps]

Greptile Summary

This PR installs a Charlie daemon (pr-merge-conflict-repair) that monitors default-branch pushes and automatically resolves merge conflicts on open, non-draft PRs when the resolution is unambiguous. It adds two files: a DAEMON.md configuration and a read-only TypeScript discovery script that queries GitHub's GraphQL API for conflicted PRs.

• DAEMON.md defines the trigger (default-branch push), routines (discover → re-fetch → resolve → verify → push), and a thorough set of deny rules (no draft PRs, no force-push, no new PRs/issues, no product/security decisions).
• find-conflicted-pulls.ts is a well-typed, defensive script using gh api graphql with pagination, UNKNOWN-mergeability retries, and strict runtime validation of the GraphQL response shape.
• The routine hard-codes bun to run the TypeScript script directly; this will fail if Charlie's execution environment does not have bun available, since the project's declared runtime is npm/Node.js v24+.

Confidence Score: 4/5

Safe to merge with low risk — only new files in .agents/daemons/ are added and no existing project code is modified.

The daemon won't activate until merged and ingested by Charlie, so there is no immediate production impact. The one notable concern is that the routine instructs Charlie to run the script with bun, which is not the project's declared runtime; if Charlie's environment lacks bun, every daemon activation will fail before doing any work. The PR title also misses the required conventional commit prefix, which could affect semantic-release versioning on squash-merge.

.agents/daemons/pr-merge-conflict-repair/DAEMON.md — confirm bun is available in Charlie's runtime before merging.

Important Files Changed

Filename	Overview
.agents/daemons/pr-merge-conflict-repair/DAEMON.md	New daemon configuration defining the purpose, watch triggers, routines, and deny rules for automatic merge-conflict repair; well-structured with clear guard clauses.
.agents/daemons/pr-merge-conflict-repair/scripts/find-conflicted-pulls.ts	Read-only TypeScript discovery script using gh api graphql to enumerate open non-draft PRs with CONFLICTING mergeability; well-typed with defensive JSON parsing and retry logic for UNKNOWN state.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Default branch push detected] --> B[Run find-conflicted-pulls.ts]
    B --> C{Any CONFLICTING\nnon-draft PRs?}
    C -- No --> D[No-op / silent stop]
    C -- Yes --> E[For each conflicted PR]
    E --> F[Re-fetch remote PR head\n& current base branch]
    F --> G{Remote head\nchanged?}
    G -- Yes --> H[Stop / no-op for this PR]
    G -- No --> I{Resolution clear\nfrom context?}
    I -- No --> J[Comment with\nblocking reason]
    I -- Yes --> K[Resolve conflict]
    K --> L[Run focused verification]
    L --> M[Push to existing PR branch]
    M --> N{More PRs?}
    N -- Yes --> E
    N -- No --> O[Done]

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
    A[Default branch push detected] --> B[Run find-conflicted-pulls.ts]
    B --> C{Any CONFLICTING\nnon-draft PRs?}
    C -- No --> D[No-op / silent stop]
    C -- Yes --> E[For each conflicted PR]
    E --> F[Re-fetch remote PR head\n& current base branch]
    F --> G{Remote head\nchanged?}
    G -- Yes --> H[Stop / no-op for this PR]
    G -- No --> I{Resolution clear\nfrom context?}
    I -- No --> J[Comment with\nblocking reason]
    I -- Yes --> K[Resolve conflict]
    K --> L[Run focused verification]
    L --> M[Push to existing PR branch]
    M --> N{More PRs?}
    N -- Yes --> E
    N -- No --> O[Done]

Loading

_{Reviews (1): Last reviewed commit: "Install pr-merge-conflict-repair daemon" | Re-trigger Greptile}

[greptile-apps]

PR title doesn't follow the required conventional commit format

CLAUDE.md and AGENTS.md both require all PRs and AI-generated commits to use conventional commit format (e.g. feat: add PR merge conflict repair daemon). The current title "Add PR Merge Conflict Repair daemon" will not be parsed correctly by semantic-release if squash-merged, potentially skipping a version bump or release note entry.

Context Used: CLAUDE.md (source)

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

bun runtime assumed but not guaranteed in this project

The project's CLAUDE.md declares npm and Node.js v24+ as the runtime. The routine hard-codes bun to execute the TypeScript script directly. If the environment where Charlie runs does not have bun installed, the daemon will fail immediately on every activation. Consider confirming that bun is available in Charlie's execution environment, or add a node --import tsx / npx tsx fallback if the intent is to align with the project's existing runtime.

[greptile-apps]

pagesFetched: 1 in parseGraphqlResponse is a dead value

parseGraphqlResponse returns a type that extends FetchResult (which requires pagesFetched), so it hard-codes pagesFetched: 1. However, fetchOpenPullRequests never reads page.pagesFetched — it tracks the count independently with its own pagesFetched counter. The field silently satisfies the type but is misleading; a reader might assume the returned value is meaningful. Returning pagesFetched: 0 or splitting the return type to omit the field would make the intent clearer.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!