Skip to content

Channel Configuration

You can change the repository mapping anytime by entering the /pullflow config command in the Slack channel. Use this command to:

  • Connect or disconnect repositories to the channel.
  • Configure if “Draft” PRs should be ignored until ready for review.
  • Configure if updates and messages from 3rd-party bots and apps should be ignored.
  • Choose if CI/CD and check-run updates should be posted as they happen, only on failure, once on completion, or silently with reactions.

Configuration Options

You can configure the repository-to-channel mapping to match your team’s development workflow. Here are a few options:

Option 1: Dedicated Code-Review Channel Per Repo

Attach each GitHub repo to a dedicated channel for pull requests (PRs) per team.

Pros:
  • One-to-one repo and channel mapping makes it easier for developers to join/leave and set notifications based on their role and interest.
  • The channel serves as a useful at-a-glance view of the project’s status.
  • A dedicated channel where each thread is started by the Pullflow agent makes the channel focused on PRs, free of other conversations.
Cons:
  • Some projects may have many repos, leading to too many code review channels with sparse activity.
  • Some teams may prefer more active collaboration across repos and teams.

Option 2: General Development-Channel Per Team

Attach the repo to an existing (or new) development channel for the team.

Pros:
  • A single place for all code-related conversations, including code reviews.
  • Code reviews become part of the conversation, spawning off other tasks and threads in the channel.
Cons:
  • Mixing agent-generated threads with human conversations can make it harder to see all the PR to-dos at a glance.
  • Team members can’t use channel-level notification control.

Option 3: One Channel for Project-Wide Code Reviews

Attach all project repos to one project-wide code review channel.

Pros:
  • Promotes project-wide knowledge-sharing and transparency.
  • Everyone knows how the project is changing, sparking spontaneous collaboration and minimizing redundant work.
Cons:
  • The all-in-one channel can get really busy, and team members may start to ignore the channel.
  • For team members only interested in some of the repos, it may be harder to stay up to date or set custom notifications.

Recommendation: If you’re unsure which option will work best for you, start with Option 1 and explore other configurations as your team gets accustomed to the Pullflow experience.