Playbooks

Playbooks let you bring your own testing methodology into Cracken. A playbook is a structured prompt plus its capability bindings that you select explicitly when launching an operation or automation, giving you repeatable, consistent assessments aligned with how your team works.

At a glance

• What it is — A reusable, structured methodology (system prompt plus capability bindings) you select explicitly when launching an operation or automation.
• When to use it — Repeatable, consistent assessments aligned with a specific testing methodology, launched on demand or run recurring through an automation.
• Inputs — Name, description, system prompt (written manually, generated by the agent from an objective description, or imported from .json/.zip), optional capability bindings (capabilities, skills, integrations), optional LLM config, assets, appearance, and visibility.
• Outputs — A saved playbook in the Library, attachable to operations and automations; each save records a new version in its history.
• Related objects — Skills, Automations, Operations.
• Common actions — Create (manually / build with agent / import), Edit, Export, Delete.
• API / tool links — UI only — no public API documented on this page.

Overview

A playbook is built around a system prompt — the methodology text the agent follows — together with optional metadata and capability bindings. Once saved, a playbook can be attached to any operation or automation to drive the assessment.

You can build a playbook in three ways: write it yourself in the editor, have the agent build one for you from a description, or import an existing one from a file. All three produce the same kind of playbook.

Prerequisites

• Access to an active (non-archived) realm in your tenant.
• Playbooks are managed from the Library, reached from the top navigation bar.

Playbook structure

A playbook stores these fields:

