repokit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

repokit

Configure a GitHub repository's metadata through the

gh

CLI, in two explicit modes:

about
. Infer a one-line About description and a focused set of topics from the repo's own contents (README, manifest, code), show them against whatever is already set, and apply what you approve.
labels
. Provision the issue-workflow lifecycle and priority labels (the sets issuekit uses to track work and rank it), creating what's missing and reconciling what drifted.

Two jobs, one skill, because both answer "make this repo's GitHub metadata right": the outward-facing blurb people read, and the label vocabulary the issue workflow runs on.

通过

gh

CLI配置GitHub仓库的元数据，包含两种明确的模式：

about
模式：从仓库自身内容（README、清单文件、代码）中推断一行About描述和一组精准主题，将其与现有设置进行对比，仅应用你批准的内容。
labels
模式：配置用于工单工作流的生命周期和优先级标签（即issuekit用于跟踪工作任务并划分优先级的标签集），创建缺失的标签并调整已偏离标准的标签。

两项任务，一个工具，因为它们都能解决“让GitHub仓库元数据合规”的需求：面向外部的简介内容，以及工单工作流依赖的标签体系。

When this fires

触发场景

The user wants to set a repo's GitHub metadata. Route to a mode from what they ask:

about. "Set the repo description", "add topics", "write an About blurb", "tag this repo", "update the repo's About".
labels. "Provision the workflow labels", "set up this repo's labels", "add the issuekit labels", "add priority labels", "the
```
blocked
```
label is missing".
both. A vague "set up this repo" or "configure repo metadata" → offer to run
```
about
```
then
```
labels
```
.

If no mode is clear, ask first. Present the two modes and let the user pick before touching anything.

当用户想要设置GitHub仓库的元数据时，根据其需求匹配对应模式：

about模式：用户提及“设置仓库描述”、“添加主题”、“撰写About简介”、“为仓库打标签”、“更新仓库About信息”。
labels模式：用户提及“配置工作流标签”、“设置仓库标签”、“添加issuekit标签”、“添加优先级标签”、“
```
blocked
```
标签缺失”。
双模式：用户表述模糊，如“设置仓库”或“配置仓库元数据”→ 先运行
```
about
```
模式，再运行
```
labels
```
模式。

若模式不明确，先询问用户。展示两种模式，让用户选择后再执行操作。

Preflight (every mode)

前置检查（所有模式通用）

Before any GitHub call, confirm the tooling and target:

gh --version                                          # gh installed?
gh auth status                                        # authenticated?
gh repo view --json nameWithOwner -q .nameWithOwner   # which repo? (the current dir's remote)

If
```
gh
```
is missing or unauthenticated, say so and point to
```
https://cli.github.com
```
/
```
gh auth login
```
. Don't work around it.
If there's no GitHub remote (the
```
repo view
```
call fails), stop and say so, because repokit acts on a repo that exists on GitHub.
No shell or
gh
at all (e.g. a browser-based agent)? You can't call
```
gh
```
. Do the reasoning from what the user provides and print the exact
gh
commands for them to run, whether the description/topics lines or the
```
gh label create
```
block, as a codeblock to paste.

Safety stance, for the whole skill. A repo's description, topics, and labels are outward-facing state. Preview every mutation and get an OK before it runs, so nothing changes on GitHub unprompted. Always echo the exact command(s) you run, so the change is auditable and replayable.

Re-run safe. Every mode reconciles against what's already there, so running repokit a second time on an unchanged repo proposes nothing and mutates nothing. It's always safe to re-run.

在调用任何GitHub接口前，确认工具状态和目标仓库：

gh --version                                          # 是否已安装gh？
gh auth status                                        # 是否已认证？
gh repo view --json nameWithOwner -q .nameWithOwner   # 目标仓库是哪个？（当前目录关联的远程仓库）

若未安装gh或未完成认证，告知用户并引导至
```
https://cli.github.com
```
/
```
gh auth login
```
，不进行后续操作。
若不存在GitHub远程仓库（
```
repo view
```
命令执行失败），停止操作并告知用户，因为repokit仅作用于已存在于GitHub的仓库。
完全无shell或gh环境（如基于浏览器的Agent）：无法调用gh。根据用户提供的信息进行逻辑推导，并输出精确的gh命令供用户运行，无论是描述/主题相关命令还是
```
gh label create
```
代码块，以代码块形式展示方便用户复制粘贴。

