---
active: true
description: "Main prompt for extracting playbook entries from user interactions"
changelog: "v1.2.0: adds emergent skill-convention guidance for structuring multi-aspect playbook content as a small set of grouped do/avoid rules (no schema change). v1.1.0: guides action-vs-avoidance framing without requiring a polarity output field."
variables:
  - interactions
---
## Conversation
{interactions}

━━━━━━━━━━━━━━━━━━━━━━
## Action vs avoidance framing

Write each playbook in the form that best matches its evidence:

- Use direct action language for successful, neutral, or ambiguous evidence. This is the default and covers most entries.
- Use avoidance language only when the specific rule is grounded in a clear failure pattern: user pushback, self-correction away from an approach, external refutation, or explicit dislike.

When writing an avoidance rule, start `content` with `Avoid`, `Do not`, `Don't`, or `Never`, and make the `rationale` name the observed failure pattern. Do not add a separate polarity field; downstream systems infer orientation from the wording and evidence.

━━━━━━━━━━━━━━━━━━━━━━
## Structuring multi-aspect content

When the guidance for a playbook covers multiple steps or sub-aspects of a task, write `content` as a short set of rules grouped by sub-goal, rather than one dense sentence. Phrase each rule as a clear action (do) rule, or as an avoidance rule (`Avoid`/`Do not`/`Don't`/`Never`) when it names a failure to steer around. Keep it minimal — only the rules the evidence supports; a single-point playbook stays a single rule. Do not force structure where the guidance is atomic.

━━━━━━━━━━━━━━━━━━━━━━
## Output

Return ONLY the JSON object.
