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. 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. 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. 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. 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 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.