claude-smart 0.2.42 → 0.2.44

package/plugin/vendor/reflexio/reflexio/server/prompt/prompt_bank/playbook_aggregation/v2.1.0.prompt.md

@@ -0,0 +1,193 @@
+---
+active: false
+description: "Generates agent playbook entries from user playbook entries by combining them into actionable policies — structured trigger + markdown-bullet content"
+changelog: "v2.1: apply Agent-Skills formatting discipline — imperative conditional triggers with broad keyword coverage; markdown bullet-list content; one-sentence rationale. Matches extraction prompt v1.4.0 so the downstream agent sees the same shape across UserPlaybooks and AgentPlaybooks. (in-place 2026-05-30: deprecated and removed blocking_issue.)"
+variables:
+  - user_playbooks
+  - existing_approved_playbooks
+---
+You are a policy consolidation and normalization engine for an AI agent.
+
+You are given:
+- A cluster of raw extracted playbook entries with SIMILAR (but not necessarily identical) triggers
+- A list of existing approved playbook rules (canonical policies)
+
+Each raw playbook entry is shown in per-item format with its Content (the primary human-readable description) followed by optional structured fields.
+
+Your job is to generate a NEW canonical playbook rule that:
+
+- Represents a *real, generalizable agent behavior improvement*
+- Consolidates all items into one coherent policy
+- Covers policy gaps NOT already handled by approved playbooks
+- Prevents recurrence of the same class of agent mistakes
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Input Format
+
+Each raw playbook entry is shown as a numbered item:
+
+[1]
+Content: "primary human-readable description of the playbook entry"
+Trigger: "when this condition applies"
+Rationale: "reasoning behind the playbook entry" (optional)
+Blocking issue: [kind] details (optional)
+
+[2]
+Content: "another playbook entry description"
+Trigger: "another condition"
+...
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Mandatory Deduplication Gate
+
+Before writing anything:
+
+Does any existing approved playbook already prevent the same class of mistake?
+
+If YES -> Output {{"playbook": null}}
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Playbook format (how to shape the output fields)
+
+The `trigger`, `content`, and `rationale` fields are the RETRIEVAL key and
+the INSTRUCTION packet the downstream agent reads at runtime. Shape them so
+they work for both roles. These rules mirror the extraction prompt — the
+downstream agent sees the same shape across per-user UserPlaybooks and
+aggregated AgentPlaybooks, so it parses once.
+
+### `trigger` — the consolidated retrieval key
+
+- Use **imperative conditional phrasing**: "When …", "If …", "For …".
+- Capture the **common theme** across all input triggers, broad enough to
+  cover every variation in the cluster but narrow enough to stay actionable.
+- Include domain **keywords** the agent's future queries would naturally
+  employ — not just the literal conversational vocabulary of the inputs.
+- Keep to **1–2 sentences, 150–300 characters**.
+
+Examples:
+
+- ❌ `"reviewing code"` — too narrow; misses "PR review", "inline suggestions".
+- ❌ `"when the agent interacts with users"` — too broad; fires on unrelated queries.
+- ✅ `"When reviewing code — pull requests, inline comments, pre-merge checks, or any code-review activity."`
+
+### `content` — the consolidated instruction packet
+
+- Format as a **markdown bullet list (`- ...`)** when the policy has
+  multiple independent instructions. Take the UNION of bullets across all
+  input entries; dedup semantically overlapping ones; preserve the distinct
+  ones.
+- Use a **numbered list (`1. ...`)** only when the order is load-bearing
+  (e.g. "run tests, then fix, then review").
+- Each bullet starts with an **imperative verb** ("Flag …", "Prioritize …",
+  "Avoid …", "Always …").
+- Each bullet is **self-sufficient** — a reader should understand it
+  without the surrounding bullets.
+- When ALL input entries collapse to a single action, a one-sentence
+  imperative is fine; don't force bullets for a one-item list.
+- Length budget: simple rules under ~500 characters; complex multi-step
+  rules up to ~2000. Never drop a distinct input bullet to hit a budget —
+  split into multiple playbooks under different triggers instead.
+
+Examples:
+
+- ❌ `"The agent should check for missing test coverage, and also it should prioritize type-safety over style nits, and for every suggestion it should explain why the change is better."` — run-on prose; buries the actions.
+- ✅
+  ```
+  - Flag missing test coverage and any new public API without a docstring.
+  - Prioritize type-safety and correctness over style nits (line length, whitespace).
+  - For every suggested change, explain WHY it is better — not just what to change.
+  ```
+
+When inputs are historical prose entries, **re-shape them into bullets** in
+the output. The aggregation step is the right place to do the upgrade.
+
+### `rationale` — one sentence explaining WHY
+
+- **One sentence**, synthesized across all inputs' rationales.
+- Explains the motivation behind the rule, not the rule itself.
+- OMIT rather than restate the content in prose.
+
+Example:
+
+- ✅ `"The user wants to learn the reasoning, not just apply edits."`
+- ❌ `"For every suggested change, explain why it is better."` — that's
+  the content, not the rationale.
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Policy Consolidation Rules
+
+To create a valid new policy, you must:
+
+1. Synthesize all Content descriptions and Rationale summaries into ONE
+   clear `content` following the format above — actionable bullets preferred.
+2. Analyze all Trigger conditions and synthesize ONE clear, generalized
+   `trigger` that:
+   - Captures the common theme across all listed triggers
+   - Uses imperative conditional phrasing with broad keyword coverage
+   - Is specific enough to be actionable
+   - Is general enough to cover all the variations
+3. When input items have Rationale fields, synthesize them into a one-
+   sentence consolidated `rationale`; omit if not substantive.
+4. Remove redundant or overlapping actions.
+5. Normalize into a minimal enforceable policy.
+
+Note: The Trigger conditions may vary slightly because clustering is based
+on semantic similarity. Your job is to identify the underlying common
+context and express it clearly.
+
+━━━━━━━━━━━━━━━━━━━━━━
+## What a Valid Canonical Policy Must Be
+
+It MUST:
+- Improve agent behavior globally
+- Be portable across topics and users
+- Be enforceable as default behavior
+- Eliminate the underlying failure class
+- Not duplicate or partially overlap approved playbooks
+
+It MUST NOT:
+- Be a paraphrase of a raw rule
+- Encode personal preferences
+- Encode topic-specific behavior
+- Add conversational language
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Output Format (Strict JSON)
+
+Return a JSON object with the following structure:
+
+{{
+  "playbook": {{
+    "rationale": "1 sentence: why the new policy prevents recurrence (optional)",
+    "trigger": "consolidated imperative conditional trigger (required)",
+    "content": "markdown bullet list (or single imperative sentence when only one action) — the actionable policy (required)"
+  }}
+}}
+
+Rules:
+- "rationale" is OPTIONAL — one sentence on the violated expectation and why the policy prevents recurrence
+- "trigger" is REQUIRED — must consolidate all input Trigger conditions into one imperative conditional phrase
+- "content" is REQUIRED — bullet-shaped when multiple actions; single imperative sentence when one
+
+If NO playbook should be generated (duplicates existing approved playbooks), return:
+{{"playbook": null}}
+
+Examples:
+
+{{"playbook": {{"rationale": "The agent assumed GUI workflows for technical users who prefer CLI, causing misaligned tool recommendations.", "trigger": "When assisting technical users with tool selection — CLI vs GUI, package managers, dev tooling, build systems.", "content": "- Ask for CLI preference before recommending GUI workflows.\n- Default to CLI-first suggestions when the user's context signals technical fluency."}}}}
+
+{{"playbook": {{"rationale": "The agent jumped to implementation details before the user understood the trade-offs, causing rework.", "trigger": "When users are exploring architecture decisions — design reviews, system-design interviews, tech choice evaluations.", "content": "- Lead with the high-level strategy and trade-offs.\n- Defer implementation steps until the user signals readiness.\n- Surface alternatives before locking in one direction."}}}}
+
+{{"playbook": null}}
+
+{{"playbook": {{"rationale": "The agent attempted to delete files without proper permissions, risking data loss.", "trigger": "When a user asks to delete shared files, admin-owned resources, or anything requiring elevated permissions.", "content": "- Inform the user that the deletion requires admin approval.\n- Offer to draft the request on their behalf.\n- Do NOT attempt the deletion directly."}}}}
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Existing Approved Playbooks
+{existing_approved_playbooks}
+
+## Clustered Raw Playbooks
+{user_playbooks}
+
+## Output
+Return only the JSON object as specified above.

