会议纪要整理器

The most common post-meeting trap is not that nobody took notes, but that the material is too raw to act on. A transcript of a few thousand words where the actual decision was one sentence. Chat logs where the conclusion is buried an hour in, buried among small talk, and the action items are scattered across different people's messages. Hand-written notes are even worse: numbers and arrows on the page, and no one knows which one is who's, or when it's due. Pass this kind of input to a generic chat model with "write a meeting summary" and it either over-summarizes and drops the details that matter, or smartly "infer"s owners and deadlines that were never actually said into the room. This skill is not a prompts-for-nice-text thing; it's a processor with a defined input format and defined output fields, taking in raw material and producing a verifiable, trackable artifact.

Source type comes first

After triggering, the first action is to determine the shape of the source. The four common forms are each handled differently:

• Full transcription: direct structured extraction, keeping the original discussion thread as intact as possible.
• Scattered notes: patch the logical connections, but mark the information that the notes did not contain; do not fill it in silently.
• Chat records: extract only the decisions and tasks relevant to the meeting's subject, and skip the rest of the chatting.
• Verbal key points: turn the colloquial "basically this was decided" into formal, quotable statements.

Four extraction channels run side by side

The generic model's strength is making output read smooth, and its weakness is that the smoother the reading, the easier it is to lose information. Here, four independent extraction channels cover the material out, and each one's output is within its own lane:

1. Decisions: items that the group explicitly agreed and settled on—the outcome, not the impression.
2. Action items: each needs the three elements of who + what to do + by when. If one is missing, it's marked as a missing piece of information, rather than being guessed from the context.
3. Discussion points: key viewpoints and differences, kept in the participants' original positions, not folded into a fake consensus of "everyone agrees".
4. Background information: project context, goals and constraints, so reading the summary later can restore the scene and why some decisions were made.

Output and tracking list

The summary is output in a standard structure that can be quickly scanned and archived. A separate action item tracking list is produced in parallel: each item is numbered, with the original source, and the owner and time are noted as "determinable" or "pending confirmation". The list keeps a text format that can be directly pasted into task tools such as ClickUp, Jira, and Feishu Tasks, without re-keying in the database by hand.

Quality checks and boundaries

A built-in checklist runs item by item before and after the output, looking specifically at "does the decision match the source material" and "is the vague information marked as pending confirmation". The bottom line is that no decisions or action items may appear that are not in the material. If the person's name or time is not complete, leave it blank and mark it instead of filling it in with a plausible-looking name or date. Sensitive content is flagged at the source material's confidentiality level. For overly long sources, split them into segments to process and then merge, to avoid losing the tail section to the context window.