# A project handoff that exposes the loose ends.

Reviewed: 2026-09-12

Canonical: https://clankercloud.ai/templates/project-handoff

Use this starter to turn project notes into a handoff brief with explicit source versions, outstanding decisions, and a first-run checklist. A saved brief helps a new owner understand the work; it does not grant them file access, transfer account ownership, or confirm unresolved commitments.

## What you are working toward

A handoff brief with a source map, open-risk register, and ordered next steps.

## Start with

- The outgoing owner’s dated notes and current file list

- A named incoming owner and defined responsibility

- Known access requests, unresolved decisions, and dependencies

## Define what is being handed over

Name the responsibility and its boundaries before summarizing the history. In this example, Leo takes coordination of a pilot results brief, not control of every system used by the project. The pilot end date is unknown, so the handoff cannot promise a reporting deadline from the information supplied.

Keep the original notes in a Project and ask for a handoff brief that cites H1–H10. The fictional filenames in these notes are references for a planning exercise; their contents are not attached. The Agent should not claim it has opened or validated files merely because their names appear in a paragraph.

## Identify current, draft, and historical files

A handoff is easier to trust when it explains which file to use for which purpose. pilot-brief-v2.md is the current scope reference; v1 is superseded. metric-definitions.md contains the reviewed counting rule. results-draft.md is a draft with placeholder totals. The August brief is a format example, not evidence for current results.

With real files, verify that each reference exists and open the important ones. If two files both appear current, record the conflict and ask the owner to choose. Do not rely only on a larger version number or a later modification time when the approval status is unclear.

## Keep access checks in the handoff

H8 says folder access was requested for Leo. That is different from a successful sign-in and a readable source file. Include a check that Leo can reach the required location using the intended account. Never put passwords, tokens, or private access links into a broadly circulated handoff to make that step seem complete.

Workspace Project files, external services, and other people’s permissions are separate access concerns. Creating the brief does not grant another person access to its referenced systems. Use the relevant sharing and connection controls, then verify the recipient’s experience before declaring the transfer ready.

## Order the first steps by what they depend on

Leo should confirm the reporting period and source delivery with Priya before calculating totals. The agreed measure is accounts with a completed session, not individual users. Duplicate account IDs need an agreed treatment before the data can support a final count. These are practical prerequisites, not optional housekeeping after writing the summary.

The expected 2026-09-15 delivery is not confirmed. Preserve that distinction in the risk register and name the person who can resolve it. An effective handoff gives the incoming owner a clear starting sequence without inventing acceptance from anyone else.

## Test whether a new owner can follow it

Read the brief as if you had not attended the project meetings. Can you identify the goal, current scope, source definitions, blockers, and next useful action without guessing? Check that the important warnings are next to the relevant files, especially the placeholder totals and the historical format example.

Ask the incoming owner to flag missing context before considering the handoff accepted. Acceptance might require accessible source files, an answered question, or a walkthrough. The template can draft that checklist, but the Agent cannot establish another person’s understanding or agreement from the outgoing notes alone.

## Preserve the handoff as a dated checkpoint

Save the approved brief with its date and source references. Add subsequent decisions as dated updates so the project can distinguish what was known at handoff from what changed afterward. This is particularly useful when a delivery slips or a counting rule is corrected.

If a referenced file is missing or unreadable, list it as unverified and continue only with supported facts. Do not fill gaps from an older file without saying so. A concise incomplete handoff with explicit next checks is more useful than a polished document that conceals the missing inputs.

## Sample files

Fictional inputs. Download and add to your Project.