工具安全原则：仓库的描述、主题和标签是对外展示的状态。在执行任何变更前预览所有操作并获得用户确认，避免未经许可修改GitHub上的内容。始终回显执行的精确命令，确保变更可审计、可重复执行。

可重复执行：所有模式都会与现有状态进行对比，因此在未修改的仓库上重复运行repokit不会产生任何变更建议或实际修改。重复执行始终安全。

Detect (every mode)

状态检测（所有模式通用）

Read the repo's current state once before proposing anything. It's the raw material every mode reconciles against, and it surfaces guardrails early. Fetch what the chosen mode needs plus the guardrail flags:

undefined

在提出任何变更建议前，先读取仓库的当前状态。这是所有模式进行对比的基础，也能提前发现限制条件。获取所选模式所需的信息及限制条件标识：

undefined

guardrail flags + about state

限制条件标识 + about模式状态

gh repo view --json isArchived,isFork,isTemplate,description gh api repos/{owner}/{repo}/topics --jq '.names' # current topics (about mode) gh label list --json name,color,description # current labels (labels mode)


Check the guardrail flags **before** any mutation:

- **Archived** (`isArchived: true`). GitHub rejects metadata edits on an archived repo, so **stop** and tell the user to unarchive first.
- **Fork or template** (`isFork` / `isTemplate`). Its metadata is often inherited or throwaway, so **confirm the user means to edit *this* repo** before continuing.

---

gh repo view --json isArchived,isFork,isTemplate,description gh api repos/{owner}/{repo}/topics --jq '.names' # 当前主题（about模式） gh label list --json name,color,description # 当前标签（labels模式）


在执行任何变更前检查限制条件：

- **已归档**（`isArchived: true`）：GitHub拒绝修改已归档仓库的元数据，因此**停止操作**并告知用户先取消归档。
- **复刻或模板仓库**（`isFork` / `isTemplate`）：这类仓库的元数据通常是继承或临时的，因此**在继续操作前确认用户确实要编辑该仓库**。

---

Mode:

about

about

模式

Infer the description and topics, reconcile against what's there, apply on approval.

推断描述和主题，与现有状态对比，获得批准后应用变更。

1. Start from what's already set

1. 基于现有设置开始

You read the current description and topics in Detect, so carry them in and reconcile against curated metadata instead of clobbering it.

你已在状态检测步骤中读取了当前描述和主题，需将这些内容纳入考量，与标准化元数据进行对比而非直接覆盖。

2. Gather signal from the repo

2. 从仓库收集信息

Read the cheap, high-signal sources first; only dig deeper when they're thin:

Primary. The
```
README
```
and the project manifest (
```
package.json
```
,
```
pyproject.toml
```
,
```
Cargo.toml
```
,
```
go.mod
```
,
```
composer.json
```
,
```
Gemfile
```
, …): name, existing description/keywords, dependencies, scripts.
Fallback. Only when the above are missing or uninformative: scan the file tree and language mix (
```
gh repo view --json languages
```
, a shallow
```
ls
```
/
```
git ls-files
```
) to infer what the repo is.

优先读取低成本、高价值的信息源；仅当这些信息源不足时才深入挖掘：

主要信息源：
```
README
```
文件和项目清单文件（
```
package.json
```
、
```
pyproject.toml
```
、
```
Cargo.toml
```
、
```
go.mod
```
、
```
composer.json
```
、
```
Gemfile
```
等）：名称、现有描述/关键词、依赖项、脚本。
备用信息源：仅当上述信息源缺失或信息不足时：扫描文件目录和语言占比（
```
gh repo view --json languages
```
、浅层
```
ls
```
/
```
git ls-files
```
）推断仓库用途。

3. Generate the description and topics

3. 生成描述和主题

Description. One line, plain, specific about what the repo is/does, no trailing period, short enough for GitHub's About panel. Say what it is, not how great it is.
Topics. A focused, high-signal set (language, framework, domain, purpose), not keyword-stuffed. Enforce GitHub's format so they'll be accepted: lowercase, digits and single hyphens only, must start with a letter or number, ≤50 chars each, ≤20 topics total. Prefer widely-used topic slugs (e.g.
```
typescript
```
,
```
cli
```
,
```
github-actions
```
) so the repo surfaces under real topic pages.

