Chapter 7 — Your team's skill library writes itself.
Every finished run can become a skill or workflow that all your agents reuse, so the team gets faster and cheaper with every task, and you approve what gets shared.
Vocabulary: Chapter 0. One runtime, many surfaces: Product concepts.
#Why a shared library beats one agent's memory
Each coding agent remembers things in its own way, and that memory stays in that tool. A project Library is shared: a skill saved from a Claude Code run is found and run by Codex, Cursor, Gemini or Antigravity in the same project, through the same AgentWitch tools (skills_find, skills_run). Each computer keeps a local copy of the project's skills, so agents read them without fetching them again on every run (principles).
What is shared and what is not:
| Shared with the project | Stays on your computer |
|---|---|
| Skills, playbooks and workflows you saved or approved | Files, repos, run transcripts |
| Per-skill use counts and estimated tokens saved (Reports) | Learned run memory (episodes), per account |
#Auto skills: skills from finished runs
Switch on auto skills for a project in its Library. Then:
- AgentWitch on a linked computer drafts skills from repeated, finished runs. Drafts stay on that computer until the owner decides.
- A bot that just finished work that will clearly repeat can propose a skill with
suggest_auto_skill. - The owner (or an allowed member) gets one question per suggestion: Save, Not now or Never. Only Save publishes it to the project Library.
When AgentWitch triages a finished run before drafting, it decides from what the run produced and what changed (outcome and file/git evidence), not from how the original request was worded.
A suggestion must never contain secrets or tokens.
#Token savings you can check
The project Reports tab shows, per skill, how often it was used and the estimated tokens saved compared with a measured baseline without that skill. Bars marked ≈ are based on fewer than 3 samples. These are estimates per skill, not a promised saving on every run.
#One dispatch engine, four names you might hear
| User-facing idea | What it is | Where it lives |
|---|---|---|
| Playbook | Saved behavior: prompts, rules, templates | Library, marketplace listings, harness files on the Mac |
| Capability | A published agent offering (metadata, version, policy) | Cloud (AgentWitch Cloud) |
| Workflow | A capability shape with a form (and sometimes a step graph) | Cloud |
| Harness | Rules/skills/commands on disk under ~/.agent-witch/harness/ | Your Mac |
Library = your saved playbooks. Marketplace = company-published listings others can browse and install. Neither replaces dispatch—they point at capabilities and project composition when you install (Mac pull applies files into the repo).
Engineering detail: Mac harness, workflow, and agent dispatch.
#Capabilities (what can run)
A capability answers: which agent profile, which form fields, and which policies apply before AgentWitch creates a Run.
You encounter capabilities when you:
- Pick an offering in the task composer or workflow runner.
- Publish or edit a workflow (create/edit forms, optional outputs).
- Browse team directory or admin tooling (company setups).
Capabilities are cloud objects. They do not execute code on the computer by themselves—they describe what the next Task or workflow step will send.
#Playbook context on Resources (estimate)
On a project’s Resources tab, Playbook context (estimate) lists repo-relative paths your linked Mac last reported from materialized playbook files (for example after link-folder or playbook pull). AgentWitch shows file count, an approximate token sum (bytes ÷ 4), and last sync time. Use it to see how heavy installed rules might be in the editor—not as usage billing. Details: playbook context estimate Q&A.
#Playbooks and the library
Each project has a Library tab (/projects/<id>#library). It is where playbooks, workflows, and skills for that project live after you save or fork them. Every library item belongs to one project. To reuse an item in another project, use Add from another project; that makes a copy.
The old top-level /library page is gone. /library opens Projects with a note to pick a project, and /library/<id> opens the item in its own project. If you cannot open that project, you land on Projects instead.
Typical loop:
- Complete a good Run or finish a workflow you like.
- Save to library (or fork from marketplace).
- Open the playbook later, adjust if needed, and run again on your Mac.
You stay in control: saving or forking does not silently change team templates until publish/install flows say so (learn from usage). Library items reference capabilities/workflows you already use. Running from library still creates a normal Run (or workflow run)—same honesty rules for terminal and outcomes (run UX honesty).
#Guest library (before sign-in)
Drafts saved earlier in this browser (local storage, before sign-in) still sync after you sign in, into a project Library; newer updatedAt wins, with the cloud copy winning on a tie.
Details: Guest library browser drafts.
#Running from library
- Guests are redirected to sign in before send.
- Signed-in users need a dispatch-ready Mac or a configured Cursor Cloud API key before Send is enabled; otherwise the UI shows connect / API-key guidance.
#Installing workflows and agents (project-first)
Marketplace Install always asks for a project and a Mac. The listing is saved to your library and linked in cloud project composition (workflow/agent + playbook metadata)—not as a global dump into ~/.agent-witch/harness/.
Start a task on the install success screen opens New task on that same project, not on Default.
On the computer, open the same project in AgentWitch Local. Pull into repo writes the linked playbook into that folder’s .cursor tree. If the playbook is already on the computer, you confirm the sets and pull. If it is only linked in Console, the same button still writes the official playbook files. The project folder must sit under your home directory.
Each marketplace card includes a How to use section (steps, prerequisites, supported writers: Claude Code, Codex, Cursor, Antigravity).
Same-machine identity: How AWC knows this computer.
#Marketplace (team templates)
Marketplace listings are published harness/capability packages for others to borrow. For a company user, marketplace is how leads ship standard playbooks without every teammate rebuilding forms and rules—that is team learning as a default path, not a side quest.
Flow (simplified):
- Browse listing → read How to use → Install (choose Mac and project).
- Cloud records library + project bindings. Start a task keeps that project. Mac pull writes repo files only after the harness set is installed locally.
- Teammates run from library or marketplace entry → shared Runs history.
Marketplace is not a separate runtime—install + library + dispatch.
#Workflows as playbooks with forms
A workflow capability adds structured questions before dispatch: text, choices, file upload, etc. Official presets may add checkpoints (see Chapter 6 — Workflows and checkpoints).
When you save a workflow to library, you are saving a playbook you can rerun with the same form shape. Custom workflows without an official graph still dispatch as one agent Run with operator steps embedded in the prompt (workflow builder).
#Project folder and Mac-only pickers
The console cannot browse your computer’s disk directly. Set repository / project folder via:
- AgentWitch Local on the computer (its folder picker), or
- Local bridge folder picker when the browser runs on that Mac.
See AWC project folder picker and AWC vs AWL projects source of truth.
Wrong folder → failed or misleading Runs; fix the path in settings or the workflow form before blaming the agent.
#Local hints vs cloud improvements (pillar 2 vs 3)
| Surface | What it does | You approve? |
|---|---|---|
| AgentWitch on this computer → Knowledge suggestions | Counts how often snippets or errors repeat; may suggest a Playbook step or harness rule | Yes—nothing installs until you act on the computer or in the Console |
| Capabilities → improvements (Console) | Proposed new capability version from feedback | Yes—accept or reject before publish |
Saving a Playbook from a Run is separate from both: you name what worked; the computer does not silently rewrite harness files when a suggestion appears (Chapter 4, Chapter 10 dev — memory loop).
#What to defer until you need it
| Defer | Reach for when |
|---|---|
| Authoring marketplace listings | You own team standards |
| Deep harness file editing | You outgrow UI install |
| Cursor Cloud dispatch | No computer available (explicit setup) |
Most teams start with: auto skills on, one installed playbook, and Chapter 5.
#Related reading
- System Q&A index
- Developer guide — mismatch traps (if UI says harness and docs say playbook, fix the product copy)
- Feature READMEs:
src/features/library/README.md,src/features/capabilities/README.md
#Query aliases
- AgentWitch library playbooks capabilities marketplace
- auto skills suggest_auto_skill Save Not now Never, skill library writes itself
- tokens saved per skill Reports, shared skills across Claude Code Codex Cursor Gemini Antigravity
- save to library run again fork workflow
- install playbook on computer harness
- guest library localStorage sign in sync
- capability vs workflow vs playbook user guide
- thu vien AgentWitch, playbook luu lai chay lai
- cai dat harness len Mac tu marketplace
- khach luu workflow tren trinh duyet chua dang nhap
- capability workflow khac nhau the nao
- team learning marketplace library share playbooks, team chia se playbook
- tiet kiem ngữ cảnh playbook thu vien, luu kinh nghiem chay lai