WorkBuddy Practice: Dropping Incident Materials into Fixed Directories Helps Draft Post-Mortems

Local file automation tools like WorkBuddy are better suited for organizing scattered items from CSVs, chat logs, monitoring screenshots, and change tables into verifiable structures. Figuring out the root cause still relies on humans. I've used WorkBuddy for about a month. When handling reimbursement forms earlier, I found that breaking complex tasks into single operations and solidifying templates is more stable. Recently, I saw a case study of a P0 incident (highest priority online outage) where a post-mortem compressed three hours into forty minutes. Coincidentally, my club project had an API timeout last week, so I gave it a try. My judgment is that WorkBuddy saves time mainly by turning materials scattered across multiple places into a repeatable input-output set.

That day, I had six types of materials on hand, including alert CSVs, duty WeChat screenshots, monitoring PDFs, change record Excels, group chat txt files, and the previous incident document. Formats varied, and time standards differed. If I threw them directly at a chat model, I'd have to copy segment by segment, possibly exceeding the context limit. So I opened WorkBuddy and selected "Ops Expert" on the task page. To explain, "Ops Expert" is a scenario template I saw, suitable for handing alerts, logs, and changes over for preliminary organization. Then I clicked Authorize File Directory. A popup asked me to select a local folder, meaning it could only read content within that folder. I didn't select the entire desktop; instead, I created a new folder named incident-review, subdivided by purpose into alerts, chat, monitoring, changes, duty, and history. After confirming, the authorized path appeared above the input box, and only then did I place the files inside.

When inputting instructions, I didn't just write "help me generate a post-mortem report." I asked it to first read all subdirectories under incident-review, outputting a timeline, 5Why root causes, an action item table, and a PPT outline. Here, 5Why means continuously asking "why" until digging up process or design-level causes, avoiding stopping at "recovered after restart." I also added acceptance criteria: the timeline should not exceed ten key nodes, recovery actions cannot be listed as root causes, action items must have owners and deadlines, and output files should go to output. After clicking Execute, the interface entered Agent mode, meaning it broke down steps and executed them itself. I could see it listing stages like reading alerts, aligning times, reading changes, and generating reports, but the intermediate process was basically a black box with no streaming output; I had to wait for a full round to finish before asking follow-ups. If smooth, a post-mortem Markdown and an action item Excel would appear in output.

The first result wasn't bad, but there was an obvious pitfall. The timestamps in the alert CSV were UTC (Coordinated Universal Time), while chat logs and duty schedules were in local time. WorkBuddy placed both directly on the same timeline, making the first few alerts appear eight hours earlier than the group chat responses. This error wasn't surprising since the materials didn't specify time zones clearly. Later, I added a time_rule.md in the root directory, explicitly stating "alerts are UTC, output converted uniformly to UTC+8, chat and duty are local time." After rerunning, the timeline normalized. This pitfall reminded me that when material volume is large, don't expect a perfect draft in one go. Let it do the timeline first, then run root causes and action items separately, which is more stable.

I was also conservative with permissions. Since WorkBuddy needs to read local files, I only authorized the current incident directory, not the entire document drive. Duty screenshots contained some classmates' phone numbers, which I didn't let it touch; I manually masked them first. The output directory output generated Markdown (a plain text format) and Excel, suitable for my secondary editing. When showing the club lead, I only sent the report and action items from output, keeping raw materials private. I didn't let it fill in owners and deadlines directly; I left them as "To Be Confirmed" for the actual duty personnel to complete. This way, it handles organization, and humans handle verification, ensuring generated content isn't taken as final conclusions.

After using it for a month, I feel WorkBuddy's boundaries are also clear. It can't connect directly to alert systems; materials must be exported manually. Agent mode doesn't execute much faster, and details aren't visible mid-process. The final generated text still leans towards official documents, and root cause analysis requires human judgment. But its value in handling messy local files is indeed stronger than pure chat models, especially since it can read different formats like CSV, Excel, and PDF, and deliver several files according to fixed directories. My current habit is to archive materials and templates together after each incident, naming files with dates, so next time I only change the time range and key events.

So if you're using WorkBuddy for a post-mortem for the first time, I suggest not aiming for full automation right away. Start with a set of no more than twenty files, create a fixed directory, write time zones, fields, and acceptance criteria into a readme file, then let it run the timeline. Once that works, save the instruction as a template. Future use becomes easier, mainly relying on this directory and template structure being reusable by you.