Manual Setup
Configure Stitch around the work you want your agents to do.
Follow these steps to set up Stitch yourself. To work with a coding agent instead, use Agentic Setup.
Connect Your Repository
Sign in, select your organization, and connect your repository.
Follow the CLI setup guide to install the CLI and sign in. Check your active identity and connected repositories:
stitch auth whoami
stitch repositories listConfirm the organization and find your active repository. Save its id and defaultBranch.
Work from the root of the matching local checkout and read its repository instructions.
Decide What to Automate
Choose the work you want an agent to do. For example, it could investigate new issues, review pull requests, or respond to events from an external service.
Decide:
- Which events should start a run?
- What instructions should the agent receive?
- Which harness, model, and sandbox should it use?
- Which filters and guards should prevent unwanted or repeated runs?
Start with a small workflow. You can add more triggers later.
Create or Update the Factory
Create stitch-factory.yaml at your repository root. If it already exists, review it and
update only what you need rather than replacing it.
| Resource | Purpose |
|---|---|
| Harnesses | Choose the agent runtime, model, and authentication |
| Sandboxes | Choose the execution environment and setup |
| Triggers | Select events, agents, prompts, filters, and guards |
| Secrets | Provide credentials through named references |
Want a starting point? Download the example factory, then keep, change, or remove its workflows to fit your repository. You do not need to use its agents, skills, labels, or providers.
Use the factory schema for supported fields and values. Keep new triggers disabled while you prepare their prerequisites:
- Make sure the selected agents and any skills referenced by prompts are available.
- Create any GitHub labels used by your filters.
- Fill in the required provider settings, such as Vercel team and project IDs.
- Review prompts, filters, and guard limits for the work you chose.
Add Required Secrets
Check the secret names referenced by your harnesses, sandboxes, and environment bindings. Add missing credentials through the UI or CLI. For supported subscription tokens, see Import Secrets.
Reuse existing secrets where possible. Confirm that all referenced names exist in your active organization:
stitch secrets listKeep values out of factory files, command arguments, and logs. The factory uses names, not secret values.
Validate
At the repository root, run both checks:
stitch validate --dry-run
stitch validate --repository <connected-repository-id>Replace <connected-repository-id> with the repository ID from step 1.
Fix reported errors and validate again. See CLI validation
for details.
Validation checks configuration. It does not apply changes or test provider credentials.
Review, Activate, and Deploy
Before activating your new triggers, check that:
- Their agents, skills, labels, secrets, and provider settings are ready.
- Their events and filters select the work you want.
- Their guards set suitable limits and prevent duplicate work where needed.
- Both validation checks pass.
Set enabled: true on the triggers you want to activate, then validate again.
You can also deploy with new triggers disabled and activate them later.
Commit the factory file and any required agent or skill files, then follow your normal
review and merge process. Stitch reads configuration from the default branch, so changes
on another branch must be merged before they apply. There is no CLI apply or startup command.
Verify the applied configuration in the Stitch app.