Share a reviewed method, then test the recipient’s copy.

Decide what the recipient should be able to repeat

Name the role, expected inputs, saved deliverable, and review responsibility. A colleague receiving a reporting specialist should know whether it drafts internal updates or is intended to send client messages. Sharing is easier to assess when the job is narrow and its action boundary is written down.

Run the acceptance exercise before distributing the setup. Keep a sample output and the tests used to review it. Explain the limits honestly: which source formats you tried, which operations were involved, and which behaviors remain untested. A familiar Agent name or an attractive profile does not establish readiness for the recipient’s work.

Review the actual content being distributed

Open the supported sharing flow and inspect its current included content and dependency review. Instructions and reusable methods can contain client names, private examples, or internal operating details. Read them as material another person may be able to inspect and edit. Remove anything you are not authorized to distribute.

Review attached Skills and supported dependencies rather than assuming the recipient gets only a short description. When the interface asks you to confirm included instructions, base that confirmation on the displayed package. Resolve missing or unsupported dependencies before continuing; a link is not evidence that every component will arrive usable.

Separate the Agent copy from its working access

Write a setup note listing the source types, selected operations, and connections the role expects. The receiver needs their own appropriate files and separately configured access. Do not send secrets in the note or assume your connected account travels with the Agent. A shared definition and account authorization solve different problems.

For the first task, use a fictional packet that does not depend on private systems. Confirm that the recipient can read the intended sources and save the expected output in their Project. If a later real task needs an external connection, review that account and action scope explicitly before enabling it.

Choose the supported copy or publication route

A private sharing link lets someone sign in and add a supported copy after reviewing it. Use the Team route where available for your organization’s supported workflow. Marketplace publication creates a separate reviewed version, with its own listing, package, and installation behavior. Choose the route that matches the intended audience.

Do not describe an Agent reference ZIP as a supported executable import package. Use the product’s supported sharing and installation controls. For any route, inspect what the recipient is receiving and whether it is editable or hosted. The answer determines how they can customize behavior and which publisher changes they may later review.

Run the acceptance test in the recipient’s account

Ask the recipient to review the instructions, reference requirements, Skills, and selected Tools before providing real work. Run the same small normal case and difficult case you used. Open the actual saved files and compare them with the reviewer reference. Record any missing capability or setup step in the handoff note.

A sender’s successful task does not prove the receiver has the same sources, grants, or environment. If their copy fails, identify the difference before editing the role. Keep the failure visible and avoid compensating with broad access. The first checked run should establish a working setup for this recipient, not a promise about every future task.

Give the team a maintenance rule

Identify an owner for improvements and a place to record proposed changes. Explain whether colleagues are maintaining independent copies or reviewing a published version. Do not promise that a later edit to your personal Agent automatically updates everyone. Use the behavior shown in the current sharing or Marketplace flow.

When a material change arrives, repeat the acceptance exercise and retain local decisions that matter to the receiver. Keep current inputs and client-specific instructions in the appropriate Project. This lets the shared method improve while each team member remains responsible for their working evidence, account access, and final deliverable.

Try it with a small example.

Before you use the result.

• The shared role and action boundary are documented.
• The sender reviewed the actual included content and dependencies.
• The setup note contains no credentials or unsupported transfer promises.
• The recipient checked their sources, access, and saved output.
• The team knows how to propose and retest future changes.