Skill Hub — Productivity and Execution Control

Task Clarification Working Skill

Turn a vague or ambiguous task into a clear, actionable work item with defined inputs, outputs, success criteria, and ownership so the assignee can start immediately and finish with confidence.

What this skill is for

Most project delays start with a poorly defined task. A ticket says "fix the integration issue" or a meeting note says "review the process." No one knows what done looks like, what information is needed, or who decides whether the result is acceptable. This skill converts vague assignments into a Clarified Task Brief: a one-page document that states the task, the inputs, the expected output, the acceptance criteria, the owner, and the deadline. The brief becomes the contract between the requester and the assignee. It eliminates ambiguity, prevents rework, and makes progress measurable.

When to use this skill

A task is assigned with a single sentence or a vague subject line.
Two people interpret the same task differently and produce conflicting results.
A task has been open for days with no progress because the assignee does not know where to start.
A task is returned as "not what I asked for" even though the assignee followed instructions.
An AI agent is being asked to perform work and the prompt is ambiguous or underspecified.
A work package from a WBS needs to be converted into an executable task for a single owner.

Real work situations

SAP support ticket: "Customer master is wrong"

A ticket arrives with the subject "Customer master is wrong." The assignee spends two hours trying to identify which customer, which field, and what "wrong" means. After back-and-forth messages, it turns out that the payment terms are outdated for one customer in one company code. A Clarified Task Brief would have stated: "Update payment terms for customer C-10001 in company code 1000 from ZB30 to ZB15. Input: current customer master record. Output: updated customer master with payment terms ZB15. Acceptance: customer record displays ZB15 in XD03 and the change is logged in the change log. Owner: support analyst. Deadline: 2026-06-14." The task would have been completed in 15 minutes.

Project task: "Improve the reporting process"

A project manager assigns a task: "Improve the reporting process." The analyst produces a 20-page document proposing a new data warehouse. The manager wanted a one-page checklist to reduce report generation time from 30 minutes to 10 minutes. A Clarified Task Brief would have asked: what is the current time? What is the target time? What is the scope of reports? What is the budget for tools? The brief would have prevented the mismatch and saved a week of wasted work.

Integration task: "Handle the IDoc error"

An operations lead assigns: "Handle the IDoc error." The developer reprocesses the IDoc. The business user complains that the root cause was never identified and the error will recur. A Clarified Task Brief would have distinguished between three possible tasks: (1) reprocess the failed IDoc, (2) diagnose why the IDoc failed, or (3) implement a fix to prevent recurrence. Each has a different input, output, and owner. Without clarification, the wrong task was performed.

Inputs required

Original task description, ticket, email, or meeting note that created the assignment.
Context: the system, process, project, or business area affected.
Stakeholder who requested the task and who will accept the result.
Any existing documentation, logs, or data samples that describe the current state.
Constraints: deadline, budget, tools available, authority limits.
Related tasks or dependencies that affect how this task is performed.
Historical examples of similar tasks that succeeded or failed (optional).

Questions to ask

What is the current state, and what is the desired state?
What is the smallest change that would satisfy the requester?
What system, transaction, or document must be changed?
What data or evidence is needed before work can begin?
Who will verify that the task is complete, and what criteria will they use?
What is the deadline, and what happens if the deadline is missed?
What is out of scope: what should the assignee not do?
What has been tried before, and why did it succeed or fail?

Working method

Capture the original request. Copy the exact text of the task, ticket, or message. Do not paraphrase. The original wording is evidence of what was asked.
Identify the requester and the acceptor. Name the person who asked for the task and the person who will judge completion. If they are different, both must agree on the brief.
State the current state. Describe what exists now, with references to systems, documents, or data. Example: "Customer C-10001 in company code 1000 has payment terms ZB30."
State the desired state. Describe what must be true when the task is complete. Example: "Customer C-10001 in company code 1000 has payment terms ZB15."
Define the output artifact. Name the document, configuration change, log, report, or update that proves the task is done. Example: "Updated customer master record with change log entry."
Define acceptance criteria. List 2–5 verifiable conditions that the acceptor will check. Example: "XD03 shows ZB15." "Change log shows the update on 2026-06-14." "No other fields were modified."
Define inputs required. List what the assignee needs to begin: access, data, approvals, documentation, or decisions from others.
Define out-of-scope items. Explicitly list what the assignee should not do. This prevents scope creep and mismatched expectations.
Define the owner and deadline. Name one person accountable and a date by which the brief must be completed.
Validate the brief with the requester. Send the brief back to the requester and ask: "Is this what you meant?" Do not start work until the brief is confirmed. If the requester changes the brief, update it and reconfirm.
Execute against the brief. Use the brief as the contract. If new information changes the task, update the brief and reconfirm before continuing.

