launchdarkly-release-autopilot-settings

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

LaunchDarkly Release Autopilot Settings

LaunchDarkly Release Autopilot 设置

You're using a skill that configures Release Autopilot (GitHub App code automation) through the LaunchDarkly MCP, or explains why a PR was not classified. Release Autopilot can open and change pull requests (auto-flagging) and can drive auto-releasing. Treat every write as production automation with a blast radius.

你正在使用一个通过 LaunchDarkly MCP 配置 Release Autopilot（GitHub App 代码自动化）的 skill，或用于解释某个 PR 未被分类或自动标记的原因。Release Autopilot 可以创建和修改 pull request（auto-flagging），并可驱动 auto-releasing。请将每次写入视为会影响生产环境的自动化操作，并明确其影响范围。

Prerequisites

前置条件

This skill requires the remotely hosted LaunchDarkly MCP server.

Required MCP tools:

get-release-autopilot-settings

update-release-autopilot-settings

```
list-release-autopilot-github-repos
```
(GitHub App install — mappable repos)
```
list-release-autopilot-repo-settings
```
(already mapped)

update-release-autopilot-repo-settings

get-release-autopilot-repo-settings

delete-release-autopilot-repo-settings

If these tools are missing, stop. Do not invent REST calls, numeric GitHub ids, or "fixes" by guessing settings.

Release Autopilot settings are in alpha: the underlying endpoints are gated by an alpha feature flag. If every Release Autopilot tool returns 404, the account is not in the alpha — tell the user rather than retrying or falling back to REST.

此 skill 需要远程托管的 LaunchDarkly MCP server。

必需的 MCP 工具：

get-release-autopilot-settings

update-release-autopilot-settings

```
list-release-autopilot-github-repos
```
（GitHub App install 中可映射的仓库）
```
list-release-autopilot-repo-settings
```
（已映射的仓库）

update-release-autopilot-repo-settings

get-release-autopilot-repo-settings

delete-release-autopilot-repo-settings

如果缺少这些工具，请停止。不要虚构 REST 调用、数字形式的 GitHub id，也不要通过猜测设置来尝试“修复”。

Release Autopilot 设置仍处于 alpha 阶段：底层端点受 alpha feature flag 控制。如果所有 Release Autopilot 工具都返回 404，则表示该账户不在 alpha 范围内——应告知用户，不要重试或回退到 REST。

Core Principles

核心原则

Fail closed. Diagnosis is read-only. Never change settings to "make classification work" unless the user confirmed that exact write after seeing current vs proposed state.
Account settings are the master gate. A mapped repo cannot enable a capability the account has off. Turning a capability off at the account level turns it off for every mapped repo. Turning it on at the account level allows every mapped repo that inherits (no override off) to start automating PRs.
Confirm before every Release Autopilot write. Account PATCH, mapping, repo overrides, and unmap all use Confirm before write. Only touch repos the user named.
Least privilege. Never enable auto-releasing unless the user explicitly asked to auto-release (that can ship code). Never turn
```
approvalRequired
```
off unless they explicitly asked to drop the approval gate. Never map or unmap repos they did not name. Never iterate the install list and map everything.
Discover, then map. Pass
```
owner/name
```
. Never ask for a numeric GitHub id. Prefer
```
git remote
```
of the current workspace when they say "this repo" / "this PR"; if remotes disagree (fork vs upstream), ask which one.
```
owner/name
```
resolves against the GitHub App install list only — a repo outside the install cannot be resolved or acted on, because Release Autopilot works through the App. A 404 saying the repo is not on the install, or that the App is not installed, is the answer; do not retry with other spellings or look the repo up elsewhere.
projectKey
on first map. Required when creating a mapping; later updates can omit it.
Omit
autoCleanup
. Not part of Release Autopilot settings yet. Never send it; never copy it from a response into a PATCH.
GitHub connect is a browser link. If
```
list-release-autopilot-github-repos
```
returns
```
githubConnectUrl
```
, give the user that exact URL and wait until they say they finished. Then call
```
list-release-autopilot-github-repos
```
again. Do not install or authorize GitHub yourself.
```
flow=install
```
is Install GitHub App.
```
flow=authorize
```
is Authorize GitHub. Both are the same pages as the integration drawer. The user must already be logged into LaunchDarkly in that browser.

