Extract the choice, its conditions, and its limits
To turn a story from your book into instructions for an author skill, identify the decision someone made, the information available at that moment, and the conditions that justified it. Then state what would have changed the recommendation. Keep the reported outcome separate from the rule you want to teach.
A story can show a useful decision without proving that the same action always works. Your job is to preserve the reasoning a reader can apply, including uncertainty and exceptions.
Use the annotation method below on one written example. You will finish with a compact rule card, a list of unanswered questions for author review, and contrasting scenarios to use when testing the eventual skill.
Keep the value of stories without treating them as universal proof
Readers can want concrete examples and still question their implications. In a request for business books containing cases of both success and failure, u/biziguy wrote:
“I like such books as I get a lot of take-aways rather than the writer's opinions.”
This expresses one reader's preference. It does not establish that every case study is stronger evidence than an explicit argument. Original post.
Another reader, u/frankOFWGKTA, questioned advice from successful entrepreneurs:
“However, those making this argument are the ones who have succeeded. What about those who have failed?”
The wider post asks about survivorship bias. You do not need to adopt every claim in that discussion to take the question seriously: which cases are missing from the lesson you are extracting? Original post.
For an author skill, use the story to make a decision inspectable. Do not convert “this worked here” into “this produces the same result everywhere.”
Carnegie Mellon's teaching guidance for case studies recommends asking learners to examine assumptions and substantiate claims. That is a useful standard for reviewing your extraction, though the guidance does not validate this particular authoring procedure. CMU Eberly Center.
Read the story in two passes
First, read for the narrative. What problem did the person face? What happened next? What does the passage explicitly claim about the result?
Second, stop immediately before the important decision. List only the information available at that point. Do not give the decision maker facts that appear later in the story.
This matters when a successful outcome makes a choice appear inevitable. The person may have been acting with incomplete information, uncertain forecasts, or a reversible experiment. Those details belong in the rule if they affect its use.
Mark each annotation as one of three types:
- Explicit: Stated in the source passage.
- Inferred: A plausible interpretation that the passage does not state.
- Unresolved: Information needed before you would teach the rule.
If you are the author, you may be able to resolve an inference from notes or recollection. Record that as an additional source or clarification. Do not silently rewrite the published story as if it contained the new information all along.
Worked example: a customer-service queue
The following story and method are fictional. They are created to demonstrate extraction, not presented as a real business case or evidence of an outcome.
A team handling customer questions planned to buy a new queue-management tool. Before deciding, the team lead reviewed twenty recent cases. Several had waited because staff could not tell which person owned the next step. The team tried adding a named owner and next action to each case for one week, using its existing system. It kept the original records so the trial could be reversed. At the review, staff reported fewer ownership questions. The lead postponed the purchase while checking whether other delays remained.
A careless extraction would say: “Do not buy software; fix your process.” That rule reaches beyond the story. The passage describes a provisional decision after identifying one possible source of delay, not a conclusion that software never helps.
A more faithful extraction asks what the lead knew and which uncertainty the trial addressed.
| Story element | What the passage establishes | What it does not establish |
|---|---|---|
| Proposed purchase | A new tool was being considered. | Its price, capabilities, or likely return. |
| Review of recent cases | Twenty cases were examined. | That they represent all cases or all delays. |
| Ownership confusion | Several cases lacked a clear next owner. | That ownership was the only cause of delay. |
| One-week trial | Named owner and next action were added in the existing system. | That one week is sufficient for every workflow. |
| Reported change | Staff reported fewer ownership questions. | A measured reduction in total resolution time. |
| Decision | Purchase postponed pending further investigation. | Purchase permanently rejected. |
The table prevents the skill from inventing a result metric or turning a temporary choice into permanent policy.
Write the first rule as a conditional proposal
A candidate rule from this example could be:
When considering a new tool for a workflow problem, first identify a specific observed obstacle. If a small, reversible process change can address that obstacle within the existing system, define a limited trial and inspect the result before deciding whether the tool is still needed.
This is an editorial proposal based on the fictional story. It is more general than the source, so it needs author review and contrasting examples before becoming a published instruction.
Ask whether every clause belongs. “Reversible” comes from preserving the original records. “Specific observed obstacle” comes from reviewing cases. “Inspect the result” comes from the follow-up. The story does not justify a universal twenty-case sample or one-week trial, so those numbers remain example details.
Also ask what is missing. Could changing ownership fields disrupt reporting? Did the lead have permission to run the trial? Were urgent customer obligations protected? The passage does not answer. Keep those questions visible rather than assuming a harmless change in every setting.
Build a rule card the skill can use
Use one card per important decision, with a link or location pointing back to the source.
| Field | Filled example |
|---|---|
| Reader decision | Whether to investigate a process change before buying a tool. |
| Trigger | A proposed tool purchase intended to address a described workflow obstacle. |
| Required facts | Observed obstacle, current process, available authority, constraints, possible trial. |
| Action | Compare a bounded process trial with proceeding directly to a purchase decision. |
| Conditions | Trial can be contained, reviewed, and reversed without violating obligations. |
| Exception | Existing system cannot perform a required function, or a trial would introduce unacceptable disruption. |
| Evidence status | Proposed generalization from a fictional example; not validated guidance. |
| Output | A trial proposal or a list of missing facts, not an automatic purchase decision. |
| Source | Illustrative queue story in this article. |
The exception is an author-added boundary for the proposed rule, not a fact reported in the story. Labeling that distinction lets a reviewer check what came from the text and what was added during method design.
For your actual book, use a chapter and section reference instead of the illustrative source label. Include the edition when page numbers or wording could differ.
Change one condition and see whether the rule still makes sense
Create contrasting scenarios to expose hidden assumptions. These are thought exercises until you actually run and evaluate a skill.
Scenario A: Missing ownership. The reader has examples of cases waiting for an owner and can change a field in the current system. A suitable response explores a limited trial and how to inspect it.
Scenario B: Missing capability. The reader needs a function the current system cannot provide. A response that insists on another process trial has overgeneralized. The skill should identify the capability requirement and help frame the tool decision.
Scenario C: Missing evidence. The reader only says “our software is terrible.” The skill should ask for a recent example of the obstacle. It should not invent a root cause.
Scenario D: Missing authority. The reader cannot change the workflow. The skill can help draft questions or a proposal for the responsible person; it should not tell them to alter the system anyway.
Write down the expected behavior for each case before testing. The agent skill testing guide explains how to compare actual runs with expectations.
Preserve uncertainty in the output
An author skill should be able to say, in plain language, what the example supports and what it leaves open.
For the queue story, a good explanation might be: “This example suggests checking whether ownership confusion contributes to the delay. It does not show that your proposed tool is unnecessary. We need a recent case and the capability you expect the tool to add.”
That answer offers a useful next step without borrowing certainty from the story's ending.
Avoid language that hides a leap. “Obviously,” “always,” and “the lesson is simple” can turn a limited interpretation into an absolute instruction. Replace them with the relevant conditions or remove the rule if you cannot state those conditions reliably.
If the author disagrees with the extracted rule, preserve the disagreement as work to resolve. A persuasive AI summary is not an authority on the author's intent.
Separate the story, the rule, and the evidence record
Maintain three connected items. The story provides the context. The rule supplies the proposed procedure. The evidence record identifies sources, uncertainties, and any subsequent checks.
This organization helps when the method changes. You may revise a rule after learning that it fails in a particular situation while leaving the historical story intact. Conversely, correcting a factual detail in the story may require rechecking several rules that relied on it.
You do not need to show the reader every authoring note. You do need the skill's claims and instructions to reflect the evidence accurately. Give the reader enough context to understand why the recommendation fits their case.
The guide to writing an agent skill covers packaging the resulting instructions and examples. Finish the extraction and author review before treating the rule as ready to run.
Choose one story with a real decision in it
Start with a passage where the person had options, faced a constraint, and chose a next step. Annotate what is explicit, inferred, and unresolved. Then create one rule card and at least one contrasting case.
If you want help developing those reviewed rules into an author skill, visit Skillfully and choose Book onboarding. Bring the source passage, the proposed rule, and the conditions under which you would recommend something different.