OutcomeCI
officielCréez, validez et gérez des workflows propulsés par des agents à travers les outils de votre équipe avec OutcomeCI.
Que pouvez-vous faire avec OutcomeCI MCP ?
- Rédiger un plan de workflow — Demandez à votre IA de lire une demande et de proposer un plan étape par étape à l’aide de l’outil
draft. - Affiner le plan par la discussion — Faites itérer votre IA sur le plan avec vous via
discussjusqu’à ce que vous l’approuviez. - Exécuter les modifications approuvées — Demandez à votre IA de mettre en œuvre le plan convenu dans les permissions définies à l’aide de
implement. - Rapporter les résultats — Demandez à votre IA de publier le résultat, comme les liens de PR, dans le fil de conversation d’origine avec
announce. - Examiner les traces d’exécution — Demandez un résumé de ce que chaque étape du workflow a appelé, retourné ou refusé.
Serveur MCP hébergé
npx add-mcp 'https://api.outcomeci.com/v1/mcp'S’installe dans Claude Code, Codex, Cursor et plus
Documentation
Décrivez le workflow. Construisez-le ensemble.
Connectez votre agent préféré à OutcomeCI et décrivez ce que vous souhaitez accomplir. Construisez les étapes, les outils et les approbations ensemble, puis laissez OutcomeCI exécuter le workflow.
draft
Lisez la demande et les dépôts. Proposez un plan dans le fil de discussion.
discuss
Travaillez sur les retours avec le demandeur jusqu'à ce qu'il approuve.
implement
Effectuez les modifications convenues dans les limites des autorisations du workflow.
announce
Ramenez le résultat dans la conversation où tout a commencé.
Créez un workflow qui transforme les demandes Slack en pull requests. Discutez du plan avec le demandeur et attendez l'approbation avant d'apporter des modifications.
- 01
draftÉtape d'agent - 02
discussApprobation humaine - 03
implementÉtape d'agent - 04
announceÉtape d'agent
Examinez le workflow ensemble. OutcomeCI l'exécute lorsque le travail arrive.
Voir le workflow complet
apiVersion: outcomeci.workflow/v1
name: slack-to-pull-request
trigger:
webhook: {uses: slack, auth: secrets.slack_signing, events: [mention, dm]}
secrets:
slack: vault:slack/bot-token
slack_signing: vault:slack/signing-secret
github: vault:github
apis:
slack: {uses: slack, auth: secrets.slack}
github: {uses: github, auth: secrets.github}
reasoning:
default: {runner: codex}
steps:
- draft:
reason: >
Read the repositories named in the request. Draft a plan with
a section per repository and post it in the request's thread.
from: trigger
can:
- github.read
- slack.post: {channel: trigger.channel, thread_ts: trigger.ts}
returns:
plan: {summary, repos: [{repo: {owner, name}, steps: [string]}]}
- discuss:
with: draft.plan
converse: slack.thread(draft.calls.slack.post)
by: trigger.user
until: converged
max_turns: 12
returns: [plan, status]
- implement:
when: discuss.status == "converged"
for_each: discuss.plan.repos as target
reason: Implement the approved plan and open one pull request.
with: [discuss.plan, target]
can:
- github.write: {repo: target.repo}
policy: "One branch, one PR, only files the plan needs. No force-push."
returns:
pr?: {url, number: int, branch}
reason?: string
- announce:
with: [implement, discuss.plan]
reason: Reply in the original thread with each PR link or the reason no PR was opened.
can:
- slack.post: {channel: trigger.channel, thread_ts: trigger.ts}
Explorer le format de workflow
Façonnez le plan. Puis approuvez-le.
Décidez où les personnes guident, examinent et approuvent. Donnez aux agents des autorisations claires pour chaque étape et maintenez les modifications dans les limites que vous avez définies.
-
Autorisations pour chaque étape
Choisissez les opérations que chaque étape peut effectuer et les ressources auxquelles elle peut accéder. Les appels en dehors de ces autorisations sont refusés. -
Revue de politique avant les modifications
Ajoutez des règles telles qu'une seule branche et une seule PR. Un réviseur de politique vérifie les modifications proposées avant qu'elles ne soient envoyées. -
Les identifiants restent dans le coffre
OutcomeCI attache les identifiants aux appels API. L'agent travaille via les autorisations sans recevoir les jetons.
# product-engineering
OutcomeCI APP
Je vais ajouter un export CSV pour la page d'activité et inclure des tests.
Maya
Exportez uniquement les résultats filtrés et conservez l'ordre des colonnes existant.
OutcomeCI APP
Plan mis à jour : exporter les résultats filtrés dans l'ordre actuel des colonnes, avec des tests pour les deux. Prêt à continuer ?
Plan révisé prêt pour approbation
Jordan
Ça fonctionne. Allez-y.
Autorisations d'implémentation
Dépôt
acme/console
Autorisation
github.write
Politique
Une branche. Une PR. Pas de force-push.
Identifiants
Attachés par le courtier
Un environnement d'exécution tracé.
Chaque exécution laisse un enregistrement que vous pouvez inspecter, du premier appel d'outil au résultat final.
Voyez ce que chaque étape a appelé, ce qui est revenu et ce qui a été refusé, avec la raison associée. Suivez le travail jusqu'à son résultat.
Explorer l'exécution et la revue de politique
slack-to-pull-request
Terminé · 5 appels API · 1 refusé
01 github.read acme/console Confirmé
Lecture de la page d'activité et de ses tests existants. Le contenu du dépôt a été renvoyé à l'étape de brouillon.
02 slack.post #product-engineering / fil original Confirmé
Publication du plan d'export CSV révisé, incluant les résultats filtrés et l'ordre des colonnes existant. Le reçu du message identifie la conversation utilisée pour l'approbation.
03 github.write Proposition de force-push Refusé
La revue de politique a refusé le force-push proposé. La politique autorise une nouvelle branche et une PR, sans force-push. Cette demande n'a pas été envoyée à GitHub.
04 github.write acme/console / pull request #142 Confirmé
Ouverture d'une pull request depuis une nouvelle branche pour l'export CSV approuvé. GitHub a renvoyé le numéro et l'URL de la PR.
05 slack.post #product-engineering / fil original Confirmé
Publication du lien de la pull request et d'un résumé dans le fil d'origine. Slack a renvoyé le reçu du message.
Résultat renvoyé dans le fil Slack · Développer un appel pour inspecter
Gardez votre workflow. Changez votre agent ou modèle.
Conservez vos workflows dans OutcomeCI ou dans votre dépôt. Choisissez l'agent et le modèle pour chaque étape, et exécutez localement ou dans le cloud.
Votre agent
- Codex
- Claude Code
- OpenCode
Définissez une valeur par défaut, remplacez une étape ou ajoutez un repli pour les limites d'utilisation.
Vos modèles
- OpenRouter
- LiteLLM
Apportez l'accès aux modèles que vous avez déjà. Choisissez un modèle par workflow ou par étape sans lier votre orchestration à un seul fournisseur.
Votre environnement d'exécution
Local · Cloud OutcomeCI
Le même format de workflow et la même image d'exécuteur. Identifiants configurés pour chaque environnement.
Vous préférez commencer avec votre agent favori ?
Connectez-le à OutcomeCI avec MCP et construisez votre workflow ensemble.
URL du serveur MCP
https://api.outcomeci.com/v1/mcp
Guides de configuration officiels : OpenCode ↗ Claude Code ↗ Codex ↗
Vous préférez commencer sur votre machine ?
Testez localement avec Docker et votre connexion d'agent. Aucun compte OutcomeCI requis.
$ pipx install outcomeci-cli
Suivre le guide de démarrage rapide
Un workflow n'est que le début.
Commencez par un événement, un calendrier ou une demande. Rassemblez les outils, les agents et les approbations dont chaque tâche a besoin.
Alerte → Investigation → Revue
Trier une alerte entrante
Partez d'un webhook entrant, enquêtez sur le problème et proposez un correctif pour examen avant d'apporter des modifications.
Demande → Recherche → Réponse
Répondre à une question sur le dépôt
Donnez à un agent un accès en lecture seule au code pertinent et ramenez une réponse à la personne qui a posé la question.
Construire un workflow en lecture seule
Calendrier → Résumé → Mise à jour
Préparer la mise à jour du matin
Rassemblez l'activité du dépôt, résumez ce qui a changé et partagez une mise à jour selon un calendrier de votre choix.
Commencer avec un workflow planifié
Commencer avec un événement Slack · Webhook · Email · Calendrier · CLI
Connecter vos outils Explorer les connecteurs open-source ↗
Questions fréquentes
OutcomeCI est-il uniquement pour les workflows de codage ?
Non. OutcomeCI est un framework d'orchestration pour les workflows d'agents. Définissez un déclencheur, des étapes, des outils et des approbations autour du travail que vous souhaitez accomplir. La démonstration de pull request n'est qu'un exemple ; les workflows peuvent également enquêter sur des questions, résumer l'activité et agir via des connecteurs pris en charge.
Quels agents et modèles puis-je utiliser ?
OutcomeCI prend en charge Codex, Claude Code et OpenCode. Choisissez un exécuteur et un modèle qu'il prend en charge dans votre workflow, remplacez l'agent pour une étape particulière ou configurez un repli pour les limites d'utilisation. Conservez vos workflows dans OutcomeCI ou dans votre dépôt.
Où mes workflows peuvent-ils s'exécuter ?
Exécutez des workflows sur les exécuteurs gérés du cloud OutcomeCI, ou testez-les localement avec Docker et votre propre connexion d'agent. Les deux utilisent la même image d'exécuteur et le même format de workflow. Les identifiants et les connexions d'agents sont configurés pour chaque environnement.
Qu'enregistre la trace d'exécution ?
Le journal de l'exécution enregistre les appels API, leurs résultats et les refus avec les raisons. Utilisez-le pour inspecter ce qu'un workflow a tenté et ce qui s'est passé. C'est un enregistrement de l'exécution des outils, pas une transcription du raisonnement privé d'un agent.
Que se passe-t-il si une exécution échoue ou si un agent atteint une limite ?
Ouvrez le journal d'exécution pour voir ce qui a échoué et inspectez les appels enregistrés avant de réessayer. Les exécutions cloud réessayent certaines pannes temporaires, comme une connexion d'agent occupée, jusqu'à cinq fois. Configurez un agent de repli pour les limites d'utilisation ou de débit. Pour les exécutions locales échouées, corrigez la cause et reprenez avec l'option de nouvelle tentative de la CLI. Les appels dont le résultat est incertain ne sont pas automatiquement rejoués.
Et si personne n'approuve le plan ?
Vous définissez la fenêtre d'approbation. Une étape d'approbation qui expire ignore les étapes restantes. Dans la démonstration, l'implémentation nécessite un plan approuvé ; si la discussion expire ou atteint sa limite de tours sans accord, l'implémentation est ignorée.
Comment les autorisations et les secrets sont-ils gérés ?
Chaque étape dispose d'autorisations explicites limitées aux opérations et aux arguments. Le courtier refuse les appels en dehors de ces autorisations et attache les identifiants du coffre aux appels autorisés. Une revue de politique facultative vérifie les modifications proposées par rapport à des règles en langage clair, et les workflows peuvent attendre une approbation humaine.
Quels outils et déclencheurs sont pris en charge ?
Les connecteurs GitHub et Slack sont disponibles aujourd'hui. Démarrez des workflows à partir de mentions et de messages directs Slack, de webhooks, d'e-mails, de planifications cron ou de la CLI. Les connecteurs sont open-source ; demandez des API supplémentaires via le dépôt des connecteurs.
Ai-je besoin d'un compte pour essayer localement ?
Non. Installez la CLI et testez les workflows localement avec Docker, votre connexion d'agent et les identifiants des outils que vous connectez. Créez un compte OutcomeCI pour exécuter des workflows sur des exécuteurs cloud gérés.