rfc

name	rfc
description	提交 RFC 到 memex GitHub。入参可以是：(A) RFC 文件路径（相对或绝对均可）；(B) 一段文字描述——此时自动起草 RFC 文件、保存到 ref/rfc/、再提交 issue。

/rfc — 提交 RFC 到 memex GitHub

用途

子 wiki 发现 memex 主系统问题后，用 /rfc <路径> 或 /rfc <文字描述> 一键将其提交为 GitHub issue。

模式判断

收到参数后，先判断输入类型：

• 文件路径模式：参数是一个存在的文件路径（用 test -f <参数> 验证）→ 跳至步骤 1（读取文件）
• 文字描述模式：参数不是文件路径（或未提供参数，改由用户在提示后输入描述）→ 跳至步骤 0（起草文件）

---

步骤 0（仅文字描述模式）：起草 RFC 文件

0.1 推断 wiki 名与下一个编号

# 当前 wiki 名（取 CLAUDE.md 中 Source wiki 字段，或从目录名推断）
WIKI=$(basename $(git rev-parse --show-toplevel))

# 找下一个 RFC 编号
ls ref/rfc/rfc-${WIKI}-*.md 2>/dev/null | grep -oP '\d{4}' | sort -n | tail -1

若目录为空，编号从 0001 开始；否则取最大值 +1，零填充为四位。

0.2 生成 slug

从描述文字中提取 3-5 个关键英文词（或拼音首字母），拼成 kebab-case slug。

示例：描述"search.html 标题硬编码了项目名"→ slug search-html-hardcoded-title

0.3 起草文件内容

按以下模板，用描述文字填充各节。Problem 节直接使用用户描述；Root cause 和 Proposed change 节由 Claude 根据描述合理推断，并在文件中注明"（待补充）"若有不确定之处。

# RFC-<WIKI>-<NNNN>: <标题>

- **Status**: proposed
- **Date**: <今日日期 YYYY-MM-DD>
- **Issue**:
- **Source wiki**: <wiki>
- **Target**: <推断的 memex 目标路径，若不确定写 TBD>

---

## Problem

<用户描述的问题，适当整理为散文>

## Root cause

<推断的根因>

## Proposed change

<建议的修改方案>

0.4 写入文件并展示

文件路径：ref/rfc/rfc-<WIKI>-<NNNN>-<slug>.md

用 Write 工具写入（先确认 ref/rfc/ 目录存在，不存在则 mkdir -p ref/rfc/）。

展示文件内容，询问用户：「草稿如上，是否直接提交 issue？还是先修改？」

• 用户确认继续 → 以此文件路径进入步骤 1
• 用户要求修改 → 按反馈修改后再询问

---

执行步骤（文件路径模式从此开始）

1. 读取 RFC 文件

用 Read 工具读取参数指定的文件（如 ref/rfc/rfc-aima-0001-remove-data-from-gitignore-template.md）。

提取以下字段：

• # RFC-<wiki>-NNNN: <标题> — 从第一行 H1 标题解析（如 RFC-aima-0001）
• Source wiki — 来源 wiki 名
• Target — 目标 memex 文件
• Status — 当前状态（必须是 proposed 才继续，否则告知用户已处理过）
• Issue — 若已有 issue URL，说明已提交过，询问用户是否重复提交
• ## Problem 节内容 — 问题摘要
• ## Proposed change 节内容 — 建议修改

1.5 验证 RFC 编号

在当前 wiki 目录执行：

ls ref/rfc/rfc-<wiki>-*.md 2>/dev/null | sort

其中 <wiki> 从上一步的 Source wiki 字段提取。

1. 提取所有现有文件名中的 NNNN，找到最大编号 MAX
2. 若目录为空（首个 RFC），则 MAX = 0，期望编号为 0001
3. 将 RFC 文件名和 H1 标题中的编号与 MAX+1 对比：
   • 一致 → 通过，继续
   • 不一致 → 显示差异：当前编号 XXXX，建议编号 YYYY（MAX+1）
     • 询问用户是否修正：
       • 用户确认 → 自动重命名文件并更新文件内 H1 标题和 RFC ID，再继续
       • 用户拒绝 → 终止流程，提示编号冲突风险

注意：不同 wiki 有各自独立的编号空间（rfc-aima-NNNN vs rfc-shiji-NNNN），不共用。

2. 推导 RFC 文件的 GitHub 可读链接

在当前 wiki 目录执行：

git remote get-url origin

将 remote URL 转换为 GitHub blob 链接：

• https://github.com/USER/REPO.git 或 https://github.com/USER/REPO → https://github.com/USER/REPO/blob/main/<RFC文件相对路径>
• [e-mail]:USER/REPO.git → 同上转换

RFC 文件相对路径 = 从 repo 根目录到文件的路径（如 ref/rfc/0001-slug.md）。

若 remote 不可用或非 GitHub，则在 issue 中只写文件路径，不加链接。

3. 构造 issue 内容

标题格式：[<wiki>] RFC-<wiki>-<NNNN>: <标题>（如 [aima] RFC-aima-0001: ...）

正文格式：

## 来源
Wiki: <source_wiki>
RFC 文件: [ref/rfc/NNNN-slug.md](<GitHub blob 链接>)
Target: <target>

## 问题摘要
<Problem 节的前3-5句话>

## 建议
<Proposed change 节的核心内容（含 diff 如果有）>

---
详见 RFC 文件。

4. 创建 GitHub issue

gh issue create \
  --repo baojie/memex \
  --title "[<wiki>] RFC-<NNNN>: <标题>" \
  --body "<正文>"

记录返回的 issue URL。

5. 将 issue URL 写回 RFC 文件

在 RFC 文件的 - **Target**: ... 行之后（或 Status/Date 块末尾），插入：

- **Issue**: <issue URL>

用 Edit 工具修改文件（必须先 Read，本 skill 第 1 步已读过，可直接 Edit）。

6. 提交 RFC 文件更新

git add ref/rfc/<RFC文件名>.md
bash wiki/scripts/skill_commit.sh -m "docs(rfc): <RFC-ID> 添加 issue 链接"

7. 输出确认

告知用户：

• Issue 已建：<issue URL>
• RFC 文件已更新 Issue 字段并提交
• 下一步：等待 memex 维护者审阅

铁律

• 只处理 status: proposed 的 RFC；其他状态告知用户跳过原因
• 不自动修改 RFC 的 Status 字段——status 由 memex 维护者在接受/拒绝时更新
• issue 创建前展示标题和正文草稿，询问用户确认后再执行 gh issue create
• 目标 repo 固定为 baojie/memex，不接受其他 repo