描述：单行、简洁、明确说明仓库的用途/功能，无末尾句号，长度适配GitHub的About面板。说明仓库是什么，而非夸赞其优势。
主题：一组精准、高价值的标签（语言、框架、领域、用途），避免关键词堆砌。遵循GitHub的格式要求以确保可被接受：小写、仅包含数字和单个连字符、必须以字母或数字开头、每个主题≤50字符、最多20个主题。优先使用广泛认可的主题标识（如
```
typescript
```
、
```
cli
```
、
```
github-actions
```
），以便仓库能在对应主题页面展示。

4. Show current vs proposed, let the user decide per field

4. 对比当前值与建议值，让用户逐字段决策

Present a side-by-side so nothing is a surprise, and let the user accept, edit, or keep-current each field independently:

Field	Current	Proposed
Description	`old blurb`	`new blurb`
Topics	`a, b`	`a, c, d` (+ `c` , `d` ; − `b` )

Don't apply anything until the user signs off on the final values.

以并排方式展示，避免意外变更，让用户对每个字段独立选择接受、编辑或保留当前值：

字段	当前值	建议值
描述	`旧简介`	`新简介`
主题	`a, b`	`a, c, d` （新增 `c` 、 `d` ；移除 `b` ）

在用户确认最终值前，不执行任何变更。

5. Apply, echoing the commands

5. 应用变更并回显命令

On approval, write the approved values and print each command you run:

gh repo edit --description "the approved one-liner"

获得批准后，写入确认的值并打印执行的每个命令：

gh repo edit --description "批准的单行描述"

reconcile topics to the approved set:

调整主题至批准的集合：

gh repo edit --add-topic new-one --add-topic another --remove-topic dropped-one


To *replace the whole topic set* in one call instead of add/remove reconciliation, the topics API is cleaner: `gh api --method PUT repos/{owner}/{repo}/topics -f 'names[]=a' -f 'names[]=b'`. Either is fine, so pick whichever expresses the change more simply.

gh repo edit --add-topic new-one --add-topic another --remove-topic dropped-one


若要一次性替换整个主题集合而非逐个添加/移除，使用topics API更简洁：`gh api --method PUT repos/{owner}/{repo}/topics -f 'names[]=a' -f 'names[]=b'`。两种方式均可，选择更能清晰表达变更的方式即可。

6. Hand off

6. 操作收尾

Write every hand-off in this skill in the procedural register: one instruction per sentence, active voice, present tense, no metaphor.

What changed. Report the description and topics as they now stand, and anything the user chose to keep current rather than replace. A field you proposed and they rejected is worth one line; it's the part most likely to come up again.

Where it landed. Name the repo's About panel, with its URL, so they can eyeball the result.

Next. Name one move and stop. If

labels

hasn't run in this repo, that's it: the lifecycle and priority labels are what an issue workflow needs and the About panel isn't. If both modes are done, repokit is finished with this repo, so point at what the metadata unblocks (issuekit to start filing work, when installed) rather than manufacturing more configuration.

本工具的所有收尾说明均采用流程化表述：每句一个指令、主动语态、现在时态、无隐喻。

变更内容：报告当前的描述和主题，以及用户选择保留的原有内容。用户拒绝的建议字段需单独说明，这是后续可能再次提及的部分。

变更位置：告知用户仓库的About面板及其URL，方便用户查看结果。

下一步建议：给出一个明确操作后结束。若该仓库尚未运行

labels

模式，建议执行该模式：生命周期和优先级标签是工单工作流所需的，而About面板并非必需。若两种模式均已完成，repokit对该仓库的配置已完成，可提示用户元数据已准备就绪（安装issuekit后即可开始创建工单），无需额外配置。

Mode:

labels

labels

模式

Provision the issue-workflow lifecycle and priority labels so issuekit (and any workflow that reads them) has the vocabulary it expects. repokit creates and reconciles these labels; issuekit only uses them, and repokit never applies one to an issue. This mode stands alone, because both sets are useful for any issue workflow, so it never checks whether issuekit is installed before provisioning them.

