setup-leandrocfe-skills

配置 leandrocfe Skills

为 engineering skills 所依赖的按仓库配置搭建脚手架：

• Issue 跟踪器 — issue 所在的位置（默认使用 GitHub；也开箱支持本地 Markdown）
• 分流标签 — 用于五种规范分流角色的字符串
• 领域文档 — CONTEXT.md 和 ADR 的存放位置，以及读取它们的使用规则

这是一项由提示词驱动的 skill，而非确定性脚本。先探索并介绍发现的内容，与用户确认后再写入。

流程

1. 探索

检查当前仓库，了解初始状态。读取现有内容；不要想当然：

• 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 issue 跟踪约定的迹象
• 是否已安装 triage skill？（与此 skill 并列的 triage skill 文件夹，或可用 skills 中的 triage。）这决定是否运行 B 节。
• monorepo 迹象 — pnpm-workspace.yaml、package.json 中的 workspaces 字段，或包含自身 src/ 的非空 packages/*。只有在真正大型的多包仓库中才会出现；如果不存在这些迹象，就意味着是单一上下文，这适用于绝大多数仓库。

2. 展示发现并提问

总结已有内容和缺失内容。然后按顺序逐节进行——每次一节，得到回答后再进行下一节。

每节先给出推荐答案，让用户可以用一个词接受。只有在选项确实会导致不同分支时，才用一句话说明；如果探索已解决该问题，就跳过整节（未安装 triage 时跳过 B 节；没有 monorepo 时跳过 C 节）。

A 节——Issue 跟踪工具。

说明：这里的“issue 跟踪工具”是指这个仓库中存放 issue 的地方。to-tickets、triage 和 to-spec 等技能会在其中读取和写入内容——它们需要知道是调用 gh issue create、在 .scratch/ 下写入 markdown，还是遵循你描述的其他工作流。请选择你实际用来跟踪该仓库工作事项的地方。

默认建议：这些技能是为 GitHub 设计的。如果某个 git remote 指向 GitHub，就推荐 GitHub。如果某个 git remote 指向 GitLab（gitlab.com 或自托管主机），就推荐 GitLab。否则（或用户有其他偏好时），提供以下选项：

• GitHub — issue 存放在仓库的 GitHub Issues 中（使用 CLI gh）
• GitLab — issue 存放在仓库的 GitLab Issues 中（使用 CLI glab）
• 本地 Markdown — issue 作为文件存放在此仓库的 .scratch/<feature>/ 下（适用于个人项目或没有 remote 的仓库）
• 其他（Jira、Linear 等）— 请用户用一段话描述工作流；技能会以自由文本的形式记录

将选择记录在 docs/agents/issue-tracker.md 中。GitHub 和 GitLab 模板都包含一个“将 PR 作为请求入口”的标志，默认值为 off——保持关闭，不要提起；如果用户希望将外部 PR 纳入 triage 队列，之后可以在文件中打开该标志。

B 节——Triage 标签词汇表。 如果未安装 triage 技能（探索已告知你），则跳过整节——未安装的技能不需要标签。

如果已安装，只问一个问题：

你想保留默认的 triage 标签吗？（推荐：是）

默认值是五个规范角色，每个标签字符串都与角色名称相同：needs-triage、needs-info、ready-for-agent、ready-for-human、wontfix。如果回答是，就按原样写入。只有用户回答否时——通常是因为其跟踪工具已使用其他名称（例如，用 bug:triage 对应 needs-triage）——才收集覆盖值，让 triage 应用已有标签，而不是创建重复标签。

C 节——领域文档。 默认使用 single-context——在仓库根目录放置一个 CONTEXT.md 和一个 docs/adr/。这适用于几乎所有仓库；直接写入，无需提问。

只有在探索发现 monorepo 迹象时，才提供 multi-context——在根目录放置一个 CONTEXT-MAP.md，指向各上下文对应的 CONTEXT.md 文件。此时再确认用户想要哪种布局。

3. 确认并编辑

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

• 要添加到正在编辑的 CLAUDE.md / AGENTS.md 文件中任意一个的 ## Agent skills 区块（选择规则见第 4 步）
• docs/agents/issue-tracker.md、docs/agents/domain.md 和 docs/agents/triage-labels.md 的内容（仅在已安装 triage 时提供最后一个文件）

写入前让用户先行编辑。

4. 编写

选择要编辑的文件：

• 如果存在 CLAUDE.md，则编辑它。
• 否则，如果存在 AGENTS.md，则编辑它。
• 如果两者都不存在，询问用户要创建哪个文件——不要替用户做决定。

如果 CLAUDE.md 已存在，绝不要创建 AGENTS.md（反之亦然）——始终编辑已有文件。

如果所选文件中已存在 ## Agent skills 区块，就地更新其内容，而不是追加重复内容。不要覆盖周围各节中用户所做的编辑。

该区块：

## Agent skills

### Issue tracker

[resumo de uma linha de onde issues são rastreadas]. Veja `docs/agents/issue-tracker.md`.

### Triage labels

[resumo de uma linha do vocabulário de labels]. Veja `docs/agents/triage-labels.md`.

### Domain docs

[resumo de uma linha do layout — "single-context" ou "multi-context"]. Veja `docs/agents/domain.md`.

只有在已安装 triage 且已运行 B 节时，才包含 ### Triage labels 子区块并编写 docs/agents/triage-labels.md。如果未安装，则省略两者。

接下来，使用此技能目录中的模板种子文件作为起点，编写文档文件：

• issue-tracker-github.md — GitHub issue 跟踪器
• issue-tracker-gitlab.md — GitLab issue 跟踪器
• issue-tracker-local.md — 本地 Markdown issue 跟踪器
• triage-labels.md — 标签映射（仅在已安装 triage 时）
• domain.md — 领域文档使用者规则和目录布局

对于“other”issue 跟踪器，根据用户的描述从头编写 docs/agents/issue-tracker.md。

5. 完成

告知用户设置已完成，以及现在会从这些文件中读取信息的工程技能。说明用户之后可以直接编辑 docs/agents/*.md——只有在想更换 issue 跟踪器或从头开始时，才需要重新运行此技能。