失败关闭（Fail closed）。 诊断操作必须是只读的。除非用户在看到当前状态与建议状态后，明确确认了这项具体写入，否则绝不能为了“让分类正常工作”而更改设置。
账户设置是主控开关。 已映射的仓库无法启用账户级已关闭的能力。在账户级关闭某项能力，会将其关闭到每个已映射仓库；在账户级开启某项能力，则允许每个继承该设置（未设置仓库级关闭覆盖）的已映射仓库开始自动处理 PR。
每次 Release Autopilot 写入前都要确认。 账户 PATCH、仓库映射、仓库覆盖和取消映射都必须遵循写入前确认。只能操作用户明确指定的仓库。
最小权限。 除非用户明确要求 auto-releasing，否则绝不能启用它（该操作可能会发布代码）。除非用户明确要求取消审批关卡，否则绝不能关闭
```
approvalRequired
```
。绝不能映射或取消映射用户未指定的仓库。绝不能遍历 install 列表并映射其中所有仓库。
先发现，再映射。 传入
```
owner/name
```
。绝不要索要数字形式的 GitHub id。当用户提到“this repo”或“this PR”时，优先使用当前工作区的
```
git remote
```
；如果 remotes 不一致（fork 与 upstream），询问用户使用哪一个。
```
owner/name
```
只能在 GitHub App install 列表中解析——不在 install 中的仓库无法解析或操作，因为 Release Autopilot 通过该 App 工作。如果收到 404，提示仓库不在 install 中或 App 未安装，这就是答案；不要尝试其他拼写，也不要从其他地方查找该仓库。
首次映射时需要
projectKey
。创建映射时必须提供；后续更新可以省略。
省略
autoCleanup
。它尚不属于 Release Autopilot 设置。绝不能发送该字段，也绝不能将其从响应复制到 PATCH 中。
GitHub connect 是浏览器链接。 如果
```
list-release-autopilot-github-repos
```
返回
```
githubConnectUrl
```
，请将该 URL 原样提供给用户，并等待用户表示已完成。随后再次调用
```
list-release-autopilot-github-repos
```
。不要自行安装或授权 GitHub。
```
flow=install
```
表示安装 GitHub App，
```
flow=authorize
```
表示授权 GitHub；两者都对应集成抽屉中的同一页面。用户必须已在其浏览器中登录 LaunchDarkly。

Confirm before write

写入前确认

STOP. Do not call

update-release-autopilot-settings

update-release-autopilot-repo-settings

, or

delete-release-autopilot-repo-settings

until the user has answered yes to the proposal in this turn. A yes from an earlier turn, or a vague "fix it" / "go ahead" that does not name the setting, is not enough.

Read current state first (
```
get-release-autopilot-settings
```
, and repo get/list if the change is repo-scoped).
State now vs proposed, in one or two sentences. Include blast radius. For a map, state inherited auto-flagging and auto-releasing from the account (read
```
get-release-autopilot-settings
```
first).
Wait. Do not batch the write in the same tool round as the question.

Account change (any field on

update-release-autopilot-settings

, including turning things on):

Auto-flagging is ON for this account. Turn it OFF for all mapped repos? Auto-flagging pull requests will stop until it is turned back on.

Auto-flagging is OFF for this account. Turn it ON for the account? Mapped repos that inherit this setting can start getting auto-flagging pull requests.

Auto-flagging approvalRequired is ON. Turn it OFF? Auto-flagging PRs would no longer require that approval gate.

Same pattern for auto-releasing, and say that auto-releasing can ship.

