Design the Slack-to-PR Contract Before You Choose the Agent

The most active recent DEV article in my 2026-07-12 08:00 UTC snapshot was “How I Turned Slack Into an AI Teammate That Opens Pull Requests”, with 25 reactions and 11 comments. Its linked project separates classification, requirements, implementation, tests, and PR creation.

That separation is the part worth carrying into production. The model call is one component. The feature is a distributed workflow spanning chat identity, repository state, an execution environment, GitHub credentials, and human review.

Define one operation record

type Operation = {
  id: string;
  chatThreadId: string;
  requesterId: string;
  repository: string;
  baseCommit: string;
  intent: "question" | "investigate" | "change";
  state:
    | "clarifying"
    | "awaiting_approval"
    | "running"
    | "validating"
    | "delivered"
    | "failed"
    | "cancelled";
  approval?: {
    approvedBy: string;
    approvedAt: string;
    scopeHash: string;
  };
};

The chat message is input, not the database. A deleted or edited message must not silently rewrite an in-flight operation.

Make the workflow idempotent

Slack event
  -> verify signature
  -> deduplicate event ID
  -> load/create operation
  -> authorize requester + repository
  -> enqueue next legal stage
  -> persist result
  -> update the original thread

Slack retries events. Workers retry jobs. GitHub requests can time out after succeeding. Give every external write an idempotency key derived from the operation and stage. Before opening a PR, search for the operation ID in a branch name or marker so a retry cannot create duplicates.

Separate permissions by intent

Intent	Repository access	Network	Human gate
question	read-only	dependency/docs allowlist	none
investigate	read-only + test execution	restricted	before any change
change	isolated write branch	restricted	approved scope before run
delivery	push one branch, open PR	GitHub only	repository rules still apply

Do not give the planning step the credential that can push. Inject short-lived credentials only into the delivery stage, and keep branch protection and CI independent of the agent.

Test the failure path

Before the demo, exercise duplicate Slack delivery, an edited request, revoked GitHub access, base-branch movement, test timeout, cancellation during push, and a PR request that succeeds just before a client timeout. The user-visible thread should point to the authoritative operation state rather than improvise a new story for each retry.

The MonkeyCode connection

The public MonkeyCode repository describes AI task and requirement management, managed cloud development environments, automated PR/MR review, team collaboration, and private deployment. That makes it relevant to this end-to-end workflow category. The contract above is tool-independent and does not claim that MonkeyCode uses these exact fields or Slack integration.

Disclosure: I contribute to the MonkeyCode project. Product context is based on the linked public repository; this is an independent architecture pattern, not an integration test.

Developers evaluating a team workflow can discuss supported integrations in the MonkeyCode Discord. The team can also confirm whether free model credits are currently available and what eligibility and usage limits apply.

If the system cannot explain which stage owns authority, it is still a demo—even if the pull request appears successfully.