开发文档AI 编程Codex · Skills

ONE SOURCE · MANY PROJECTS

让 Skill 跨项目生长自定义源码目录
本地迭代与 GitHub 同步

把反复使用的方法沉淀为独立资产:在自己的仓库中维护,通过用户级入口供不同项目调用,让每一次有效改进都有记录、能同步。

2026.09.286 个步骤macOS / Linux 命令示例
一份 skill 源码连接多个项目与 GitHub本地 Git 仓库通过软链接进入用户级 skills 目录,项目 A 和 B 都读取它;提交通过 push 和 pull 在 GitHub 与本机间同步。 SKILL DEVELOPMENT LOOP 本地 Git 仓库skills/technical-writing GitHub版本与同步 pushpull 软链接 · 读取同一份文件 用户级发现入口~/.agents/skills/technical-writing 项目 A · 项目约定项目 B · 项目约定
源码只有一份。项目提供上下文,Git 保存演进过程。
01 /

结论先行

Skill 源码目录可以自己选;自动发现入口需要遵循 Codex 的目录约定。推荐把源码放入独立 Git 仓库,再将单个 skill 文件夹软链接到 ~/.agents/skills/。

SOURCE

独立维护

源码脱离某个业务仓库,修改、评审和版本记录集中进行。

DISCOVERY

跨项目可用

用户级入口指向源码,切换项目仍能使用同一个 skill。

SYNC

按需同步

本地先验证改进,再提交并推送;其他电脑拉取后采用新内容。

官方依据:OpenAI · 本地 skill 加载位置列出用户级 $HOME/.agents/skills,并明确支持 skill 文件夹软链接。
本文解决个人跨项目使用与源码同步

适用于能访问这些本地文件的 Codex 环境。若要让其他人通过安装入口分发使用,可以再封装为 plugin;见 官方插件打包文档。

02 /

问题背景

在项目 A 里整理出一套写文档的方法后,项目 B 也需要使用。如果每个项目各复制一份,修正一次流程就要到处同步;不同副本还可能逐渐出现差异。把方法放到个人目录能扩大使用范围,但还需要一个便于编辑、回看历史和跨电脑同步的源码仓库。

因此,需要把维护源码的位置与Codex 找到 skill 的入口连接起来。软链接相当于文件系统中的指针:从发现入口打开文件,实际读取的是源码目录内的文件。

源码仓库
你在编辑器中打开的独立项目,保存 SKILL.md 和配套资源。
发现入口
让 Codex 找到 skill 的目录;它可以只放一个指向源码的链接。
项目约定
当前业务仓库的输出路径、模板、命令和交付要求。
版本同步
用 Git 记录修改,通过 GitHub 在多台电脑间传递提交。

下面以通用写作 skill technical-writing 为例。示例仓库名 my-skills、GitHub 所有者 YOUR_ACCOUNT 都是占位值,按自己的情况替换。

03 /

详细内容

STEP 01确定源码与发现入口

目录职责与使用范围
目录用途本文建议
~/workspace/my-skills/自己选定的源码仓库在这里编辑、提交、推送;放在业务仓库之外。
~/.agents/skills/用户级 skill 入口为需要跨项目使用的 skill 建立链接。
项目/.agents/skills/项目相关的 skill 入口保留只适用于该项目的工作流程。

项目范围内,Codex 会沿当前工作目录向上扫描到仓库根目录的 .agents/skills。本地出现 ~/.codex/skills 或插件缓存目录,并不意味着它们适合直接充当你的源码仓库;新建个人入口时,按当前官方文档采用 ~/.agents/skills。

建议布局 · 配套目录按需增加
~/workspace/my-skills/                 # Git 仓库
└── skills/
    └── technical-writing/
        ├── SKILL.md                   # 必需
        ├── references/                # 可选:参考规范
        ├── scripts/                   # 可选:确定性操作
        └── assets/                    # 可选:模板与素材

~/.agents/skills/
└── technical-writing
    → ~/workspace/my-skills/skills/technical-writing

一个仓库可以维护多个 skill,每个 skill 对应独立文件夹。链接应指向包含 SKILL.md 的文件夹。

配置中的 path 需要看它的用途

skills.config 在官方配置参考中用于单个 skill 的启用/禁用控制。不能仅凭它带有 path 字段,就将其理解为任意目录扫描配置。本文使用有明确文档支持的软链接方案。

依据:加载位置 · 配置参考中的 skills.config。

STEP 02创建一个最小可用 skill

