Open Skills need boundaries before they carry client work

A skill describes how to do something

A reusable skill can carry a good procedure from one session to the next. Small primitives can compose into runbooks, and a session-to-skill flywheel can turn repeated work into a library. That framing is useful because it makes operating knowledge portable instead of leaving it buried in a chat.

But a procedure is not permission. Knowing how to prepare a client update does not establish who authorized it, which client records may be used, whether the update may be sent, or what should happen when the source material is incomplete.

Those questions matter as soon as a skill carries work for someone else. The skill still does the work. The surrounding boundaries make the work suitable for a real engagement.

Four controls to define before a runbook starts

1. Named authority

Name the person who owns the outcome and the scope they authorized. A useful grant is concrete: the client or matter, the intended result, the systems the runbook may access, and the actions it may prepare or take.

“Help with the account” is not a workable grant. “Draft the weekly status update from these three project records for this manager to review” is much closer. The second version gives the work an owner and a boundary that another person can inspect.

2. On-task limits and stop conditions

Define what the runbook may touch, what it must not do, and when it must stop. Limits can cover approved sources, permitted tools, maximum record counts, excluded data, or a time period. Stop conditions handle the moments when continuing would require a new decision.

Examples include a missing source, conflicting instructions, an unexpected recipient, a proposed change outside the stated matter, or a request for credentials. A stop is not a failed run. It is the correct result when the next step falls outside the authority that was given.

3. Human review for consequential steps

Separate preparation from action. A runbook may draft a client message, assemble a filing package, recommend a payment, or prepare a production change. Sending, filing, moving money, publishing, deleting records, or making another difficult-to-reverse change calls for a named person to review the actual proposed action.

The review point should say what the person is deciding and what evidence is available. A generic “approve” button is weak if the reviewer cannot see the recipient, amount, source, or change being approved.

4. An inspectable record

Keep enough information to reconstruct the outcome at the level the work requires. That may include the request, the authority used, source references, the produced artifact, the review decision, exceptions, and the final disposition.

The record does not need to expose confidential material unnecessarily. It does need to let the responsible person answer practical questions later: What was requested? What sources supported it? Where did the runbook stop? What did a human approve? What changed?

A short preflight

Before a reusable skill carries client work, write down five things:

Question	Concrete answer to capture
Who owns the outcome?	A named person or role
What is this run for?	One client, matter, and intended result
Where are its limits?	Approved sources, tools, actions, and exclusions
What requires review?	The consequential step and the evidence shown to the reviewer
What record remains?	The request, result, decision, and exceptions appropriate to the work

If one of those answers is missing, narrow the runbook or keep the work in draft mode until the boundary is explicit.

The library is the starting point

Skills make good work reusable. Boundaries make the use of those skills reviewable. That distinction is the difference between a clever personal shortcut and a repeatable way to carry work for a client.

---

Credit: the primitive → runbook → flywheel framing is from Nate B. Jones’s Open Skills.