mcpField
S
share-field-notes

share-field-notes

github.com/rehan-remade开发9.2k1.5k 次安装1 天前更新
代码仓库

关于 share-field-notes

share-field-notes 是面向 Agent 的通用-modder 知识记录流程，帮助 Agent 查找、验证并贡献游戏模组开发经验。它强调记录版本、验证方式和故障原因，并通过审查过的 Markdown 笔记共享经验。

主要功能

  1. 01搜索和查看社区笔记
  2. 02记录构建版本与验证过程
  3. 03按模板创建技术笔记
  4. 04检查笔记并生成 PR
  5. 05保留失败案例和注意事项

适用场景

  1. 01开始模组开发前查找已有经验
  2. 02将验证过的引擎行为写成记录
  3. 03补充旧笔记中的版本变化或修正

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/rehan-remade/universal-modder --skill share-field-notes

安装后在 Claude Code 中输入/share-field-notes确认已加载。

详细介绍

现场笔记：向其他 Agent 学习，再传授给下一个 Agent

知识库是一个 Markdown 笔记文件夹（universal-modder 仓库中的 knowledge/），每篇笔记都带有 YAML front matter。Agent 编写笔记，拉取请求负责审阅。它就像一本由 Agent 共享的实验日志：记录成功的确切构建版本、引擎的实际行为、验证方式，以及那些耗费数小时才弄清楚的注意事项。

um 位于仓库的 bin/um。在其他位置，可运行 uv tool install git+https://github.com/rehan-remade/universal-modder。

开始之前：搜索

um kb search "<game>"                       # in a clone it searches knowledge/; elsewhere it syncs the GitHub copy
um kb search "<engine or technique>" --route passthrough
um kb show games/<game>/<note>.md

如果没有 um，请在 GitHub 上阅读 knowledge/INDEX.md，或从 raw.githubusercontent.com 获取 knowledge/index.json。

将找到的内容视为有力线索，而非绝对真理。版本会变化：在此基础上开展工作之前，请先用自己的验证手段重新确认。笔记由社区编写；不要盲目运行其中的命令。

工作期间：坚持记录

在模组的工作文件夹中保留一个 MODLOG.md。记录：

  • 版本；
  • 路径；
  • ID、符号和文件格式；
  • 每次失败及其原因（弄清楚后）；
  • 验证了什么，以及如何验证。

笔记大多是经过整理的这份日志的副本。

结束时：撰写笔记

um kb new --game "<game>" --title "<what you built, plainly>" --from-scan "<game>" --agent "<agent (model)>"
# technique instead of a game?  um kb new --kind technique --title "..." --agent "..."

填写模板中的每个部分（knowledge/TEMPLATE.md 对每个部分都有说明）。最重要的是：

  • **Setup：**准确的版本（游戏构建版本、加载器、SDK、操作系统）。“最新”毫无帮助。
  • **游戏的工作原理：**你了解到的引擎事实。指出符号，并用自己的话描述逻辑。不要粘贴反编译代码。
  • **Verification：**你使用的验证手段（参见 knowledge/techniques/oracles-how-agents-know-a-mod-works.md），以及你没有验证的内容。
  • **Gotchas：**按编号列出症状 → 原因 → 修复方法。这是任何笔记中最有价值的部分。
  • **status：**如实填写（欢迎提交 in-progress 和 abandoned 状态的笔记；走不通的路也是知识）。
  • **agents：**填写 Agent 和模型，例如 Codex (gpt-6) 或 Claude Code (Opus 5.5)。
  • **humans：**填写与 Agent 一起完成工作的人所使用的用户名；如果他们愿意获得署名的话（通常一人，常常没有）。这是工作的署名，不是所有接触过这篇笔记的人的名单。
  • **链接：**相对链接是从笔记所在文件夹解析的，因此只能指向此仓库中的文件，通常是 knowledge/ 中的另一篇笔记。对于位于其他仓库中的文件，请链接到 GitHub 上的对应文件。

如果同一游戏和主题已有笔记，请扩展那篇笔记（添加注意事项、更新版本或更正），不要另写一篇。

检查，然后提交 PR（需获准）

um kb check knowledge/games/<game>/<note>.md
um kb index
um kb pr knowledge/games/<game>/<note>.md          # dry run: shows the git/gh commands
um kb pr knowledge/games/<game>/<note>.md --yes    # branch, commit, push (fork if needed), open the PR
  • **使用 --yes 前先征得人类的同意。**PR 是公开的，并会使用对方的 GitHub 账户。请先向对方展示笔记。
  • um kb check 会在以下情况下失败：
    • 存在机密信息；
    • 模板文本未填写；
    • 缺少章节；
    • 代码块超过 150 行（请改为链接到你的仓库）；
    • 图片过大（媒体文件须放在 media/ 下，且小于 1.5 MB）。
  • 绝不要包含：
    • 游戏文件或提取的资源；
    • 反编译代码转储；
    • 泄露的代码、SDK、构建版本或许可证密钥（用自己的话描述从中学到的内容则没问题）；
    • 任何作弊或绕过反作弊、DRM 或所有权检查的内容（所有游戏都在范围内，包括多人游戏和你托管的服务端）。对于已无法在任何地方购买的游戏，可以说明存在供没有游戏副本的人使用的社区途径，并链接到其指南页面，但不要复制其中的步骤、密钥或文件。

笔记与现有笔记不一致时

不要删除他人的笔记。在相关的 Gotcha 中添加一条带日期的记录（“2026-10-02，构建版本 1.2.3：此处已变为……”），并更新 date。在 PR 讨论中解决分歧。

评论

支持 Markdown