Make what works part of how your team works.
A correction that helped one session should help the next. Team playbooks give a useful lesson an owner, a trigger, a scope and a version, so reuse is a decision the team makes rather than something that happens by accident.
One lesson, from capture to a considered decision.
A lesson keeps its source sessions, its owner and its version · Sample workspace, synthetic data
Instructions are reviewed in the workspace · The preview carries only what the team needs to decide
- 1 Understand
- 2 Prepare
- 3 Compare
- 4 Apply & learn
Repository context
Compared, not appliedNothing is applied by being prepared · A person applies a reviewed version to future owned runs · Concept data
01 / 05 The lesson
A useful lesson should outlive the session that produced it.
- 01 Every playbook has an owner, a trigger, a scope, a version and an explicit application state.
- 02 A prepared version is compared with current practice on the same tasks before anyone relies on it.
- 03 Reading a recommendation changes nothing. A runner changes only when a person applies a reviewed version.
02 / 05 Capture, prepare, compare
Three steps from a lesson to a shared practice.
A lesson can take the form of a skill, a workflow or a hook. What the team needs to know is the same in each case: where it came from, who owns it, what it applies to and whether it has been compared.
01 Capture
Keep the lesson, and where it came from.
When a correction in one session would help the next, agentacct captures it with its source sessions, names an owner and files it in the team library as a draft. A lesson in the library is visible to the team. It is not applied to anything by being there.
- Source sessions stay attached to the lesson
- One named owner per playbook
- Drafts are visible before they are used
Repository context
Focused validation
Environment preflight
Eligible sessions counted from August usage records · Three more lessons not shown · Sample
02 Prepare
Scope the change before anyone uses it.
A prepared playbook states its trigger, its scope and its owner, and carries the acceptance criteria that current practice already has to meet. The generated instructions stay in the workspace, where the owner reviews them. The preview shows only what the team needs to decide.
- Trigger, scope, owner and version on every draft
- Acceptance criteria carried over unchanged
- Instructions reviewed in the workspace, not in a preview
Repository context
Draft v1| Trigger | Task start in a repository the team has already mapped |
|---|---|
| Scope | Future owned runs · airis · Engineering |
| Owner | Frank · Platform engineer |
| Version | Draft v1 · First version, replaces nothing |
| Source | 62 eligible sessions · August 2026 |
Trigger, scope, owner and version are the preview · Full instructions never leave the workspace · Sample
03 Compare
Compare before use. Apply on purpose.
A version runs against the same paired tasks, revision, environment and acceptance criteria as current practice. Unfinished tasks and held-out cases stay in the result. Only after review does a person apply the version to future owned runs, and the library records that state beside the version.
- Same tasks, same criteria, unfinished work retained
- Application state recorded per version
- Applied means future runs, never past evidence
Same input, revision, environment and acceptance criteria as current practice · Concept data, not a measured result
03 / 05 The library
Six lessons in the library. Three of them, up close.
Each card shows what the team needs to decide about a playbook and nothing it does not: owner, scope, trigger, version and application state. Sample
Reuse verified repository context at the start of an owned run instead of rediscovering it.
Run the checks an edit touches between edits and keep the full suite for the final pass.
Confirm the environment before the first command, so agents stop retrying setup errors.
04 / 05 What a playbook will not do
Proposals stay proposals until a person applies one.
The vocabulary is strict because the decisions are real: which runs a version touches, on what evidence, and who decided.
Reading changes nothing.
Opening a recommendation, a draft or a comparison never modifies a runner. Application is a separate, recorded action by a person.
Every version is named.
A change to a playbook is a new version with its own comparison. Runs record which version they used, so evidence stays attributable.
Comparisons keep the failures.
Paired tasks, retained unfinished work and held-out cases stay in the result. A better number on fewer tasks is not a result.
Detail stays with the owner.
Generated instructions and full workflow definitions live in the workspace, where the owner reviews them. A preview carries only what a team needs to decide.
05 / 05 Related
One improvement opens up the next.
Playbooks are where the other stories end: a cost opportunity, a quality comparison or a faster sequence becomes a practice the team keeps.
See it with your own lessons in mind
Make the next run start
one lesson ahead.
A guided look at how a lesson becomes a compared, versioned playbook for a sample cohort, and a conversation about your teams and tools.