Decision rules

If the requester and acceptor are different, the brief must be confirmed by both before work starts.
If the desired state cannot be described in one sentence, the task is too large and must be split into multiple briefs.
If the inputs are not available, the task is blocked until the inputs are provided, not started with assumptions.
If the acceptance criteria are subjective, replace them with measurable conditions or system states.
If the deadline is missing, request one. If no deadline is given, set a proposed deadline and confirm it.
If the task has been tried before and failed, include the failure mode in the brief so the assignee does not repeat it.
If the brief changes during execution, update the brief and reconfirm with the requester before continuing.

Deliverables

Clarified Task Brief — One-page document with task statement, current state, desired state, output, acceptance criteria, inputs, out-of-scope items, owner, and deadline. See template below.
Confirmation Record — Evidence that the requester confirmed the brief (email, chat, or sign-off in the ticket).
Change Log — Record of changes to the brief after initial confirmation, with reasons and reconfirmations.

Templates

Clarified Task Brief (compact)

---
artifact: Clarified Task Brief
id: CTB-<number>
status: draft | confirmed | in progress | complete
---

## Task statement
<One sentence describing what must be done>

## Original request
<Copy the original ticket, email, or message exactly>

## Context
- System / process: <name>
- Project / phase: <name>
- Requester: <name>
- Acceptor: <name>

## Current state
<What is true now>

## Desired state
<What must be true when the task is complete>

## Output artifact
<What document, change, or evidence proves completion>

## Acceptance criteria
- [ ] <Verifiable condition 1>
- [ ] <Verifiable condition 2>
- [ ] <Verifiable condition 3>

## Inputs required
- <Data, access, documentation, or decision needed>
- <Second input>

## Out of scope
- <What the assignee must not do>
- <Second out-of-scope item>

## Owner and deadline
- Owner: <name>
- Deadline: YYYY-MM-DD
- Proposed start date: YYYY-MM-DD

## Change log
| Date | Change | Reason | Confirmed by |
|------|--------|--------|--------------|
| — | — | — | — |

Quality checklist

The task statement is one sentence and describes a single outcome.
The original request is copied verbatim, not paraphrased.
Current state and desired state are specific enough to verify without interpretation.
Acceptance criteria are measurable, not subjective.
At least one input is identified; if none are needed, this is explicitly stated.
At least one out-of-scope item is identified to prevent drift.
The owner is a single named person, not a team or department.
The deadline is specific and confirmed by the requester.
The brief has been confirmed by the requester before work started.
Any changes to the brief are logged and reconfirmed.

Common mistakes

Paraphrasing the original request instead of copying it. Consequence: the brief drifts from the requester's intent. When the output is rejected, there is no evidence of what was originally asked.
Defining acceptance criteria as "the requester is happy." Consequence: the criteria are subjective and unverifiable. The assignee does not know when to stop, and the requester does not know what to check.
Skipping the confirmation step. Consequence: the assignee works on an assumption, and the requester rejects the result because it does not match their unspoken expectations.
Starting work before inputs are available. Consequence: the assignee makes assumptions about data or access, produces a flawed output, and must redo the work when the real inputs arrive.
Not defining out-of-scope items. Consequence: the assignee does extra work that is not needed, or the requester assumes adjacent tasks are included and is disappointed when they are not.

Weak output vs Strong output

Weak output

A forwarded email with a note: "Please handle this." No task statement, no current state, no desired state, no acceptance criteria, no deadline. The assignee must infer everything from the forwarded thread, which contains conflicting opinions, outdated information, and no decision.