- [handoff-notes.md](https://clankercloud.ai/templates/project-handoff-files/handoff-notes.md): Fictional reporting handoff with superseded files, placeholder totals, and unverified access.

## Try this prompt

Copy into a Workspace Session. Opening Workspace does not send it automatically.

```text
Create project-handoff.md using only the fictional notes below. Write for Leo, the incoming coordinator. Include purpose, current state, a source map with status and intended use, decisions, unresolved risks, and ordered first steps. Cite the H markers. File names in the notes are references only; do not claim their contents were inspected.

Preserve expected versus confirmed dates. Never use placeholder totals as results. Distinguish requested access from verified access. Do not grant access, send the handoff, change source files, calculate final results, or mark the transfer accepted. Finish with an acceptance checklist for the people involved to review.

# Fictional handoff: Orchard pilot reporting
Handoff date: 2026-09-10
Outgoing coordinator: Mina. Incoming coordinator: Leo.

[H1] Goal: prepare the pilot results brief after the pilot ends. The end date is not confirmed.
[H2] Approved scope is in pilot-brief-v2.md. pilot-brief-v1.md is superseded.
[H3] Reviewed file: metric-definitions.md, dated 2026-09-09. It defines an active pilot account as one with at least one completed session in the reporting period.
[H4] Draft file: results-draft.md. Its totals are placeholders and must not be reported as final.
[H5] Priya owns source-data delivery. Delivery is expected 2026-09-15 but is not confirmed.
[H6] Leo will verify the reporting dates with Priya before calculating totals.
[H7] Decision: use account counts, not individual-user counts, in the brief.
[H8] Access to the shared analytics folder has been requested for Leo but has not been verified.
[H9] Open issue: one source export appears to contain duplicate account IDs. No cleaning rule is agreed.
[H10] The last reviewed brief is archived-brief-august.md; it is a format example, not current pilot evidence.
```

## Illustrative result

Fictional sample; your result depends on your inputs and needs review.

```text
Fictional expected handoff excerpt

Goal: prepare a pilot results brief after an end date that remains unconfirmed (H1).
Current scope: pilot-brief-v2.md; v1 is superseded (H2).
Measure: active accounts with at least one completed session; use account counts, not users (H3, H7).
Do not report results-draft.md totals: they are placeholders (H4).

First steps: verify Leo’s folder access (H8); confirm reporting dates and Priya’s delivery (H5, H6); agree duplicate-account handling (H9); then calculate and review results.
Expected delivery: 2026-09-15, unconfirmed.
Acceptance pending: accessible files, agreed dates, resolved duplicate rule, and incoming-owner review.
```

## Before using the result

- All current, draft, superseded, and historical file references have distinct roles.

- Expected delivery and requested access are not described as confirmed.

- Placeholder totals and old reporting evidence are excluded from current results.

- The next steps respect data, date, and duplicate-rule dependencies.

- The brief records pending acceptance and does not claim a permission transfer.

## Common questions

### What is the difference between a Project, a Session, and an Agent?

A Project keeps related files, instructions, and work together. A Session is a conversation where work happens and progress is recorded. An Agent is the assistant doing the work, with its own instructions, skills, and selected tools.

[Read more in the FAQ](https://clankercloud.ai/faq#projects-sessions-agents)

### Where do I find and review the finished files?

Open your Project’s Files tab or General → Files. In a Session, Preview opens a side panel where you can select a file. Use page, sheet, or slide controls where available, check the contents, and download the result.

[Read more in the FAQ](https://clankercloud.ai/faq#review-files)

### Are Apps and files public as soon as I create them?

Creating or previewing an App does not publish it. Private sharing requires recipients to sign in. Publish only when you want a public link, and review the data included in the result. Manage private sharing in Shared.

[Read more in the FAQ](https://clankercloud.ai/faq#sharing)

## Sources

- [Workspace guide: Project files and results](https://workspace.clankercloud.ai/#page=faq&tab=articles&article=files-and-knowledge)

- [FAQ: Projects, Sessions, and Agents](https://clankercloud.ai/faq#projects-sessions-agents)

- [FAQ: sharing and publication](https://clankercloud.ai/faq#sharing)

## Related

- [Give your Project a source of truth.](https://clankercloud.ai/learn/organize-project-files)

- [Find what changed and why it matters.](https://clankercloud.ai/learn/compare-document-versions)

- [Meeting notes into actions you can verify.](https://clankercloud.ai/templates/meeting-action-tracker)

[Open Workspace](https://workspace.clankercloud.ai)

[Current pricing and usage](https://clankercloud.ai/pricing)