review-weekly-report

name

review-weekly-report

description

Independently review final Chinese internship or engineering weekly reports before delivery. Use for 周报 review, manager-facing email review, five-section report approval, wording cleanup, or final checks of monthly goals, weekly progress, learnings, questions, and plans. This skill requires a line-by-line model readback after automated checks and rejects reports that are structurally valid but unnatural, vague, over-translated, role-inaccurate, or unsupported.

Review Weekly Report

Review the final manager-facing report as an editor who was not present in the drafting conversation. Automated validators support this review but never replace it. Return READY only after reading every final sentence and the complete five-section sequence.

This skill reviews; it does not send email, change evidence, or invent achievements. If a claim is wrong, ambiguous, or unsupported, return NEEDS_EDIT with a proposed rewrite and identify the evidence question that must be resolved.

Inputs

Use these inputs in this order:

1. The final five-section body in JSON, HTML, Markdown, or plain text.
2. The reporting period and intended reader.
3. The evidence matrix or local records used to support claims.
4. Automated validation output, only after the prose review has begun.

Separate the manager-facing body from technical notes. Long engineering records may keep precise implementation detail; the email must expose only the result, value, risk, decision, and necessary technical context.

Mandatory Review Workflow

1. Freeze And Extract The Final Body

Review the exact text intended for delivery. Extract only:

• 本月目标
• 本周进展
• 收获与分享
• 疑惑与问题
• 下周计划

Do not review an earlier draft, evidence note, or validator-normalized copy. Record the file and revision reviewed so later edits cannot inherit an obsolete approval.

2. Read Once As The Manager

Read the five sections from top to bottom before consulting detailed evidence. For every sentence, answer:

1. Who acted, and is the exact project role named?
2. What concrete project, PR, Issue, component, setting, or number is discussed?
3. What changed or was decided?
4. Why does it matter, or what remains open?
5. Would a technical manager understand it on one read without the drafting conversation?

If any answer is missing, mark the sentence for revision. Do not infer the missing link on the reader's behalf.

Then apply a 15-second summary gate without consulting the evidence matrix:

• Can the reader name the three main outcomes?
• Can the reader tell what each outcome was intended to achieve?
• Can the reader tell what happens next?

Return NEEDS_EDIT when proof chains, theory, test mechanics, or unexplained terminology hide those answers. Three weekly-progress rows are the default; accept two or four only when the underlying work requires them.

3. Review Each Section Against Its Job

Apply these section-specific gates:

Section	Required content	Reject when
本月目标	project + monthly outcome + honest status	it lists weekly steps, PR IDs, or tests instead of the monthly result
本周进展	reporter-owned delivery state + object/evidence + value or one external state	it reports activity without an outcome, leads with proof mechanics, or treats maintainer timing as unfinished reporter work
收获与分享	event + exact object + plain meaning + future rule	it is a code note, generic slogan, or concept the writer cannot explain
疑惑与问题	decision context + real choice/blocker + impact	it is merely a status update or cannot be answered as a decision
下周计划	object + observable end state + material dependency	it says only 继续跟进, 学习, 阅读, or 跑测试

Numbers must bind to objects and owners. Keep WorkloadManager 创建 CodeInterpreter session 时使用的 2 分钟 timer, 17 项 CI 检查, and WarmPoolAvailable 相关的 6 个文件; reject a floating 2 分钟计时, 全部通过, or 改几个文件.

Technical learnings must identify where the behavior lives and which operation it affects. Reject ownerless openings such as 代码里, 逻辑里, or 系统中. Name the project, component, resource/path, and operation at the level needed to understand the conclusion, for example AgentCube WorkloadManager 创建基于 SandboxClaim 的 CodeInterpreter session 时....

PR and Issue numbers are locators, not topics. Every manager-facing row that contains #123 must name the repository and the concrete feature, component, bug, or proposal in the same task label or sentence. Reject titles made only from a generic action, repository, review type, and number, such as AgentCube #442 PR Review or 处理 Karmada #7697 与 #7777. Prefer agent-sandbox v0.5.2 适配 PR Review（AgentCube #442） and 证书轮换与 Remedy 状态修复（Karmada PR #7697、#7777）.

4. Audit Roles, Terms, And Effects

Name people and accounts by project role: 维护者, 作者, 审查者, 贡献者, or CI bot. Never distinguish a person from the writing agent with labels such as 真人 or 人类 reviewer.

Do not translate established engineering vocabulary merely to make the report look more Chinese. Keep terms a technical manager and the project already use, including E2E, CI, PR, Issue, PR Review, Feature Proposal Review, inline comments, merge, timer, mTLS, and CRD. Explain the practical consequence when the term alone does not carry the conclusion.

Preserve the repository's artifact name and the work type before simplifying prose. A GitHub PR review is PR Review, a repository design artifact may be Feature Proposal, and comments attached to exact diff lines are inline comments. Do not replace these with generic labels such as 代码审查, 功能提案, or 行级意见. State CI outcomes directly as CI 通过 or CI 失败; do not use traffic-light metaphors such as 绿灯 or 红灯 in the manager-facing body.