Why it fails: The assignee spends more time interpreting the request than doing the work. The result is unpredictable. The requester is dissatisfied because their implicit expectations were not met. The cycle repeats with additional back-and-forth messages.

Strong output

---
artifact: Clarified Task Brief
id: CTB-2026-044
status: confirmed
---

## Task statement
Update payment terms for customer C-10001 in company code 1000 from ZB30 to ZB15.

## Original request
"Customer master is wrong — payment terms should be 15 days, not 30. Please fix." — Email from Anna Kowalski, 2026-06-12.

## Context
- System / process: SAP S/4HANA customer master (XD02/XD03)
- Project / phase: Ongoing AMS support
- Requester: Anna Kowalski (AR team lead)
- Acceptor: Anna Kowalski

## Current state
Customer C-10001 in company code 1000 has payment terms ZB30 (30 days net).

## Desired state
Customer C-10001 in company code 1000 has payment terms ZB15 (15 days net).

## Output artifact
Updated customer master record with change log entry.

## Acceptance criteria
- [ ] XD03 displays payment terms ZB15 for customer C-10001 in company code 1000.
- [ ] Change log shows the update on 2026-06-14 with reason "Customer request per email."
- [ ] No other fields (address, bank details, tax number) were modified.
- [ ] AR team confirms the change in their next reconciliation run.

## Inputs required
- XD02 access in company code 1000.
- Approval from customer master governance team (already received via ticket APP-2026-112).

## Out of scope
- Updating other customers.
- Changing credit limit or risk class.
- Informing the customer directly (AR team handles communication).

## Owner and deadline
- Owner: Dmitri Volkov
- Deadline: 2026-06-14
- Proposed start date: 2026-06-12

## Change log
| Date | Change | Reason | Confirmed by |
|------|--------|--------|--------------|
| — | — | — | — |

Agent instructions

AI Prompt Pattern

Role: Task clarification specialist for enterprise support and project work.

Context: You have a vague task description, ticket, or message. You need to produce a Clarified Task Brief that the assignee can use to start work immediately and the requester can use to verify completion.

Task: Extract the original request, define current and desired state, specify acceptance criteria, identify inputs and out-of-scope items, and name an owner and deadline. Confirm the brief with the requester before work starts.

Output format: Structured Clarified Task Brief per the template, followed by a confirmation request message.

Never paraphrase the original request. Copy it verbatim. Paraphrasing introduces interpretation drift.
Always define current and desired state in specific, verifiable terms. Use system names, transaction codes, field values, and document IDs where possible.
Acceptance criteria must be checkboxes, not opinions. Each criterion must be verifiable by inspection, test, or log.
Always identify out-of-scope items. If the requester did not specify boundaries, propose them and ask for confirmation.
Never start work without confirmed inputs. If data, access, or approval is missing, flag the gap and wait.
Never guess the deadline. If no deadline is given, propose one and request confirmation.
Do not invent context or history. If you do not know what was tried before, state that the history is unknown and ask for it.
Link to Atlas diagnostics when the task touches SAP processes. For example, customer master tasks should reference SAP Customer Vendor Master Diagnostics.

Related skills

Work Breakdown Planning Working Skill — Use to decompose a project before clarifying individual tasks.
Priority Triage Working Skill — Use to decide which clarified tasks to execute first.
Blocker Escalation Working Skill — Use when a clarified task is blocked by missing inputs or decisions.
Acceptance Criteria Working Skill — Use to strengthen the acceptance criteria section of the brief.

Related Atlas pages

SAP Customer Vendor Master Diagnostics — Diagnostic context for tasks involving customer or vendor master data.
SAP Incompletion Procedure Diagnostics — Validation context for tasks involving mandatory field completeness.

Verification status and limitations

This skill is a public working interpretation of task clarification practices. It is not official ITIL, BABOK, or SAP methodology. It focuses on practical clarification for enterprise support and project work where ambiguity causes delays and rework.

Known limitations: the skill assumes the requester is available to confirm the brief. It does not cover tasks where the requester is unavailable or uncooperative. It treats the brief as a bilateral contract, not a unilateral assignment. For complex tasks requiring multi-week execution, the brief may need to be supplemented with a detailed work plan or design document. The skill does not cover legal or compliance review of task scopes.