---
name: system_runbook_analyser
description: Use when asked to read Cerebra terminal history, browser evidence, notes, or operator context and draft one or more runbook cards without saving them yet. Use this before graph generation when the graph request starts from raw live evidence instead of an existing runbook card.
owner-feature: runbooks
primary-job: Draft runbook cards from live Cerebra evidence without persisting them.
allowed-tools:
  - mcp__cerebra__workspace_snapshot
  - mcp__cerebra__toolkit_state_get
  - mcp__cerebra__terminal_read_history
  - mcp__cerebra__notes_read
  - mcp__cerebra__runbooks_list
  - mcp__cerebra__runbook_get
  - mcp__cerebra__browser_get_state
  - mcp__cerebra__browser_inspect
  - mcp__cerebra__pane_capture
---

# Mission

Use this skill to turn live Cerebra evidence into draft runbook cards.

This skill only works inside a Cerebra AI session with the Cerebra MCP server available. If those MCP tools are unavailable, say that this skill only works inside Cerebra and stop. Do not fall back to repo files, repo paths, or generic filesystem workflows.

## Working Model

- A profile is a `CommandProfile`: a named collection of runbook cards.
- A runbook card is one `Command` with `id`, `label`, `command`, `description`, `tags`, and optional `color`.
- Multi-stage command content stays in the single `command` field and uses `::cerebra:split::` only when separate executable blocks are genuinely needed.
- `description` should be ready to persist as HTML, not markdown.

## Workflow

1. Read the live evidence first. Use terminal history, notes, workspace or toolkit state, browser state, and relevant existing runbooks as needed. When terminal output needs parsing rather than exact terminal fidelity, call `terminal_read_history` with `stripAnsi: true`.
2. Decide whether the evidence maps to:
   - a new runbook card in an existing profile
   - an update to an existing runbook card
   - multiple distinct runbook cards that should be drafted separately
3. Pull the target profile through `runbooks_list` and `runbook_get` before proposing tags, labels, or updates so your draft matches existing naming and tag conventions.
4. Draft the runbook card or cards, but do not persist them. Ask for confirmation before the writer skill is used.
5. If the user also wants a graph and the request started from raw live evidence, include a graph brief that a graph-generation skill can use without re-reading the raw evidence.

## Draft Contract

For each drafted runbook card, provide:

- `profileName`: target profile
- `operation`: `create` or `update`
- `existingCommandId`: include only when updating
- `label`: concise card title
- `command`: executable command text, using `::cerebra:split::` only when separate blocks are intended
- `description`: HTML snippet suitable for Cerebra rich text
- `tags`: short list aligned with the target profile's existing tag style
- `color`: optional hex color if the technique clearly belongs to an existing color pattern
- `evidenceSummary`: short explanation of what in the live session, browser state, or notes supports this card
- `graphRecommendation`: `needed`, `optional`, or `not-needed`, with one sentence why
- `graphBrief`: include when `graphRecommendation` is `needed` or `optional`
  - `focus`: one sentence describing what the graph should explain
  - `entities`: short list of the key actors, systems, tools, and artifacts that should appear
  - `flow`: ordered list of the main transitions the graph should visualize
  - `mitreTechniques`: optional list of MITRE technique ids only when clearly supported by the evidence

## Drafting Rules

- Prefer one focused runbook card over one oversized "everything that happened" card.
- If a session contains multiple techniques, split them into multiple candidate cards.
- When updating an existing runbook, preserve the original operator intent and improve precision rather than rewriting it from scratch without cause.
- Do not invent prerequisites, gains, or defensive claims that are not supported by the evidence.
- Only include technique steps that were directly observed in the evidence or explicitly requested by the user.
- Keep the `description` operational: what the technique does, when to use it, key prerequisites, what the operator gains, and concise detection or defense notes when relevant.
- When graphing is likely, reduce the technique to a clean operational sequence so the graph skill does not have to infer structure from noisy terminal history later.
- Treat Cerebra pane usage, terminal-opening behavior, and SSH control/setup steps as evidence context by default, not as graph entities.
- Do not introduce `operator`, `analyst`, or generic observer actors unless the human user is genuinely part of the technique being documented.
- If the evidence came from named Cerebra hosts or panes, prefer those real host names over invented names like `VictimMachine`, `Operator`, or `C2-Control` unless the user explicitly wants abstraction.
- For simple reverse-shell runbooks, the graph brief should usually center on listener setup, payload execution, callback, and shell establishment, not on the analyst SSHing into lab boxes.
- When the evidence clearly shows a host plus service/listener/session nodes that belong on that host, the graph brief should describe them as host internals so the graph skill places them inside a host container rather than as floating peers.
- Do not call `runbook_save` or `runbook_save_graph` from this skill unless the user explicitly changes the task from drafting to persistence.

## Completion Check

- The target profile name is real.
- The draft aligns with the profile's existing tag style.
- Command blocks are runnable and not mixed with explanation text.
- The HTML description is ready for direct persistence.
- The user still needs to confirm before anything is saved.
