factory-setup

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

factory-setup

Overview

概述

factory-setup

is an interactive skill that wires a repo to its issue tracker for the factory (

factory-mission

factory-queue

factory-review

). It asks which tracker the repo uses, then writes

.adlc/issues-provider.yml

from the release template — provider and field mappings only, never credentials. It is invoked three ways:

User-invoked (
```
/factory-setup
```
) — anytime, to configure or check a project.
Model-invoked by
team-boot
— suggested when factory skills are installed but no provider config resolves (self-install hint, like
```
team-setup
```
).
Headless via
adlc-cli factory setup
— scripted runs;
```
--provider
```
pre-answers the pick so no question is asked.

The skill is non-destructive: it never overwrites an existing

.adlc/issues-provider.yml

. If one exists, it verifies the wiring instead (Mode 3).

factory-setup

是一个交互式 skill，用于将仓库连接到其 issue tracker，以供 factory（

factory-mission

、

factory-queue

、

factory-review

）使用。它会询问仓库使用哪个 tracker，然后根据发布模板写入

.adlc/issues-provider.yml

——只写入 provider 和字段映射，绝不写入凭据。它有三种调用方式：

用户调用（
```
/factory-setup
```
）——可随时用于配置或检查项目。
由
team-boot
调用模型——当 factory skills 已安装但无法解析出 provider 配置时进行建议（类似
```
team-setup
```
的自我安装提示）。
通过
adlc-cli factory setup
无头运行——用于脚本化运行；
```
--provider
```
会预先回答选择项，因此不会提出问题。

该 skill 是非破坏性的：绝不会覆盖已有的

.adlc/issues-provider.yml

。如果文件存在，则改为验证连接配置（模式 3）。

When to Use

使用时机

A tracker run halted with "no provider resolves" and named this skill.
Setting up a new repo for factory runs (GitHub, GitLab, Linear, or Jira).
You're unsure which tracker a repo is wired to and want a quick check.
Switching a repo from one tracker to another (re-pick, file rewritten only on explicit confirmation).
```
team-boot
```
suggested it because factory skills are installed but no provider config resolves.

某次 tracker 运行因“no provider resolves”而停止，并指定使用此 skill。
为 factory 运行设置新仓库（GitHub、GitLab、Linear 或 Jira）。
不确定仓库连接了哪个 tracker，希望快速检查。
将仓库从一个 tracker 切换到另一个 tracker（重新选择；仅在明确确认后重写文件）。
```
team-boot
```
建议使用此 skill，因为 factory skills 已安装，但无法解析出 provider 配置。

Decline Handling (when model-invoked by team-boot)

拒绝处理（由 team-boot 调用模型时）

The user may choose not to configure the tracker right now. Handle decline explicitly to avoid a re-prompt loop:

If the user declines, do not write anything. Exit cleanly; the decline is session-scoped only.
There is deliberately no persistent opt-out marker: the marker would live in
```
.adlc/init-options.json
```
, whose schema is shared with adlc-cli — a tracker-specific key there is schema churn for a session preference. team-boot simply asks again next session.
Never force a mode; setup is user-consented at every step. In headless runs there is no one to ask —
```
--provider
```
is required, else halt.

用户可以选择暂时不配置 tracker。应明确处理拒绝情况，以避免重复提示循环：

如果用户拒绝，不要写入任何内容。正常退出；该拒绝仅在当前会话内有效。
特意不设置持久化退出标记：该标记将位于
```
.adlc/init-options.json
```
中，而该文件的 schema 与 adlc-cli 共用——为会话偏好添加 tracker 专用键会造成 schema 变动。下次会话时，team-boot 会再次询问。
绝不强制进入某种模式；每一步设置都需要用户同意。在无头运行中没有人可以询问，因此必须提供
```
--provider
```
，否则应停止运行。

Core Process

核心流程

Goal

目标

Leave the repo with a committed-ready

.adlc/issues-provider.yml

carrying the correct

provider:

, or verify the existing wiring.

最终让仓库拥有正确

provider:

且达到可提交状态的

.adlc/issues-provider.yml

，或验证现有连接配置。

Security: Input Validation

安全：输入验证

The only free-form value this skill writes is the provider literal, which must be exactly one of

github

gitlab

linear

jira

— anything else is rejected before any write. Field-mapping values (project IDs, keys) are written verbatim into YAML comments or values only after the user confirms the rendered file content; never interpolate user values into shell — the write path is file-only (

cp

template, edit the

provider:

line). If the user pastes anything token-like (

glpat-

ghp_

xoxb-

sk-

), refuse to write it and remind them credentials arrive via environment only.