配置工单工作流的生命周期和优先级标签，确保issuekit（及所有依赖这些标签的工作流）拥有预期的标签体系。repokit负责创建和调整这些标签；issuekit仅负责使用它们，repokit绝不会将标签应用到工单上。该模式独立运行，因为这两组标签对任何工单工作流都有用，因此无需检查是否已安装issuekit即可配置。

Two sets, two independent namespaces

两组独立的标签体系

The map below is really two, and keeping them apart is what makes both usable:

Lifecycle answers can this be worked?, meaning where the issue sits in the workflow.
Priority answers should this be worked next?, meaning how much it matters relative to everything else workable.

They are orthogonal: an issue carries at most one label from each, and neither implies the other.

ready

low

is a perfectly coherent issue (workable, not urgent), and so is

blocked

critical

(urgent, and that's exactly why its blocker matters). Downstream skills read them as two separate signals, so never collapse them into one ordered set.

以下标签映射实际上分为两组，保持独立是确保其可用性的关键：

生命周期标签：回答“该工单是否可处理？”，即工单在工作流中的所处阶段。
优先级标签：回答“是否应优先处理该工单？”，即该工单相对其他可处理任务的重要程度。

它们是正交的：一个工单最多携带每组中的一个标签，且彼此互不影响。

ready

low

是合理的组合（可处理、非紧急），

blocked

critical

也是合理的组合（紧急，这正是其阻塞原因至关重要的原因）。下游工具会将它们视为两个独立信号，因此绝不能将其合并为单一有序集合。

The canonical lifecycle set

标准生命周期标签集

Provision exactly this map. The

description

column here is canonical; issuekit mirrors the same names, colors, and meanings in execution-oriented wording.

name	color	description
`triage`	`FBCA04`	filed, not yet assessed or broken down
`needs-planning`	`F1C40F`	needs a human plan/grill session before it is workable
`ready`	`0E8A16`	specified and independent, safe to take into its own worktree now
`blocked`	`D93F0B`	has an unmet prerequisite (see 'Blocked by #N' in the body)
`in-progress`	`1D76DB`	actively being worked in a worktree
`in-review`	`5319E7`	a PR is open, awaiting review or merge
`needs-info`	`D4C5F9`	stalled pending more detail before it can proceed
`wontfix`	`FFFFFF`	will not be actioned
`duplicate`	`CFD3D7`	superseded by another issue

严格按照以下映射配置。此处的

description

列是标准定义；issuekit在执行逻辑中会沿用相同的名称、颜色和含义，仅表述方式更偏向执行层面。

name	color	description
`triage`	`FBCA04`	已提交，尚未评估或拆解
`needs-planning`	`F1C40F`	需要人工规划/评审后才可处理
`ready`	`0E8A16`	需求明确且独立，可立即开始处理
`blocked`	`D93F0B`	存在未满足的前置条件（请查看工单正文中的“Blocked by #N”）
`in-progress`	`1D76DB`	正在工作目录中处理
`in-review`	`5319E7`	已提交PR，等待评审或合并
`needs-info`	`D4C5F9`	因缺少信息而停滞，需补充后才可推进
`wontfix`	`FFFFFF`	不会进行处理
`duplicate`	`CFD3D7`	已被其他工单替代

The canonical priority set

标准优先级标签集

Four levels, and the colors run a deliberate hot-to-cold ramp so the family reads as one scale at a glance rather than as four unrelated labels:

name	color	description
`critical`	`B60205`	drop everything; preempts work already in progress
`high`	`E99695`	do this before other workable issues
`medium`	`FEF2C0`	normal priority, the default once assessed
`low`	`C5DEF5`	worth doing eventually; never preempts anything

Colors are 6-hex, no leading

No priority label means unassessed, not medium. The absence is a real state and downstream skills read it as one; it's how

triage

finds issues nobody has ranked yet. Never provision a default, and never treat a missing label as an implied middle.

Four levels is the ceiling, and it's already generous. The point of a priority scale is a backlog someone can order in their head; every level past the fourth is one more place for the same issue to plausibly sit, which is how a scale turns into a coin flip. If the user asks for a fifth, say what it costs before adding it.

四个级别，颜色从暖到冷渐变，让用户一眼就能识别出这是一个统一的优先级标尺，而非四个独立标签：

name	color	description
`critical`	`B60205`	暂停所有工作，优先处理该任务
`high`	`E99695`	在其他可处理工单前优先处理
`medium`	`FEF2C0`	常规优先级，评估后的默认级别
`low`	`C5DEF5`	最终需要处理，但绝不优先于其他任务

颜色为6位十六进制值，无前置

。

无优先级标签表示“未评估”，而非“medium”。缺失标签是一种真实状态，下游工具会将其视为未评估状态；这也是

triage

模式识别未排名工单的方式。绝不配置默认优先级，也绝不将缺失标签视为默认的中等优先级。

四个级别已是上限，且已足够。优先级标尺的意义在于让用户能在脑海中梳理任务队列；超过四个级别后，同一工单可能被归到多个级别，导致标尺失去意义。若用户要求添加第五个级别，需先说明其弊端再进行添加。

1. Check for an existing scheme first, in both namespaces

1. 先检查现有标签体系（两组标签均需检查）

You read the repo's labels in Detect. Before diffing, look for a different-but-equivalent scheme the repo already runs, in either namespace:

Lifecycle.
```
status: blocked
```
,
```
S-ready
```
,
```
blocked ⛔
```
, or a
```
needs-*
```
family that already covers this ground.
Priority.
```
P0
```
/
```
P1
```
/
```
P2
```
,
```
priority: high
```
,
```
pri-1
```
,
```
urgent
```
, or a
```
severity:
```
family being used as a de facto priority.

If one exists, don't silently add a parallel set (two ways to say "blocked" is worse than none, and two ways to say "urgent" is worse still, because the two will disagree). Surface it and ask which way to go:

Map onto theirs. Treat the repo's labels as canonical; skip provisioning and (optionally) note the name mapping so issuekit-style workflows can be pointed at the existing names.
Add the canonical set. The repo's scheme is incidental or abandoned; provision ours alongside it, and offer to retire the old labels only if the user explicitly asks.

Handle the namespaces independently, because a repo very often has a mature lifecycle scheme and no priority scheme at all, and the answer there is "map onto theirs for lifecycle, provision ours for priority." Asking one question about both forces a wrong answer to half of it.

Priority names collide harder than lifecycle names, so check meaning and not just spelling.

ready

and

in-review

are workflow-shaped words that mostly mean this one thing;

critical

high

, and

low

are generic English and a repo may already be using them for something else entirely: bug severity (how badly it breaks), effort or T-shirt size, risk, or a customer tier. A name match is not a meaning match. When the repo already has a

critical

high

, read its description and a couple of the issues carrying it before assuming it's the same axis, and if it turns out to be severity, say so plainly. Severity and priority are genuinely different things (a critical crash nobody hits can be

low

), so the honest fix is to name the collision and let the user decide whether to rename theirs, rename ours, or map onto it.

