Operating packages
A Skill on its own is a method. An operating package is that method plus everything it needs to run safely.
Four layers sit between a connection and a job someone can deploy.
| Layer | What it means |
|---|---|
| Connection | Approved access to a service or system |
| Tool | An action the run may perform through that connection |
| Skill | A tested method for completing a type of job |
| Operating package | A Skill with its required connections, templates, Knowledge, permissions, and checks |
People deploy a weekly controller close, an account brief, a release investigation, or a pipeline review. The underlying Skill may be stored as a versioned file, but the operating package is the useful unit, because it includes everything the job needs.
Why the package is the unit
A Skill handed to a team without its connections produces a run that cannot reach the systems. Handed over without its Knowledge, it produces work in the wrong format against the wrong rules. Handed over without its checks, it produces a result nobody can accept.
Packaging them together is what makes a workflow portable between teams rather than something that only works where it was built.
Building one from a successful run
- 01Run it manually until it is dependableThe completion test has to hold before the method is worth packaging.
- 02Extract the stable procedureSeveral good examples help separate the method from one-off details.
- 03Attach the connections and permissionsThe smallest set the job requires, as an explicit allowlist.
- 04Attach the Knowledge and templatesThe approved facts and formats the run depends on.
- 05Name the checks and the exception ownerWhat proves completion, and who receives what the run will not decide.
- 06Test on a held-out caseBefore broad use, run the candidate against a case it was not built from.