Write the Exceptions to Your Method Before Teaching It to AI

An exception register records the conditions that change your recommendation: the usual rule, the signal that makes it unsuitable, the reason, and the alternative action. Build it before turning your method into an AI skill, so the default instruction does not become an unconditional command.

The useful exception is specific. “Adapt to the reader's circumstances” leaves the decision unexplained. “If the reader's work hours change each week, do not assume the same daily time slot is available” gives the skill something to check.

Start with cases where you would interrupt someone applying your advice. What did they overlook? Which assumption failed? What would you tell them to do instead?

A recommendation can depend on control over time, access to information, a particular goal, or someone else's agreement. Those conditions may be obvious to you and invisible to a reader.

A retail supervisor, u/Imthegoat1212, described a scheduling constraint:

“My boss allows me to have 2 preferred days off (Tue/Sat) but I’m never guaranteed to have those days off consistently.”

The original post discusses several personal challenges. Here, the relevant fact is simply the reported lack of control over a repeating schedule; it does not support a medical claim or a general conclusion about shift workers. Original discussion.

An author teaching a fixed weekly planning routine should account for that possibility. Telling this reader to protect the same Tuesday slot would assume a condition the reader has explicitly said is absent.

The same issue appears in other methods. In a writing discussion, u/WyrdHarper noted:

“Genre is a really important consideration, and something that frequently gets omitted from questions, but has a profound effect on the answers.”

That is a participant's observation about fiction advice, not a measured finding. It illustrates why the purpose and context belong beside a rule. Original comment.

For each exception, record five things:

• Default: what the method normally recommends.
• Trigger: a fact that changes whether the default applies.
• Reason: why that fact matters.
• Alternative: what the skill should do instead.
• Counterexample: a nearby situation where the default still applies.

Keep an author source beside the entry while drafting: book section, approved note, or incident you can review. If the exception is a new interpretation, mark it for approval rather than attributing it to the published method.

An exception without an alternative may still be valid. The alternative can be to pause, identify a dependency, or explain that the method does not cover the situation. It does not have to be another confident recommendation.

Consider a fictional author whose book recommends reserving a recurring weekly slot to plan a personal creative project. The following register is an invented design example, not a tested productivity intervention.

The register does not promise that a different slot or a clearer dependency will solve the reader's wider situation. It prevents a narrower mistake: applying a rule after its required condition has failed.

Notice that “the reader is unmotivated” is not a trigger in this table. It is an interpretation, and it may not explain the problem. Use facts the reader can report or the skill can inspect within its authorized task.

Place the check before the action it changes. If the skill drafts a repeating schedule and only then asks whether the reader has stable hours, it has already built the output on an unsupported condition.

A proposed instruction for the first row could be:

“Before suggesting a recurring planning slot, confirm whether availability repeats. If it changes with a work rota, plan only within confirmed availability and label later dates provisional.”

Keep the explanation short but accessible. The reader should understand why the recommendation changed. “Your available hours vary, so this plan uses the week you can confirm” is more useful than announcing that an exception handler was triggered.

Do not bury a governing exception in a long reference file without telling the skill when to consult it. A detailed example can live elsewhere; the condition that changes the decision belongs at the decision point.

Prepare paired cases that differ in one relevant fact. One reader has a stable Tuesday evening; another has a rota that changes weekly. Write the expected behavior for each, then run the actual skill and retain its responses.

Also check whether the skill overuses the exception. Variable hours do not mean the reader cannot plan anything. An unconfirmed contribution does not mean every other task must stop. The alternative should be as narrow as the reason for it.

When several exceptions apply, establish their order. In the fictional example, a changed project goal should be reviewed before scheduling tasks toward the old goal. Record that precedence rather than leaving the skill to choose whichever rule it notices first.

The agent skill testing guide covers execution checks. Your exception register supplies the author-specific cases those checks need.

A useful first register can be small: a few recurring exceptions with clear triggers and contrasting examples. Expand it when actual reader situations expose a missing condition, while keeping the source and reason for each change.

To discuss turning your method into a skill, visit Skillfully and choose Book onboarding. Bring the usual procedure and the cases where you would give different advice.