task-review-workflow

TotalClaw 作者 totalclaw

用于任务驱动开发的标准 PR 审查和合并工作流程。在审查链接到任务的程序员代理 PR、决定合并与更改请求、处理合并后操作(Trello + 分支清理)以及发送明确的结果移交时使用。

安装 / 下载方式

TotalClaw CLI推荐
totalclaw skills install shop:totalclaw:totalclaw~anikgnr-task-review-workflow
cURL直接下载,无需登录
curl -fsSL https://skills.taituai.com/api/skills/totalclaw%3Atotalclaw~anikgnr-task-review-workflow/file -o anikgnr-task-review-workflow.md
# Task Review Workflow

Follow this workflow in order for every task-linked PR.

## 1) Gather Context

- Read the PR description.
- Open and read the linked task before reviewing code.
- Confirm expected behavior and acceptance criteria from the task context.

## 2) Review Against Standard

- Use `REVIEW_CHECKLIST.md` as the mandatory review baseline.
- Check correctness, edge cases, regressions, security, performance, and test adequacy.

## 3) Review the Diff Thoroughly

- Review file-by-file.
- Flag logic flaws, unsafe assumptions, missing validation, unclear naming, dead code, and side-effect risks.

## 4) Validate Locally When Possible

- Check out the PR branch.
- Run relevant test/lint/build commands.
- Exercise changed behavior directly where practical.

## 5) Write Clear Review Feedback

- Leave actionable, specific CR comments.
- Separate must-fix issues from optional suggestions.

## 6) Decide Outcome

- If issues remain: request changes with a concrete fix list.
- If quality is acceptable: approve/merge with a short merge note.

## 7) Execute Post-Merge Steps

- Move the related Trello card to **Done**.
- Delete the **task branch** after merge.
- Never delete the `main` branch.

## 8) Complete Handoff

- Send the final outcome back to the programmer agent:
  - `merged`, or
  - `CR sent`, or
  - `waiting for fixes`.
- Ensure the next task starts only after this outcome message.

---

## 中文说明

# 任务审查工作流程

对每个关联任务的 PR 都按顺序遵循此工作流程。

## 1) 收集上下文

- 阅读 PR 描述。
- 在审查代码之前,打开并阅读关联的任务。
- 从任务上下文中确认预期行为和验收标准。

## 2) 对照标准进行审查

- 将 `REVIEW_CHECKLIST.md` 作为强制性的审查基准。
- 检查正确性、边界情况、回归、安全性、性能以及测试的充分性。

## 3) 彻底审查 Diff

- 逐个文件审查。
- 标记逻辑缺陷、不安全的假设、缺失的校验、命名不清晰、死代码以及副作用风险。

## 4) 尽可能在本地验证

- 检出 PR 分支。
- 运行相关的 test/lint/build 命令。
- 在可行的情况下直接实测变更后的行为。

## 5) 撰写清晰的审查反馈

- 留下可操作、具体的 CR 评论。
- 将必须修复的问题与可选的建议区分开。

## 6) 决定结果

- 如果仍有问题:请求更改并附上具体的修复清单。
- 如果质量可接受:批准/合并,并附上简短的合并说明。

## 7) 执行合并后步骤

- 将相关的 Trello 卡片移动到 **Done**。
- 合并后删除**任务分支**。
- 切勿删除 `main` 分支。

## 8) 完成移交

- 将最终结果发回给程序员代理:
  - `merged`,或
  - `CR sent`,或
  - `waiting for fixes`。
- 确保只有在收到此结果消息后才开始下一个任务。