> ## Documentation Index
> Fetch the complete documentation index at: https://docs.overcut.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Reuse a Workflow Across Repositories

> Run one workflow against repositories with different base branches by defining a context parameter once and setting a value per repository.

Most of your repositories branch from `main`, but two legacy services still use `develop`. Instead of keeping a copy of the pull request workflow per repository, define one `base_branch` context parameter, set a repository value where it differs, and reference it from the workflow. This guide takes about ten minutes.

## Before you start

You need a project with at least two connected repositories and a workflow that runs an agent against a repository. Defining a workspace parameter requires a role that can create context parameters; ask a workspace admin if the **New Parameter** button is missing.

<Steps>
  <Step title="Define the parameter" icon="key">
    Open **Context Parameters** in the workspace navigation and select **New Parameter**. Enter `base_branch` as the **Key**, leave **Level** at **Workspace (visible to every project)**, and set the **Default value** to `main`. Save.

    The default is what every run uses unless a more specific value applies.
  </Step>

  <Step title="Set a value on the legacy repository" icon="code-branch">
    Open the legacy repository's page and find its **Context Parameters** panel. Select **Add override**, pick `base_branch`, enter `develop`, and save. The value applies immediately to the next run on that repository.

    You can do the same from the parameter's own page: open `base_branch`, select **Add override** in the **Overrides** section, and choose the repository under **Where it applies**.
  </Step>

  <Step title="Reference the parameter in the workflow" icon="sliders">
    Open the workflow in Workflow Builder, select the Agent Run step, and edit **Instructions**. Type `{{params.` and pick `base_branch` from the completion list. For example:

    ```text theme={"dark"}
    Open the pull request against {{params.base_branch}}.
    Never target any other branch.
    ```

    Publish the workflow. Publishing checks that every referenced key exists.
  </Step>

  <Step title="Preview the value per repository" icon="magnifying-glass">
    Open the **Playground**, select the workflow, then select the legacy repository. The **Context parameters** panel lists `params.base_branch` with the value `develop` and the source `Repository: <name>`. Switch to any other repository and the panel shows `main` from `workspace default`.

    If the panel says `no value: the run will fail at preparation`, the key has no default and no value on this path. If it says `not defined: publishing will be blocked`, check the spelling.
  </Step>

  <Step title="Run once and confirm" icon="check-circle">
    Run the workflow from the Playground against the legacy repository. When the run appears under **Logs**, open **View Details** and select **Context** in the run header. The **Run Context** panel shows `"base_branch": "develop"` under `params`. That snapshot is what every step in the run used.
  </Step>
</Steps>

## What you built

One published workflow serves every repository. Adding a third legacy repository is one value on that repository's page, with no workflow edit and no publish. Changing the convention for everyone is one edit to the default.

## What to try next

* **An orchestration value.** Two orchestrations run this workflow with different branch-name suffixes. Add a `branch_suffix` parameter, reference it in the instruction, and set a value on each orchestration in its properties panel. The orchestration value wins over the workflow's own value.
* **An agent value.** Set `review_tone` to `thorough` on a security reviewer agent and `concise` on everyone else. Each agent's steps resolve its own value in the same run; the **Run Context** panel shows the difference under `agentParamOverrides`.
* **A Run Script step.** Read the same value from a script as `$OC_PARAM_BASE_BRANCH`, or map it into **Environment Variables**. See [Run Script](/docs/workflows/run-script).

## Related

* [Context Parameters](/docs/reference/context-parameters): every control, the resolution order, and troubleshooting.
* [Reuse Across Projects](/docs/concepts/reuse-across-projects): when a parameter is the right tool and when the Workspace Library is.