md-report-summary

Markdown Weekly Report / Report / Summary / Introduction

I. Task Identification

Document Type	Trigger Words
Weekly Report	Weekly report, this week's summary, weekly report
Work Report	Work report, report materials, progress report
Summary	Summary, retrospective, phase summary, project summary
Introduction	Introduction, overview, project introduction, personal introduction

Weekly Report Type Selection

After identifying a "weekly report" type task,first ask the user to choose the weekly report type, then continue with the subsequent process:

Please choose the weekly report type (default: Results-Oriented Weekly Report):

1. Results-Oriented Weekly Report — APB(Default) — Accomplishments · Plans · Blockers, quantified results / next steps / needed resources and assistance, suitable for upward reporting or cross-team alignment
2. Standard Weekly Report — 3P Report — Progress · Plans · Problems, completed this week / in progress / next week's plan / issues and risks, suitable for internal team synchronization

When the user does not specify a type, use by defaultResults-Oriented Weekly Report. After the user selects, execute the subsequent process according to the corresponding template.

II. Process Branches

Situation	Execution
No draft provided	Execute "III. No-Draft Process"
Draft provided	Execute "IV. Draft Process"

III. No-Draft Process

1. Confirm information: Confirm with the user the topic, time range, audience, and key direction
2. Web search: Use WebSearch to search for relevant background, industry progress, and best practices (search results are for reference only and must not be copied directly)
3. Choose template: According to reference/templates.md select the corresponding template
4. Write: Fill in content according to "VI. Writing Quality Standards" and output

IV. Draft Process

1. Read draft: Read the draft from the content pasted by the user or the file path
2. Analyze draft: Identify structural completeness, omissions, and expressions that can be optimized
3. Organize output：

• Tables, lists, blockquotes, data, imagesare all retained as-is, without deletion or summarization
• Image reference ![描述](路径) paths must not be modified and must be retained as-is
• Polish sentences, straighten out paragraph logic, and add transitional phrases
• Missing sections may be supplemented with WebSearch , but must be marked as supplementary content

1. Output: The complete organized Markdown

V. General Principles

• Do not omit: When there is a draft, all original content (tables, data, images, blockquotes) is retained
• Do not fabricate: Do not fabricate facts that do not exist in the draft; supplementary content from searches must be summarized and not exaggerated
• Images as-is：![描述](路径) The paths in must never be modified
• Consistent formatting: Clear heading hierarchy, use lists and tables as needed, do not overuse bold

VI. Writing Quality Standards

High-quality output must meet the following requirements:

Content level

• Has conclusions, not just statements: Each work item should clearly state "what was done → what the result/progress is", rather than merely listing actions
  • 🚫 Bad:完成了模型测试
  • 👍 Good:完成 Qwen3.5-122B-A10B-AWQ 在 4×24G NVIDIA 环境下的高考模拟卷测试，错题率降至 1/18，推荐作为 NVIDIA 多卡方案首选
• Specific data: Preserve quantitative information such as time, quantity, and percentages as much as possible
• Clear problem identification: Problem descriptions must include the three elements "phenomenon → root cause → scope of impact"
• Executable plans: Next week's plan must be specific, clearly state goals and expected time, and do not write empty phrases like "continue to advance"

Structural level

• Usesubheadingsto distinguish different business modules and avoid cramming all content into one list
• For multiple work items, prioritize usingtablesto present comparisons (such as model test results), clearly and intuitively
• Important conclusions or recommendations can be highlighted with **blockquotes (>)**

Language level

• Active voice, concise and direct
• Retain professional terminology (such as model names, parameter names, configuration specifications), and do not translate it into vague expressions
• Use consistent wording for the same thing throughout

VII. Reference Resources

• Template files:reference/templates.md