---
active: true
description: "Reconcile newly-extracted playbooks against existing storage. Decides per-candidate whether each one unifies with one-or-more existing rows (growing a coherent multi-rule skill, mixed do/avoid rules allowed), is rejected as redundant against an existing row, should differentiate (refine both triggers), or is independent."
changelog: "v2.3.0: `unify` now COMPOSES — it may grow a broader multi-rule skill from coherent related fragments (related sub-aspects of one task), not only same-trigger duplicates. A skill MAY hold mixed-polarity rules (do-rules and avoid-rules for different sub-aspects). Replaced the mechanical single-orientation/same-polarity contract with an LLM-judged no-self-contradiction guard: do NOT unify if combining the rules would make the skill contradict itself on the same situation (same trigger/condition with opposite advice) — route those to `differentiate` or `reject_new`. Re-synthesis (fewest/most-general rules, preserve avoid-detail) and the over-budget `differentiate` preference are unchanged. v2.2.0: `unify` re-synthesizes leaner, more general content (MDL / simplify-in-place) instead of concatenating — fewest, most general rules that still cover all inputs; drop redundant/subsumed wording. Asymmetric fidelity: compress/generalize success guidance, but preserve every distinct avoidance/failure detail verbatim — never soften a named pitfall into a vague platitude. Prefer `differentiate` over `unify` when merging would force an over-long, low-cohesion rule. v2.1.0: `unify` no longer emits a `polarity` field — the unified row's orientation is derived from its wording (recommendation vs avoidance) by the apply-path polarity validator. Same-trigger opposite-orientation rules still must not unify; express orientation through the rule wording. v2.0.0: collapsed 5-kind union → 4-kind. `unify` subsumes `duplicate`+`prefer_new`; `reject_new` replaces `prefer_existing`. Output schema is structurally incompatible with v1.x."
variables:
  - new_playbook_count
  - new_playbooks
  - existing_playbooks
---
You are reconciling a set of newly-extracted playbooks against the related existing playbook rows already in storage. For each new candidate, decide its relationship to the existing rows.

Each rendered row carries `Content`, `Trigger`, `Rationale`, `Name`, `Source`, and `Last Modified`. Read each rule's orientation (do-this vs avoid-this) directly from its `Content` / `Rationale` wording. A unified skill may hold both do-rules and avoid-rules for different sub-aspects, so do not treat differing orientation alone as a reason not to merge. Use `Trigger` together with the actual situation each rule addresses as the primary keys for comparison.

[New playbooks (count: {new_playbook_count})]
{new_playbooks}

[Existing related playbooks]
{existing_playbooks}

# Decision kinds

Emit exactly one decision per NEW candidate. Each decision is one of:

- **unify** — the NEW belongs in the same skill as one or more EXISTING rows. This covers two cases:
  1. **Dedup / supersede** — the NEW is the same rule as an EXISTING row (after merge), or supersedes one (stronger / broader / more specific evidence).
  2. **Compose** — the NEW covers a **related sub-aspect of the same task** as an EXISTING playbook (coherent, not a strict duplicate). Grow a **broader multi-rule skill** by incorporating the fragment as an additional rule, instead of forcing `reject_new`/`independent`.

  Provide the final `content`, `trigger`, and `rationale`. List which EXISTING ids you're archiving in `archive_existing_ids` (use an empty list when no EXISTING rows are absorbed). A composed skill MAY hold **mixed-polarity rules** — do-rules and avoid-rules together — when they address **different** sub-aspects of the one task (e.g. "Do: announce in the deploy channel" alongside "Avoid: Friday-afternoon deploys"). Only unify fragments that are **genuinely coherent** (same task scope); unrelated fragments are `independent`.

- **reject_new** — an EXISTING row already covers NEW or makes NEW redundant. Name the EXISTING id that wins via `superseded_by_existing_id`. Storage-stability tie-break: when same-situation opposite advice is balanced, default here.

- **differentiate** — both valid in distinct contexts (typically same trigger, opposite advice, where the contexts differ). Set `refined_new_trigger` and `refined_existing_trigger` to be strictly narrower than the originals AND mutually exclusive.

- **independent** — different topic or task from any existing row. Insert NEW with no archive.

# How to write a unified skill (re-synthesis, not concatenation)

When you `unify`, re-synthesize a single leaner skill. Do not stitch the inputs together.

- Produce the **fewest, most general rules that still cover all the inputs**. Generalize the shared behavior into one clear statement; drop wording that is redundant with or subsumed by another input.
- A skill may carry several rules. When it does, keep each rule a clean, self-contained do-rule or avoid-rule for its own sub-aspect — do not blur distinct rules into one.
- **Preserve every distinct avoidance/failure detail with high fidelity.** This is asymmetric: compress and generalize the success guidance, but keep each specific failure intact. Never collapse a named pitfall, concrete error, or specific anti-pattern into a vague platitude — carry it forward in its specific form.
- Prefer **`differentiate` over `unify`** when merging the inputs would force an over-long, low-cohesion skill. Two focused rules that each read cleanly beat one bloated skill that tries to say everything. If you cannot state the merged skill concisely without losing distinct failure detail, that is a signal to `differentiate` (or keep NEW `independent`) rather than `unify`.

# The no-self-contradiction guard

A skill MAY hold mixed-polarity rules (do-rules and avoid-rules) for **different** sub-aspects. What it must NEVER hold is two rules that **contradict each other on the same situation** — the same trigger/condition paired with opposite advice (e.g. "use `-F`" and "avoid `-F`" for the very same case).

- Before you `unify`, ask: *would combining these rules produce a skill that contradicts itself on the same situation?* If yes, do **not** unify — route the pair to `differentiate` (refine the triggers so each rule owns a disjoint situation) or `reject_new` (one rule wins).
- Mixed polarity across **different** sub-aspects is fine and expected; mixed advice on the **same** sub-aspect is the forbidden case.

# Hard constraints

- A NEW + EXISTING pair that gives opposite advice on the **same** situation (same trigger) MUST route to `differentiate` or `reject_new` — never `unify` (that would make the skill self-contradict) and never `independent`.
- `differentiate.refined_new_trigger` and `refined_existing_trigger` MUST be non-empty and strictly narrower than the originals.
- When in doubt about a same-situation opposite-advice stalemate, default to `reject_new`. Storage stability wins ties.

Output strictly conforming to the `PlaybookConsolidationOutput` schema (a JSON object with a single key `decisions` whose entries each carry a `kind` discriminator).
