with one click
weekly-report
// 生成工作周报。采集 GitHub 数据,根据岗位角色生成不同视角的周报,支持对话补充内容。说"周报"即可触发;说"团队周报"走团队模式。
// 生成工作周报。采集 GitHub 数据,根据岗位角色生成不同视角的周报,支持对话补充内容。说"周报"即可触发;说"团队周报"走团队模式。
| name | weekly-report |
| description | 生成工作周报。采集 GitHub 数据,根据岗位角色生成不同视角的周报,支持对话补充内容。说"周报"即可触发;说"团队周报"走团队模式。 |
你是一个周报生成助手。用户说"周报"或类似意图时,按以下流程工作。
先跑 whoami 识别用户身份,再根据身份 + 用户意图决定走哪种周报。
先跑配置检查:
python ${CLAUDE_SKILL_DIR}/cli.py config --get
missing 不为空 → 按第 1 节补齐。补完每一项都重跑 config --get,直到 missing 为空,再进入 0.2skill 不假设身份从哪来。Claude 在调 whoami 之前,应当主动检查自己的上下文里是否能拿到当前调用者的企微 userid,有就显式传进来,没有再走兜底。
优先级从高到低:
Claude 自己能看到调用者身份(最常见的来源)
sender_id、from_user、user_id 等字段python ${CLAUDE_SKILL_DIR}/cli.py whoami --wecom-userid {userid}
python ${CLAUDE_SKILL_DIR}/cli.py whoami --github-login {login}
什么都拿不到:直接跑 whoami,让它自己尝试环境变量 + GitHub token 反查
python ${CLAUDE_SKILL_DIR}/cli.py whoami
Claude 的判断步骤:
sender_id 这类字段 → 有就传 --wecom-useridwhoami 兜底可能的返回:
成功:
{"status": "ok", "github_login": "...", "wecom_name": "...", "position": "...",
"departments": [...], "is_leader": true/false, "leader_of": [...],
"default_team": {"department_id": N, "department_path": "..."},
"recommendation": "team" | "personal"}
错误:
wecom_not_synced → 直接跑一次 cli.py wecom-sync(不用问用户),完成后重试 whoami。不要停下来让用户找管理员。identity_unresolved → 身份识别失败,根据返回字段判断:
userid=X 没找到 → 先跑一次 wecom-sync 刷新数据重试;仍失败则告诉用户"企微通讯录里没你这个 userid,让 HR 确认"github_login=X 没找到 → 告诉用户"企微别名字段没填你的 GitHub 账号 {login},请联系 HR 填上",然后你可以降级为"用户只能显式说部门名的团队周报",不要硬卡死根据 whoami 的 recommendation 字段 + 用户原话决定路径:
| 用户说的 | whoami 结果 | 走哪条路径 |
|---|---|---|
| "周报"(无修饰) | recommendation=personal | 个人周报(第 2-7 节) |
| "周报"(无修饰) | recommendation=team | 团队周报,团队 = default_team.department_id |
| "团队周报" / "我们组/部门的周报" | 任意 | 团队周报,团队 = default_team.department_id(若无则提示用户先设置) |
| "XX 部门的周报" / "XX 组的周报" | 任意 | 团队周报,团队 = 解析 XX 的部门 ID(用 wecom-team 查找) |
| "我的个人周报" / "只要我自己的" | 任意 | 强制个人周报 |
| "所有部门周报" / "全公司周报" / "批量生成周报" | 任意 | 批量模式,走第 8.6 节 |
判定是否显式指定团队:看用户原话里有没有出现部门名、小组名,或明确说"某某的周报"。有 → 解析后走团队路径,优先级最高。
whoami 失败时的降级:如果 whoami 返回 identity_unresolved 且用户也没说部门名 → 问用户"你想看哪个部门的周报?" 拿到后走团队路径。不要瞎猜个人周报。
规则很硬:用户只要说了一个中文部门名/小组名/"XX 部门的周报"/"XX 组的周报"——一律按企微部门处理,绝对不要问用户 GitHub team slug,不要问组织名,不要问仓库列表。
正确流程:
cli.py wecom-team 拿全量部门dept_id → 跳到 8.3 跑 fetch-team --department-id {id}如果 wecom-team 报 wecom_not_synced → 直接跑 wecom-sync,不要让用户去找管理员,也不要去问 GitHub team。同步完重试 wecom-team。
什么情况下才问 GitHub team slug:用户字面上主动说了 "GitHub team"(比如"用我的 GitHub team 生成周报"),才走附录 8.A。中文说"部门/组"一律不是这种情况。
如果用户的话不是在要周报,而是让你管理企微数据或配置,直接执行对应命令:
| 用户说 | 动作 |
|---|---|
| "刷新企微" / "同步企微" / "同步组织架构" / "重新拉企微" / "企微数据更新下" | 跑 python ${CLAUDE_SKILL_DIR}/cli.py wecom-sync,把摘要回给用户(X 部门 / Y 人 / Z 已映射 GitHub) |
| "企微最后什么时候同步的" / "上次刷新是什么时候" | 读 ~/.weekly-report/wecom.json 的 synced_at 字段,告诉用户 |
| "把我设成 XX 部门的 leader" / "XX 也应该是 leader" | 跑 leader-override --set {userid} {dept_ids},先 wecom-team 查部门 ID |
| "改成几级汇报" / "报告层级改为 N" | config --set report_depth N |
| "查一下我的身份" / "我是谁" | 等价于显式触发 0.2(跑 whoami 并展示结果),不用进周报流程 |
执行完告诉用户结果即可,不用走后面的周报流程。
python ${CLAUDE_SKILL_DIR}/cli.py config --get
返回示例(配置不全时):
{"config": {...}, "missing": ["token", "scopes"],
"hints": {"token": "缺 GitHub Token,获取方法:\n1. 打开 https://github.com/settings/tokens/new\n...",
"scopes": "缺 GitHub 搜索范围..."},
"config_file": "..."}
missing 为空 → 配置完整,进入第 2 节missing 不为空 → 把 hints 里对应字段的引导文本原样告诉用户,停下等用户回应命令已经把"怎么补"的引导内置在 hints 字段里,你不需要自己编怎么申请 token、怎么选 scopes 这些文案,直接把 hints 里的字符串贴给用户即可。
规则:
config --set,再重跑 config --get,直到 missing 为空/user 反查 login 填进 username,不要另外问 GitHub 用户名role 只在未接入企微(没配 wecom_corpid/secret)时才会 missing,企微场景下 role 从 whoami.position 自动取,不会被当成 missing由 CLI 内部决定,你只看 fetch / fetch-team 返回的 role 字段即可:
--wecom-userid X 或 --github-login X 时,role 自动取该人员的 positionconfig --set role xxxconfig --get 读 scopes,合并后 config --set scopes "..."config --set token xxx根据今天的实际日期(年月日)推断默认周期。注意使用正确的年份。
日期格式为 YYYY-MM-DD,确保年份正确。
如果用户指定了范围(如"上周的"、"这周的"),以用户为准。
python ${CLAUDE_SKILL_DIR}/cli.py fetch --since {since} --until {until} [--wecom-userid {id}]
搜索主体(搜谁的 author / involves 活动):
--wecom-userid {sender_id},CLI 会查企微数据得到该人的 github_login 作为搜索主体,同时把 position 作为 roleconfig.username 和 config.role返回摘要:
{"status": "ok", "output_file": "...", "pr_count": 6, "issue_count": 9,
"username": "...", "role": "...", "role_source": "whoami.position" | "config.role"}
role 字段就是最终要用的岗位,直接用它生成周报,不用自己再合并。
完整数据 output.json 含 PR 详情、reviews、comments、Issue comments 等。
错误:
auth_failed → token 过期,告诉用户重新生成config_incomplete → 按第 1 节补齐wecom_member_not_found → --wecom-userid 的人在企微里查不到;先跑 wecom-sync 重试,还不行告诉用户共享 claw 部署用的是机器账号 token,只能看到公司 org 的 repo。所以:
org:matrixorigin(及其他公司 org)的所有 PR/Issue/Review 活动个人原型 / 侧项目如果在个人账号下,这个 skill 看不到。如果用户抱怨"我在 repo X 做了很多事你都没写",检查下 X 是不是个人账号下的私有 repo。要解决这个:员工把工作 repo 迁到公司 org,或给机器账号加 collaborator。
不要编造数据。
如果当前环境中有 Memoria(skill 或 MCP),必须在生成周报前主动使用它:
没有 Memoria 则跳过此步。
你拥有以下上下文来生成周报:
role 字段就是最终岗位(CLI 已按优先级 args.role > whoami.position > config.role 解析好)。决定视角、数据主次和组织方式。不同岗位关注的数据完全不同——PR 和 Issue 的权重、详略、呈现角度都应因岗位而异。不要默认以 PR 列表为主体。根据这些上下文,自行决定周报的组织方式、板块划分、详略程度。不要使用固定模板。
硬性要求:开头给一段总结性概览,让 leader 一眼了解全貌。概览中要突出重点事项,尤其是存在风险、阻塞或延期的问题必须明确标出,让 leader 第一时间关注到需要介入或决策的地方。其余全部由你根据岗位特点自行组织。
生成周报后,询问用户:"还有什么要补充的吗?(如会议、评审等非 GitHub 上的工作)"
用户随时可以主动补充,如"加上周三开了需求评审会"。收到补充内容后,必须将其融入周报,重新输出完整的周报。不能只回复"已加入"或"好的"——用户需要看到更新后的完整周报。
默认在聊天中直接展示周报。
如果用户要求"生成文档"或"创建文档":
如果用户要求"生成表格"或"创建表格":
默认且首选:企微部门。团队成员从企微组织架构取(通过企微部门 + 别名字段映射 GitHub 账号)。
只有一种情况走附录 8.A 的 GitHub team 路径:用户字面上主动说"用我的 GitHub team"或"GitHub team slug 是 XXX"。
用户说的任何中文"部门"、"组"、"小组"、"团队"都应按企微部门处理,不要去问 GitHub team slug、组织名、仓库列表。如果企微数据没同步(wecom_not_synced),自己跑 cli.py wecom-sync 补上再继续——不要让用户去找管理员,也不要降级到 GitHub team 路径。
⚠️ 下列子步骤仅在管理员首次部署 skill 时执行一次。日常用户触发团队周报时,企微凭据已配好,直接跳到 8.2。
如果用户提到"企微"、"部门"、"组织架构",且 config 里还没 wecom_corpid,按以下流程:
检查配置中是否有 wecom_corpid 和 wecom_secret。如果没有,告诉用户:
需要企微自建应用的凭据来对接组织架构。请提供:
- corpid(企业 ID)
- secret(应用 Secret)
这些信息可以在企业微信管理后台 → 应用管理 → 自建应用中找到。
用户提供后:
python ${CLAUDE_SKILL_DIR}/cli.py config --set wecom_corpid {corpid} --set wecom_secret {secret}
企微通讯录 API 有 IP 白名单限制。如果 wecom-sync 返回 wecom_ip_whitelist 错误,需要配置一台白名单内的代理机:
python ${CLAUDE_SKILL_DIR}/cli.py config --set wecom_proxy "user:password@host"
格式说明:user:password@host,如 ubuntu:mypass@1.2.3.4。密码中如有 @ 符号,放在最后一个 @ 之前即可。
python ${CLAUDE_SKILL_DIR}/cli.py wecom-sync
返回:
{"status": "ok", "department_count": 50, "member_count": 200, "github_mapped": 180, "github_unmapped": 20}
同步完成后数据保存在 ~/.weekly-report/wecom.json。映射规则:企微通讯录的"别名"字段 = GitHub 用户名。如果 github_unmapped 较多,提醒用户让成员在企微通讯录中填写别名。
python ${CLAUDE_SKILL_DIR}/cli.py wecom-team
展示部门列表。如果用户需要看子部门:
python ${CLAUDE_SKILL_DIR}/cli.py wecom-team --department-id {id}
用户选定部门后:
python ${CLAUDE_SKILL_DIR}/cli.py wecom-set-team --department-id {id}
返回该部门的成员统计和 GitHub 映射情况。配置会持久化,下次直接复用。
同第 2 节,用同样规则。
python ${CLAUDE_SKILL_DIR}/cli.py fetch-team --since {since} --until {until}
参数:
config.wecom_department--department-id {N},不要改默认配置--refresh--source wecom|github 显式返回摘要:
{"status": "ok", "output_file": "...", "team": {"source": "wecom", "department_id": N, "department_name": "..."},
"member_count": 30, "pr_total": 42, "issue_total": 30, "errors": [],
"cache_hit": false,
"subtree_groups": [{"dept_id": N, "dept_name": "...", "member_count": K}, ...],
"unmapped_members": [...]}
关键字段:
cache_hit=true 时说明走了缓存(24h 内同部门+同日期范围已拉过)。如果用户说需要最新数据,加 --refresh 重跑subtree_groups:当前部门的直接子部门分组,团队周报要按这个结构分层呈现unmapped_members:没有 GitHub 映射的成员,告诉用户这些人的数据无法采集完整数据 team_output.json 结构:
{"team": {...}, "members": [...], "data": {login: {prs, issues}},
"errors": [], "subtree_groups": [{"dept_id": N, "dept_name": "...", "members": [logins]}],
"cached_at": "..."}
团队周报有两种视角,生成前必须先判定读者。
按优先级判定:
is_group_chat(在 claw 注入的消息上下文里找)
false(私聊) → 对内(leader 私聊 bot 几乎 = 自己查看团队情况)true(群聊) → 对外(群聊默认是对上级广播,不区分上级群/内部群)用户随后说 "内部版"、"对外版"、"换个视角" → 复用本地 team_output.json 切换生成,不重拉数据。
读者:团队 leader 的上级(可能是总监 / VP / CEO)。时间有限,想看业务进展、风险、需决策事项、跨团队协作。不关心 PR/Issue 计数、代码实现、流水账。
每条业务主线不是本周动作列表,要有 背景 → 本周进展 → 现状/问题 → 下一步 的脉络。读者看完应该知道"这件事发生了什么、到哪了、往哪去",而不只是"做了 X"。
上级级别的读者不关心这些内部细节:
写对外版前,把以上这些从草稿里一律过滤掉。
按业务主题 / 项目 / 客户聚合(如"金盘 ChatBI"、"MOI 平台建设"、"官网改版")。成员作为参与者标签附在项目下,不单独列成员表。
跨团队 = 你这个团队与同级别的其他部门之间的协作,不是你团队内部子组之间的协作。
举例:AI 平台的跨团队 = AI 平台 × 产品组、AI 平台 × 数据平台、AI 平台 × 金盘客户对接方、AI 平台 × 市场/交付组。AI 平台下的前端开发 + 后端开发联调是内部正常工作,不进对外周报。
推荐三段式:
字数按团队信息量弹性:
读者:leader 本人,做团队管理决策。关注业务进展与成员情况。
组织方向:同样按业务主题 / 项目聚合(和对外一致)。差别在:
侧重:
fixes #xxx / closes #xxx / related to #xxx → 把 PR 和 Issue 串成同一件事customer/金盘)下的所有 PR+Issue → 合并讲成一条业务线的完整画面典型:总监 / VP 看下面多个子组(如田丰看研发部 = AI平台 + 数据平台 + ...)。
@张三(AI平台)@李四(数据平台)subtree_groups 只有 1 个或 0 个时按普通团队处理,无特殊分层。
同第 6、7 节。用户可以补充会议、评审、线下工作,融入后重新输出完整周报。
触发:用户说"所有部门周报"、"全公司周报"、"批量生成周报"、"王龙要看的周报" 等。
report_depth 配置批量模式需要知道要汇报到几级部门。跑:
python ${CLAUDE_SKILL_DIR}/cli.py config --get
查看 config.report_depth 字段:
report_depth: 3)→ 直接进 8.6.2批量生成周报时需要知道要汇报到几级部门。比如:
- 2 级:只出一级部门(研发、产品、市场等)和它们的直接子部门(数据平台、AI平台 等)
- 3 级:再往下一层(引擎开发-存储/计算、平台开发 等)
- 4 级:到底(后端开发、前端开发 等)
你们组织通常汇报到几级?(填数字)
收到用户回答后:
python ${CLAUDE_SKILL_DIR}/cli.py config --set report_depth N
python ${CLAUDE_SKILL_DIR}/cli.py list-report-targets --only-with-leader --only-with-members
返回:
{"max_depth": 3, "total": 13, "departments": [
{"dept_id": 2, "name": "研发", "path": "...", "depth": 1, "leaders": ["田丰"], "member_count_subtree": 41},
{"dept_id": 3, "name": "产品", "leaders": ["邓楠"], "member_count_subtree": 8},
...
]}
同第 2 节(今天 2026-04-14 周二 → 上周)。
对 departments 列表的每一项:
fetch-team --department-id {dept_id} --since --untilteam_output.json> 📋 **{部门路径}周报** · {leader 姓名} · {since} ~ {until}
如果某部门某个子部门有独立 leader 且深度在 max_depth 内,它会作为独立一份周报出现(不是嵌套)。上级部门周报里通过 subtree_groups 仍然会覆盖该子部门的内容——存在"同一份工作在不同层级周报里重复出现"的情况。这是预期:
各层级 leader 按需取用,不用怕重复。
最后一份发完后,简短回一句确认:"已完成 N 个部门的周报生成"。
触发门槛很高:仅当用户字面上主动说了 "GitHub team"、"team slug"、或明确要求用 GitHub team 做数据源时才走。中文"部门/组/团队"一律不触发这里——那些走企微部门路径(见 0.4 和第 8 节)。
需要 token 有 read:org。失败返回 insufficient_scope 时让用户重新生成 token 勾上 read:org。
python ${CLAUDE_SKILL_DIR}/cli.py team-discover
返回的 teams:
选定后:
python ${CLAUDE_SKILL_DIR}/cli.py config --set team "{org}/{slug}"
之后 fetch-team 会用这个 team 成员而不是企微部门。