package/plugin/vendor/reflexio/reflexio/server/prompt/prompt_bank/playbook_aggregation/v2.2.0.prompt.md

@@ -0,0 +1,206 @@
+---
+active: true
+description: "Generates agent playbook entries from user playbook entries by combining them into actionable policies — structured trigger + markdown-bullet content"
+changelog: "v2.2: preserve distinct orientations when merging — never collapse a do-rule and an avoid-rule (opposite orientations) into a single rule; keep both as separate rules in the merged multi-rule content. This replaces the retired mechanical whole-content polarity-bucketing gate (infer_playbook_polarity) in the aggregator; orientation now lives in rule wording and is the model's judgment (Option B). v2.1: apply Agent-Skills formatting discipline — imperative conditional triggers with broad keyword coverage; markdown bullet-list content; one-sentence rationale. Matches extraction prompt v1.4.0 so the downstream agent sees the same shape across UserPlaybooks and AgentPlaybooks. (in-place 2026-05-30: deprecated and removed blocking_issue.)"
+variables:
+  - user_playbooks
+  - existing_approved_playbooks
+---
+You are a policy consolidation and normalization engine for an AI agent.
+
+You are given:
+- A cluster of raw extracted playbook entries with SIMILAR (but not necessarily identical) triggers
+- A list of existing approved playbook rules (canonical policies)
+
+Each raw playbook entry is shown in per-item format with its Content (the primary human-readable description) followed by optional structured fields.
+
+Your job is to generate a NEW canonical playbook rule that:
+
+- Represents a *real, generalizable agent behavior improvement*
+- Consolidates all items into one coherent policy
+- Covers policy gaps NOT already handled by approved playbooks
+- Prevents recurrence of the same class of agent mistakes
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Input Format
+
+Each raw playbook entry is shown as a numbered item:
+
+[1]
+Content: "primary human-readable description of the playbook entry"
+Trigger: "when this condition applies"
+Rationale: "reasoning behind the playbook entry" (optional)
+Blocking issue: [kind] details (optional)
+
+[2]
+Content: "another playbook entry description"
+Trigger: "another condition"
+...
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Mandatory Deduplication Gate
+
+Before writing anything:
+
+Does any existing approved playbook already prevent the same class of mistake?
+
+If YES -> Output {{"playbook": null}}
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Playbook format (how to shape the output fields)
+
+The `trigger`, `content`, and `rationale` fields are the RETRIEVAL key and
+the INSTRUCTION packet the downstream agent reads at runtime. Shape them so
+they work for both roles. These rules mirror the extraction prompt — the
+downstream agent sees the same shape across per-user UserPlaybooks and
+aggregated AgentPlaybooks, so it parses once.
+
+### `trigger` — the consolidated retrieval key
+
+- Use **imperative conditional phrasing**: "When …", "If …", "For …".
+- Capture the **common theme** across all input triggers, broad enough to
+  cover every variation in the cluster but narrow enough to stay actionable.
+- Include domain **keywords** the agent's future queries would naturally
+  employ — not just the literal conversational vocabulary of the inputs.
+- Keep to **1–2 sentences, 150–300 characters**.
+
+Examples:
+
+- ❌ `"reviewing code"` — too narrow; misses "PR review", "inline suggestions".
+- ❌ `"when the agent interacts with users"` — too broad; fires on unrelated queries.
+- ✅ `"When reviewing code — pull requests, inline comments, pre-merge checks, or any code-review activity."`
+
+### `content` — the consolidated instruction packet
+
+- Format as a **markdown bullet list (`- ...`)** when the policy has
+  multiple independent instructions. Take the UNION of bullets across all
+  input entries; dedup semantically overlapping ones; preserve the distinct
+  ones.
+- **Preserve distinct orientations — never collapse a "do" rule and an
+  "avoid" rule into one.** When the inputs include both a positive rule
+  ("Do …", "Always …") and a negative rule ("Avoid …", "Never …") — even on
+  the same broad topic — keep them as **separate bullets** in the merged
+  content. A single skill may legitimately hold mixed-orientation rules for
+  different sub-aspects of one task (e.g. "Do: announce in the channel" plus
+  "Avoid: Friday-afternoon deploys"). Merging an avoidance bullet into a
+  do-bullet (or vice versa) silently discards the failure that motivated it.
+  Only drop a bullet when another bullet of the **same** orientation already
+  covers it. If two rules genuinely contradict each other on the **same**
+  situation (the same trigger with opposite advice), prefer leaving them
+  under separate, more-specific triggers (return null here so they are not
+  forced into one self-contradictory skill) rather than collapsing them.
+- Use a **numbered list (`1. ...`)** only when the order is load-bearing
+  (e.g. "run tests, then fix, then review").
+- Each bullet starts with an **imperative verb** ("Flag …", "Prioritize …",
+  "Avoid …", "Always …").
+- Each bullet is **self-sufficient** — a reader should understand it
+  without the surrounding bullets.
+- When ALL input entries collapse to a single action, a one-sentence
+  imperative is fine; don't force bullets for a one-item list.
+- Length budget: simple rules under ~500 characters; complex multi-step
+  rules up to ~2000. Never drop a distinct input bullet to hit a budget —
+  split into multiple playbooks under different triggers instead.
+
+Examples:
+
+- ❌ `"The agent should check for missing test coverage, and also it should prioritize type-safety over style nits, and for every suggestion it should explain why the change is better."` — run-on prose; buries the actions.
+- ✅
+  ```
+  - Flag missing test coverage and any new public API without a docstring.
+  - Prioritize type-safety and correctness over style nits (line length, whitespace).
+  - For every suggested change, explain WHY it is better — not just what to change.
+  ```
+
+When inputs are historical prose entries, **re-shape them into bullets** in
+the output. The aggregation step is the right place to do the upgrade.
+
+### `rationale` — one sentence explaining WHY
+
+- **One sentence**, synthesized across all inputs' rationales.
+- Explains the motivation behind the rule, not the rule itself.
+- OMIT rather than restate the content in prose.
+
+Example:
+
+- ✅ `"The user wants to learn the reasoning, not just apply edits."`
+- ❌ `"For every suggested change, explain why it is better."` — that's
+  the content, not the rationale.
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Policy Consolidation Rules
+
+To create a valid new policy, you must:
+
+1. Synthesize all Content descriptions and Rationale summaries into ONE
+   clear `content` following the format above — actionable bullets preferred.
+2. Analyze all Trigger conditions and synthesize ONE clear, generalized
+   `trigger` that:
+   - Captures the common theme across all listed triggers
+   - Uses imperative conditional phrasing with broad keyword coverage
+   - Is specific enough to be actionable
+   - Is general enough to cover all the variations
+3. When input items have Rationale fields, synthesize them into a one-
+   sentence consolidated `rationale`; omit if not substantive.
+4. Remove redundant or overlapping actions.
+5. Normalize into a minimal enforceable policy.
+
+Note: The Trigger conditions may vary slightly because clustering is based
+on semantic similarity. Your job is to identify the underlying common
+context and express it clearly.
+
+━━━━━━━━━━━━━━━━━━━━━━
+## What a Valid Canonical Policy Must Be
+
+It MUST:
+- Improve agent behavior globally
+- Be portable across topics and users
+- Be enforceable as default behavior
+- Eliminate the underlying failure class
+- Not duplicate or partially overlap approved playbooks
+
+It MUST NOT:
+- Be a paraphrase of a raw rule
+- Encode personal preferences
+- Encode topic-specific behavior
+- Add conversational language
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Output Format (Strict JSON)
+
+Return a JSON object with the following structure:
+
+{{
+  "playbook": {{
+    "rationale": "1 sentence: why the new policy prevents recurrence (optional)",
+    "trigger": "consolidated imperative conditional trigger (required)",
+    "content": "markdown bullet list (or single imperative sentence when only one action) — the actionable policy (required)"
+  }}
+}}
+
+Rules:
+- "rationale" is OPTIONAL — one sentence on the violated expectation and why the policy prevents recurrence
+- "trigger" is REQUIRED — must consolidate all input Trigger conditions into one imperative conditional phrase
+- "content" is REQUIRED — bullet-shaped when multiple actions; single imperative sentence when one
+
+If NO playbook should be generated (duplicates existing approved playbooks), return:
+{{"playbook": null}}
+
+Examples:
+
+{{"playbook": {{"rationale": "The agent assumed GUI workflows for technical users who prefer CLI, causing misaligned tool recommendations.", "trigger": "When assisting technical users with tool selection — CLI vs GUI, package managers, dev tooling, build systems.", "content": "- Ask for CLI preference before recommending GUI workflows.\n- Default to CLI-first suggestions when the user's context signals technical fluency."}}}}
+
+{{"playbook": {{"rationale": "The agent jumped to implementation details before the user understood the trade-offs, causing rework.", "trigger": "When users are exploring architecture decisions — design reviews, system-design interviews, tech choice evaluations.", "content": "- Lead with the high-level strategy and trade-offs.\n- Defer implementation steps until the user signals readiness.\n- Surface alternatives before locking in one direction."}}}}
+
+{{"playbook": null}}
+
+{{"playbook": {{"rationale": "The agent attempted to delete files without proper permissions, risking data loss.", "trigger": "When a user asks to delete shared files, admin-owned resources, or anything requiring elevated permissions.", "content": "- Inform the user that the deletion requires admin approval.\n- Offer to draft the request on their behalf.\n- Do NOT attempt the deletion directly."}}}}
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Existing Approved Playbooks
+{existing_approved_playbooks}
+
+## Clustered Raw Playbooks
+{user_playbooks}
+
+## Output
+Return only the JSON object as specified above.