Distinguish three cases:

• Established project artifact or engineering term: preserve it exactly, for example Karmada 偶发 E2E 失败 and #431 Feature Proposal Review.
• Necessary low-level object: preserve it once with its owner and operation, for example WorkloadManager 创建 CodeInterpreter session 时，2 分钟 timer 到期会取消 SandboxClaim GET.
• Internal drafting shorthand: replace it with cause and effect, for example replace 高基数指标 with 未识别的 HTTP 方法会持续新增监控数据项.

Do not blindly replace every English term. The goal is immediate comprehension, not literal translation or deliberate jargon removal.

Use 合同 only for an actual company, legal, procurement, or business contract. For code, API, protocol, or security design, use the concrete meaning: 方案, 要求, 规则, or 约束. Reject phrases such as mTLS 合同 and API 合同 in manager-facing text.

5. Verify Evidence And Status

Only after the first prose pass, trace every number, ID, result, and status to evidence. Check especially:

• 已合并, 已完成, 进行中, 受阻, and 等待维护者审核.
• Whether 已完成/进行中 describes the reporter-owned weekly scope independently from maintainer review or merge timing.
• Authored work versus another contributor's work that was reviewed.
• Automatic checks versus local build, unit test, integration test, E2E, or live-environment validation.
• A posted suggestion versus an accepted suggestion or merged implementation.
• A current PR head versus an obsolete review comment.

For community contributions, do not make completion depend on a maintainer's schedule. If the reporter finished the promised PR submission, Review, inline comments, nomination, or evidence package, the weekly row may be 已完成; record 等待维护者审核 or 尚未 merge separately when relevant. Keep 进行中 only when the reporter still has an unfinished action in that row.

Never repair weak evidence by weakening the wording silently. State what evidence is missing.

6. Rewrite For Spoken, Precise Chinese

For each finding, quote the exact original phrase and propose the smallest factual rewrite. Prefer familiar technical vocabulary and ordinary verbs. Remove compressed noun piles, inflated language, process narration, and claims that add no fact, value, risk, or decision.

Use this pattern when helpful:

状态或结果 + 具体对象/数字 + 实际价值或剩余风险

Examples:

• Reject: 17/17 checks 通过，等待真人 review。
• Use: 17 项检查全部通过，等待维护者审核。
• Reject: Karmada 偶发端到端测试失败。
• Use: Karmada 偶发 E2E 失败。
• Reject: 参与跨项目代码审查和功能提案审查。
• Use: 参与 AgentCube/Karmada PR Review 与 Feature Proposal Review。
• Reject: CI 绿灯不代表新版功能已验证。
• Use: CI 通过不代表新版适配已验证。
• Reject: #400 解决高基数指标。
• Use: #400 将未识别的 HTTP 方法统一归类，避免监控数据项持续增加。
• Reject: 运行时适配补证。
• Use: 完成 agent-sandbox v0.5.2 的旧集群升级验证。

7. Read The Whole Report Again

After revisions, stop looking at evidence and reread the final five sections in order. Check:

• goals, progress, and plans describe the same priorities;
• a role, term, PR state, and status are named consistently;
• adjacent rows do not repeat the same accomplishment;
• every learning changes a future engineering decision;
• every question requests a decision;
• every plan has a visible completion condition;
• the tone is natural for a technical manager, neither a low-level debug log nor over-simplified prose.
• every project artifact and review type still uses the repository's established name.
• every PR or Issue number has a topic in the same row, so the reader never needs to look up a bare ID.

Any edit after this pass invalidates READY until the changed section is reread and status/evidence are rechecked.

8. Use Automated Checks As Supporting Evidence

Run the repository's content, layout, privacy, and skill validators after the line-by-line review. Treat their output as regression evidence only. A green script cannot detect whether the writer understands the sentence, whether E2E was translated unnaturally, or whether the five sections tell one coherent story.

Never approve with only content ok, layout ok, unit tests, a keyword scan, or a static forbidden-phrase list.

Review Output Contract

Lead with findings ordered by severity. Each finding must contain:

• section and exact original phrase;
• why a technical manager may misunderstand it or why the evidence does not support it;
• the smallest factual rewrite or the evidence needed;
• severity: 阻塞, 重要, or 措辞.

End with exactly one verdict:

• READY: no manager-facing wording, evidence, status, privacy, or layout problem remains.
• NEEDS_EDIT: at least one issue remains; list the edits required before another review.

Also state 已完成逐句通读：是/否. Never return READY when that answer is 否.

Stop Conditions

• Do not send an email or publish a report without separate explicit authorization.
• Do not expose identity, addresses, credentials, private URLs, or confidential logs.
• Do not approve a report whose rendered output differs from the reviewed source.
• Do not hide uncertainty behind smoother wording.
• Do not mark the report ready because the automated validator passed.