Fast path: if

.adlc/issues-provider.yml

already exists with a valid

provider:

, skip to Mode 3 (Already Configured) — do not re-detect, re-pick, or rewrite.

此 skill 写入的唯一自由格式值是 provider 字面值，它必须严格为

github

、

gitlab

、

linear

、

jira

之一——其他值都会在写入前被拒绝。只有在用户确认渲染后的文件内容后，字段映射值（项目 ID、键）才会原样写入 YAML 注释或值中；绝不将用户值插入 shell——写入路径仅限文件（

cp

模板，编辑

provider:

行）。如果用户粘贴任何类似 token 的内容（

glpat-

、

ghp_

、

xoxb-

、

sk-

），拒绝写入，并提醒用户凭据只能通过环境变量传入。

**快速路径：**如果

.adlc/issues-provider.yml

已存在且包含有效的

provider:

，直接跳到模式 3（已配置）——不要重新检测、重新选择或重写。

Modes at a Glance

模式概览

#	Mode	When	Details in
1	Detect from git remote	quick heuristic wanted (always confirmed)	`references/mode-detect.md`
2	Pick explicitly	heuristic wrong, non-git remote, or `--provider` given	`references/mode-pick.md`
3	Already configured	file exists — verify wiring	`references/mode-configured.md`

#	模式	使用时机	详细信息见
1	从 git remote 检测	需要快速启发式判断时（始终需要确认）	`references/mode-detect.md`
2	显式选择	启发式判断错误、非 git remote，或给出了 `--provider`	`references/mode-pick.md`
3	已配置	文件存在——验证连接配置	`references/mode-configured.md`

Mode Selection Flow

模式选择流程

Check: read
```
.adlc/issues-provider.yml
```
in the repo root (CWD; do not walk up). Valid
```
provider:
```
present → Mode 3.
Ask: present the choice — detect from remote (show the remote URL) or pick from the four providers. In headless runs (
```
--provider
```
supplied), skip asking and use Mode 2 with the given literal.
Confirm: show the exact file content to be written and get explicit confirmation before writing (interactive runs). Headless runs write directly — the
```
--provider
```
flag IS the confirmation.
Commit step: copy the release template (
```
skills/factory/factory-runbook/references/issues-provider.yml
```
) to
```
.adlc/issues-provider.yml
```
, set the
```
provider:
```
line, report the path, and remind the user to commit it. Never write credentials, never overwrite.

Requires: the

factory-runbook

skill (provides

references/issues-provider.yml

adlc-cli skills add tikalk/adlc-team-skills --skill factory-runbook

检查：读取仓库根目录中的
```
.adlc/issues-provider.yml
```
（CWD；不要向上查找）。存在有效的
```
provider:
```
→ 模式 3。
询问：提供选项——从 remote 检测（显示 remote URL），或从四个 providers 中选择。在无头运行中（提供了
```
--provider
```
），跳过询问并使用模式 2，采用给定的字面值。
确认：显示将要写入的确切文件内容，并在写入前获得明确确认（交互式运行）。无头运行会直接写入——
```
--provider
```
标志就是确认。
提交步骤：将发布模板（
```
skills/factory/factory-runbook/references/issues-provider.yml
```
）复制到
```
.adlc/issues-provider.yml
```
，设置
```
provider:
```
行，报告文件路径，并提醒用户提交该文件。绝不写入凭据，绝不覆盖文件。

**要求：**需要

factory-runbook

skill（提供

references/issues-provider.yml

）：

adlc-cli skills add tikalk/adlc-team-skills --skill factory-runbook

Commit Step (shared by Modes 1–2)

提交步骤（模式 1–2 共用）

Refuse if the target exists (route to Mode 3 instead) — unless the user explicitly confirmed a switch in Mode 2.
Copy the template; uncomment and set
```
provider: <literal>
```
.
Show the final content; write only on confirmation (interactive) or
```
--provider
```
(headless).
Report: path written, provider selected, reminder to commit, and that tracker runs will now resolve without halting.

如果目标文件已存在，则拒绝执行（改为进入模式 3）——除非用户在模式 2 中明确确认了切换操作。
复制模板；取消注释并设置
```
provider: <literal>
```
。
显示最终内容；仅在获得确认后写入（交互式），或在提供
```
--provider
```
后写入（无头）。
报告：写入的路径、所选的 provider、提交文件的提醒，以及 tracker 运行现在可以正常解析而不会停止。