package/plugin/vendor/reflexio/reflexio/server/prompt/prompt_bank/playbook_consolidation/v1.0.0-deprecated.prompt.md

@@ -0,0 +1,66 @@
+---
+active: false
+description: "Identifies and merges duplicate playbook entries from multiple extractors (deprecated)"
+changelog: "Add Last Modified timestamp + temporal contradiction guidance — when a NEW playbook contradicts an EXISTING one (e.g., overrides or reverses an earlier rule), prefer the newer one and group them as duplicates so the older rule is superseded. Deprecated under playbook_deduplication; renamed to playbook_consolidation. Retained as v1.0.0-deprecated to avoid filename collision with the fresh v1.0.0 introduced in Task E5."
+variables:
+  - new_playbook_count
+  - existing_playbook_count
+  - new_playbooks
+  - existing_playbooks
+---
+[Goal]
+You are a playbook deduplication assistant. Your job is to identify and merge duplicate playbooks across NEW extractions and EXISTING playbooks in the database.
+
+[Input]
+You will receive two groups of playbooks:
+- {new_playbook_count} NEW playbooks (just extracted, not yet saved)
+- {existing_playbook_count} EXISTING playbooks (already in the database)
+
+Every playbook has a `content` field (primary human-readable content), a `trigger` field (search key), and a `Last Modified` date showing when it was extracted. Some also have optional structured fields (`instruction`, `pitfall`, `rationale`).
+
+[NEW Playbooks]
+{new_playbooks}
+
+[EXISTING Playbooks]
+{existing_playbooks}
+
+[Your Task]
+1. Analyze ALL playbooks (both NEW and EXISTING) and identify groups of duplicates
+2. A duplicate group can contain ANY mix of NEW and EXISTING items — when a NEW playbook is about the same issue as an EXISTING one, they should be grouped together
+3. For each duplicate group:
+   - List the item_ids (e.g., "NEW-0", "EXISTING-1") of all items in this group
+   - Create a merged_content that combines the best/most specific information from all members
+   - The merged result MUST always produce a `content` field and a `trigger` field. Optional fields (`instruction`, `pitfall`, `rationale`, `blocking_issue`) should be included when the group members provide them.
+   - Explain your reasoning briefly
+4. List unique_ids of NEW playbooks that are truly unique (no duplicates found in either NEW or EXISTING)
+
+[Guidelines for Identifying Duplicates]
+- Playbooks about the SAME issue/insight/recommendation are duplicates even if worded differently
+- Example: "Agent should remember user preferences" and "Agent needs to track user settings" are duplicates
+- Example: "Response time is slow" and "Agent takes too long to respond" are duplicates
+- Playbooks about DIFFERENT issues are NOT duplicates even if similar in structure
+- A NEW playbook that refines or updates an EXISTING playbook should be grouped with it
+- A NEW playbook that **contradicts or overrides** an EXISTING playbook on the same trigger MUST be grouped with the EXISTING one — for example, if EXISTING says "always do X for trigger T" and NEW says "only do X for trigger T when condition Y holds, otherwise do Z", these are duplicates and the older rule must be superseded by the newer one. Do not let opposite conclusions on the same trigger persist as separate playbooks.
+
+[Guidelines for Merging]
+- Combine all unique information from duplicates
+- Remove redundancy but keep all actionable insights
+- Use clear, concise language
+- Choose the most specific/detailed wording when there's overlap
+- The merged result should be the best version combining insights from all group members
+- The merged `content` must be a clear, self-contained human-readable summary
+- Each playbook includes a `Last Modified` date. **When a NEW playbook contradicts or overrides an EXISTING one** (e.g., reverses the rule, adds an exception that flips the default, or corrects a previous mistake), the merged playbook MUST reflect the newer guidance — use the NEW playbook's instruction/pitfall as the primary basis and only retain non-contradictory context from the older one.
+
+[Output Format]
+Return a JSON object with:
+- duplicate_groups: Array of objects, each containing:
+  - item_ids: Array of strings (IDs matching the [PREFIX-N] format, e.g., "NEW-0", "EXISTING-2")
+  - merged_content: Object with fields: rationale (string or null, optional), trigger (string, required), instruction (string or null, optional), pitfall (string or null, optional), blocking_issue (object with kind and details, or null, optional), content (string, required)
+  - reasoning: String (brief explanation)
+- unique_ids: Array of strings (IDs of unique NEW playbooks, e.g., "NEW-2")
+
+[Important]
+- Every NEW playbook must appear EXACTLY ONCE (either in a duplicate_group's item_ids or in unique_ids)
+- EXISTING playbooks only appear in item_ids when they are superseded by a merged version
+- Be conservative - only group true duplicates
+- If there are no EXISTING playbooks, just deduplicate among the NEW playbooks

package/plugin/vendor/reflexio/reflexio/server/prompt/prompt_bank/playbook_consolidation/v1.0.0.prompt.md

@@ -0,0 +1,43 @@
+---
+description: "Reconcile newly-extracted playbooks against existing storage. Decides per-candidate whether each one is a duplicate, supersedes / is superseded by an existing row, should differentiate (refine both triggers), or is independent."
+changelog: "v1.0.0: rewritten from playbook_deduplication. Output is a 5-kind discriminated union (duplicate, prefer_new, prefer_existing, differentiate, independent). Polarity-aware: same-trigger opposite-polarity pairs must resolve to prefer_new / prefer_existing / differentiate — never duplicate or independent."
+variables:
+  - new_playbook_count
+  - new_playbooks
+  - existing_playbooks
+---
+You are reconciling a set of newly-extracted playbooks (each with a `polarity` of `"positive"` or `"negative"`) against the related existing playbook rows already in storage. For each new candidate, decide its relationship to the existing rows.
+
+[New playbooks (count: {new_playbook_count})]
+{new_playbooks}
+
+[Existing related playbooks]
+{existing_playbooks}
+
+# Decision kinds
+
+Emit exactly one decision per `(new, related-existing)` consideration. Each decision is one of:
+
+- **duplicate** — same intent across NEW + one-or-more EXISTING (same trigger, same polarity, semantically the same rule). Set `kind: "duplicate"`, list all `item_ids`, write `merged_content` / `merged_trigger` / `merged_rationale`, and set `merged_polarity` to the polarity all members share. All members MUST share polarity.
+
+- **prefer_new** — NEW wins; archive the existing row and insert NEW. Choose when:
+  - NEW contradicts EXISTING (opposite polarity) and NEW's evidence is stronger, OR
+  - NEW is broader and correctly subsumes EXISTING's narrower case.
+
+- **prefer_existing** — EXISTING wins; drop NEW. Choose when:
+  - EXISTING contradicts NEW (opposite polarity) and EXISTING's evidence is stronger, OR
+  - EXISTING is broader and already subsumes NEW's narrower case, OR
+  - NEW is a weaker / stale restatement of EXISTING.
+
+- **differentiate** — both valid in distinct contexts (typically same trigger, opposite polarity, 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 trigger from any existing row. Insert NEW with no archive.
+
+# Hard constraints
+
+- A pair with the same trigger and opposite polarity MUST resolve to `prefer_new`, `prefer_existing`, or `differentiate`. NEVER `duplicate` (different intent). NEVER `independent` (same trigger).
+- Polarity comes from each playbook's `polarity` field — do not infer it from content framing.
+- `differentiate.refined_new_trigger` and `refined_existing_trigger` MUST be non-empty and strictly narrower than the originals.
+- When in doubt about a same-trigger opposite-polarity stalemate, default to `prefer_existing`. 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).

package/plugin/vendor/reflexio/reflexio/server/prompt/prompt_bank/playbook_consolidation/v1.1.0.prompt.md

@@ -0,0 +1,46 @@
+---
+active: false
+description: "Reconcile newly-extracted playbooks against existing storage. Decides per-candidate whether each one is a duplicate, supersedes / is superseded by an existing row, should differentiate (refine both triggers), or is independent."
+changelog: "v1.1.0: rendered NEW/EXISTING rows now include `Trigger` and `Rationale` alongside `Content` so the model can compare the fields it is asked to refine (differentiate, same-trigger contradictions, trigger refinements). No variable changes."
+variables:
+  - new_playbook_count
+  - new_playbooks
+  - existing_playbooks
+---
+You are reconciling a set of newly-extracted playbooks (each with a `polarity` of `"positive"` or `"negative"`) 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`, `Polarity`, `Name`, `Source`, and `Last Modified`. Use `Trigger` and `Polarity` (not content framing) 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, related-existing)` consideration. Each decision is one of:
+
+- **duplicate** — same intent across NEW + one-or-more EXISTING (same trigger, same polarity, semantically the same rule). Set `kind: "duplicate"`, list all `item_ids`, write `merged_content` / `merged_trigger` / `merged_rationale`, and set `merged_polarity` to the polarity all members share. All members MUST share polarity.
+
+- **prefer_new** — NEW wins; archive the existing row and insert NEW. Choose when:
+  - NEW contradicts EXISTING (opposite polarity) and NEW's evidence is stronger, OR
+  - NEW is broader and correctly subsumes EXISTING's narrower case.
+
+- **prefer_existing** — EXISTING wins; drop NEW. Choose when:
+  - EXISTING contradicts NEW (opposite polarity) and EXISTING's evidence is stronger, OR
+  - EXISTING is broader and already subsumes NEW's narrower case, OR
+  - NEW is a weaker / stale restatement of EXISTING.
+
+- **differentiate** — both valid in distinct contexts (typically same trigger, opposite polarity, 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 trigger from any existing row. Insert NEW with no archive.
+
+# Hard constraints
+
+- A pair with the same trigger and opposite polarity MUST resolve to `prefer_new`, `prefer_existing`, or `differentiate`. NEVER `duplicate` (different intent). NEVER `independent` (same trigger).
+- Polarity comes from each playbook's `polarity` field — do not infer it from content framing.
+- `differentiate.refined_new_trigger` and `refined_existing_trigger` MUST be non-empty and strictly narrower than the originals.
+- When in doubt about a same-trigger opposite-polarity stalemate, default to `prefer_existing`. 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).

package/plugin/vendor/reflexio/reflexio/server/prompt/prompt_bank/playbook_consolidation/v2.0.0-deprecated.prompt.md

@@ -0,0 +1,64 @@
+---
+active: false
+description: "Identifies and merges duplicate playbook entries from multiple extractors — simplified schema without instruction/pitfall (deprecated; superseded by v1.0.0 in Task E5)"
+changelog: "v2: Remove instruction and pitfall fields. Content is the sole actionable field. Simplified merged output format. Drop unused per-group reasoning field to reduce output token usage. Renamed from playbook_deduplication to playbook_consolidation in Task E1. Marked -deprecated to avoid filename collision with the fresh v1.0.0 that Task E5 introduced; flipped active: false once the fresh v1.0.0 landed."
+variables:
+  - new_playbook_count
+  - existing_playbook_count
+  - new_playbooks
+  - existing_playbooks
+---
+[Goal]
+You are a playbook deduplication assistant. Your job is to identify and merge duplicate playbooks across NEW extractions and EXISTING playbooks in the database.
+
+[Input]
+You will receive two groups of playbooks:
+- {new_playbook_count} NEW playbooks (just extracted, not yet saved)
+- {existing_playbook_count} EXISTING playbooks (already in the database)
+
+Every playbook has a `content` field (primary human-readable content), a `trigger` field (search key), and a `Last Modified` date showing when it was extracted. Some also have optional fields (`rationale`).
+
+[NEW Playbooks]
+{new_playbooks}
+
+[EXISTING Playbooks]
+{existing_playbooks}
+
+[Your Task]
+1. Analyze ALL playbooks (both NEW and EXISTING) and identify groups of duplicates
+2. A duplicate group can contain ANY mix of NEW and EXISTING items — when a NEW playbook is about the same issue as an EXISTING one, they should be grouped together
+3. For each duplicate group:
+   - List the item_ids (e.g., "NEW-0", "EXISTING-1") of all items in this group
+   - Create a merged_content that combines the best/most specific information from all members
+   - The merged result MUST always produce a `content` field and a `trigger` field. Optional fields (`rationale`, `blocking_issue`) should be included when the group members provide them.
+4. List unique_ids of NEW playbooks that are truly unique (no duplicates found in either NEW or EXISTING)
+
+[Guidelines for Identifying Duplicates]
+- Playbooks about the SAME issue/insight/recommendation are duplicates even if worded differently
+- Example: "Agent should remember user preferences" and "Agent needs to track user settings" are duplicates
+- Example: "Response time is slow" and "Agent takes too long to respond" are duplicates
+- Playbooks about DIFFERENT issues are NOT duplicates even if similar in structure
+- A NEW playbook that refines or updates an EXISTING playbook should be grouped with it
+- A NEW playbook that **contradicts or overrides** an EXISTING playbook on the same trigger MUST be grouped with the EXISTING one — for example, if EXISTING says "always do X for trigger T" and NEW says "only do X for trigger T when condition Y holds, otherwise do Z", these are duplicates and the older rule must be superseded by the newer one. Do not let opposite conclusions on the same trigger persist as separate playbooks.
+
+[Guidelines for Merging]
+- Combine all unique information from duplicates
+- Remove redundancy but keep all actionable insights
+- Use clear, concise language
+- Choose the most specific/detailed wording when there's overlap
+- The merged result should be the best version combining insights from all group members
+- The merged `content` must be a clear, self-contained human-readable summary
+- Each playbook includes a `Last Modified` date. **When a NEW playbook contradicts or overrides an EXISTING one** (e.g., reverses the rule, adds an exception that flips the default, or corrects a previous mistake), the merged playbook MUST reflect the newer guidance — use the NEW playbook's content as the primary basis and only retain non-contradictory context from the older one.
+
+[Output Format]
+Return a JSON object with:
+- duplicate_groups: Array of objects, each containing:
+  - item_ids: Array of strings (IDs matching the [PREFIX-N] format, e.g., "NEW-0", "EXISTING-2")
+  - merged_content: Object with fields: rationale (string or null, optional), trigger (string, required), blocking_issue (object with kind and details, or null, optional), content (string, required)
+- unique_ids: Array of strings (IDs of unique NEW playbooks, e.g., "NEW-2")
+
+[Important]
+- Every NEW playbook must appear EXACTLY ONCE (either in a duplicate_group's item_ids or in unique_ids)
+- EXISTING playbooks only appear in item_ids when they are superseded by a merged version
+- Be conservative - only group true duplicates
+- If there are no EXISTING playbooks, just deduplicate among the NEW playbooks