Absent any existing scheme in a namespace, go straight to the diff for that one.

你已在状态检测步骤中读取了仓库的标签。在对比前，先检查仓库是否已运行不同但等效的标签体系：

生命周期标签：
```
status: blocked
```
、
```
S-ready
```
、
```
blocked ⛔
```
，或已覆盖相关场景的
```
needs-*
```
系列标签。
优先级标签：
```
P0
```
/
```
P1
```
/
```
P2
```
、
```
priority: high
```
、
```
pri-1
```
、
```
urgent
```
，或被用作实际优先级的
```
severity:
```
系列标签。

若存在此类标签体系，不要静默添加并行标签集（两种方式表示“阻塞”比没有更糟，两种方式表示“紧急”更糟，因为两者会产生冲突）。需告知用户并询问处理方式：

映射到现有体系：将仓库的现有标签视为标准；跳过配置步骤（可选）记录名称映射，以便issuekit类工作流能适配现有标签名称。
添加标准标签集：仓库的现有体系是临时或已废弃的；在现有体系旁添加标准标签集，仅当用户明确要求时才提供移除旧标签的选项。

独立处理两组标签体系，因为仓库通常拥有成熟的生命周期标签体系但无优先级标签体系，此时的合理方案是“生命周期标签映射到现有体系，优先级标签配置标准集”。若将两组标签的问题合并询问，会导致其中一组的答案不合理。

