Skill Hub — Work Documentation and Handover

Meeting Notes to Action Log Working Skill

Convert raw meeting notes into a structured action log with owners, deadlines, and dependencies so decisions become executable tasks.

What this skill is for

Meetings produce decisions, but decisions do not become work until someone is assigned, a deadline is set, and dependencies are understood. This skill converts raw meeting notes into an Action Log: a structured list of tasks that can be tracked, reported, and completed. The output is designed to bridge the gap between conversation and execution. It is different from convert-notes-to-requirements, which produces requirements documents, not task lists. This skill produces actionable tasks with owners and deadlines that can be entered into a project management tool, a ticketing system, or a shared tracker.

When to use this skill

A meeting has ended and the team needs to know who is doing what by when.
Meeting notes are verbose and unstructured, and the project manager needs a clean task list for tracking.
A steering committee or working group meets regularly and needs consistent action tracking across meetings.
An AI agent has generated meeting notes and a human needs to verify and convert them into trackable actions.
A retrospective or review meeting produced observations that must be turned into improvement tasks.

Real work situations

SAP project: status meeting with scattered actions

A weekly SAP project status meeting produces three pages of notes: updates on development, testing delays, and a discussion about a BP replication issue. Buried in the notes are four implicit tasks: the basis team must increase the RFC connection limit, the functional team must re-test the BP relationship scenario, the project manager must schedule a steering committee update, and the integration team must fix a mapping error. Without an action log, two of these tasks are forgotten by the next meeting, the mapping error becomes a production incident, and the steering committee update is missed.

Data governance: workshop with decisions but no owners

A data governance workshop produces a whiteboard full of decisions: standardize material group codes, clean duplicate vendor records, define a new data quality rule, and implement a governance dashboard. The notes say "we agreed to do this" but do not say who will do it or by when. Without an action log, the workshop energy dissipates. Two weeks later, nothing has happened. The duplicate vendor records continue to block purchase orders.

Support operations: incident review meeting

An incident review meeting discusses a recent SAP IDoc failure. The notes mention that monitoring is insufficient, error handling is unclear, and the runbook is outdated. The implicit actions are: add a new alert for status 51 IDocs, update the error handling procedure, and revise the runbook. Without an action log, these improvements are discussed but never executed. The same incident type happens again the following month.

Inputs required

Raw meeting notes, transcript, or recording showing what was discussed and decided.
Attendee list with roles, so actions can be assigned to the right people.
Project or support tracker context, so action IDs and statuses can be aligned with existing work.
Previous action log from the last meeting, to carry forward incomplete actions.
Deadline constraints: sprint end, milestone date, go-live date, or SLA target.
Decision log or meeting agenda, to separate pre-planned topics from emergent actions.

Questions to ask

What was decided in the meeting? Decisions are not actions; actions are what must happen to implement the decision.
Who said they would do something? If no one volunteered, who is the right owner?
By when must this be done? If no deadline was mentioned, what is a realistic date?
What does this action depend on? Does it need another action, a decision, or a resource first?
Is this action new, or is it a continuation of a previous action? If it is a continuation, link to the previous action ID.
Is this action a task, a decision, or information? Tasks belong in the action log. Decisions belong in the decision log. Information belongs in the minutes.
What is the definition of done? How will the owner know the action is complete?

Working method

Read the notes and mark potential actions. Go through the notes and highlight every sentence that implies someone must do something. Use a different color for decisions, questions, and information.
Separate decisions from actions. A decision is "we will use SAP PI." The action is "the integration team will create the PI configuration document by Friday." Put decisions in the decision log, not the action log.
Convert each action into a task statement. Rewrite each action as a clear, specific task: "Who does what by when." Avoid vague phrasing like "look into" or "consider." Use verbs: write, review, test, deploy, update, confirm.
Assign an owner. Name the person who is accountable for completing the task. If the owner is unclear, assign the person who has the authority or skill to do it, and confirm with them. Never leave an action unassigned.
Set a deadline. Use the meeting context, sprint dates, or milestone dates to set a realistic deadline. If no deadline is possible, set a review date. Actions without deadlines are wishes, not work.
Identify dependencies. For each action, list what must happen before it can start. If an action depends on another action in the same log, link them by ID. Flag blockers explicitly.
Define done. State what the output or outcome is. For example: "Definition of done: updated runbook published to the wiki and link shared in the team channel."
Carry forward incomplete actions. Compare the new action log with the previous one. Carry forward actions that are still open, updating status and expected completion date.
Write the Action Log. Use the template below. Include meeting reference, action ID, task, owner, deadline, dependency, status, and definition of done.
Distribute and track. Share the action log with all attendees within 24 hours of the meeting. Enter actions into the project tracker or ticketing system. Review open actions at the start of the next meeting.

