Playbooks
Define how the assistant handles your recurring tasks — personal skills stored in your account.
What are playbooks?
Playbooks are your personal version of the built-in assistant skills. While system skills are curated by Dailify and cover standard workflows (GitHub, research, document creation, etc.), playbooks let you define custom behaviour specific to your work.
Think of a playbook as a named, reusable set of instructions. When you ask the assistant to do something that matches a playbook, it automatically loads those instructions and follows them — exactly like a system skill, but written by you.
How playbooks work
Every time you send a message, a fast planning pass reviews the conversation and decides which skills (system or personal) are relevant. Playbooks participate in that process on equal footing with built-in skills:
- Keyword matching— if your message mentions words from a playbook's keyword list, that playbook is automatically considered.
- Intent matching— the planning model reads your playbook's description and decides whether it fits the request.
- Instruction injection — if selected, the full playbook body is injected into the assistant context. The assistant reads it before drafting a reply or calling tools.
Creating a playbook
Go to Playbooks in the sidebar and click the + button. Each playbook has four parts:
- Title— a human-readable label (e.g. "Code review checklist").
- Name (slug) — a short identifier the assistant uses to reference the playbook (e.g.
code-review). Auto-filled from the title. Must be unique per account. - Description— one line that tells the planning agent when this playbook is relevant (e.g. "Structured code review process covering security, performance, and tests"). Required for the playbook to be active.
- Keywords— comma-separated trigger phrases (e.g. "code review, pr, pull request"). When the user message mentions these words, the playbook scores higher during matching.
- Instructions (body) — the full guidance the assistant should follow. Be specific: use headings, numbered lists, and concrete steps. Write it as if you were briefing a new colleague.
Making a playbook active
A playbook must have both a name and a description to be considered by the planning agent. Playbooks without these fields are saved as drafts and will not be used. The editor shows an Active badge when both fields are present.
Writing effective instructions
Good playbook bodies share a few traits:
- Concrete steps — numbered lists the assistant can follow sequentially rather than vague advice.
- Output format guidance— tell the assistant how to format its reply (e.g. "always output a summary table first, then detailed notes").
- Scope boundaries — clarify what the playbook covers and what it does not, so the assistant knows when to apply it.
- Context the assistant may not have— include domain-specific terms, your team's conventions, or standards the assistant wouldn't know otherwise.
Example playbook
Title: Code review checklist
Name: code-review
Description: Structured code review covering security, performance, and test coverage
Keywords: code review, pr, pull request, review
Instructions:
When reviewing code, always check in this order:
1. Security — look for injection risks, missing auth checks, and secrets in code.
2. Correctness — does it handle edge cases and error paths?
3. Performance — any obvious N+1 queries, unnecessary loops, or blocking I/O?
4. Tests — is the new behaviour covered? Are existing tests updated?
5. Readability — would another engineer understand this in 6 months?
Format the review as a numbered list with a short summary at the top. Flag critical issues with ❗ and suggestions with 💡.
Difference from system skills
System skills are maintained by Dailify and updated with new integrations and capabilities. Playbooks are personal — only you can see and edit them, and they never affect other users. Both types are considered together during planning; the assistant does not distinguish between them when following instructions.
Future features
Playbook instructions will soon support:
#workflow-name— reference a workflow directly inside playbook text./playbook-name— mention another playbook inside instructions.{{env.MY_VAR}}and{{now}}— embed environment variables and the current date/time in playbook bodies.
See also: Assistant overview · Memories