以下命令假设 ~/workspace/my-skills 是新建的独立仓库,终端使用 macOS / Linux 的 Bash 或 Zsh。先创建目录并初始化 Git:

首次创建 · 在终端执行
mkdir -p "$HOME/workspace/my-skills/skills/technical-writing"
git -C "$HOME/workspace/my-skills" init -b main

随后在编辑器中创建 skills/technical-writing/SKILL.md。下面是本文设计的可复用起点:

skills/technical-writing/SKILL.md
---
name: technical-writing
description: 将工程讨论、实现方案或排查经验整理为技术文档;用户要求写文档、写文章或沉淀实践时使用,遵循当前项目的格式与发布约定。
---

# 技术文档编写

1. 读取当前任务适用的 AGENTS.md,确认输出格式、目录、
   文章模板与目录登记要求;用户的明确要求优先。
2. 读取项目指定的规范与范例。缺少必要信息时,先检查现有
   文档结构;仍无法确定的交付位置或格式,再询问用户。
3. 区分已验证事实、方案建议和示例。涉及工具机制、版本或
   配置时核对官方资料,并给出支持关键结论的链接。
4. 按项目模板组织内容;项目未约定结构时,可采用
   “结论、背景、操作步骤、验证方式、参考资料”。
5. 检查命令、路径和示例是否前后一致,并将敏感信息替换为
   通用占位符。仅在项目要求时维护文档目录与多语言入口。
6. 核对成品结构和相关链接;有视觉要求时检查展示效果。
   报告交付文件、验证结果与仍需处理的问题。

name 和 description 是必需的元数据;触发描述应写清任务范围。参考规范、脚本和模板可按需要增加,并从正文链接到它们。这里无需预先创建空目录。

格式依据:OpenAI · Build skills。以上具体写作流程是本文示例。

STEP 04推送到 GitHub,并在其他电脑同步

先在 GitHub 创建一个空的 my-skills 仓库。采用下面的首次推送流程时,远端先不初始化 README 等文件。把 YOUR_ACCOUNT 替换为实际所有者,并完成 GitHub 的 Git 身份认证。

首次提交与推送 · 每一步成功后再执行下一步
cd "$HOME/workspace/my-skills"
git status --short
git add skills/technical-writing/SKILL.md
git diff --cached
git commit -m "feat: add reusable technical-writing skill"
git remote add origin https://github.com/YOUR_ACCOUNT/my-skills.git
git push -u origin main

这里提交的是实际 skill 文件。用户级软链接是本机安装入口,不需要放进源码仓库。如果源码来自已有 GitHub 仓库,直接 clone,再建立链接即可,无需再次 init 或添加 origin。

流程依据:GitHub · Adding locally hosted code to GitHub。

另一台电脑:克隆一次,再建立自己的链接

首次获取 · 目标目录应尚不存在
mkdir -p "$HOME/workspace"
git clone https://github.com/YOUR_ACCOUNT/my-skills.git \
  "$HOME/workspace/my-skills"

克隆后执行 STEP 03 的链接配置。此后更新前先查看本地状态;存在未提交修改时先提交或妥善保存,再拉取:

后续更新 · 工作区清理好后执行 pull
git -C "$HOME/workspace/my-skills" status --short
git -C "$HOME/workspace/my-skills" pull --ff-only

--ff-only 只接受快进更新;本地与远端提交已分叉时会停止,需要先决定如何整合两边的修改。它不负责自动处理所有冲突。

依据:Git · git pull。

STEP 05建立可验证的迭代循环

“持续迭代”来自真实任务反馈:发现缺失的判断条件,修改相应规则,再用代表性任务验证。建议一次改进一个明确问题,把项目特例留在项目约定中。

01 / EDIT

编辑源码,说明本次要改善的任务与判断。

02 / VERIFY

在不同项目试用,检查触发、输出及项目适配。

03 / SHARE

检查 diff,提交验证过的修改,再推送同步。

不同动作实际改变了什么
动作本地文件版本记录 / 其他电脑
保存 SKILL.md链接指向的文件随即改变尚未生成 Git 提交,也未同步远端
git commit保存当前选中的修改快照只增加本地提交
git push无需为本机加载额外复制将本地提交推送到远端
另一台电脑 git pull更新该电脑的本地检出该电脑的链接继续指向更新后的文件

共享一个工作目录意味着各项目采用该目录的当前内容,尚未提交的修改也可能被后续任务读到。如果需要试验版本与稳定版本并存,可以使用两个独立检出,并分别采用明确区分的 skill 名称和入口。

