| 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=$(basename $(git rev-parse --show-toplevel))
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 字段提取。
- 提取所有现有文件名中的 NNNN，找到最大编号
MAX
- 若目录为空（首个 RFC），则
MAX = 0，期望编号为 0001
- 将 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文件相对路径>git@github.com: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
