final-task-report
GitHub用于在任务完成后生成最终 Markdown 交付报告。该技能指导智能体基于实际完成的工作,按照指定结构编写包含任务描述、实施细节及特殊说明的报告,并保存至本地文件,确保内容真实且便于阅读。
Trigger Scenarios
Install
npx skills add waltstephen/ArgusBot --skill final-task-report -g -y
SKILL.md
Frontmatter
{
"name": "final-task-report",
"description": "Use when the main execution agent must produce a final Markdown delivery report after the task is complete, especially when reviewer status is done and the report must be saved to a specific local file for human\/mobile reading and bot delivery."
}
Final Task Report
Use this skill only in the final handoff phase.
Goal
Produce one Markdown report file that a user can read directly on phone or desktop.
The report must stay grounded in the actual work completed in the repository and current session. Do not invent experiments, datasets, or code changes.
This skill is meant to be updated over time as the reporting format evolves. Main agent should follow this skill directly for final report generation.
Required Sections
Always include these sections in order:
## 0. Original User Taskor## 0. 原始用户任务## 1. What This Task Proposedor## 1. 本次实验提出了哪些点## 2. How It Was Done and What Data Was Usedor## 2. 具体是怎么做的,使用了什么数据## 3. What the Main Agent Changed, What Approach It Used, and What Experiments It Ranor## 3. main agent 修改了什么,使用了什么思路,跑了什么实验## 4. Special Notesor## 4. 特殊说明
If the task context is mixed-language, bilingual section titles are acceptable.
Content Rules
- Summarize only completed work.
- If no dataset was used, write
未使用ornone. - If no experiment was run, write
未运行额外实验ornone. - Include the original user task and any explicit user follow-up requirements.
- Special Notes should capture:
- maintenance rules
- user-visible caveats
- follow-up constraints
- any special thing the user explicitly asked to be highlighted
- Do not infer or mention unrelated internal skill context. User requirements are enough.
- Prefer the language of the user task:
- Chinese task -> Chinese report
- English task -> English report
- mixed context -> bilingual or mixed headings
- Prefer concrete evidence:
- files changed
- commands/checks run
- observed outputs
- validation results
- Keep it readable on mobile:
- short paragraphs
- flat bullets
- avoid long walls of text
Write Contract
- Write to the exact file path requested by the caller.
- Do not rename the output file.
- Do not create multiple alternative reports unless explicitly requested.
- After writing, reply only with the final file path/status if the caller asks for a terse machine-readable response.
Version History
- c2efd8d Current 2026-07-25 09:25


