メニュー
为 fastnote 仓库构建发布产物、确定或补建版本 tag、创建或修复 GitHub Release、上传多平台资产并完成最终验收。用于用户提出“发布一个版本 release”“补发 beta 版本”“重新上传 release 资产”“修复 tag 和 release 不一致”“帮我发预发布版本”这类需求时。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
升级 fastnote 仓库中的 PocketBase 版本，包括后端 Go 宿主依赖与前端 JavaScript SDK，并完成最新版本核验、兼容性检查、构建测试与按需提交。用于用户要求“升级 PocketBase 到最新版本”“同步 Go 和 npm 的 PocketBase 依赖”“核实最新 release 并升级”“提交仅包含 PocketBase 升级改动”时。
fastnote 项目的中文架构师技能。面向前后端一体仓库的结构设计、重构、代码评审与变更落地。前端按 FSD 分层，后端按 `backend/main.go + internal/server + migrations` 组织，适用于 PocketBase Go 集成、同步链路治理、路由编排、编辑器流程、跨端数据契约和部署结构调整。
按 fastnote 的开发计划文档执行研发任务并交付代码、自动化测试与状态回写。用于用户提出“按任务ID开发/根据开发计划落地实现/补自动化测试/执行并更新任务状态”类需求，输入通常是 `docs/开发计划/迭代计划与任务看板.md`、`docs/开发计划/组件与数据契约清单.md`、`docs/开发计划/测试与发布计划.md`。
基于 fastnote 的代码反推 PRD 与当前仓库代码，产出中文“功能拆分 + 技术方案”文档并落盘到 `docs/功能拆分与技术方案/`，默认按“总览 + 分模块”多文件交付。用于版本规划、迭代评审、重构前设计、开发任务拆解，或当用户提出“功能拆分/技术方案/实施方案/从 PRD 到研发落地”类需求时使用。
将 fastnote 的“功能拆分与技术方案”文档转换为开发执行文档（迭代计划与任务看板、组件与数据契约清单、测试与发布计划）。当用户提出“从方案到开发排期/任务拆解/组件设计/测试发布落地”类需求，或需要把 `docs/功能拆分与技术方案/` 产物转为可执行研发计划时使用。
将一句话、几句话或一段简短业务描述扩展为结构化中文需求文档 / PRD 草案的技能。用于需求澄清、想法成稿、版本规划、功能定义、立项前梳理，或当用户只提供简短目标描述，希望输出范围、用户故事、流程、规则、验收标准、风险与待确认问题时使用。
| name | fast-note-release-publisher |
| description | 为 fastnote 仓库构建发布产物、确定或补建版本 tag、创建或修复 GitHub Release、上传多平台资产并完成最终验收。用于用户提出“发布一个版本 release”“补发 beta 版本”“重新上传 release 资产”“修复 tag 和 release 不一致”“帮我发预发布版本”这类需求时。 |
按 fastnote 仓库当前的真实发布链路发版：先校验工作区和现有版本，再构建 build/releases/ 产物，随后处理 git tag、GitHub prerelease 和资产上传，最后以远端 Release 状态作为交付依据。
不要假设仓库已经有完整自动化发布。当前仓库里的 scripts/release.mjs 只负责构建多平台产物，不会自动创建 tag 或 GitHub Release。
先确认仓库当前状态，再决定是新发版、补发版，还是修复已有 release。
git status --short --branchgit tag --sort=-version:refname | head -n 20gh release list --limit 20package.jsonscripts/release.mjsREADME.md重点确认：
用户明确给出版本号时，直接使用，不要自行改写。
用户只说“发一个版本”而未指定版本号时，按现有版本序列推断，但先做事实核验：
v0.1.1-beta.3，默认递增到 v0.1.1-beta.4在汇报里始终写出明确版本号，不只说“最新”或“下一个版本”。
发版前至少执行以下检查：
gh auth statusgit remote -vnpm run build处理规则：
npm run build 失败：先修复或停止，不要继续发版gh 未登录或权限不足：先解决认证问题，再继续统一使用根目录脚本：
npm run release -- --version=<version>npm run release:local -- --version=<version> 不适用当前仓库，release:local 已固定 --currentnpm run release -- --version=<version> --currentnpm run release -- --version=<version> --targets=<targets>默认完整发布走全平台，产物输出在 build/releases/。
构建完成后至少检查：
build/releases/manifest.jsonfastnote_<version>_<target>.zip当前支持目标固定为：
darwin-amd64darwin-arm64linux-amd64linux-arm64linux-armv7linux-ppc64lelinux-s390xwindows-amd64windows-arm64在仓库临时目录生成 notes 文件，避免把长文本直接塞进命令行。
推荐路径：
.tmp/release-<version>-notes.mdnotes 内容要基于本次版本相对上一版本的真实提交，不要凭空总结。
建议先看：
git log --oneline <last-tag>..HEADgh release view <last-tag>先分别检查三件事，不要把它们混为一谈：
git tag -l <version>git ls-remote --tags origin <version>gh release view <version>按以下规则处理：
创建 tag 时优先使用 annotated tag，例如：
git tag -a <version> -m "release: <version>"git push origin <version>注意：写 .git 元数据通常需要提升权限；若沙箱拦截，按规范申请 escalation。
优先创建 prerelease，除非用户明确要求正式版。
创建命令模式：
gh release create <version> --repo voidvon/fast-note --prerelease --title <version> --notes-file <notes-file>如果 gh release view <version> 返回 release not found，但远端 tag 已存在，这是正常的“只有 tag 没有 release”场景，直接重新执行 gh release create 即可。
如果 Release 创建后状态异常，先重新用 gh release view <version> --json ... 核实，不要假设 CLI 的上一条输出可靠。
对当前仓库，最稳定的顺序是：
manifest.json命令模式：
gh release upload <version> manifest.json --repo voidvon/fast-note --clobbergh release upload <version> <zip-file> --repo voidvon/fast-note --clobber不要默认一次性上传全部 9 个 zip。这个仓库在当前环境里批量上传更容易出现长时间无回显或状态不一致。
如果上传过程中出现异常：
gh release view <version> --json assets 查看远端真实资产列表最终以 GitHub 远端状态为准，不以本地命令退出码为准。
至少执行：
gh release view <version> --json url,assets,isDraft,isPrereleasegh release list --limit 10验收标准：
isDraft=falseisPrerelease 符合预期manifest.json如有需要，再补充：
git status --shortgit rev-parse HEAD最终输出至少包含：
gh release view 结果收口