setup-luizrocha-skills

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Setup Luiz Rocha's Skills

设置Luiz Rocha的Skills

Scaffold the per-repo configuration that the engineering skills assume:

Issue tracker — where issues live (GitHub by default; local markdown is also supported out of the box)
Triage labels — the strings used for the five canonical triage roles
Domain docs — where
```
CONTEXT.md
```
and ADRs live, and the consumer rules for reading them

This is a prompt-driven skill, not a deterministic script. Explore, present what you found, confirm with the user, then write.

搭建工程类Skill所需的仓库专属配置：

问题追踪器 —— 存储问题的位置（默认是GitHub；也原生支持本地Markdown）
分类标签 —— 用于五个标准分类角色的字符串
领域文档 ——
```
CONTEXT.md
```
和ADR的存储位置，以及读取它们的规则

这是一个由提示驱动的Skill，而非确定性脚本。流程为：探索仓库、展示发现结果、与用户确认、然后完成写入。

Process

流程

1. Explore

1. 探索

Look at the current repo to understand its starting state. Read whatever exists; don't assume:

```
git remote -v
```
and
```
.git/config
```
— is this a GitHub repo? Which one?
```
AGENTS.md
```
and
```
CLAUDE.md
```
at the repo root — does either exist? Is there already an
```
## Agent skills
```
section in either?
```
CONTEXT.md
```
and
```
CONTEXT-MAP.md
```
at the repo root
```
docs/adr/
```
and any
```
src/*/docs/adr/
```
directories
```
docs/agents/
```
— does this skill's prior output already exist?
```
.scratch/
```
— sign that a local-markdown issue tracker convention is already in use

查看当前仓库以了解初始状态。读取所有已存在的内容，不要做假设：

```
git remote -v
```
和
```
.git/config
```
—— 这是GitHub仓库吗？具体是哪一个？
仓库根目录下的
```
AGENTS.md
```
和
```
CLAUDE.md
```
—— 两者是否存在？其中是否已有
```
## Agent skills
```
章节？
仓库根目录下的
```
CONTEXT.md
```
和
```
CONTEXT-MAP.md
```
```
docs/adr/
```
以及任何
```
src/*/docs/adr/
```
目录
```
docs/agents/
```
—— 本Skill之前的输出是否已存在？
```
.scratch/
```
—— 表明已在使用本地Markdown问题追踪器的标志

2. Present findings and ask

2. 展示发现并询问

Summarise what's present and what's missing. Then walk the user through the three decisions one at a time — present a section, get the user's answer, then move to the next. Don't dump all three at once.

Assume the user does not know what these terms mean. Each section starts with a short explainer (what it is, why these skills need it, what changes if they pick differently). Then show the choices and the default.

Section A — Issue tracker.

Explainer: The "issue tracker" is where issues live for this repo. Skills like
to-issues
,
triage
, and
to-prd
read from and write to it — they need to know whether to call
gh issue create
, write a markdown file under
.scratch/
, or follow some other workflow you describe. Pick the place you actually track work for this repo.

Default posture: these skills were designed for GitHub. If a

git remote

points at GitHub, propose that. If a

git remote

points at GitLab (

gitlab.com

or a self-hosted host), propose GitLab. Otherwise (or if the user prefers), offer:

GitHub — issues live in the repo's GitHub Issues (uses the
```
gh
```
CLI)
GitLab — issues live in the repo's GitLab Issues (uses the
```
glab
```
CLI)
Local markdown — issues live as files under
```
.scratch/<feature>/
```
in this repo (good for solo projects or repos without a remote)
Other (Jira, Linear, etc.) — ask the user to describe the workflow in one paragraph; the skill will record it as freeform prose

Section B — Triage label vocabulary.

Explainer: When the
triage
skill processes an incoming issue, it moves it through a state machine — needs evaluation, waiting on reporter, ready for an AFK agent to pick up, ready for a human, or won't fix. To do that, it needs to apply labels (or the equivalent in your issue tracker) that match strings you've actually configured. If your repo already uses different label names (e.g.
bug:triage
instead of
needs-triage
), map them here so the skill applies the right ones instead of creating duplicates.

The five canonical roles:

```
needs-triage
```
— maintainer needs to evaluate
```
needs-info
```
— waiting on reporter
```
ready-for-agent
```
— fully specified, AFK-ready (an agent can pick it up with no human context)
```
ready-for-human
```
— needs human implementation
```
wontfix
```
— will not be actioned

Default: each role's string equals its name. Ask the user if they want to override any. If their issue tracker has no existing labels, the defaults are fine.

Section C — Domain docs.

Explainer: Some skills (
improve-codebase-architecture
,
diagnose
,
tdd
) read a
CONTEXT.md
file to learn the project's domain language, and
docs/adr/
for past architectural decisions. They need to know whether the repo has one global context or multiple (e.g. a monorepo with separate frontend/backend contexts) so they look in the right place.

Confirm the layout:

Single-context — one
```
CONTEXT.md
```
+
```
docs/adr/
```
at the repo root. Most repos are this.
Multi-context —
```
CONTEXT-MAP.md
```
at the root pointing to per-context
```
CONTEXT.md
```
files (typically a monorepo).

总结已存在的内容和缺失的部分。然后逐个引导用户完成三个决策——展示一个部分，获取用户的答案，再进入下一个部分。不要一次性抛出所有三个问题。

假设用户不了解这些术语的含义。每个部分都以简短的解释开头（是什么、这些Skill为什么需要它、选择不同选项会有什么变化）。然后展示选项和默认值。

A部分 —— 问题追踪器

解释：“问题追踪器”是本仓库存储问题的地方。
to-issues
、
triage
和
to-prd
等Skill会从中读取内容并向其写入内容——它们需要知道是调用
gh issue create
、在
.scratch/
下写入Markdown文件，还是遵循您描述的其他工作流程。请选择您实际用于追踪本仓库工作的位置。

默认设置：这些Skill是为GitHub设计的。如果

git remote

指向GitHub，则推荐使用GitHub。如果

git remote

指向GitLab（

gitlab.com

或自托管实例），则推荐使用GitLab。否则（或用户偏好其他选项），提供以下选择：

GitHub —— 问题存储在仓库的GitHub Issues中（使用
```
gh
```
CLI）
GitLab —— 问题存储在仓库的GitLab Issues中（使用
```
glab
```
CLI）
本地Markdown —— 问题作为文件存储在本仓库的
```
.scratch/<feature>/
```
目录下（适合个人项目或无远程仓库的项目）
其他（Jira、Linear等）—— 请用户用一段文字描述工作流程；本Skill会将其作为自由格式文本记录下来

B部分 —— 分类标签词汇

解释：当
triage
Skill处理新问题时，它会通过一个状态机来推进问题状态——需要评估、等待报告者回复、准备好由AFK agent接手、准备好由人类处理、或不会修复。要实现这一点，它需要应用与您实际配置的字符串匹配的标签（或问题追踪器中的等效项）。如果您的仓库已经使用不同的标签名称（例如
bug:triage
而非
needs-triage
），请在此处映射它们，以便Skill应用正确的标签而非创建重复标签。

五个标准角色：

```
needs-triage
```
—— 需要维护者评估
```
needs-info
```
—— 等待报告者回复
```
ready-for-agent
```
—— 完全明确，可由AFK agent接手（无需人工上下文即可处理）
```
ready-for-human
```
—— 需要人工实现
```
wontfix
```
—— 不会采取行动

默认值：每个角色的字符串与其名称一致。询问用户是否要覆盖任何默认值。如果您的问题追踪器没有现有标签，使用默认值即可。

C部分 —— 领域文档

解释：部分Skill（
improve-codebase-architecture
、
diagnose
、
tdd
）会读取
CONTEXT.md
文件以了解项目的领域语言，并读取
docs/adr/
以获取过往的架构决策。它们需要知道仓库是采用单一全局上下文还是多上下文（例如包含独立前端/后端上下文的单体仓库），以便在正确的位置查找内容。

确认布局：

单一上下文 —— 仓库根目录下有一个
```
CONTEXT.md
```
+
```
docs/adr/
```
。大多数仓库属于此类。
多上下文 —— 根目录下的
```
CONTEXT-MAP.md
```
指向各个上下文对应的
```
CONTEXT.md
```
文件（通常是单体仓库）。

