Weekly Review Builder
Compress one week's activity into an updated, honest project state. Prevent long-term drift.
Input
Required:
- -
project_card — full project card with current state, goals, phase - INLINECODE1 — array of 5-7 daily loop logs from this week
- INLINECODE2 — decisions made during the week
- INLINECODE3 — tangible outputs produced this week
- INLINECODE4 — tasks that were planned but not completed
Optional:
- -
blocked_tasks — tasks that failed due to blockers
Output Schema
CODEBLOCK0
Rules
- 1. Must remove outdated actions. If a planned task wasn't touched, mark it stale and either drop or reschedule it.
- Must identify the single current bottleneck. Not 3, not 5 — one.
- Must distinguish progress from activity. Meetings attended ≠ progress. Code shipped ≠ impact. Be precise.
- Must be honest if no real progress was made. Say so. A stagnant review is better than a flattering one.
- Evidence-based only. Do not update phase or bottleneck without supporting evidence from logs.
Review Phases
Phase 1: Log Compression
- - Read all weeklydailylogs
- Extract: findings, decisions, completions, blockers
- Separate actual progress from busy-work
Phase 2: Gap Analysis
- - Compare weeklyoutputs against weeklydailylogs stated objectives
- Identify: what was claimed vs what was delivered
- Mark staletasks as resolved or remaining
Phase 3: State Refresh
- - Update current_phase based on evidence (not ambition)
- Identify current bottleneck (the one thing blocking most progress)
- Assess risk: what's the biggest threat to the project right now?
Phase 4: Forward Planning
- - Set nextweekgoal (one clear goal)
- List next3actions (ranked by impact)
- Write onepageproject_summary for human readability
Phase 5: Writeback
- - Populate reviewwriteback with structured record
- Set reviewconfidence based on evidence quality
Failure Handling
If evidence is insufficient (e.g., logs are missing, can't determine progress):
- - Mark INLINECODE6
- Do not fabricate phase changes or bottleneck updates
- Request missing log recovery before completing review
- Write partial review with explicit gaps noted
每周回顾生成器
将一周的活动压缩为更新后的、真实的项目状态。防止长期偏离轨道。
输入
必需：
- - projectcard — 包含当前状态、目标和阶段的项目卡片
- weeklydailylogs — 本周5-7天的每日循环日志数组
- weeklydecisions — 本周做出的决策
- weeklyoutputs — 本周产出的有形成果
- staletasks — 已计划但未完成的任务
可选：
- - blocked_tasks — 因阻碍因素而失败的任务
输出结构
updatedcurrentphase: string # 更新后的项目阶段
updatedcurrentbottleneck: string # 当前最关键的一个阻碍因素
nextweekgoal: string # 下周的单一明确目标
next3actions: string[] # 下周最重要的3项行动
risk_check: string # 对当前风险的诚实评估
onepageproject_summary: string # 压缩后的项目状态（≤300字）
review_confidence: high | medium | low
review_writeback: object # 用于项目记忆的结构化记录
staletasksresolved: string[] # 本周已清理的任务
staletasksremaining: string[] # 仍待处理的任务
规则
- 1. 必须移除过时的行动。 如果计划的任务未被触及，将其标记为过时，要么放弃要么重新安排。
- 必须识别出当前唯一的瓶颈。 不是3个，不是5个——只有一个。
- 必须区分进展与活动。 参加会议≠进展。代码提交≠影响。要精确。
- 如果没有真正进展，必须诚实说明。 如实陈述。停滞的回顾比粉饰的回顾更好。
- 仅基于证据。 没有日志中的支持证据，不要更新阶段或瓶颈。
回顾阶段
阶段1：日志压缩
- - 阅读所有weeklydailylogs
- 提取：发现、决策、完成项、阻碍因素
- 区分实际进展与无效忙碌
阶段2：差距分析
- - 将weeklyoutputs与weeklydailylogs中陈述的目标进行对比
- 识别：声称的内容与实际交付的内容
- 将staletasks标记为已解决或待处理
阶段3：状态更新
- - 基于证据（而非雄心）更新current_phase
- 识别当前瓶颈（阻碍大部分进展的那一件事）
- 评估风险：当前项目面临的最大威胁是什么？
阶段4：前瞻规划
- - 设定nextweekgoal（一个明确目标）
- 列出next3actions（按影响排序）
- 撰写onepageproject_summary以便人类阅读
阶段5：回写
- - 用结构化记录填充reviewwriteback
- 根据证据质量设定reviewconfidence
失败处理
如果证据不足（例如，日志缺失，无法确定进展）：
- - 标记review_confidence = low
- 不要捏造阶段变更或瓶颈更新
- 在完成回顾前请求恢复缺失的日志
- 撰写部分回顾，明确标注存在的缺口
