Before you start
You need at least one connected repository. Workflows run against the projects Console has access to through your source control provider — if the Projects page is empty, connect a repository first. You do not need to create any agents. Console ships a library of agents that covers scanning, detection authoring, patching, and review. See the agent library for the catalog.Create it
From Workflows, click New workflow. You land in the editor with an empty draft and four sections to fill in, top to bottom. Nothing is saved until you click Save.Name
The field at the top of the editor. It identifies the workflow in lists, run history, and — if you add a merge gate — in the GitHub check that appears on pull requests.- Required, and must be unique within your organization.
- Choose something durable. Once a workflow has a merge gate output, its name is locked, because the check name customers pin in branch protection is derived from it. Renaming would silently stop the check from reporting and leave pull requests waiting forever. To rename, remove the merge gate output, save, then rename.
Description
A short statement of what the whole workflow is for — shown in the workflow list and in run history so your team can tell workflows apart at a glance. It doesn’t shape what any step does. Each agent in the chain already carries its own instructions, and runs the same way whether it’s the only step or one of many — write the description for the humans who’ll read the workflow list, not as an instruction to the chain: Good:Scans pull requests for injection and access-control vulnerabilities, patches anything confirmed exploitable, and posts the result as a review comment.Too vague to tell apart from your other workflows:
Security workflow.
If you want a step to behave differently, change that agent or its own
description — see
writing an agent. The workflow description is documentation, not an
instruction.Triggers
Optional. When the workflow should fire on its own. You can save a workflow with no triggers at all and still run it by hand whenever you like — every workflow supports manual runs. Add a trigger only when you want it to fire automatically. Click Add trigger and pick a type. Today that means on pull requests, where you choose which repositories to watch and, optionally, restrict it to specific base branches. If you add a trigger, it must name at least one repository, or the workflow won’t save. See Triggers for the full details.Agents
Required. The ordered chain of agents that does the actual work. Click the + button to search the agent library and add an agent. Each one becomes a step, drawn as a pill with an arrow to the next — the chain reads left to right.- At least one agent, at most twenty.
- Reorder by dragging a pill.
- Remove a step by clicking the grip icon on its pill and choosing Remove from chain.
Output
Optional. Where the results go when a run completes. Click Add output and choose a destination:- Comment on triggering pull request — posts review comments on the pull or merge request that fired the run.
- Gate merging on security review — adds a required check that blocks merging until the agent’s verdict passes or a human approves the pull request.
Save
Click Save. Console creates the workflow, then applies your triggers and outputs. If a trigger or output can’t be applied, the workflow is still created — you’ll land on its detail page with a banner explaining what didn’t stick, and you can finish wiring it up there. Clicking Cancel with unsaved changes asks you to confirm before discarding.Edit or delete later
Open a workflow from the Workflows list to see it in read-only form, then click Edit. The same four sections become editable, with Save, Cancel, and Delete in the header. Editing a workflow does not affect runs already in flight — each run uses the definition as it was when it fired.Requirements at a glance
Next steps
Run your workflow
Fire it manually and watch the run.
Pick the right agents
The agent catalog and common chains.