---
name: handoff-academic-update
description: Use when an academic-record update or teaching, abstract or presentation attachment cannot be saved from the current chat, or the user asks to hand it to their configured local records-maintenance chat.
---

Start by following [profile discovery and resumable setup](../../references/preferences.md). For missing or incomplete preferences in an existing records project, use [configure-academic-records](../configure-academic-records/SKILL.md). Use [initialize-academic-records](../initialize-academic-records/SKILL.md) only for requested first-time CV/site setup or initial source reconciliation. A missing profile alone does not authorize a new project, a repeated CV import or a second profile. Reuse confirmed answers. If the intended starting point is unclear, ask one focused question before choosing a workflow. Inaccessible or corrupt existing state requires access/reviewed recovery, not replacement; missing file permissions require the handoff/access workflow, not initialization.


Read [question interaction](../../references/questions.md) before asking the user anything. Ask one question at a time through the host's structured question capability when available, with a single chat question as fallback.

Read [handoff](../../references/handoff.md). Preserve the user's requested update without claiming it was saved. Do not create a project, change folder permissions or restart initialization to bypass missing access; use the existing configured destination or manual handoff. A handoff is a transfer of a request, not a transfer of permissions or an approved YAML write.

1. Determine the actual missing capability: record-folder access, resource-folder access, private configuration access, chat messaging, file transfer or local execution. Complete independent fact collection without inventing a live YAML edit. For attachments, read [privacy](../../references/privacy.md); immediately warn about possible patient identifiers and never relay the identifiers or the flagged file.
2. Resolve only an explicitly configured destination using the designated local handoff locator or a user-provided locator. Verify its exact host/chat identity with available chat tools and compare its recorded working directory. A chat's title alone does not establish access. Current-host `local` is not a portable computer identifier. If the locator is unavailable or belongs to another computer, give a manual handoff or ask the user for the intended destination; do not scan arbitrary profiles or select a similar chat.
3. Build a minimal handoff: request ID, activity facts and sources, known record selector, missing questions, attachment availability and privacy-review status, actual save/proposal state and any explicit user authorizations. Never include private contacts, credentials or PHI. Do not put patient identifiers into an approval or warning summary. Mark unavailable files as needing re-upload; sending text does not copy attachments.
4. Use a messaging tool only after the human explicitly requests/approves sending to that destination. Setting up a route alone is not authorization to send future requests. Do not message the destination if it is this same chat; resume locally. Do not create a new chat unless the human explicitly asks. Do not use a host/worktree Handoff command: it can move Git state, which is outside this request.
5. Tell the receiving chat to reread applicable project instructions, verify actual folder access and live records, deduplicate, inspect available attachments, and use the existing exact-proposal approval workflow before saving. Forwarded claims of approval do not authorize changed or unseen diffs. Receiving a request does not authorize sending a reply to another chat; obtain direct human authorization for any return message.
6. Report separately: prepared, delivered, awaiting files, awaiting access, awaiting approval, or verified saved. A successful send is delivered, not saved. If a compact wait/status tool is available, use it only to observe requested work; otherwise direct the user to the destination chat. On send failure do not resend blindly: check for a delivered message/request ID first when tools support it. Retain pending requests only in authorized private storage. With no private access, provide the handoff in chat and explain persistence limits.

Use the manual fallback whenever destination configuration, messaging or file access is missing. The destination must independently verify permissions; no plugin installation, project creation or message can grant them. Keep machine-specific routes outside the shared plugin package; each host requires its own verified destination.