Our review
This Gaiya365 skill gives a small structure to delegation. It turns a rough request into five labeled fields: who owns the deliverable, which inputs are available, what actions are allowed, which decisions still need approval, and what observable result counts as done. A four-line return report makes a blocked or partial handoff useful instead of hiding uncertainty.
Use it when an agent or colleague might otherwise guess about scope, source material, or permission. It is especially useful before work that could touch external systems. Skip it for a tiny, fully specified task that already has a clear owner and acceptance check. The method cannot grant authority on its own; the requester still has to decide any unresolved boundary.
The archive is plain text: a skill file, two templates, six worked rewrites, license, listing, README, and security note. There are no scripts, network calls, or credential reads. The included SECURITY.md describes that scope. Read the full SKILL.md below before copying the folder into an agent.
Download the archive from this page, verify its SHA-256, extract the entire folder, and put it in the skills location documented by your agent. The full SKILL.md appears below so you can read the workflow first. Test it with an unimportant task and review the resulting brief before using it for a sensitive handoff.
Download and verify
Version 1.0.1 is free under the MIT license. The archive contains exactly these files:
five-field-handoff/ SKILL.md README.md LISTING.md LICENSE SECURITY.md examples/rewrites.md templates/brief.md templates/report.md
SHA-256 of the archive
751ff7463a9de7bfa7088c56ae8403cb0159954f3dfecfd7e17e50b82f230f8fCompare this value with the downloaded archive before installing. A matching hash confirms the bytes match this release; it does not guarantee safe or correct output.
Read SKILL.md
This is the complete instruction file in the archive. The templates and worked examples are listed above and included in the download.
--- name: five-field-handoff description: Use when assigning a bounded task to an agent or teammate, especially when the original request mixes goals, context, and permissions; turn it into a checkable five-field brief and a four-line return report. license: MIT (see LICENSE) --- # Five-Field Handoff Use this before delegating work that another person should be able to finish without guessing the outcome or authority. First resolve any missing safety boundary with the requester. Then write a fresh brief in your own words. **Do not forward original wording.** Preserve the intent, sources, and constraints, not the phrasing. Write exactly these five labeled fields: 1. **Owns:** One deliverable and one owner. State the result someone can inspect, not a broad role. 2. **Inputs:** Specific source files, links, facts, or access boundaries. Say when an input is missing. 3. **May:** Concrete actions the owner can take without another decision, such as read, edit, test, or draft. 4. **Must ask before:** Actions that require the requester to decide first. Include sending messages, spending, publishing, deleting, changing live systems, or expanding scope when relevant. A blank field means "none beyond the stated scope," never unlimited authority. 5. **Done when:** Observable acceptance checks, including where the result should be saved and how it should be verified. Keep each field concise. Do not convert a vague request into an invented authorization. If the owner cannot proceed without a decision, put that decision in **Must ask before** and return a blocked report. Ask the owner to return four lines, using these labels: ```text Status: done | blocked | partial What changed: concrete artifacts and checks What was not done: excluded or unfinished actions What needs a decision: one precise choice, or none ``` Use `templates/brief.md` and `templates/report.md`. The six before/after examples show how the same structure works across different jobs. ## Anti-patterns - "Handle everything" as **Owns**: name one deliverable. - "Use anything available" as **Inputs**: name sources and boundaries. - "Do what is needed" as **May**: list allowed actions. - An approval gate that arrives after an irreversible action: put it in **Must ask before**. - "Looks good" as **Done when**: provide observable checks. - Copying the request verbatim into the brief: rewrite it in operational language. - Reporting only "done": include what changed and what remains undecided. ## Common mistakes 1. **Two owners in one brief.** "Design and engineering own the launch" makes accountability unclear. Pick one owner for one deliverable and put collaborators in **Inputs**. 2. **A link without a usable input.** "Use the docs" leaves the owner searching. Name the exact document, version, and access boundary; mark a missing source explicitly. 3. **Permission hidden inside the goal.** "Get the page live" does not authorize publishing. Put drafting and testing in **May**, and publication in **Must ask before** unless already approved. 4. **Success based on effort.** "Spend two hours on it" is not a completion check. State the artifact, location, and observable acceptance test in **Done when**. 5. **A blocked report that says only 'waiting'.** Name the one decision needed, who must make it, and the work already completed in the four-line return report.
Source and license
Maintainer: Gaiya365. Checked: October 18, 2026. This is Gaiya365’s own release.