Map or change one repo (

update-release-autopilot-repo-settings

Always name both inherited account capabilities in the proposal. Omitted overrides inherit auto-flagging and auto-releasing; do not confirm a map that only mentions auto-flagging.

launchdarkly/gonfalon
is not mapped. Map it to project
default
, inheriting account auto-flagging (ON) and auto-releasing (OFF)? Release Autopilot can start classifying and opening auto-flagging PRs in that repo. Auto-releasing will stay off unless the account (or a repo override) turns it on.

launchdarkly/gonfalon
is not mapped. Map it to project
default
, inheriting account auto-flagging (ON) and auto-releasing (ON)? Release Autopilot can start auto-flagging PRs in that repo and auto-releasing, which can ship.

launchdarkly/gonfalon
is mapped to
default
with auto-flagging effective ON and auto-releasing effective OFF. Set a repo override turning auto-flagging OFF for this repo only? Auto-releasing stays inherited (OFF).

Unmap (

delete-release-autopilot-repo-settings

launchdarkly/gonfalon
is mapped to project
default
with auto-flagging effective ON and auto-releasing effective OFF. Unmap it? Release Autopilot will stop auto-flagging and auto-releasing that repo until it is mapped again.

After they confirm, apply only the fields in the proposal. Then verify (do not use verify as the safety check).

停止。 在用户于本轮明确回答“是”以确认建议之前，不要调用

update-release-autopilot-settings

、

update-release-autopilot-repo-settings

或

delete-release-autopilot-repo-settings

。更早轮次中的“是”，或未明确指定设置的模糊表述，如“修复它”或“继续”，均不足以作为确认。

首先读取当前状态（
```
get-release-autopilot-settings
```
；如果修改范围限定在仓库，还应读取仓库的 get/list）。
用一两句话说明当前状态与建议状态，并包含影响范围。对于映射操作，必须同时说明从账户继承的 auto-flagging 和 auto-releasing；先读取
```
get-release-autopilot-settings
```
。
等待用户确认。不得在提出确认问题的同一轮工具调用中一并执行写入。

账户级变更（

update-release-autopilot-settings

中的任何字段，包括开启某项能力）：

此账户的 auto-flagging 已开启。要为所有已映射仓库关闭它吗？自动标记 pull request 将停止，直到重新开启。

此账户的 auto-flagging 已关闭。要在账户级开启它吗？继承此设置的已映射仓库可能开始收到自动标记的 pull request。

此账户的 auto-flagging
approvalRequired
已开启。要关闭它吗？自动标记的 PR 将不再需要该审批关卡。

auto-releasing 遵循相同模式，并且必须说明 auto-releasing 可能会发布代码。

映射或修改单个仓库（

update-release-autopilot-repo-settings

）：

始终在建议中同时说明两项继承自账户的能力。省略的覆盖项会同时继承 auto-flagging 和 auto-releasing；不要确认一个只提及 auto-flagging 的映射操作。

launchdarkly/gonfalon
尚未映射。是否将它映射到项目
default
，并继承账户级 auto-flagging（开启）和 auto-releasing（关闭）？Release Autopilot 可能开始在该仓库中分类 PR 并创建 auto-flagging pull request。除非账户或仓库级覆盖开启 auto-releasing，否则它会保持关闭。

launchdarkly/gonfalon
尚未映射。是否将它映射到项目
default
，并继承账户级 auto-flagging（开启）和 auto-releasing（开启）？Release Autopilot 可能开始在该仓库中创建 auto-flagging pull request，并执行 auto-releasing，后者可能会发布代码。

launchdarkly/gonfalon
已映射到
default
，当前有效的 auto-flagging 为开启，auto-releasing 为关闭。是否设置仓库级覆盖，仅为此仓库关闭 auto-flagging？auto-releasing 将继续继承账户设置（关闭）。

取消映射（

delete-release-autopilot-repo-settings

）：

launchdarkly/gonfalon
已映射到项目
default
，当前有效的 auto-flagging 为开启，auto-releasing 为关闭。是否取消映射？在重新建立映射之前，Release Autopilot 将停止为此仓库执行 auto-flagging 和 auto-releasing。

用户确认后，仅应用建议中包含的字段。然后进行验证（不要将验证用作安全检查）。

Choose a workflow

选择工作流

"Why didn't Release Autopilot classify / auto-flag my PR?" (or similar) → Why didn't my PR get classified? first. Do not write settings in that workflow.
Configure / map / turn on / unmap → Configure settings.

“为什么 Release Autopilot 没有分类或自动标记我的 PR？” 或类似问题 → 先执行为什么我的 PR 没有被分类？。此工作流中不要写入设置。
配置、映射、开启或取消映射 → 执行配置设置。

Why didn't my PR get classified?

为什么我的 PR 没有被分类？

Use this when the user asks why a PR was not classified, not auto-flagged, or Release Autopilot ignored the PR. Read-only. Check in this order. Stop at the first failure and tell them how to fix it (then Confirm before write if they ask you to apply the fix).

Identify the GitHub repo (

owner/name

) from the PR URL,

git remote

, or the name they gave. If you cannot identify one repo, ask. Do not diagnose a different repo.

Is auto-flagging on for the account?
```
get-release-autopilot-settings
```
. If
```
autoFlagging.enabled
```
is false, that is the answer: account gate is off, so no repo can auto-flag. Stop.
Is this repo mapped to a project?
```
get-release-autopilot-repo-settings
```
with
```
repo: "owner/name"
```
(or
```
list-release-autopilot-repo-settings
```
and find it). If the error or
```
list-release-autopilot-github-repos
```
includes
```
githubConnectUrl
```
, read
```
flow
```
:
- ```
flow=install
```
  : the GitHub App is not installed, so Release Autopilot never sees the PR. That is the answer. Give the user the link and stop.
- ```
flow=authorize
```
  : this member has not authorized GitHub, so
```
owner/name
```
  cannot be looked up. That is not why Release Autopilot skipped the PR. Say so, give the user the link, and resume at this step after they finish. Do not report it as the fix.
A repo that is on the install but unmapped is a different answer. Unmapped install repos do not run Release Autopilot. Stop.
Does this repo override auto-flagging off? On the repo payload, if auto-flagging
```
enabled
```
is false, or
```
enabledOverride
```
is true while
```
enabled
```
is false, the repo is opted out even if the account is on. Stop.

If all three look fine (account on, repo mapped, repo auto-flagging effective on):

Do not flip settings to "try something."
Point them at the Release Autopilot runbooks. These are internal LaunchDarkly Confluence pages (PD space) while Release Autopilot is in alpha; there is no public docs URL yet. Classification can still fail for reasons this MCP surface cannot see (GitHub App install on the wrong org, PR not in an installed repo, workflow/app permissions, classifier skip rules).
- Flag Classification (ODD) Runbook — the classifier itself: verdicts (
```
not-suited
```
  ,
```
already-flagged
```
  ), escalations, and the per-PR ledger that records why a PR got the verdict it did.
- GitHub App Runbook — the PR event never reaching Release Autopilot: install scope, permissions, webhooks.
Optional reads:
```
list-release-autopilot-github-repos
```
to confirm the repo is on the install list;
```
autoFlagging.approvalRequired
```
if they expected a PR and one exists but is waiting on approval.

当用户询问 PR 未被分类、未被自动标记，或 Release Autopilot 忽略该 PR 的原因时，使用此工作流。只读。 按以下顺序检查。遇到第一个故障时立即停止，并告知用户如何解决；如果用户要求应用修复，再执行写入前确认。

从 PR URL、

git remote

或用户提供的名称识别 GitHub 仓库（

owner/name

）。如果无法唯一确定一个仓库，则询问用户。不要诊断其他仓库。

账户是否开启了 auto-flagging？ 调用
```
get-release-autopilot-settings
```
。如果
```
autoFlagging.enabled
```
为 false，这就是原因：账户级开关已关闭，因此任何仓库都无法执行 auto-flagging。停止。
此仓库是否已映射到项目？ 使用
```
repo: "owner/name"
```
调用
```
get-release-autopilot-repo-settings
```
（或调用
```
list-release-autopilot-repo-settings
```
并查找对应项）。如果错误响应或
```
list-release-autopilot-github-repos
```
包含
```
githubConnectUrl
```
，请读取
```
flow
```
：
- ```
flow=install
```
  ：GitHub App 未安装，因此 Release Autopilot 从未看到该 PR。这就是原因。向用户提供链接并停止。
- ```
flow=authorize
```
  ：此成员尚未授权 GitHub，因此无法查找
```
owner/name
```
  。这并不是 Release Autopilot 跳过该 PR 的原因。应明确说明这一点，向用户提供链接，并在用户完成后从本步骤继续。不要将此报告为修复方案。
位于 install 中但未映射的仓库属于另一种情况。未映射的 install 仓库不会运行 Release Autopilot。停止。
此仓库是否覆盖并关闭了 auto-flagging？ 在仓库数据中，如果 auto-flagging 的
```
enabled
```
为 false，或者
```
enabledOverride
```
为 true 且
```
enabled
```
为 false，则即使账户级设置已开启，该仓库也已选择退出。停止。

如果这三项均正常（账户已开启、仓库已映射、仓库的有效 auto-flagging 已开启）：

不要切换设置来“尝试看看”。
引导用户查看 Release Autopilot runbook。由于 Release Autopilot 仍处于 alpha 阶段，这些是 LaunchDarkly 内部的 Confluence 页面（PD space），目前还没有公开文档 URL。分类仍可能因当前 MCP 接口无法看到的原因而失败，例如 GitHub App 安装在错误的组织、PR 不在已安装的仓库中、workflow/App 权限问题或分类器跳过规则。
- Flag Classification（ODD）操作手册——介绍分类器本身，包括判定结果（
```
not-suited
```
  、
```
already-flagged
```
  ）、升级处理，以及记录每个 PR 为何得到相应判定的台账。
- GitHub App 操作手册——处理 PR 事件从未到达 Release Autopilot 的情况，包括 install 范围、权限和 webhooks。
可选的读取操作：调用
```
list-release-autopilot-github-repos
```
，确认仓库位于 install 列表中；如果用户预期某个 PR 应被处理且该 PR 已存在但正在等待审批，则读取
```
autoFlagging.approvalRequired
```
。

Configure settings

配置设置

Step 1: Read current settings

第 1 步：读取当前设置

```
get-release-autopilot-settings
```
```
list-release-autopilot-repo-settings
```

list-release-autopilot-github-repos

(optional

projectKey

; install is account-wide)

githubConnectUrl

is present, give the user that link and stop this turn. Do not map until a later call omits the URL.

```
get-release-autopilot-settings
```
```
list-release-autopilot-repo-settings
```

list-release-autopilot-github-repos

（可选

projectKey

；install 是账户范围的）

如果存在

githubConnectUrl

，向用户提供该链接并结束本轮。在后续调用不再返回该 URL 之前，不要进行映射。

Step 2: Account defaults (if needed)

第 2 步：账户默认设置（如有需要）

If an account PATCH is needed, follow Confirm before write, then

update-release-autopilot-settings

with only the confirmed fields:

autoFlagging.enabled

autoFlagging.approvalRequired

(approval is only valid here)

```
autoReleasing.enabled
```

Do not send

autoCleanup

. Requires permission to update account Release Autopilot settings.

如果需要进行账户 PATCH，请遵循写入前确认，然后使用仅包含已确认字段的

update-release-autopilot-settings

：

autoFlagging.enabled

autoFlagging.approvalRequired

（审批设置仅在此处有效）

```
autoReleasing.enabled
```

不要发送

autoCleanup

。此操作需要更新账户 Release Autopilot 设置的权限。

Step 3: Map or override a repository

第 3 步：映射或覆盖仓库

Only for repos the user named. Follow Confirm before write, then

update-release-autopilot-repo-settings

Prefer
```
repo: "owner/name"
```
.
Include
```
projectKey
```
when creating a mapping.
Optional repo-level
```
autoFlagging
```
/
```
autoReleasing
```
overrides. Omitted capabilities inherit the account setting. A repo cannot enable a capability the account has off.

Requires permission to update Release Autopilot repo settings on the mapped project.

仅操作用户明确指定的仓库。遵循写入前确认，然后调用

update-release-autopilot-repo-settings

：

优先使用
```
repo: "owner/name"
```
。
创建映射时包含
```
projectKey
```
。
可选地设置仓库级
```
autoFlagging
```
/
```
autoReleasing
```
覆盖。省略的能力会继承账户设置。仓库无法启用账户级已关闭的能力。

此操作需要具备在已映射项目上更新 Release Autopilot 仓库设置的权限。

Step 4: Verify (after a confirmed write)

第 4 步：验证（完成已确认的写入后）

get-release-autopilot-repo-settings

get-release-autopilot-settings

as appropriate.

Effective
```
enabled
```
must match the proposal (account off ⇒ repo cannot be on).
Mapped repos appear in
```
list-release-autopilot-repo-settings
```
.

To unmap: Confirm before write, then

delete-release-autopilot-repo-settings

根据修改范围调用

get-release-autopilot-repo-settings

get-release-autopilot-settings

。

有效的
```
enabled
```
必须与建议一致（账户级关闭意味着仓库级不可能开启）。
已映射的仓库应出现在
```
list-release-autopilot-repo-settings
```
中。

取消映射：遵循写入前确认，然后调用

delete-release-autopilot-repo-settings

。

Out of scope

不在范围内

Auto-cleanup
Completing GitHub OAuth inside the tool. Hand the user
```
githubConnectUrl
```
instead.
Vega BYOK
Observability MCP (
```
github_repositories
```
) — do not require a second MCP server just to map a repo
Changing classification rules, GitHub App permissions, or org install scope via this skill

Auto-cleanup
在工具内完成 GitHub OAuth。应改为向用户提供
```
githubConnectUrl
```
。
Vega BYOK
Observability MCP（
```
github_repositories
```
）——不要仅仅为了映射仓库就要求使用第二个 MCP server
通过此 skill 修改分类规则、GitHub App 权限或组织 install 范围