Field	Description
Name	Human-readable identifier for the playbook
Description	Brief summary of what the playbook covers
System prompt	The methodology text the agent follows (the playbook's content)
Operation naming guidance	Optional instruction for how operations launched from this playbook are named
Capability bindings	Three separate bindings: capabilities — the tools the agent may use (see Capabilities); skill_uuids — pinned skills; and integration_ids — pinned integrations
LLM config	Optional model and reasoning-effort the playbook starts with
Assets	Optional reference files bundled with the playbook
Appearance	Icon and color shown in the library
Visibility	Realm-scoped or account-wide (see Visibility)

The system prompt is free-form text. You author it however suits your methodology — Cracken does not impose a fixed section layout.

Create a playbook

Open Library → Playbooks (the layers icon in the top navigation) and switch to the Playbooks tab (the Library also has a Skills tab). The New Playbook button offers Create manually and Build with agent, and Import brings one in from a file. Every playbook you create or import belongs to a realm. Create manually and Build with agent ask which realm to use only when more than one active realm is available — archived realms are never offered; Import shows a required, preselected Realm field whenever at least one active realm exists. The chosen realm is stored as the playbook's realm_uuid. Built-in system playbooks are the exception — they are account-wide and belong to no realm. Each save records a new version you can review from the editor's version history.

Create manually

Step-by-step instructions

1. From inside your realm, open the Library (top bar) and switch to the Playbooks tab.
2. Click New Playbook → Create manually.
3. If more than one active realm is available, choose the realm to create the playbook in and click Continue. With a single active realm this step is skipped. The playbook editor opens.
4. Edit the name and description in the header, and pick an icon.
5. Write the system prompt — the methodology text the agent follows.
6. Open the Capabilities panel to pin capabilities (see Capabilities), and the Skills panel to pin skills from your library.
7. Open the Advanced panel to set operation naming guidance and the LLM config.
8. Click Save. The playbook lands in your Playbooks list.

Build with the agent

Step-by-step instructions

1. From inside your realm, open the Library (top bar) and switch to the Playbooks tab.
2. Click New Playbook → Build with agent.
3. If more than one active realm is available, choose the realm to create the playbook in and click Continue. With a single active realm this step is skipped.
4. Cracken opens an operation in that realm's console seeded with its built-in Configure playbook.
5. Describe the engagement in plain language — scope, target, goals, and constraints — then submit.
6. The agent writes a structured playbook and saves it to your library. Review the sections and edit as needed.

This runs as a normal operation, so you can review and refine the result in conversation before it is saved. The saved playbook appears in your library and as a launchable card on the Release the Cracken operation screen.

Import from a file

1. Click Import.
2. Drag and drop a file or click to browse. Both .json files and .zip bundles are accepted.
3. Pick the Realm to import into. The required field appears whenever at least one active realm exists, preselected with your most recently active realm that has finished onboarding — falling back to the most recently active one when none have. If you have no active realms, the dialog asks you to create one — or restore an archived one — and Import stays disabled.
4. Click Import. The playbook is saved to that realm and available for use.

JSON import: the file must contain name and prompt (both strings). These are the only required fields. The importer also reads the following optional fields when present:

{
  "name": "My Methodology",
  "prompt": "Full system prompt the agent will follow...",
  "description": "Brief description",
  "icon": "shield",
  "icon_color": "#3b82f6",
  "input_prompt": "Original description this playbook was built from",
  "operation_naming_guidance": "Prefer concise names that include the target and finding class.",
  "assets": [],
  "skill_uuids": ["..."],
  "integration_ids": ["..."],
  "capabilities": ["execution_and_files", "cybergraph_read"]
}

platform_tools remains supported as a legacy compatibility field: when capabilities is omitted, the tools it lists are validated and converted to the equivalent capabilities. Any other field not listed above is ignored on JSON import.

ZIP import: a .zip bundle (such as one produced by Download/export) carries the playbook as a Markdown file with YAML frontmatter plus its assets, and preserves additional configuration including llm_config. Importing an exported bundle round-trips the playbook with its model configuration intact.

Edit naming guidance and the LLM config from the playbook editor's Advanced panel. llm_config uses the same model_id and settings as the operation model catalog; saving a playbook with an llm_config changes the default model and effort for operations launched from it.

Capabilities

A playbook can restrict what its agent can do during execution. The Capabilities panel lists every capability available to your tenant — each with a name, a description of what it covers, and the specific tools it grants — and you tick the ones this playbook should have.

Leaving the selection unconstrained (the default) means the agent has every capability available. Customizing it restricts the agent to exactly the capabilities you tick — for example, a passive-recon playbook that pins only Cybergraph — Read and Web Search, leaving out Execution & Files.

Some capabilities depend on another: pinning Cybergraph — Write also pins Cybergraph — Read, since write access requires read access. The panel enforces this automatically — ticking a capability ticks what it depends on, and a capability another selected one still needs cannot be unticked on its own.

A few capabilities are system-only and are never offered for pinning on a playbook.

Skills and integrations are pinned separately from capabilities, through their own bindings on the playbook.

Use a playbook in an operation

Attach a playbook when creating an operation to guide the assessment:

1. Create a new operation.
2. Select a playbook from the list.
3. The operation inherits the playbook's system prompt and capability bindings.

The playbook's system prompt becomes the operational framework: the agent follows the methodology and is limited to the pinned capabilities.

If the playbook has an llm_config, new operations launched from it inherit that model unless the operator picks a different one in the launcher. If neither the launcher nor the playbook sets a model, Cracken uses the deployment default. Switching the model on a running operation affects that operation only; it does not rewrite the playbook.

If a playbook pins a plan-gated model (such as Red) and it is launched by a tenant whose plan does not include that model, the operation is transparently downgraded to the tenant's best entitled model rather than failing — the pinned model is only enforced when the operator selects it explicitly.

Playbooks can also be attached to automations for recurring scheduled assessments with a consistent methodology.

System playbooks

Cracken includes built-in system playbooks for common tasks. System playbooks are:

• Available across all realms in your tenant.
• Maintained by Cracken.
• Not editable or deletable.

You can see a system playbook's name and description, but its prompt content, assets, exports, and attachments are hidden. Use system playbooks directly; the Build with agent flow uses the built-in Configure playbook under the hood.

The operation launcher also surfaces upcoming premium modules as locked Talk to sales cards in the same grid. They are searchable and visible for planning, but instead of launching an operation they route to the billing Plans tab focused on Enterprise to start a sales conversation.

Web App Pentest workflow

The Web App Pentest system playbook runs an authorized web application penetration test as an adaptive loop rather than a fixed sequence. It plans its information gathering around whatever is known about the target at the start, maps the application itself, and delegates depth to background sub-operations while it keeps mapping and steering.

Use it for authorized web application assessments where you want broad coverage kept proof-driven:

• The operation maps the application directly: reachability, stack fingerprint, routes, parameters, forms, APIs, identities, and the filtering sitting in front of them. Slow breadth-first work such as wordlist enumeration is delegated so it never blocks the main flow.
• It establishes several identities where it can — access-control testing needs at least two — and records the application's roles, business processes, and the relationships between endpoints in the Cybergraph.
• It then spawns focused background sub-operations, one per attack surface and vector family, which probe and exploit in parallel in their own clean context.
• Proof stays with the parent: it adjudicates every candidate a sub-operation proposes, reproduces the signal itself, and only then records a finding and pushes it as far as scope allows.

Sub-operations are ordinary background operations scoped by the tools the parent grants them, so the parent decides what each worker may do and keeps judgement in one place. A finding is reportable only once a reproduced, attacker-meaningful signal exists — a reflected string, a missing header, or a scanner verdict is not enough.

Manage playbooks

Edit

Open any user-created playbook to change its prompt, capabilities, appearance, or metadata. Saving a playbook records a new version, so you can review its version history from the editor.

Visibility

Toggle a playbook's visibility between:

• Realm-scoped — available only within the realm where it was created.
• Account-wide — available across all realms in your tenant.

Export and delete

• Export downloads the playbook as a .zip bundle you can re-import.
• Delete removes the playbook from the library. Operations that previously used it keep their own configuration; the playbook reference is cleared.

Next steps

• Skills — pin reusable knowledge blocks to a playbook.
• Automations — run a playbook on a schedule or trigger.
• Operations — launch an operation with a playbook attached.