> ## 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. # Context Parameters > Define a value once, reference it from instructions by key, and let each project, repository, workflow, orchestration, or agent supply its own value at run time. A context parameter is a named plain-text value that workflows and agents reference as `{{params.}}`. Each run resolves every referenced key to the most specific value on its path, so one workflow or agent serves many teams, repositories, and orchestrations without being copied. Definitions live on the workspace **Context Parameters** page and in each project's settings; values can be set on projects, repositories, workflows, orchestrations, and agents. ## When to use a context parameter Teams copy a workflow, an agent, or an orchestration because one constant differs between the copies: a base branch, a branch-name suffix, a pull request title format, a reviewer list, a set of review conventions. The definition is identical and only the value changes per project, repository, or orchestration. A context parameter keeps one definition and moves the value out of it. | You need | Use | Not | | ----------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | | A non-secret value that differs by project, repository, workflow, orchestration, or agent | Context parameter | A copy of the workflow | | A credential such as an API key or token | [Vault](/docs/reference/vault) secret, injected as an environment variable and hidden from the model | A context parameter, which is visible in prompts and logs | | A value a person types when they start a run | Manual run inputs in the Playground, or slash command arguments | A context parameter, which is stored configuration | | Ambient guidance about one codebase that every agent should know | Repository custom instructions | A context parameter, unless an instruction needs to place the value inline | Typical keys: `base_branch` (`develop` for two legacy repositories, `main` everywhere else), `branch_suffix` per orchestration, `review_conventions` per repository, `pr_title_format` per project, `default_reviewers` per project. ## How values resolve A parameter has one **definition** (key, description, optional default) and any number of **values**, one per entity. When a run is prepared, Overcut looks for each referenced key from the most specific scope to the least specific and uses the first value it finds: ```text theme={"dark"} workspace default < project < repository < workflow < orchestration < agent ``` Two placements are deliberate: * **An orchestration beats the workflow's own value.** The workflow value is what the workflow uses on its own. An orchestration hands configuration to every workflow it runs, so it wins when both exist. * **A repository sits below a workflow.** Repository values describe the codebase, such as its base branch. A workflow author who sets a value on the workflow is making a narrower, deliberate choice. For example, `review_branch` has these values: | Scope | Value | | ----------------- | ------------ | | Workspace default | `main` | | Project | `develop` | | Repository | `release` | | Workflow | `staging` | | Orchestration | `production` | A standalone run of that workflow on that repository uses `staging`. The same workflow started by the orchestration uses `production`. Three more rules shape what a run sees: * **Agent values apply per step, not per run.** A value set on an agent applies only to the Agent Run or Agent Session steps that use that agent. Two agents in the same run can resolve the same key differently. * **Resolution happens once, at preparation.** Overcut resolves every referenced key before the first step starts and freezes that snapshot for the run. Editing a default or a value affects the next run, not one that is already prepared. * **Only referenced keys load, and nothing is broadcast.** A run loads the keys its steps and agents actually name. A parameter reaches an agent only through an instruction that contains `{{params.}}`; it is never added to the agent's context on its own. ## Define a parameter Create workspace definitions from **Context Parameters** in the workspace navigation. Create project definitions from **Project Settings → Context Parameters → Project Context Parameters**. Both open the same form. Enter the **Key**. Overcut formats it as lowercase with underscores as you type, so `Review Branch` becomes `review_branch`. Keys are unique across the workspace, including across the workspace and project levels, and cannot be changed after creation. **Level** is either **Workspace (visible to every project)** or **Project: *project name***. A workspace parameter can be given values at every scope. A project parameter is visible only inside that project, and its default acts as the project's value, so it takes no separate project value and cannot be given a value on another project's resources. The **Default value** is used when no more specific value applies. Turn on **No default: every run must find a value at a more specific level** when every run should get its value from a project, repository, workflow, orchestration, or agent. A referenced key with no value stops the run during preparation. Keys can contain letters, digits, and underscores, start with a letter or underscore, and are at most 64 characters. A value can be up to 16 KB, so multi-line conventions fit. A workflow, including the agents it uses, can reference at most 50 keys. Values are plain text. They appear in rendered prompts, run logs, and the audit trail. Keep credentials in the [Vault](/docs/reference/vault). ## Reference a parameter Insert a parameter into a supported field with this syntax: ```text theme={"dark"} Open the pull request against {{params.review_branch}}. ``` | Field | Rendered | | ------------------------------------------------------------------------- | -------- | | **Instructions** on any workflow step | Yes | | String inputs on a workflow step, such as a branch or a working directory | Yes | | **Environment Variables** values on a Run Script step | Yes | | **Inputs** values on an Execute CI Workflow step | Yes | | **Additional Instructions** on an agent | Yes | | **Bash Script** body on a Run Script step | No | Three editors offer completion: **Instructions** on an Agent Run step, **Instructions** on an Agent Session step, and **Additional Instructions** on an agent. Type `{{params.` to list the keys visible to the project with their descriptions and defaults. Parameters work with the same template helpers as trigger data. Values are strings, so a switch looks like this: ```text theme={"dark"} {{#if (eq params.strict_mode "true")}} Block the merge on any failing check. {{/if}} ``` ### In a Run Script step The **Bash Script** body is never rendered, which keeps trigger text and agent output from being interpreted as shell syntax. Put the reference in **Environment Variables** and read the variable from the script: ```yaml theme={"dark"} params: script: | printf 'Release channel: %s\n' "$RELEASE_CHANNEL" env: RELEASE_CHANNEL: "{{params.release_channel}}" ``` Run Script also receives every key the workflow references as `OC_PARAM_`, with the key in uppercase. `release_channel` is available as `$OC_PARAM_RELEASE_CHANNEL`. These variables carry the run-wide value, not an agent's value. ## Set values per scope There are two places to manage values: * **On the definition.** Open a parameter and use its **Overrides** section. Select **Add override**, choose where it applies (a project, repository, workflow, orchestration, or agent), enter the value, and select **Save**. The grid lists every value with its type, the entity it belongs to, and the value. * **On the entity.** Open a project (**Project Settings → Context Parameters → Project Values**), a repository, a workflow (the metadata panel in Workflow Builder), an orchestration (the properties panel with nothing selected), or an agent, and use its **Context Parameters** panel. Select **Add override**, pick the parameter, and enter the value. An entity's panel lists only the values set on that entity. It does not show what the entity inherits or which value a run would use. To see the effective value and its source, use the Playground preview described below. Values save immediately. A workflow or orchestration value is independent of the draft, so you do not publish to apply it; the next run picks it up. Use **Edit** to replace a value. Use **Delete**, then confirm with **Remove**, to remove it. Runs that include the entity then fall back to the next less specific value or the default. Removing a value never deletes the definition. Setting a value on a repository requires a workspace-level grant, because repositories belong to the workspace rather than to a project. ## Preview and verify ### Before a run In the **Playground**, select a workflow and, when relevant, a repository. The **Context parameters** panel lists each key the workflow references, the value it would resolve to, and the scope that supplies it, for example `Repository: web-app` or `workspace default`. The preview uses the committed workflow. If the Playground run is set to use the working draft, the preview follows the draft. A manual run resolves workspace defaults plus project, repository, and workflow values. Orchestration and agent values do not apply, because they are not part of a manual run. | Panel shows | Meaning | What to do | | -------------------------------------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------ | | The value and its source scope | Resolved | Confirm that the source is the scope you intended. | | `not defined: publishing will be blocked` | No definition with that key is visible to the project | Check the spelling, then create the definition at the right level. | | `no value: the run will fail at preparation` | A definition exists but nothing on the manual-run path supplies a value | Add a default, or a value on the project, repository, or workflow. | The panel is empty when the selected workflow references no parameters. ### After a run Open **Logs → Workflow Executions**, select **View Details**, then select **Context** in the run header. The **Run Context** panel shows read-only JSON with the run's `trigger` data, step `outputs`, and the resolved parameters under `params`. When an agent used a more specific value, the panel also shows `agentParamOverrides`, grouped by agent. Run Context shows the frozen values a specific run used. It does not show which scope won. For that, use the Playground. ## Troubleshooting | Symptom | Cause | Fix | | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Publishing a workflow, or saving an agent, fails with `Unknown context parameter(s): params.. Define them under Context Parameters before publishing.` | The key has no visible definition. It was never created, or it is a project parameter of another project. | Create the definition, at the workspace level if more than one project needs it. Draft saves do not validate keys; only publish and agent save do. | | A run shows **Failed** with no failed step, and the preparation step reports `Context parameter(s) params. has no value for this run` | The key is defined but has no default and no value on the run's path. | Add a default, or a value on the project, repository, workflow, or orchestration. A key used only in an agent's Additional Instructions can also be satisfied by a value on that agent. | | The run used a value that the workflow's panel does not show | A more specific scope supplied it. The usual cause is an orchestration or an agent value. | Preview in the Playground for the manual-run path, and check the orchestration's and agent's **Context Parameters** panels for the rest. | | The Playground shows one value and the orchestration run used another | Orchestration values do not apply to manual runs. | Expected. Use Run Context on the orchestration run to see the frozen value. | | A multi-repository run used the wrong repository's value | Repository values come from the trigger repository, or the repository selected for a manual run. A repository identified later by a Repo Identify step does not change the resolved values. | Set the value on the workflow or orchestration instead, or trigger the run from the repository that should win. | | A scheduled or custom-event run ignored a repository value | Runs without a repository skip the repository scope. | Add a default or a project, workflow, or orchestration value. | ## Lifecycle and governance **Delete a definition.** Select **Delete** on the parameter and confirm the `Delete ""?` dialog. Every value is removed with it. Published workflows and agents that still reference the key fail at run preparation until you define the key again. Deleting a definition is different from removing one value. **Promote to workspace.** A project parameter has a **Promote to workspace** action. The parameter becomes visible to every project, keeps its id and every existing value, and cannot be moved back. Use it when a second project needs the same key, and before a Library template references it. **Export and import.** A workflow export lists the keys it references, with their descriptions, but not their definitions or values. An imported workflow lands as a draft and publishes only after every referenced key is defined in the target workspace. The same applies to templates installed from the [Workspace Library](/docs/reference/workspace-library): a template's keys must be workspace parameters, because a project parameter is not visible to the project that installs the copy. **Permissions.** Creating, editing, and deleting definitions and setting values are separate permissions on workspace roles. A project parameter follows that project's role assignments. Workspace parameters, and promoting to the workspace, need a workspace-level grant. Setting a value follows the entity that receives it, so a project editor can set a project or workflow value for a workspace parameter. The UI shows every action; an action you are not allowed to perform fails when you save. **Audit Trail.** Definition and value changes are recorded in the [Audit Trail](/docs/reference/audit-trail), including the value itself. Values are never treated as secrets. ## Chat Overcut chat can list definitions, create and edit them, set and remove values on any scope, and preview which values a workflow would use on a manual run. It can also insert `{{params.}}` references into workflow steps and agent instructions, checking that each key exists. Deleting a definition and **Promote to workspace** stay in the UI. See [Chat with Overcut](/docs/how-to/chat-with-overcut). ## Related * [Reuse a Workflow Across Repositories](/docs/quick-starts/reuse-a-workflow-across-repositories): an end-to-end walkthrough. * [Reuse Across Projects](/docs/concepts/reuse-across-projects): when to use a parameter, a Library resource, or a template. * [Workspace Library](/docs/reference/workspace-library): shared resources and templates. * [Vault](/docs/reference/vault): credentials that must stay hidden. * [Run Script](/docs/workflows/run-script): environment variables and `OC_PARAM_`.