Turn One Good AI Result into Experience You Can Reuse

Imagine finishing a set of meeting minutes with AI. The table is orderly, with clear owners and dates. Save the conversation, substitute another recording next time, and it seems reasonable to expect another good result.

Except the new recording never confirms an owner. The requirement saved from last time says “all task fields must be complete.” The table can still be filled, along with a decision the meeting never made.

We saved what success looked like. Why could we not repeat it? That is what I want to understand when organizing Skills and working methods.

Where did that complete table come from?

In this hypothetical case, the framework is 5W1H. It prompts us to look for purpose, people, timing, and actions. But the owner in the earlier table may have been supplied by a participant after the meeting. We kept the framework and lost the account of how that information arrived.

Next time, all that remains is “every field must be complete.” There is less source material, but the required output has not changed. The executor might guess or ask for help. If the procedure never explains how to handle a gap, someone familiar with the project still has to step in.

That part belongs in the method too: which details can be extracted from the recording, which need another source, and how to mark anything that cannot be confirmed. 5W1H prompts us to find a task owner; it does not appoint one for the meeting.

A photograph of a good meal preserves the memory without teaching us how to cook it. What condition were the ingredients in, and why did the cook turn down the flame? Those decisions are absent from the finished dish. To reuse a working method, we also need to know what the person doing it noticed and what they changed as a result.

Tools and methods such as codex-ppt and 5W1H inform how I organize this work; I did not originate all of them. What I mainly accumulate is experience from applying them: when an approach works, how it needs to change under different conditions, and how to tell whether the revised result fits.

Which parts of past experience belong here?

Once we recover those decisions, it can be hard to leave anything out. We may end up carrying the whole history into the next assignment.

Consider a presentation. “Every page should be readable” is useful across many topics. “Use dark blue for this deck” may be a choice for its particular style. Why dark blue was chosen belongs in the decision record. All three may be worth keeping, without all three becoming requirements for the next deck. Otherwise, the previous assignment's answers arrive before the new task begins.

I put recurring judgment criteria, important steps, and tool instructions in a Skill. The current objective, confirmed choices, and unresolved items belong in the task record; original material retains its source. They should be easy to cross-reference when needed, without all being read on every assignment.

The record should also show which changes affect which decisions. A new audience calls for another look at depth; new dimensions call for a layout review. Correcting one typo usually does not require another discussion of audience and structure. These conditions tell the next person what to revisit and what can still be used.

Old decisions can stay, provided the current version is clear. Otherwise, “Final” and “Final, Really This Time” join the discussion together. Their filenames grow more certain while their contents disagree.

Anthropic's article on context engineering emphasizes selecting and organizing useful information while retaining sufficient necessary background.^[1] When simplifying, I first set aside requirements that no longer apply or have been superseded. Leave out a crucial attachment, and a shorter conversation can make the next person's job harder.

One more rule can create one more problem

Consider another hypothetical failure: a long presentation title gets clipped. Adding “never use long titles” looks like learning promptly from the mistake. But the next title contains a full name that must stay, requiring an exception. A new page size makes the old length limit unsuitable, so another qualification follows.

Over time, each rule remembers what went wrong but loses the conditions around it. On a new task, the executor has to work out which rules apply and which conflict, then ask for help when they cannot be reconciled. As the rules accumulate, so does the work required before the task can begin.

Look again at the title. It was the combination of text, dimensions, and layout that caused the clipping. A line break, a different layout, or tighter wording might each solve it. The title needs to remain complete and readable; no single remedy has to become a permanent prohibition.

When merging rules, I would first ask whether they address the same problem, apply under similar conditions, and can be assessed by the same check. Several rules preventing clipped titles can sit together with their relevant differences explained. If one requirement preserves exact words and another makes material easy to paraphrase, we need to say when each applies. Merging them into “be accurate and concise” makes the instruction shorter and the next step less clear.

The revised wording still needs to help with the original problem. Replace “avoid long titles” with “ensure quality,” and the next person still does not know what to inspect. A tidier file does not necessarily make a more useful method.

When is the checking enough?

The method also needs to explain how to check the result. Once a file is generated, we still need to see whether its recipient can open it, whether the important content is present, and whether the pages are readable. Reading back the actual paragraphs and tables after writing to Feishu serves the same purpose. A successful interface response will not restore a missing passage.

How much checking is needed depends on what changed. A new, complex presentation calls for inspecting its pages. A change to one passage calls for checking that edit and its surrounding meaning. Once the relevant questions have been answered, several more rounds of confirmation add time to every small revision.

Resolving a problem need not always produce a new prohibition. Some issues belong to particular material, some to a project's preferences, and others repeatedly affect a class of work. A serious problem with a clear cause need not happen twice before being addressed. An occasional preference does not become universal because it was written into a file.

I want someone who missed the previous assignment to know how to begin and which changes call for another look. If they still need the author to explain, listen to the sentence the author adds. It may be exactly what the record left out last time.