On this page
01Two shapes of reusable know-how
Good ways of working with AI often live in chat histories. A teammate cannot find or reuse them. One person finds a prompt that works. Another finds a better sequence for the same job. The next person starts again.
Reusable know-how comes in two shapes. Naming each one makes it easier to share and improve.
Those two shapes are playbooks and skills. Playbooks are process. Skills are capability. They sound adjacent. They are not the same unit of know-how.
02Playbooks are process
A playbook is a process for getting a recurring result. It might explain how to write a launch memo or prepare for a partner review. It answers one question: what sequence do we follow when this work appears again?
The team owns the playbook because the process belongs to the team. Each approved change creates a new version. The result is a current, shared way to do the work.
A shared playbook gives the next person a clear starting point. The sequence, checkpoints, and definition of done are visible. For a closer look, step inside a working playbook.
03Skills are capability
A skill is a reusable capability for a person or an AI agent. It might summarize a call into decisions and owners. It might draft in the team's voice. A skill is not tied to one workflow.
Skills travel between processes. The same drafting skill can support a launch memo or a partner update. Improve the capability once and each process can use the new version.
Think of skills as portable competence. A playbook says when and in what order to use that competence. A skill says how to do one kind of work well, no matter which larger process called for it.
04A skill is not an SOP
A skill is not an SOP. An SOP, like a playbook, describes a process. A skill describes a capability that can serve many processes.
Keep the two separate and both are easier to reuse. Playbooks hold repeatable processes. Skills provide the building blocks inside them.
The difference becomes clear when the work changes. A new step order changes the playbook. A better way to extract decisions from a transcript changes the skill. Each kind of learning has its own home.
Forcing every capability into one long procedure makes that procedure brittle. Separating process from capability keeps each unit clear and reusable.
05How they compound together
Playbooks and skills are strongest together. Consider a launch memo.
The playbook sets the sequence. Gather release notes. Decide what the audience needs first. Draft the memo. Route it for review. Publish the approved version.
Skills support the steps. One skill can summarize release notes. Another can apply the team's voice. Neither skill is the launch process. Each is a reusable block within it.
Improve the summarizing skill and every playbook that uses it can benefit. Change the launch memo playbook and its sequence improves without changing the skill.
The same pattern applies to support work. Change the playbook when routing rules change. Change a skill when the method for extracting context improves.
Improve a skill once and every playbook that uses it gets better. Improve a playbook and the process sharpens without touching the skills.
Composition is the point. Playbooks prevent useful skills from becoming disconnected parts. Skills prevent teams from copying the same capability instructions into every process.
06Where know-how needs to live
Playbooks and skills need a shared home. Constraint stores org-authored SOPs as immutable versions. It also stores versioned skill packages for use with Codex and Claude Code.
A playbook run snapshots its rendered steps and company memory when it starts. Human-gated steps can require an attestation. That keeps the record tied to the version that ran.
Constraint sits beside the agents and tools teams already use. Playbooks hold process. Skills hold capability. The team keeps ownership of the method.
The takeaway
Ask two questions. What processes do we repeat? Those become playbooks. What capabilities do we use across those processes? Those become skills.
Name them and keep them current. The team gets a shared starting point instead of rebuilding the method in each chat.
See how that looks in practice. Browse the Bank.