3. Confirm and edit

3. 确认并编辑

Show the user a draft of:

The
```
## Agent skills
```
block to add to whichever of
```
CLAUDE.md
```
/
```
AGENTS.md
```
is being edited (see step 4 for selection rules)

The contents of

docs/agents/issue-tracker.md

docs/agents/triage-labels.md

docs/agents/domain.md

Let them edit before writing.

向用户展示以下内容的草稿：

要添加到
```
CLAUDE.md
```
/
```
AGENTS.md
```
中任一文件的
```
## Agent skills
```
区块（选择规则见步骤4）

docs/agents/issue-tracker.md

、

docs/agents/triage-labels.md

、

docs/agents/domain.md

的内容

在写入前允许用户编辑。

4. Write

4. 写入

Pick the file to edit:

If
```
CLAUDE.md
```
exists, edit it.
Else if
```
AGENTS.md
```
exists, edit it.
If neither exists, ask the user which one to create — don't pick for them.

Never create

AGENTS.md

when

CLAUDE.md

already exists (or vice versa) — always edit the one that's already there.

If an

## Agent skills

block already exists in the chosen file, update its contents in-place rather than appending a duplicate. Don't overwrite user edits to the surrounding sections.

The block:

markdown

undefined

选择要编辑的文件：

如果
```
CLAUDE.md
```
存在，则编辑它。
否则如果
```
AGENTS.md
```
存在，则编辑它。
如果两者都不存在，请询问用户要创建哪一个——不要自行选择。

当

CLAUDE.md

已存在时，切勿创建

AGENTS.md

（反之亦然）——始终编辑已存在的文件。

如果所选文件中已存在

## Agent skills

区块，请原地更新其内容，而非追加重复区块。不要覆盖用户对周边章节的编辑。

区块内容如下：

markdown

undefined

Agent skills

Issue tracker

[one-line summary of where issues are tracked]. See

docs/agents/issue-tracker.md

[问题追踪位置的一行摘要]。详见

docs/agents/issue-tracker.md

。

Triage labels

[one-line summary of the label vocabulary]. See

docs/agents/triage-labels.md

[标签词汇的一行摘要]。详见

docs/agents/triage-labels.md

。

Domain docs

[one-line summary of layout — "single-context" or "multi-context"]. See

docs/agents/domain.md


Then write the three docs files using the seed templates in this skill folder as a starting point:

- [issue-tracker-github.md](./issue-tracker-github.md) — GitHub issue tracker
- [issue-tracker-gitlab.md](./issue-tracker-gitlab.md) — GitLab issue tracker
- [issue-tracker-local.md](./issue-tracker-local.md) — local-markdown issue tracker
- [triage-labels.md](./triage-labels.md) — label mapping
- [domain.md](./domain.md) — domain doc consumer rules + layout

For "other" issue trackers, write `docs/agents/issue-tracker.md` from scratch using the user's description.

[布局的一行摘要——“single-context”或“multi-context”]。详见

docs/agents/domain.md

。


然后以本Skill文件夹中的种子模板为起点，写入三个文档文件：

- [issue-tracker-github.md](./issue-tracker-github.md) —— GitHub问题追踪器模板
- [issue-tracker-gitlab.md](./issue-tracker-gitlab.md) —— GitLab问题追踪器模板
- [issue-tracker-local.md](./issue-tracker-local.md) —— 本地Markdown问题追踪器模板
- [triage-labels.md](./triage-labels.md) —— 标签映射模板
- [domain.md](./domain.md) —— 领域文档读取规则 + 布局模板

对于“其他”类型的问题追踪器，根据用户的描述从头编写`docs/agents/issue-tracker.md`。

5. Done

5. 完成

Tell the user the setup is complete and which engineering skills will now read from these files. Mention they can edit

docs/agents/*.md

directly later — re-running this skill is only necessary if they want to switch issue trackers or restart from scratch.

告知用户设置已完成，以及哪些工程类Skill将从此读取文件。提醒用户之后可以直接编辑

docs/agents/*.md

——只有当他们想要切换问题追踪器或从头开始重新配置时，才需要重新运行本Skill。