成员填 1 张交付卡
不是“做视频”。而是“本批交2条、谁验、几点前验完”。
先把保底装进产能,再按批次收结果。不是再写一遍工作计划。
不是“做视频”。而是“本批交2条、谁验、几点前验完”。
按时间收结果,优先处理阻断与逾期风险,不替执行人做完。
谁日常催、谁验收、谁有权决定,分别写清,不默认都是你。
同档先看不可延期的时间,再看阻断影响。P0冲突交授权人取舍;新插一件事,要写清哪件事减量、移后或增援。
这是条件示例,不是通用配额。若最低需求是每周3条,保底可能仍为12;若只有6条有效需求,保底也可为6。已确认硬承诺未经同意不能降低;质量和合规底线不能减。
① 成员填手上所有事项 → ② 统筹合并同类结果、检查每人产能 → ③ 授权人确认本周保底与日期 → ④ 写回原飞书任务 → ⑤ 按时间清单收结果。
建议每天只回报:已验收结果链接、下批能否按时交、卡点需要谁几点前处理。每周核对原承诺的按时交付;计划改动保留原数量/原日期、新安排、批准人和原因,不改小分母美化兑现率。
建议每人先限制1件主要交付并行,其他排队;是否适用由实际岗位确认。量先稳定,流程再优化,效果后优化;基本正确性与审核从第一天保留。
仅当前页面内存保存;离开前请下载。未上传、未同步、未派单。正式任务沿用原飞书记录。
填净可排人时:实际出勤 − 已知日常工作 − 本模板之外已承诺的工作 − 异常缓冲。本页不会再次扣减。加入所有执行人和验收人。
这里只核算填写的P0/P1保底,不代表全公司已完成产能核算。等待审核不等于全部人工时;目标增加量需另估后再排。
建议安排 · 未下发。按北京时间排序,不代表自动提醒。没有完整时间的事项在下方列为待补,不会静默消失。
①核实硬承诺与人时 → ②执行人确认能做 → ③验收人确认标准与审核时间 → ④授权人拍板保底/期限 → ⑤写回原飞书任务,留下确认记录。
完成只认“验收通过+结果凭据”。记录原保底、原截止、已验收数、按时验收数;不同单位不相加。改期/减量必须留前后变化及批准记录。没有验收结论只叫“已交稿”,不叫“已完成”。
skill是给AI用的工作方法,不会替团队自动执行或让承诺生效。
适合每周排产:先算可用人时,再选工作、排依赖,装满就停止增加。需把软件开发用语改成我们的件数、成片、验收凭据。
已读取该SKILL.md并核对目录,目录仅此文本文件;未执行。尚未完成完整仓库克隆审计,不能认定全包安全。建议只将这一项列入待审候选,不安装整个技能包。本模板独立编写,不把远程文本作为执行指令。
适合公司取舍:当前做、下一步做、以后做;插入新事项时说明哪些事项让路。它不是逐件追交付的完整模板。
已读正文、核对该目录仅SKILL.md;引用上级连接器说明,接入项目工具后可能提出更新记录。未审查全部连接器、未安装或执行,不授权自动修改现有任务。只借鉴取舍和依赖的管理思路。
偏大型软件项目组合、风险模型及管理报告。当前先抓基础交付,这一套负担较重。
目录含脚本、参考和资源,脚本未审查、不执行。SKILL头标MIT + Commons Clause,GitHub官方接口未识别标准许可;商业使用限制需另核。未安装。
核对日期:2026-09-30;star来自各仓库GitHub官方接口,仅代表仓库关注度,不是单项下载数或安全证明。官方openai/skills精选列表未发现直接匹配本需求的专门模板。任何安装另经本地审计与确认。
若浏览器没有开始下载,可复制下面文本另存。离开前请确认文件已保存;这里不自动上传。