Decision rules

If an action has no owner, assign one immediately or escalate to the meeting chair. Do not leave it unassigned.
If an action has no deadline, set a default deadline based on the meeting cadence. Weekly meetings get one-week deadlines unless otherwise specified.
If an action is a decision, move it to the decision log. If it is a question, move it to a questions list or parking lot.
If an action is too large, break it into smaller actions with intermediate milestones. Do not create a single action that spans multiple weeks with no intermediate check.
If an action repeats across meetings, convert it into a recurring task or a process improvement, not an infinite action log entry.
If an action depends on an external party, flag the external dependency and set a follow-up date. Do not assume the external party will deliver on time.

Deliverables

Action Log — Structured task list per meeting, with owners, deadlines, dependencies, and status. See template below.
Carry-Forward Report — List of actions from previous meetings that are still open, with updated status and revised dates.
Decision Log Extract — Decisions captured during the meeting, separated from the action log for clarity.

Templates

Action Log (compact)

---
artifact: Action Log
meeting: <Meeting name>
date: YYYY-MM-DD
facilitator: <Name>
scribe: <Name>
status: draft | reviewed | distributed
---

## Carry-Forward Actions (from previous meetings)
| ID | Task | Owner | Deadline | Status | Notes |
|----|------|-------|----------|--------|-------|
| A-2026-001 | <Task> | <Owner> | YYYY-MM-DD | <open | done | blocked> | <Update> |

## New Actions (from this meeting)
| ID | Task | Owner | Deadline | Dependency | Status | Definition of Done |
|----|------|-------|----------|------------|--------|---------------------|
| A-2026-005 | <Specific task> | <Owner> | YYYY-MM-DD | <Dependency or blocker> | open | <Outcome> |
| A-2026-006 | <Specific task> | <Owner> | YYYY-MM-DD | A-2026-005 | open | <Outcome> |

## Decisions Made (for reference, not action log)
| Decision | Implied Action | Action ID |
|----------|---------------|-----------|
| <Decision text> | <Task derived from decision> | A-2026-005 |

## Blockers and Escalations
| Blocker | Affected Actions | Escalation Path | Follow-up Date |
|---------|-----------------|-----------------|----------------|
| <Description> | <Action IDs> | <Who to escalate to> | YYYY-MM-DD |

Quality checklist

Every action has a specific, verb-led task statement.
Every action has a named owner who has been notified.
Every action has a deadline or a review date.
Dependencies are identified and linked to other actions or external deliverables.
Decisions are separated from actions and stored in the decision log.
Incomplete actions from previous meetings are carried forward with updated status.
Each action has a definition of done that is verifiable.
The action log is distributed within 24 hours of the meeting.

Common mistakes

Recording decisions as actions without converting them into tasks. Consequence: the action log says "decide to use PI" but no one is tasked with creating the PI configuration. The decision sits idle.
Using vague task statements like "look into the issue." Consequence: the owner does not know what to do, and the task is never completed because the definition of done is unclear.
Leaving actions unassigned. Consequence: the task is not done. Unassigned actions are orphan tasks that no one owns.
Setting unrealistic deadlines to please stakeholders. Consequence: deadlines are missed, trust erodes, and the action log becomes a fiction document.
Creating mega-actions that span weeks. Consequence: the action is never completed because it is too large, and progress is invisible. Break it into smaller tasks.

Weak output vs Strong output

Weak output

A copy-paste of meeting notes with no structure: "We discussed the BP replication issue. The basis team said they would check the RFC connections. The functional team needs to test the relationship scenario. The PM should update the steering committee. Someone needs to fix the mapping error." No owners, no deadlines, no action IDs, no dependencies, no definition of done. The PM must re-read the notes every week to remember what was supposed to happen.

