Test It, Fix It, Keep It Current

Your skill is written and installed. Do not hand it real work yet. A skill earns trust the same way a new hire does: by passing a probation you designed. Three test scenarios, run before any real customer sees its output, will tell you more than a month of casual use.

The three-scenario test

Run each of these in a fresh conversation, so leftover chat context cannot bail the skill out.

Scenario 1: a normal case. Feed Quote Builder a typical job, say site notes for a fall cleanup with bed edging at a house inside your service area. Check the boring things: did it pull the right rates, keep your structure, stay under the length limit, end with your next step? Most drafts pass this one, which is why stopping here fools people.

Scenario 2: an edge case. Something legitimate but unusual. A customer 40 minutes outside your service area, or a job mixing two services you price differently. You are checking whether the skill reaches for the travel rule and the rate card, or quietly averages its way to something wrong.

Scenario 3: a trap case. Design notes intended to make the skill break one of its own rules. Ask it to quote a service that has no rate-card entry, hydroseeding, say, when you only stored mowing, beds, and cleanups. The pass condition is exact: the draft shows [PRICE NEEDED] and flags it at the top. If a plausible invented price appears instead, the skill failed its most important test, and you found out for the cost of five minutes instead of an honoured bad quote.

Write your three scenarios down. You will reuse them after every future edit, the way a developer reuses tests.

Fix the file, not the chat

When a test fails, the tempting move is correcting it in conversation: "no, travel past 30 minutes is $40 extra, redo it." The draft improves, you feel done, and next week the same mistake returns. Chat corrections evaporate when the conversation ends. File edits persist.

So the repair loop is: notice the failure, open the skill file, add or sharpen the rule that would have prevented it, reinstall, and rerun the scenario that caught it. The travel correction becomes a permanent line in Rules. Ten minutes now, and that class of mistake is gone for good instead of gone for one draft.

Version it like you mean to keep it

Add two lines at the top of your skill file:

The version line sounds like overkill for a one-page file. It is not. Six months from now you will wonder whether the copy installed in your assistant is the one with the travel fix, and this line answers in one glance. The change note tells future-you why a rule exists, which is the difference between confidently editing the file and being afraid to touch it.

The monthly ten-minute review

Skills decay quietly, because your business changes and the file does not. Put a recurring ten-minute appointment in your calendar, first Monday of the month works, and ask three questions:

1. Did any prices change? Update the rate card in the skill the same day you update it anywhere else, or the skill starts quoting last season's numbers.
2. Did services change? Added snow clearing for winter? It goes in Setup and the rate card, or every winter quote comes back [PRICE NEEDED].
3. Did I spot a new failure? Any output you had to correct twice this month is a missing rule. Add it.

While you are in there, apply the retirement test: is this skill still earning its upkeep? A skill you built for a service you dropped, or one you route around because a toolbox skill like Proposal Studio turned out to fit better, should be retired. Delete it from your assistant, keep the file in a folder in case you were wrong, and spend the maintenance attention on skills you use weekly. Two well-kept skills beat six stale ones.

What testing cannot give you

Be clear-eyed about what you have built. A tested skill reduces variance: fewer forgotten exclusions, fewer format wobbles, no invented prices. It does not remove the need to read every output before it reaches a customer. Assistants can still misread notes and state wrong things smoothly, and no rule catches a mistake type you have not met yet. The skill drafts fast so that your review is the slowest step, and that is the correct place for the human to be.

Try it now

Write your three scenarios, normal, edge, and trap, and run them today. Fix any failure in the file, add your version line, and book the monthly review before you close your calendar. That habit is the whole difference between a skill that lasts and a clever file you forget by October.