project-health-check

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Project Health Check

项目健康检查

Run the scheduled health checks for this project, in order. Each check is independent — if one can't complete (a tool is missing, a command fails, access is denied), report what went wrong and continue to the next check. Never let one failed check abort the rest. Post a short summary at the end covering every check.

按顺序运行该项目的定期健康检查。每项检查都是独立的——如果某一项无法完成（缺少工具、命令执行失败、权限被拒绝），报告问题所在并继续执行下一项检查。绝不要因一项检查失败而终止其余检查。最后发布一份涵盖所有检查内容的简短总结。

Inputs

输入参数

These are provided when the skill is invoked — don't hardcode them:

Linear team (required for Check 3) — the name or key of the team whose backlog to triage (e.g. a team key like
```
PXL
```
). If it wasn't provided and can't be inferred unambiguously from the project, ask once.
Ticket date cutoff (optional) — ignore tickets created before this date. If not provided, apply no cutoff.

这些参数会在调用该skill时提供——请勿硬编码：

Linear团队（Check 3必填）——待梳理待办事项的团队名称或标识（例如，类似
```
PXL
```
的团队标识）。如果未提供且无法从项目中明确推断，请询问一次。
工单日期阈值（可选）——忽略在此日期之前创建的工单。如果未提供，则不设置阈值。

Check 1 — Sync main branch with remote

Check 1 — 同步主分支与远程仓库

In the main worktree (not any feature worktree), bring the local

main

branch in sync with

origin/main

via a fast-forward only. Do this regardless of which branch the worktree is currently on or whether it's dirty — a worktree sitting on a feature branch with uncommitted changes is the normal case, not a reason to skip. The mechanism for not disturbing in-progress work is to stash it, sync, and put everything back exactly as it was — not to bail out. A worktree that ends on the same branch it started on, with the same changes restored, has not been disturbed.

The shape of the work, which is safe and reversible throughout:

Remember where the worktree started — its current branch and whether it has uncommitted work — so you can put it back there afterward.
Set the in-progress work aside if the tree is dirty, so
```
main
```
can be checked out cleanly. Use a reversible mechanism (stashing, including untracked files); nothing should be lost.
Get onto
main
and fast-forward it to
```
origin/main
```
. If
```
main
```
has diverged so a fast-forward isn't possible, leave it untouched and note the divergence — then still finish the restore steps so the worktree ends where it started.
Put the worktree back the way you found it — return to the starting branch and reapply the set-aside work.

Restoring the work usually reapplies cleanly. In the case where the worktree started on

main

itself, the changes now reapply on top of the freshly fast-forwarded

main

, which can conflict if upstream touched the same files. Resolve only very simple, unambiguous conflicts automatically. For anything non-trivial or where you're not certain of the right resolution, stop and consult the user — keep their set-aside work preserved and intact, surface the conflict, and don't make risky edits to their uncommitted changes.

Guardrails:

Fast-forward only — never force, reset, or rebase
```
main
```
. If it has diverged, report and move on.
The worktree must end on the same branch it started on, with the same changes present — returning to the branch and reapplying the work are mandatory, not optional. Never discard set-aside work you couldn't cleanly restore.
On success, note whether
```
main
```
moved (and to what SHA), and whether you set work aside / restored it or returned to a non-
```
main
```
branch, so the final summary is concrete.

在主工作区（而非任何功能分支工作区）中，仅通过快进方式将本地

main

分支与

origin/main

同步。无论当前工作区处于哪个分支或是否存在未提交更改，都要执行此操作——工作区处于功能分支且存在未提交更改是正常情况，不是跳过此步骤的理由。不干扰进行中工作的机制是暂存这些更改，完成同步后再完全恢复原状——而非放弃操作。只要工作区最终回到初始分支，且所有更改都已恢复，就不算受到干扰。

安全且全程可逆的操作流程：

记录工作区初始状态——当前所在分支以及是否存在未提交的工作——以便之后恢复原状。
如果工作区存在未提交更改，暂存进行中的工作，以便干净地检出
```
main
```
分支。使用可逆机制（暂存，包括未跟踪文件）；不得丢失任何内容。
切换到
main
分支并快进至
origin/main
。如果
```
main
```
分支已偏离导致无法快进，则保持其不变并记录偏离情况——然后仍需完成恢复步骤，使工作区回到初始状态。
将工作区恢复至初始状态——返回初始分支并恢复暂存的工作。

恢复工作通常能顺利完成。如果工作区初始状态就是

main

分支，那么现在更改会重新应用到刚快进完成的

main

分支上，如果上游修改了相同文件，可能会产生冲突。仅自动解决非常简单、明确的冲突。对于任何非 trivial 或不确定正确解决方案的冲突，停止操作并咨询用户——保留用户暂存的工作完整，告知冲突情况，不要对用户的未提交更改进行有风险的编辑。

约束规则：

仅快进——绝不强制推送、重置或变基
```
main
```
分支。如果分支已偏离，报告情况并继续后续步骤。
工作区必须回到初始分支，且保留所有初始更改——返回初始分支并恢复工作是强制要求，而非可选操作。绝不要丢弃无法干净恢复的暂存工作。
操作成功后，记录
```
main
```
分支是否移动（以及新的SHA值），是否暂存/恢复了工作，或者是否回到了非
```
main
```
分支，以便最终总结内容具体明确。