优先级标签的名称冲突比生命周期标签更严重，因此需检查含义而非仅拼写。

ready

和

in-review

是工作流相关词汇，含义基本固定；

critical

、

high

和

low

是通用英文词汇，仓库可能已将其用于其他场景：bug严重程度（影响范围）、工作量或T恤尺码、风险、客户等级。名称匹配不代表含义匹配。当仓库已存在

critical

或

high

标签时，需先查看其描述和部分使用该标签的工单，再假设其与标准优先级标签含义相同；若实际是严重程度标签，需明确告知用户。严重程度和优先级是完全不同的概念（无人遇到的严重崩溃可标记为

low

优先级），因此需如实说明冲突情况，让用户决定是重命名现有标签、重命名标准标签还是进行映射。

若某组标签体系不存在现有方案，直接进入该组的对比步骤。

2. Diff against the canonical sets and preview

2. 与标准标签集对比并预览

Sort each canonical label, from both sets, into one of three buckets and show the plan before touching anything, grouped by namespace so the user can approve one and decline the other:

Missing. Not in the repo → will be created.
Drifted. Present but wrong color or description → offer to update (this rewrites the label; get an explicit OK per label or for the batch).
Matches. Present and correct → leave alone.

Labels outside the canonical sets (GitHub's defaults like

bug

enhancement

, or the repo's own) are left untouched, and you never delete a label unless the user explicitly asks.

将两组标准标签分别归入以下三类，在执行操作前展示计划，按标签体系分组以便用户分别批准或拒绝：

缺失：仓库中不存在→将创建该标签。
偏离：已存在但颜色或描述不正确→提议更新（这会重写标签；需获得用户对单个标签或批量操作的明确批准）。
匹配：已存在且符合标准→保持不变。

标准标签集之外的标签（GitHub默认标签如

bug

enhancement

，或仓库自定义标签）保持不变，除非用户明确要求，否则绝不删除任何标签。

3. Apply, echoing the commands

3. 应用变更并回显命令

On approval:

undefined

获得批准后：

undefined

create a missing label

创建缺失的标签

gh label create ready --color 0E8A16 --description "specified and independent, safe to take into its own worktree now" gh label create critical --color B60205 --description "drop everything; preempts work already in progress"

gh label create ready --color 0E8A16 --description "需求明确且独立，可立即开始处理" gh label create critical --color B60205 --description "暂停所有工作，优先处理该任务"

update a drifted label (rewrites color/description in place)

更新偏离标准的标签（原地重写颜色/描述）

gh label edit blocked --color D93F0B --description "has an unmet prerequisite (see 'Blocked by #N' in the body)"


`gh label create --force` also upserts (create-or-overwrite) if you'd rather not branch on existence, but prefer the explicit create/edit split so the preview in [Diff against the canonical sets and preview](#2-diff-against-the-canonical-sets-and-preview) stays honest about what's new versus changed.

gh label edit blocked --color D93F0B --description "存在未满足的前置条件（请查看工单正文中的'Blocked by #N'）"


`gh label create --force`也可实现创建或覆盖操作，但若想让[与标准标签集对比并预览](#2-与标准标签集对比并预览)步骤的预览如实反映新增和变更内容，建议使用明确的创建/编辑拆分方式。

4. Hand off

4. 操作收尾

What changed. Report what was created, updated, and left as-is, per namespace, and confirm which of the two sets the repo now carries in full. Provisioning one and skipping the other is a normal outcome, not a partial failure, so say which, and nobody goes looking for the missing half later.

Where it landed. Name the repo's label list. If you mapped onto an existing scheme instead of provisioning ours in either namespace, say which names won, because everything downstream now has to use those.

Next. Name one move and stop. The labels are a vocabulary, not an outcome: what they unblock is the issue workflow, so the move is to start using it, with issuekit

create

to file work from a plan, or

triage

to classify and rank issues that were sitting unlabeled while the vocabulary was missing. When the repo already had open issues and priority is the set you just provisioned,

triage

is the stronger of the two: every one of those issues is now formally unassessed, and nothing downstream can rank them until somebody says what matters. Absent issuekit, say the labels are now available to whatever issue workflow the repo runs. If

about

hasn't run yet and the repo's About panel is empty, offer that as the smaller follow-up.

变更内容：报告每组标签体系中已创建、已更新和保持不变的标签，确认仓库当前完整的标签集。仅配置其中一组标签是正常结果，而非未完成操作，需明确说明，避免用户后续寻找缺失的标签。

变更位置：告知用户仓库的标签列表。若某组标签体系选择映射到现有方案而非配置标准集，需说明最终使用的标签名称，因为下游所有工具都需使用这些名称。

下一步建议：给出一个明确操作后结束。标签是一种词汇体系，而非最终结果：它们解锁的是工单工作流，因此下一步是开始使用该体系，比如使用issuekit的

create

命令从计划创建工单，或使用

triage

命令对未标记的工单进行分类和排名。若仓库已有未处理工单且你刚配置了优先级标签集，

triage

是更合适的选择：所有这些工单现在都处于未评估状态，下游工具无法对其排名，直到有人确定其优先级。若未安装issuekit，告知用户标签已准备就绪，可用于仓库的任何工单工作流。若尚未运行

about

模式且仓库的About面板为空，可提议执行该模式作为后续操作。

Notes

注意事项

Never delete a repo's topics wholesale or its labels outside the canonical sets without an explicit ask; the default is additive and reconciling, not destructive.
The
```
labels
```
maps are a shared contract with issuekit: the same thirteen names across two namespaces, with the same colors and meanings, and repokit's descriptions canonical.
repokit provisions the vocabulary; it never applies it. No mode here ever puts a label on an issue, neither a lifecycle one nor a priority one. Deciding that #42 is
```
high
```
is a judgment about the work, which is issuekit
```
create
```
and
```
triage
```
's job; repokit only guarantees the word exists to say it with. Keeping that line is what makes this mode safe to re-run on a repo with a live tracker.
Labels can't enforce one-per-namespace, so the writer has to. GitHub will happily let an issue carry
```
critical
```
and
```
low
```
at once, and nothing here can prevent it. Provisioning is the only half repokit owns; the mutual exclusion is enforced at write time by whoever applies the label, which is why that rule lives in issuekit rather than in this map.
Defer to what the repo already curates: an existing scheme in either namespace is handled in Check for an existing scheme first, in both namespaces, and a curated About/topics is reconciled per-field (never blind-overwritten) in
```
about
```
. Offer the canonical sets as an addition, not a replacement.
Prefer
```
gh
```
's structured JSON (
```
--json
```
/
```
--jq
```
, the topics API) over scraping human-readable output, because the JSON fields are a stable contract and the display text isn't.

绝不在未获得明确要求的情况下批量删除仓库的主题或标准标签集之外的标签；默认操作是增量调整，而非破坏性修改。
```
labels
```
模式的标签映射是与issuekit的共享约定：两组标签共13个名称，拥有相同的颜色和含义，repokit的描述是标准定义。
repokit仅配置标签体系，绝不应用标签。本工具的任何模式都不会将标签应用到工单上，无论是生命周期标签还是优先级标签。判断工单#42为
```
high
```
优先级是对工作任务的决策，这是issuekit的
```
create
```
和
```
triage
```
模式的职责；repokit仅确保存在对应的标签词汇来表达该决策。保持这一界限是确保该模式可在活跃工单跟踪仓库上重复运行的关键。
标签无法强制每组仅使用一个，需由使用者自行遵守。GitHub允许工单同时携带
```
critical
```
和
```
low
```
标签，本工具无法阻止这种情况。repokit仅负责配置标签体系；互斥规则由应用标签的人员在创建时执行，因此该规则属于issuekit而非本工具的标签映射。
优先遵循仓库已有的配置：任何一组标签体系的现有方案都需在先检查现有标签体系（两组标签均需检查）步骤中处理，已有的About/主题配置需在
```
about
```
模式中逐字段对比（绝不盲目覆盖）。将标准标签集作为补充方案，而非替代方案。
优先使用gh的结构化JSON（
```
--json
```
/
```
--jq
```
、topics API）而非解析人类可读的输出，因为JSON字段是稳定的约定，而显示文本可能变化。