For AI agents: the complete documentation index is available at https://docs.flezise.com/llms.txt, the full documentation bundle is available at https://docs.flezise.com/llms-full.txt, and this page is available as Markdown at https://docs.flezise.com/integrations/pull-requests.md.
Docs
  • 26.11

    • Pull requests

    When the builder agent delivers a code change, Flezise opens a pull request on the connected repository. The title and body are generated from the approved story and the diff, laid out in the repository's own pull request template when it has one.

    What Flezise writes into the PR

    A governed pr-description prompt receives the story content, a summary of diff statistics, and the list of changed files. The generator produces a title and a description that explain what the change does and why.

    If the repository has a pull request template, the description fills in that template's headings and checklists instead of the default layout, and ticks a checklist item only when the change shows it is done. Flezise looks for pull_request_template.md in .github/, the repository root or docs/, in any letter case, and otherwise for GitLab's .gitlab/merge_request_templates/Default.md.

    A repository without a template can still get one: paste it into Pull request template under the project's Settings → General and press Save. A template in the repository always takes precedence over this setting.

    If description generation fails (timeout or network error), the PR body falls back to Implementation of story on branch <branch>.

    Below the description, a Verification section lists the checks the change passed. When the agent used a browser while it worked (with browser recording on), the section links a video of it: the acceptance-criteria click-through for a spec build, or the agent's own browser session for a work item. The work item shows the same video as Recording under Verifications.

    The PR opens as a draft by default and targets the main branch unless the repository's delivery configuration specifies a different base.

    Generated descriptions apply to every Git provider that supports PR creation: GitHub, GitLab, and Bitbucket.

    CI autofix

    When CI checks fail on the PR branch, Flezise can run a bounded fix loop to address them. This loop is opt-in and off by default.

    The loop is GitHub-only. Providers that do not support CI check polling are skipped immediately, and the loop records a skip reason without attempting a fix.

    Each fix round follows this sequence:

    1. Wait for all CI checks on the PR branch to reach a completed state.
    2. Collect the names of failing checks and, on GitHub, any PR review comments already posted.
    3. Run a sandbox session with the failure context as input.
    4. Commit any changes as fix: address CI failures (round N) and push to the same PR branch.
    5. Poll CI again.

    The loop runs up to two rounds. If checks still fail after two rounds, or if the agent produces no file changes in a round, Flezise escalates: it posts a comment on the work item and sends a notification so a person can take over. A fix round that edits CI or check files is never pushed; it escalates the same way (see CI and check files).

    There is no UI toggle for CI autofix. Enable it by setting ci_feedback_enabled in the project's pipeline configuration.

    Evidence at the pushed commit

    Flezise's checks are tied to the commit they ran on. When the pull request opens, Flezise posts a flezise/evidence commit status on its head commit. Add that status to the branch's required checks to block merging code the platform never checked.

    When someone else pushes to the pull request, the status turns pending and Flezise runs its checks again on the new head. It turns green when they pass and red, naming the failing checks, when they don't. The work item's Verifications show the same as Checked at the Pushed Commit.

    CI and check files

    A change that edits CI pipelines, git hooks or the project's check configuration (.github/workflows/, .gitlab-ci.yml, .pre-commit-config.yaml, .sdlc/*.yaml, .aislop/ and similar) always goes to a person. Flezise never accepts such a change on its own or pushes one from an autofix round. The pull request gets a Needs a person section listing the files, and the work item shows the same under Verifications.

    Conflicts with the default branch

    Every push to the default branch re-checks Flezise's open pull requests. When one now conflicts, the agent merges the default branch into it, resolves the conflicts, runs the checks again and pushes. A comment on the pull request says what it did. Conflicts in CI or check files, or a resolution whose checks fail, go to a person instead. Verifications show the state as No Conflicts.

    This is also how pull requests from agents working in parallel are handled. Two open pull requests that change the same lines don't conflict with the default branch yet, so nothing happens until the first one merges. That merge is a push to the default branch, so the second pull request is re-checked and the agent brings it up to date. Each pull request has one resolution running at a time, and when the default branch moved again while it ran, the pull request is checked once more. After three resolutions on the same pull request, Flezise stops and asks a person to decide the merge order.

    After the merge

    When one of Flezise's pull requests merges, Flezise watches CI on the merge commit until every check finishes, for at most two hours. If CI fails there, the agent looks for the cause and opens a pull request that fixes it on top of the default branch. If it can't find a fix, its fix edits CI or check files, or the fix's own CI fails, Flezise opens a pull request that reverts the merge. Either way the project is notified, and Verifications show the outcome as Default Branch After Merge. Watching after the merge needs CI checks the platform can read, which today means GitHub.

    When the PR is merged or closed

    Flezise follows what happens to the PR on GitHub or GitLab, so the board stays current without anyone moving cards.

    • When the PR is merged, the artifact moves to merged, its work item to done, and anything waiting on it starts. The history records who merged it and when.
    • When the PR is closed without merging, the work item goes back to planning so a person decides what happens next. The code stays on its branch.
    • When a GitHub review requests changes, the request is handled like CI feedback above, if CI autofix is on.

    These events arrive through the repository webhook. A repository linked before this change picks up the review and push events the next time you press Link repository on its integration.

    Next steps