Check 2 — Refresh installed skills

Check 2 — 刷新已安装的skills

Update all installed project skills to their latest versions, non-interactively:
```
npx skills update --project --yes
```
. This resolves each skill's source automatically and updates the skill files under
```
.agents/skills
```
(and the skills lock file) in place.
Check whether the refresh changed any skill files or the lock file (e.g. via the version-control status of those paths).
- If nothing changed: note "skills already up to date" and move on.
- If anything changed: create a standalone PR with just those changes — title
```
chore: refresh installed skills
```
  , body listing the updated skills. This is a plain PR — do not run it through the
```
ship
```
  stacked-PR flow. Then surface the list of updated skills and the PR link in the final summary.
Keep this PR completely separate from any feature work in Check 3 — separate branch, separate PR, no shared commits.

以非交互方式将所有已安装的项目skills更新至最新版本：
```
npx skills update --project --yes
```
。此命令会自动解析每个skill的源，并在原地更新
```
.agents/skills
```
下的skill文件（以及skills锁定文件）。
检查刷新操作是否修改了任何skill文件或锁定文件（例如，通过这些路径的版本控制状态）。
- 如果未发生任何更改：记录“skills已处于最新版本”并继续后续步骤。
- 如果发生了更改：创建一个仅包含这些更改的独立PR——标题为
```
chore: refresh installed skills
```
  ，正文列出更新的skills。这是一个普通PR——不要通过
```
ship
```
  的堆叠PR流程处理。然后在最终总结中列出更新的skills和PR链接。
确保此PR与Check 3中的任何功能工作完全分离——使用独立分支、独立PR，无共享提交。

Check 3 — Ticket triage and ship

Check 3 — 工单梳理与交付

Look at the open tickets in the provided Linear team and pick a good next ticket to work on, then hand it to the

ship

skill.

Filter conflicts before settling on a ticket — exclude any candidate that has:

A dependency /
```
Blocked by
```
relation pointing at unfinished work.
Scope overlap with another Linear issue currently
```
In Progress
```
/
```
In Review
```
.
Overlap with any non-stale open PR — stale = no commits in ~14 days; treat stale PRs as abandoned and therefore not a conflict.
A creation date before the date cutoff, if one was provided.

Always present your proposal and wait for the user's explicit approval before any work begins — never hand a ticket to

ship

on your own initiative, even when the choice seems obvious. Present a recommended next ticket with a one-line rationale, plus 3–5 other candidates with one-line summaries as alternatives, and stop. If there's no suitable actionable ticket at all, say so and skip the ship — don't force one.

Only once the user has explicitly picked or confirmed a ticket, hand it to the

ship

skill and follow that skill's workflow for the rest (worktree, stack, review, merge).

ship

owns all its own approval gates from there.

查看指定Linear团队的未结工单，挑选一个合适的下一个工单进行处理，然后将其交给

ship

skill。

筛选冲突工单——排除任何符合以下条件的候选工单：

存在指向未完成工作的依赖/
```
Blocked by
```
关联。
与当前处于
```
In Progress
```
/
```
In Review
```
状态的其他Linear工单存在范围重叠。
与任何非陈旧的开放PR存在重叠——陈旧定义为约14天无提交；将陈旧PR视为已废弃，因此不视为冲突。
如果提供了日期阈值，创建日期早于该阈值。

在开始任何工作之前，务必先提交你的提案并等待用户的明确批准——即使选择看似显而易见，也绝不要自行将工单交给

ship

skill。提交一个推荐的下一个工单及一行理由，另外提供3–5个其他候选工单及一行摘要作为备选，然后停止操作。如果完全没有合适的可执行工单，请告知用户并跳过交付步骤——不要强行选择。

只有在用户明确选择或确认工单后，才将其交给

ship

skill，并遵循该skill的后续工作流程（工作区、堆叠、评审、合并）。从此时起，

ship

负责所有自身的审批环节。

Summary

总结

End with a brief report covering every check:

Check 1 — main synced (note new SHA if it moved) or "already up to date"; if the worktree was on a feature branch or dirty, note that work was stashed, main synced, and the branch + changes restored; flag any stash-restore conflict left for the user; or report a divergence / what otherwise blocked it.
Check 2 — skills refreshed (list updated skills + PR link) or "already up to date"; or what blocked it.
Check 3 — ticket picked + current ship status; or candidates awaiting a pick; or "no actionable ticket"; or what blocked it.
Anything that needs the user's attention.

最后提供一份涵盖所有检查内容的简短报告：

Check 1——main分支已同步（如果有移动则记录新SHA值）或“已处于最新版本”；如果工作区之前处于功能分支或存在未提交更改，记录已暂存工作、同步main分支并恢复分支及更改；标记任何留给用户处理的暂存恢复冲突；或报告分支偏离情况/其他阻碍因素。
Check 2——skills已刷新（列出更新的skills + PR链接）或“已处于最新版本”；或报告阻碍因素。
Check 3——已挑选工单 + 当前交付状态；或候选工单等待选择；或“无可用可执行工单”；或报告阻碍因素。
任何需要用户关注的事项。