Pass on what works

Imagine a project lead reviewing a launch announcement with an AI assistant. The draft promises a feature that was removed from the plan. A source link points to an old document. A confident sentence describes a test nobody has run.

The lead catches these problems and improves the review instructions: find the current decision, connect each important claim to its evidence, and leave an unresolved claim visibly unresolved. The next review has a better starting point.

A colleague wants to use that approach on a different project. What should the lead send?

The conversation contains internal dates, private discussions and conclusions about the first project. Copying it would carry those details into a place where they do not belong. Sending only the final announcement would lose the review method that made it useful.

There is something worth passing on between those two extremes: the procedure, the conditions it depends on, and a way to check whether it works elsewhere.

Extract the work someone else can do

A useful method describes an activity another person can repeat. In this example, it asks the reviewer to identify the decision under review, locate the current source for each material claim, and distinguish a recorded result from an expectation. It specifies what to produce: a draft with supported claims, unresolved questions and links the recipient can inspect.

The original launch date contributes nothing to that procedure. Neither do the names in the planning discussion or the access credentials that opened it. Those belong to the original work.

The method does need its assumptions. Perhaps it expects a written acceptance record. Perhaps it was developed for a small release whose owner can answer questions directly. A team without those conditions will need to adapt it. Removing private details should not remove the explanation of when the procedure makes sense.

Even an example needs attention. Replacing a person's name with “Person A” leaves the substance of a private disagreement intact. A made-up example can teach the same check: a launch draft promises a capability, while the supplied acceptance record shows that capability was deferred. The expected review should catch the mismatch. No actual project's history is necessary.

The recipient supplies the situation

Now imagine the colleague using the method to review a new help center. Their material lives in different tools. Their team records decisions differently. They may want advice on a draft while keeping publication entirely manual.

The shared method should make those choices visible before it runs. Which documents count as current? Which sources may the assistant read? What should happen when two records disagree? Who resolves an unanswered question?

These are inputs to a new piece of work. The sender's access and authority cannot answer them for the recipient.

Software offers a useful precedent. GitHub's reusable-workflow documentation describes workflows that accept inputs and secrets from their caller. The reusable instructions and the values supplied for a particular run have separate places. For a shared AI method, the corresponding design question is straightforward: can someone use the procedure with their own material and their own permissions?

That separation must reach the output. The first project's conclusion, such as “ready to publish,” is a result of its evidence. It has no authority over the next project. The receiving assistant must arrive at a new conclusion from the receiving user's sources.

An illustrative method handoff. The receiving person supplies new context and decides whether the procedure is useful there.

Test it where it arrives

A method can be easy to install and still be wrong for its recipient. The first useful test is a small piece of work whose answer the recipient can check.

For the help-center review, prepare a short draft and an accompanying decision record. Include one claim supported by that record, one contradicted by it, and one for which evidence is absent. Keep the exercise clear enough that a person can judge the result without another assistant's opinion.

Then ask:

• Does the review distinguish those cases and point to the evidence it used?
• Does it request missing information instead of borrowing a conclusion from its example?
• Can the recipient change the source locations and review criteria without reconstructing the original author's environment?
• Does it remain within the access and actions the recipient allowed?

These checks make acceptance concrete. If the method assumes every team keeps a formal decision log, the colleague may need to supply another authoritative source. If the procedure works only when its author is present to explain hidden assumptions, it needs more work before it can travel.

Keep the first use small enough to inspect and undo. A useful review can begin with a copied draft; it does not need permission to publish the result.

Send the improvement back

Suppose the colleague discovers a weakness: the review treats a proposal as an approved decision because both appear in the same document. The correction can be shared as a better instruction and a new test example. Identify the decision's status and the evidence of approval before using it to support a claim.

The private discussion that exposed the mistake can stay with its owner. A constructed example containing a proposal and a later decision is enough to explain the failure and check the repair. The revised method should still handle the earlier examples. If it helps only the colleague's particular process, it can remain a local variation.

This is a direction we want to pursue at Zortex: make useful ways of working easier for people to create, examine and pass on. 个人上下文 helps a method work for one person. A carefully prepared method gives someone else a starting point, with room to adapt it and judge the result for themselves.

The handoff is complete when the colleague can put the method to work without needing the original private conversation. Their own project supplies the evidence. Their own review determines whether the method earns another use.