Why it fails: The team cannot track progress. Tasks are forgotten. Dependencies are invisible. The meeting was a waste of time because nothing gets executed.

Strong output

---
artifact: Action Log
meeting: Weekly SAP Project Status — Sprint 4
date: 2026-06-10
facilitator: P. Jensen
scribe: M. Chen
status: distributed
---

## Carry-Forward Actions
| ID | Task | Owner | Deadline | Status | Notes |
|----|------|-------|----------|--------|-------|
| A-2026-042 | Update BP replication error handling in ZIDOC_ALERT | T. Nguyen | 2026-06-05 | done | Runbook updated and published |
| A-2026-043 | Schedule steering committee update for go-live readiness | P. Jensen | 2026-06-08 | open | Waiting for test completion report |

## New Actions
| ID | Task | Owner | Deadline | Dependency | Status | Definition of Done |
|----|------|-------|----------|------------|--------|---------------------|
| A-2026-050 | Increase RFC connection limit to 20 for BP replication | Basis Team | 2026-06-12 | None | open | SM59 shows 20 connections; test BP sync succeeds |
| A-2026-051 | Re-test BP relationship scenario for customer-vendor pairs | M. Chen | 2026-06-14 | A-2026-050 | open | Test cases pass; no status 51 in SMW01 |
| A-2026-052 | Create PI mapping correction for delivery block field | K. Schmidt | 2026-06-13 | None | open | Mapping updated in PI; test IDoc processes correctly |
| A-2026-053 | Send steering committee update with go-live readiness summary | P. Jensen | 2026-06-15 | A-2026-051 | open | Email sent with attached readiness report |

## Blockers
| Blocker | Affected Actions | Escalation Path | Follow-up Date |
|---------|-----------------|-----------------|----------------|
| Test client 300 is down for patching | A-2026-051 | Basis Lead | 2026-06-11 |

Agent instructions

AI Prompt Pattern

Role: Meeting action log writer for an enterprise project.

Context: You have raw meeting notes, a transcript, or a recording. You need to convert them into a structured Action Log that can be tracked in a project management tool or ticketing system.

Task: Extract actions, assign owners, set deadlines, identify dependencies, and define done. Separate decisions from actions. Carry forward incomplete actions from previous meetings.

Output format: Structured Action Log in Markdown with tables for carry-forward actions, new actions, decisions, and blockers.

Never leave an action unassigned. If the owner is unclear, assign the most likely person and flag for confirmation.
Always convert decisions into specific tasks. "Decide to use X" becomes "Create X configuration document by [date]."
Always set a deadline. If no deadline is mentioned, use the meeting cadence as a default. Weekly meeting actions get one week.
Always define done. The definition of done must be verifiable: a document published, a test passed, an email sent.
Separate decisions from actions. Decisions go in the decision log. Actions go in the action log. Do not mix them.
Carry forward incomplete actions. Compare with the previous action log. Update status and revised dates.
Do not invent owners or deadlines. If uncertain, use "TBD" and flag the action for clarification.

Related skills

Decision Summary Writing Working Skill — Use to document decisions that are separated from the action log during conversion.
Convert Notes to Requirements Working Skill — Use when meeting notes contain requirements that need structured documentation, not task tracking.
Status Update Writing Working Skill — Use to report on the progress of action log items.
Handover Note Writing Working Skill — Use to package open action log items into a handover package.

Related Atlas pages

SAP Process Audit — Context for process review meetings that generate action items.
Operational Memory for SAP AMS — Framework for capturing meeting outcomes as operational memory.

Verification status and limitations

This skill is a public working interpretation of meeting documentation practices. It is not official ITIL, BABOK, or SAP documentation. It focuses on the practical task of converting conversation into trackable work in enterprise and SAP contexts.

Known limitations: the skill assumes meeting notes exist and are readable. It does not cover facilitation techniques, meeting design, or conflict resolution. It does not integrate with specific project management tools; the output is a Markdown artifact that can be copied into Jira, Azure DevOps, SAP Cloud ALM, or any other tracker. The templates should be adapted to the organization's tracking tool and naming conventions.