# Cowork task design

Template id: `cowork-task-design`

Responsible skill: `copilot-cowork:task-context-design`. The delegation map is completed with
`copilot-cowork:work-delegation-design`, the step outline with `copilot-cowork:multi-step-work-design`, the checkpoints
with `copilot-cowork:human-checkpoint-design`, the source table with `copilot-cowork:grounding-readiness`, the validation
record with `copilot-cowork:workflow-validation` and the review standard with `copilot-cowork:delegated-work-review`.

Use this design before a Copilot Cowork task is run regularly or shared with others. Every fact the organisation or team
must supply is marked `[To confirm: ...]`; replace the marker when the fact is confirmed, and never fill it with a guess.
Example rows are fictional and are there to be replaced or deleted. Personal tasks may complete sections 1 to 5 only.

## 1. Summary

| Field | Entry |
|---|---|
| Task name | [To confirm: working name] |
| Accountable owner (answers for the outcome) | [To confirm: name and role] |
| Design owner (maintains this design) | [To confirm: name or team] |
| Who may reuse it | [To confirm: personal, named team or wider audience] |
| Risk tier (0-4) | [To confirm: tier, or "not classified" with reason] |
| Fit verdict from use-case assessment | [To confirm: suits Cowork / suits Cowork with conditions, and conditions] |
| Design status | Draft / Validated / Published / Retired |
| Review date | [To confirm: date] |

## 2. Goal and definition of done

Goal, in one sentence naming the output and its audience.

> Fictional example: "A two-page briefing for the operations director on supplier delivery performance last quarter,
> naming the three suppliers most at risk with a recommended action for each."

[To confirm: goal]

| Definition of done | Specification |
|---|---|
| Format and structure | [To confirm] |
| Length and level of detail | [To confirm] |
| Quality standard (what makes it acceptable) | [To confirm] |
| What must be cited | [To confirm] |
| What must be flagged rather than resolved (uncertainty rule) | [To confirm: for example conflicting or missing sources] |

## 3. Delegation map

| # | Part of the work | Level (D0 Keep / D1 Prepare / D2 Draft / D3 Act with approval) | Human owner | Reason |
|---|---|---|---|---|
| 1 | Fictional example: collate delivery data for each supplier | D1 | Fictional example: operations analyst | Mechanical collation, checked at direction check |
| 2 | [To confirm] | [To confirm] | [To confirm] | [To confirm] |

Take-back triggers (conditions under which the delegator stops the run and takes over): [To confirm]

## 4. Context and constraints

| Element | Entry |
|---|---|
| Inputs supplied at run time | [To confirm] |
| Exclusions (sources, periods or topics to ignore) | [To confirm] |
| Style, terminology and audience rules | [To confirm] |
| Must-not rules | [To confirm: for example no named individuals' personal circumstances] |
| Example of good output (fictional or cleaned) | [To confirm: location, or "none" with reason] |
| Organisational skills, plugins or custom instructions applied | [To confirm: approved items from the governance library] |

## 5. Sources and readiness

A source with several live versions, no owner, or sharing wider than its sensitivity warrants is not ready.

| Source and location | Owner | Single version? | Current enough? | Access matches output audience? | Classification or label | Verdict | Conditions, owner and date |
|---|---|---|---|---|---|---|---|
| [To confirm] | [To confirm] | Yes / No | Yes / No | Yes / No | [To confirm] | Ready / Ready with conditions / Not ready | [To confirm] |

## 6. Step outline

| Step | Named output | Inputs | Completion test | Restart point | Checkpoint after? |
|---|---|---|---|---|---|
| 1 | Fictional example: confirmed source list | Fictional example: named sources in section 5 | Every source found or reported missing | Re-run from named sources | Direction check |
| 2 | [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] |

Where intermediate outputs are stored and who can open them: [To confirm]

## 7. Checkpoints

| Checkpoint | Type (direction / judgement / pre-effect / exception stop) | Approver role | Evidence shown | Permitted responses | On no response |
|---|---|---|---|---|---|
| [To confirm] | [To confirm] | [To confirm] | [To confirm] | Approve / edit / send back / stop | Run waits |

Actions that always need pre-effect approval under the organisation's governance position: [To confirm]

## 8. Validation record

| Case | Type (typical / awkward / planted error / reuser run) | Expected behaviour | Result (met / met with edits / flagged correctly / failed) | Notes |
|---|---|---|---|---|
| [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] |

Acceptance threshold agreed by the accountable owner: [To confirm]

Verdict: Fit to rely / Fit with conditions / Not fit. Conditions and re-test date: [To confirm]

## 9. Review standard before use

| Consequence of the output | Review depth | Second reviewer required? |
|---|---|---|
| [To confirm: low / moderate / high / affects individuals] | [To confirm] | Yes / No |

The five checks applied to every output: meets the definition of done; key claims trace to sources; nothing
inappropriate for the audience; caveats and gaps stated; any actions taken are correct.

## 10. Measures

Measured at team or role level, never for individual staff.

| Measure | Baseline and source | Target | Owner | Review date |
|---|---|---|---|---|
| Fictional example: outputs accepted with light edits | Fictional example: team estimate before delegation | [To confirm] | [To confirm] | [To confirm] |
| [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] |

## 11. Open questions and approvals

| Item | Owner | Due |
|---|---|---|
| [To confirm] | [To confirm] | [To confirm] |

| Role | Name | Date |
|---|---|---|
| Accountable owner | [To confirm] | [To confirm] |
| Design owner | [To confirm] | [To confirm] |
| Approver for publication (shared designs) | [To confirm] | [To confirm] |

> Credit: Template from CopilotForge by Simon Foote (https://github.com/SimonFoote-greensparx/CopilotForge), licensed under CC BY 4.0. Keep this credit when you share or adapt the template; in your own completed document you may keep it as a footer or remove it.