Writing Weekly Reports, Proposals and Tech Docs with WorkBuddy

By the end of this article you'll be able to use Tencent WorkBuddy for all three common writing jobs — weekly reports, proposals and technical documents — and know how to take a first draft to something you can send as-is.

1. Give It Material First, Then the Instruction

Bad documents are usually not a writing problem — the model simply doesn't have the facts. WorkBuddy reads the files you've authorized and any material you reference with @ in the input box, then organizes content from that. Before you start, put this week's chat logs, meeting notes, data sheets and the previous version of the document into the workspace, and state in the instruction: "Use only the material below; flag anything missing and ask me."

If there really is no material, dictate the key points yourself, one per line. Ten bullet points will get you much further than a single "write me a weekly report".

2. Weekly Reports: Compress Scattered Progress into Three Sections

The structure never changes: what you did this week, what came of it, and next week's plan plus risks. You can put the template straight into the instruction:

• Completed this week: grouped by project, each entry stating "action + result + data".
• In progress and blockers: who it's waiting on and what support is needed.
• Next week: three to five items in priority order.

Sample instruction: Write a weekly report from the meeting notes and task list above. Three sections, no more than two lines per item, don't invent numbers where there's no data — mark those "to be confirmed".

3. Proposals and PRDs: Ask for an Outline, Then Fill It In

Don't try to produce a long document in one shot. Have it output the outline and key points for each section first; once you've confirmed the structure, expand section by section. That's the cheapest way to revise. A PRD should cover at minimum background and goals, users and scenarios, functional scope, interaction flow, acceptance criteria, schedule and dependencies. For the scope section, make it state explicitly what you are not doing — that saves a great deal of arguing later.

4. Technical Documents and READMEs

The readers here are colleagues and your future self, so what matters is that it's actionable. Reference the project directory or key files with @, have it map out module responsibilities first, then write the four blocks: installation, configuration, running, and common issues. Run commands must come from real files — don't let it fill them in from memory. When it's done, have it self-check in the same task that the commands match the repository.

5. Multi-Round Revision and Tone Control

Once you have a draft, revise along one dimension at a time — "cut it to one page", "shift the tone toward reporting upward", "unify terminology". Keep asking follow-ups in the same task so it retains the earlier context; that's more reliable than starting a new task each time. Asking for two versions side by side is also faster than fine-tuning back and forth.

6. Review and Delivery

Three checks before delivery: do the numbers and facts match the source material, has it added conclusions of its own, and is the formatting consistent. You can have it output a separate "changes and open questions" list for you to confirm item by item. Once final, export Word from the results panel or copy it into your document system. For anything important, still read it through yourself.

If you want to walk through the basics first, see the hands-on tutorials.