# Hermes-to-Charlie project handoff A handoff transfers a finished or paused project from Hermes to Charlie so Charlie can pick it up, audit it, or continue it without hunting for files or reconstructing decisions. Finishing the project and finishing the handoff are separate outcomes. A paused project can have a complete handoff if its limits are clear. ## Save the working files Project files belong in Google Drive at `My Drive/charlie-instinct//`. Create the folder if it does not exist. Use a descriptive lowercase-hyphen project slug. Keep the handoff Google Doc in this project folder, including when the project is a skill update. Skill folders belong at `My Drive/1-fullREFIT-gd/skills//`. Copy the complete folder, including its entry file and every reference, script, asset, test or other dependency it needs. Preserve the directory structure. An archive alone is not a usable skill folder. Keep required loose files available and include any archive as an extra copy. Inspect the existing destination before copying. Reuse the right folder rather than creating a second same-name folder. Keep the current working version clear and label older or superseded material. Nothing Charlie needs may remain only on the Mac or only in Dropbox. A source checkout can stay on the Mac, but the handoff must include the files and instructions Charlie needs for the assigned work. Do not copy private material from unrelated projects. Never put passwords, tokens, keys, recovery codes, credential exports or other secrets in the handoff files, document or email. Name the credential's secure storage location and purpose without copying its value. ## Name and reference files Use descriptive lowercase-hyphen filenames. Where a date matters, use `YYYY-MM-DD`, such as `-verification-2026-10-06.md`. Preserve filenames tools require exactly, including `SKILL.md`, `README.md`, `package.json` and code dependency names. Do not break imports or references to force a naming convention. Every file or folder mentioned in the handoff, completion email or status report needs its full Drive path and its copied Drive link. A filename, folder name or "the files are in Drive" is not enough. For a local or Dropbox source, record its original full path alongside the full Drive destination path and link. Do not build Drive links from guessed IDs. A shareable link means Charlie can open the item with his existing access. It does not mean making it public. Preserve the existing audience. If access is missing and fixing it would widen access, report that blocker to Paul before changing permissions. Verify the folder, handoff Doc and linked files from the destination rather than assuming the upload worked. ## Write the handoff Google Doc Create a Google Doc in `My Drive/charlie-instinct//` named `-handoff-YYYY-MM-DD`. Check for an existing handoff first. If creating a later handoff, make the current version clear and link the earlier one rather than leaving two unexplained copies. Use the following sections. State "None" when there are no issues or blockers, and "Not run" for a check you did not perform. Do not leave a blank section that Charlie must interpret. ### Project and current state Give the project name, handoff date and who is handing it over. Write one paragraph that covers the goal, the current state, whether the project is complete or paused, and the next outcome Charlie should deliver. Distinguish implementation from verification and publication. "Built locally" does not mean "live." ### Completed work List what was actually completed. Include decisions that changed the result and why. Separate completed work from attempted, planned or unverified work. ### Files and destinations Inventory the files and folders Charlie needs. For each, give its purpose, full Drive path and Drive link. Include source paths where relevant. Identify the current working version and any earlier version it replaces. Link the handoff Doc itself by full path and Drive link. Record every existing Drive file you edited or replaced. Give its full path and link, what changed, why, and how the earlier state can be recovered where available. Do not overwrite silently. Prefer a new dated copy when an existing file's ownership or purpose is unclear. Do not delete unrelated files. ### Verification and results For each check, record what was tested, the command or procedure, when it ran, the observed result, and a full path plus Drive link to saved evidence where applicable. Reopen the Drive copy and inspect its content, not just its filename. Check that every required file and referenced dependency landed. For visual work, inspect the actual rendered result. For code, include the relevant tests and the instructions needed to reproduce them. For a deployed result, test its actual live URL and record that URL. Clearly label failures, checks not run and anything that requires Hermes's Mac or credentials. Never report a pass from an exit code or upload receipt alone. ### Open issues and blockers Describe each remaining issue, its effect and what is needed to clear it. Name the person or agent who can clear it. Call out missing inputs, uncertain facts, access gaps and tests that could not run. A blocked project can be handed off if Charlie has a readable package and the unresolved work is stated. Missing handoff files or unreadable links mean the handoff itself is blocked. ### Next steps and owners Write exact next actions in dependency order. Each action names one owner, its input files with full paths and Drive links, its output location, and a check that shows it is done. Use Charlie for work he can execute in Drive or Slack, Hermes for work requiring the Mac or local credentials, and Paul for decisions or approvals. Do not assign Charlie an action that needs access he does not have. ### Context not carried by the files Include decisions, constraints, intended audience, permissions, deadlines with timezone where relevant, known failure cases and commands Charlie needs. State any instruction that applies only to this project. If continuing the work needs information that is not written down elsewhere, write it here without including secrets. A handoff does not grant new permission to spend, publish, delete or contact other people. ## Finish the handoff Before signaling completion, verify that the destination files are present, the Google Doc contains every section, links point to the intended items, required dependencies are included, changes to existing files are recorded, and remaining work has named owners. Check for secrets in the outgoing files and text. Once the package is readable and in place, Hermes emails `agentcharlie@mail.instinct.com` with the subject `Handoff: `. The email includes the handoff Doc's full Drive path and link, the project's folder path and link, whether the project is complete or paused, the verification result, and Charlie's first next action. Any other file mentioned also gets its full Drive path and link. The email should be short. The Doc holds the detail. Send this signal only after the handoff is ready. Verify that the email was sent, then report the handoff Doc link and send status to Paul. If sending fails, report that failure and do not call the handoff done. This email is the trigger for Charlie to pick up the work. Without it, the handoff is not complete. A sent email does not prove Charlie has read or accepted it.