Templates › Cowork task design
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.