关于 project-health-check
Project Health Check 是面向项目维护者的定期健康检查技能，按顺序同步 main、更新已安装技能并分流 Linear 工单。各项检查相互独立，工单交给 ship 前必须等待用户明确批准。
主要功能
- 01快进同步 main 与 origin/main
- 02暂存并恢复进行中的工作
- 03更新项目已安装技能
- 04为技能更新创建独立 PR
- 05筛选冲突工单并提出候选
- 06获批后将工单交给 ship
适用场景
- 01定期同步项目主分支
- 02刷新项目内安装的技能
- 03从 Linear 待办中挑选可处理工单
- 04在开始工单工作前请求确认
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/project-health-check确认已加载。
详细介绍
项目健康检查
按顺序运行此项目的计划健康检查。每项检查都相互独立——如果某项无法完成（缺少工具、命令失败、访问被拒绝），请说明出错原因，并继续下一项检查。绝不要让某项检查失败而中止其余检查。最后发布一份简短摘要，涵盖每项检查。
输入
调用此技能时会提供以下信息——不要将其硬编码：
- Linear 团队（检查 3 必需）——需要分类处理其待办事项的团队名称或键（例如团队键
PXL）。如果未提供，且无法从项目中明确推断，请询问一次。 - 工单日期截止时间（可选）——忽略在此日期之前创建的工单。如果未提供，则不设截止时间。
检查 1 — 将 main 分支与远程分支同步
在主工作树中（而非任何功能工作树），通过仅快进的方式将本地 main 分支与 origin/main 同步。无论工作树当前位于哪个分支，也无论它是否有未提交的更改，都要执行此操作——工作树位于功能分支且有未提交更改是常见情况，不是跳过的理由。为避免干扰进行中的工作，应暂存这些更改、完成同步，然后原样恢复，而不是放弃同步。工作树最终仍在开始时的同一分支上，且恢复了相同更改，就没有受到干扰。
整个过程应安全且可逆：
- 记住工作树的起始状态——当前分支，以及是否有未提交的工作——以便之后恢复到原样。
- 如果工作树不干净，先将进行中的工作暂存起来，以便干净地检出
main。使用可逆的方式（包括未跟踪文件）；不得丢失任何内容。 - 切换到
main并将其快进到origin/main。如果main已发生分叉，无法快进，则保持其不变并记录分叉情况；然后仍然完成恢复步骤，确保工作树回到起始状态。 - 将工作树恢复到原来的状态——切回起始分支，并重新应用暂存的工作。
通常可以顺利重新应用工作。如果工作树起始时就在 main 上，则这些更改现在会重新应用到刚刚快进的 main 之上；如果上游修改了相同文件，可能会产生冲突。**仅自动解决非常简单且毫无歧义的冲突。**对于任何非简单的冲突，或任何无法确定正确解决方式的情况，停止并咨询用户——保留其暂存的工作原封不动，说明冲突情况，不要冒险修改其未提交的更改。
注意事项：
- 仅允许快进——绝不要强制更新、重置或变基
main。如果发生分叉，请报告并继续。 - 工作树结束时必须位于起始分支，并保留相同的更改——切回原分支并重新应用工作是强制要求，不是可选步骤。绝不要丢弃无法顺利恢复的暂存工作。
- 成功时，说明
main是否有更新（以及更新到哪个 SHA），并说明是否暂存并恢复了工作，或是否返回了非main分支，以便最终摘要具体明确。
检查 2 — 更新已安装的技能
- 以非交互方式将所有已安装的项目技能更新到最新版本：
npx skills update --project --yes。此命令会自动解析每个技能的来源，并原地更新.agents/skills下的技能文件（以及技能锁定文件）。 - 检查更新是否更改了任何技能文件或锁定文件（例如，查看这些路径的版本控制状态）。
- **如果没有任何更改：**注明“技能已是最新”，然后继续。
- 如果有任何更改：仅包含这些更改，创建一个独立 PR，标题为
chore: refresh installed skills，正文列出已更新的技能。这是一个普通 PR——不要通过ship堆叠式 PR 流程提交。然后在最终摘要中列出已更新的技能和 PR 链接。
- 此 PR 必须与检查 3 中的任何功能工作完全分开——使用单独的分支和 PR，不得共享提交。
检查 3 — 工单筛选与提交
查看所提供 Linear 团队中的未关闭工单，挑选一个合适的下一项工单，然后交给 ship 技能处理。
确定工单前，先筛除冲突项——排除所有符合以下条件的候选工单：
- 存在指向未完成工作的依赖关系／
Blocked by关系。 - 与另一项当前处于
In Progress／In Review状态的 Linear 工单范围重叠。 - 与任何未过期的未关闭 PR 存在重叠——约 14 天没有提交即视为过期；将过期 PR 视为已放弃，因此不构成冲突。
- 如果提供了日期截止条件，则创建日期早于该日期。
开始任何工作前，务必先提出建议并等待用户明确批准——绝不要自行将工单交给 ship，即使选择看起来显而易见。推荐一项合适的下一步工单，并附上一句理由；再提供 3–5 项其他候选工单作为替代项，每项附上一句摘要，然后停止。如果完全没有合适且可执行的工单，请说明情况并跳过 ship——不要勉强选择。
只有在用户明确选择或确认工单后，才能将其交给 ship 技能，并在之后遵循该技能的工作流（工作树、堆栈、审查、合并）。从此阶段开始，所有审批关卡均由 ship 管理。
摘要
结尾附上简要报告，涵盖每项检查：
- 检查 1 — 主分支已同步（如果 SHA 有变化，请注明新 SHA）或“已是最新”；如果工作树位于功能分支或处于脏状态，请注明已暂存更改、同步主分支并恢复分支和更改；如果恢复暂存内容时仍有冲突，请提醒用户；或说明存在的分歧／其他阻碍。
- 检查 2 — 技能已更新（列出已更新的技能和 PR 链接）或“已是最新”；或说明阻碍。
- 检查 3 — 已选择工单及当前 ship 状态；或列出等待用户选择的候选项；或说明“没有可执行的工单”；或说明阻碍。
- 需要用户留意的任何事项。