验证要覆盖“该用”和“不该用”的情况

  • 明确要求编写技术文档:能否触发并读取项目模板?
  • 同样的写作任务换到另一个项目:是否采用了新项目的路径与格式?
  • 仅要求解释一个术语:是否避免无依据地创建整篇文件?
  • 项目缺少输出约定:能否提出必要问题,而不是沿用上一个项目的目录?
验证思路参考:OpenAI · Test the skill;以上用例针对本文写作 skill 设计。
一次改进验证通过后的提交
cd "$HOME/workspace/my-skills"
git diff -- skills/technical-writing
git add skills/technical-writing/SKILL.md
git diff --cached
git commit -m "refactor: clarify project-specific writing rules"
git push

新增参考文件或脚本时,将相应文件一起加入提交。Git 记录的是你做出的改进;使用次数本身不会自动修改 skill 文件。

STEP 06把通用流程与项目约定分开

能被多个项目发现,只解决了可访问性。要真正复用,还要移除写死的业务仓库路径、站点视觉和发布文件位置。以项目专用的 write-doc 为例,可以按下面的边界提取通用能力。

通用写作 skill 与各项目的职责
内容建议归属示例
资料核对、事实与建议区分、操作步骤检查通用 skill核实关键机制,检查命令与引用。
输出格式与文章保存位置项目 AGENTS.md 或指定规范本站要求 HTML 并放入 common/public/。
主站主题、Banner、页面组件项目模板复用当前站点样式与导航。
首页登记与中英文简介项目发布约定说明要修改哪些目录入口与翻译文件。
与项目无关的检查脚本或模板通用 skill 的配套资源按输入参数运行,避免写死业务路径。

通用 skill 中应明确要求读取当前项目规范,并用 skill 自身位置定位随包参考资料、用当前项目根目录定位交付文件。若自行设计配置文件,要在 skill 中说明文件名、字段与读取时机;它不会因为存在就自动成为 Codex 的标准配置。

为通用版与项目版使用清晰的不同名称

例如通用版叫 technical-writing,项目专用版保留 write-doc。同名 skill 不会自动合并,不应依赖“项目版一定覆盖全局版”的假设。

同名行为依据:OpenAI · 本地 skill 加载说明。

常见问题:沿“源码 → 链接 → 调用”排查

常见现象与处理顺序
现象优先检查处理方向
源码有了,其他项目找不到用户级链接是否存在,目标内是否包含 SKILL.md先执行 STEP 03 的 readlink 与 cat,再检查元数据。
入口已存在它是目录、正常链接还是断链先核对现有目标与内容;不要直接强制覆盖。
链接目标中出现字面量 ~是否使用了 "~/workspace/..."终端示例使用 "$HOME/workspace/..."。
修改后仍表现得像旧版本调用的 skill 名称、实际读取路径、旧会话内容确认文件已保存,开启新会话;仍未显示时重启。
已 push,另一台电脑没变化另一台电脑是否拉取、是否链接到该检出检查状态并 pull,然后重新验证。
能找到 skill,却输出到错误目录通用正文是否残留项目专用路径将路径移入当前项目规范,补充跨项目用例。
移动仓库后无法读取readlink 是否仍指向原位置核对并重建本机入口,源码继续由 Git 管理。
04 /

总结归纳

REUSABLE WORKFLOW

一份源码,项目适配,版本可追溯。

把 skill 当作持续维护的工程资产:独立仓库存源码,用户级软链接提供入口,项目约定决定交付细节。真实任务推动改进,Git 记录版本,GitHub 同步提交。

首次完成创建与链接后,日常工作就是修改 → 验证 → commit → push;其他电脑通过 pull 获取更新。面向更广泛的可安装分发时,再采用插件包装。

官方依据与参考

核对日期:2026-09-28。官方资料支持工具机制与命令语义;仓库布局、写作流程和项目分工是本文的实践建议。文中个人路径与仓库所有者均使用通用示例。

  1. [01]
    OpenAI · Build skills ↗

    加载目录、软链接、调用方式、更新检测与同名行为。

  2. [02]
    OpenAI · Configuration Reference ↗

    skills.config 的启用与禁用用途。

  3. [03]
    OpenAI · Build skills for plugins ↗

    SKILL.md 格式、配套资源与行为验证。

  4. [04]
    GitHub · Adding locally hosted code to GitHub ↗

    本地仓库连接远端与首次推送。

  5. [05]
    Git · git pull ↗

    拉取更新、快进与分叉处理。

  6. [06]
    OpenAI · Package your plugin ↗

    需要可安装分发时的后续包装方式。