03: Improve a FileMaker Skill From Real Sessions

The Latin root of 'review' is revidere : to see again. The best version of your Skill comes from seeing a real session again, not from imagining one.

Your Skill is at version one. It knows one rule and, after lesson two, asks one question. Now it learns from the work.

In this post:

• The End-of-Session Review Prompt

• What Belongs in a FileMaker Skill

• When a Session Goes Wrong, Write It Down

• Ship Version 1.1 of Your FileMaker Skill

• Skill Review Vocabulary

The End-of-Session Review Prompt

Of the ways to build a Skill, this is the one that makes the most sense to me. Get to a point in time you control, generally the end of a coding session, and ask the Agent what it has just completed, and especially what it has just learnt:

Review what you have learnt in this last session,
and report on how you would add to this Skill . . .

Not mid-flow. The Agent is still working the problem then, and so are you. At the end, the session is a finished piece of evidence: what worked, what it got wrong, what you had to correct.

The same prompt works for a fresh Skill and, more importantly, for an existing Skill heading for its next release.

What Belongs in a FileMaker Skill

The Agent will suggest more than you need. You decide what goes in.

Split it into two piles. Durable knowledge will still be true in five years: how a certificate trust chain works, why a container's writable layer isn't a volume. You already carry that. Perishable knowledge has a shelf life measured in release notes: the exact flag, the exact error string, today's default. That's the pile worth storing in a Skill, because the Agent can check it against the live system every time.

Example: Three failure modes made it into my FileMaker Server Docker Skill from real install sessions: a certificate import bug, publishing components switched off by default, and startup timing that varies by tens of seconds. All three were true for that FileMaker Server release, on that Ubuntu build, on that day. That's exactly why they belong in the Skill and not in my head.

The longer version of this argument is in FileMaker Knowledge Delegation.

When a Session Goes Wrong, Write It Down

A correction you make once is a lesson. A correction the Skill holds is a rule.

Example: In the middle of October, an Agent edited one of my live blog posts on Wix and the change went straight onto the public page. The API option it used is documented as keeping the original post published. It doesn't. Within two days that became a rule in the Wix Skill I keep for my own site: never send that option, and check the response says the change is still unpublished.

Late in October it happened again, in the other direction. I asked for a past-tense pass over my website, and the Agent told me the home page cards could only be changed in the Wix Editor. I had to remind it that an Agent built those cards in the first place. Afterwards, that became a rule in the same Skill: site text the owner can't reach in the Editor is the Agent's job.

Both rules came from a session. Neither came from me sitting down to imagine what might go wrong.

Ship Version 1.1 of Your FileMaker Skill

Give your Skill a version, and change it every time the Skill changes:

metadata:
  version: "1.1.0"

Keep a short CHANGELOG.md beside SKILL.md: one line for what changed, and why. Six months time, you'll want it.

Then install it cleanly. Remove the old copy under Customize, then Skills, before you upload the new one. Multiple copies mean multiple versions, and Claude may reach for the wrong one.

Example: Late in October, I installed a copy of my own Wix Skill that carried the right version number and the wrong contents: an earlier build, saved in a different folder. Same number, older text. The fix was to delete it and upload the build that matched the release.

Skill Review Vocabulary

Session review. Asking the Agent, at a point you control, what it learnt and how it would change the Skill.

Durable knowledge. What will still be true in five years; you keep it.

Perishable knowledge. What changes with each release; the Skill keeps it, and checks it.

Version. The number in a Skill's metadata that changes every time the Skill does.

Takeaway

Revidere. See the session again before you close it. Keep the perishable pile in the Skill, turn every correction into a rule, and give each change a version and one installed copy.

Next, the Skills other people have built, and the Code tab. Continue with my next post, Install FileMaker Skills From a Plugin Marketplace.

More to come . . .