claude-smart 0.2.42 → 0.2.44

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

@@ -0,0 +1,39 @@
+---
+active: false
+description: "Reconcile newly-extracted playbooks against existing storage. Decides per-candidate whether each one unifies with one-or-more existing rows, is rejected as redundant against an existing row, should differentiate (refine both triggers), or is independent."
+changelog: "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 (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 candidate. Each decision is one of:
+
+- **unify** — the NEW is the same rule as one or more EXISTING rows (after merge), OR the NEW supersedes one EXISTING (stronger / broader / more specific evidence). Provide the final `content`, `trigger`, `rationale`, and `polarity`. List which EXISTING ids you're archiving in `archive_existing_ids` (use an empty list when no EXISTING rows are absorbed). Every archived EXISTING must share the chosen `polarity` — the polarity validator will reject mixed-polarity unify.
+
+- **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-trigger opposite-polarity evidence is balanced, default here.
+
+- **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 NEW + EXISTING pair with the same trigger and opposite polarity MUST route to `unify` (only if you can pick one shared polarity backed by evidence — the polarity validator will reject mixed-polarity unify), `reject_new`, or `differentiate`. Never `independent`.
+- 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 `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).

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

@@ -0,0 +1,39 @@
+---
+active: false
+description: "Reconcile newly-extracted playbooks against existing storage. Decides per-candidate whether each one unifies with one-or-more existing rows, is rejected as redundant against an existing row, should differentiate (refine both triggers), or is independent."
+changelog: "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`, `Polarity`, `Name`, `Source`, and `Last Modified`. The `Polarity` label (`positive` = a recommendation / do-this, `negative` = an avoidance / don't-do-this) is derived from the rule's wording. Use `Trigger` and `Polarity` 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 is the same rule as one or more EXISTING rows (after merge), OR the NEW supersedes one EXISTING (stronger / broader / more specific evidence). 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). The unified row carries a single orientation: word its `content` and `rationale` so they consistently recommend OR consistently warn against the behavior — never blend both. Every archived EXISTING must share that orientation; the apply-path polarity validator (which derives orientation from wording) will reject a mixed-orientation unify.
+
+- **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-trigger opposite-orientation evidence is balanced, default here.
+
+- **differentiate** — both valid in distinct contexts (typically same trigger, opposite orientation, 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 NEW + EXISTING pair with the same trigger and opposite orientation MUST route to `unify` (only if you can pick one shared orientation backed by evidence and word the unified row accordingly — the polarity validator will reject a mixed-orientation unify), `reject_new`, or `differentiate`. Never `independent`.
+- Orientation is read from each row's wording (the derived `Polarity` label). A unified row's orientation follows the words you choose for its `content` and `rationale`.
+- `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-orientation 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).

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

@@ -0,0 +1,47 @@
+---
+active: false
+description: "Reconcile newly-extracted playbooks against existing storage. Decides per-candidate whether each one unifies with one-or-more existing rows, is rejected as redundant against an existing row, should differentiate (refine both triggers), or is independent."
+changelog: "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`, `Polarity`, `Name`, `Source`, and `Last Modified`. The `Polarity` label (`positive` = a recommendation / do-this, `negative` = an avoidance / don't-do-this) is derived from the rule's wording. Use `Trigger` and `Polarity` 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 is the same rule as one or more EXISTING rows (after merge), OR the NEW supersedes one EXISTING (stronger / broader / more specific evidence). 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). The unified row carries a single orientation: word its `content` and `rationale` so they consistently recommend OR consistently warn against the behavior — never blend both. Every archived EXISTING must share that orientation; the apply-path polarity validator (which derives orientation from wording) will reject a mixed-orientation unify.
+
+- **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-trigger opposite-orientation evidence is balanced, default here.
+
+- **differentiate** — both valid in distinct contexts (typically same trigger, opposite orientation, 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.
+
+# How to write a unified row (re-synthesis, not concatenation)
+
+When you `unify`, re-synthesize a single leaner rule. 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.
+- **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 rule. Two focused rules that each read cleanly beat one bloated rule that tries to say everything. If you cannot state the merged rule concisely without losing distinct failure detail, that is a signal to `differentiate` (or keep NEW `independent`) rather than `unify`.
+
+# Hard constraints
+
+- A NEW + EXISTING pair with the same trigger and opposite orientation MUST route to `unify` (only if you can pick one shared orientation backed by evidence and word the unified row accordingly — the polarity validator will reject a mixed-orientation unify), `reject_new`, or `differentiate`. Never `independent`.
+- Orientation is read from each row's wording (the derived `Polarity` label). A unified row's orientation follows the words you choose for its `content` and `rationale`.
+- `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-orientation 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).

package/plugin/vendor/reflexio/reflexio/server/prompt/prompt_bank/playbook_consolidation/v2.3.0.prompt.md

@@ -0,0 +1,58 @@
+---
+active: false
+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).

package/plugin/vendor/reflexio/reflexio/server/prompt/prompt_bank/playbook_consolidation/v2.3.1.prompt.md

@@ -0,0 +1,69 @@
+---
+active: false
+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.1: replaces schema example-style output prompting with compact format guidance for the four decision shapes. 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 Format Guidance
+
+Respond ONLY with a valid JSON object matching `PlaybookConsolidationOutput`: `{{"decisions": [<one decision object for each NEW candidate>]}}`.
+
+Each decision object MUST include `kind` and `new_id`. The `kind` value determines the remaining required fields:
+
+- `unify`: include `archive_existing_ids` as a list of EXISTING list positions, plus final `content`, `trigger`, and `rationale`; optional `reason` may explain the decision.
+- `reject_new`: include `superseded_by_existing_id` as the existing row's database id; optional `reason` may explain the decision.
+- `differentiate`: include `existing_id` as the existing row's database id, plus non-empty `refined_new_trigger` and `refined_existing_trigger`; optional `reason` may explain the decision.
+- `independent`: include only `kind`, `new_id`, and optional `reason`.
+
+Do not emit markdown, prose, comments, chain-of-thought, or top-level keys other than `decisions`. Do not include fields from another decision kind.

package/plugin/vendor/reflexio/reflexio/server/prompt/prompt_bank/playbook_consolidation/v2.3.2.prompt.md

@@ -0,0 +1,71 @@
+---
+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.2: tightens schema guidance for integer id fields and compact unify content; forbids display-label strings in numeric fields. v2.3.1: replaces schema example-style output prompting with compact format guidance for the four decision shapes. 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.
+- Keep the final `content` compact enough to store directly. If a unified skill would require lengthy setup history, multiple long command transcripts, or broad background narrative to stay faithful, do not force `unify`; use `differentiate`, `reject_new`, or `independent` according to the decision rules.
+- 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.
+- Numeric id fields MUST contain bare integers, not display labels or bracketed row prefixes. Rendered row labels are for human reading only; they are never valid values for `superseded_by_existing_id` or `existing_id`.
+- When in doubt about a same-situation opposite-advice stalemate, default to `reject_new`. Storage stability wins ties.
+
+# Output Format Guidance
+
+Respond ONLY with a valid JSON object matching `PlaybookConsolidationOutput`: `{{"decisions": [<one decision object for each NEW candidate>]}}`.
+
+Each decision object MUST include `kind` and `new_id`. `new_id` is the rendered NEW label string. All EXISTING references use the numeric fields below.
+
+- `unify`: include `archive_existing_ids` as a list of EXISTING list-position integers, plus final compact `content`, `trigger`, and `rationale`; optional `reason` may explain the decision.
+- `reject_new`: include `superseded_by_existing_id` as an integer only; optional `reason` may explain the decision.
+- `differentiate`: include `existing_id` as an integer only, plus non-empty `refined_new_trigger` and `refined_existing_trigger`; optional `reason` may explain the decision.
+- `independent`: include only `kind`, `new_id`, and optional `reason`.
+
+Do not emit markdown, prose, comments, chain-of-thought, or top-level keys other than `decisions`. Do not include fields from another decision kind. Do not put any bracketed/list label string into an integer id field.

package/plugin/vendor/reflexio/reflexio/server/prompt/prompt_bank/playbook_extraction_context/v4.0.2.prompt.md

@@ -0,0 +1,254 @@
+---
+active: false
+description: "Context setting prompt for playbook extraction. Every claim must be both (a) grounded in the conversation and (b) generalized to apply in any repo; both requirements apply jointly to Correction SOPs and Success Path Recipes."
+changelog: "v4.0.2: Promotes 'grounded AND generalized' to a single joint requirement covering both categories, hoisted into Content Grounding Rules. Trigger Quality and Success Path content sections now defer to that principle instead of restating it. Rule of thumb is split into the two checks both entries must pass. Example 3 generalized so it no longer pins specific filenames or column letters."
+variables:
+  - agent_context_prompt
+  - extraction_definition_prompt
+  - tool_can_use
+---
+You are a self-improvement policy mining assistant for AI agents.
+Your job is to extract **reusable patterns** from agent trajectories that help similar future tasks run faster and more accurately.
+
+You extract TWO CATEGORIES of patterns, and a single trajectory can contain BOTH:
+
+1. **Correction SOPs** — patterns learned from user-correction signals (multi-turn dialogues where the user pushed back on the agent's default behavior).
+2. **Success Path Recipes** — concrete solution paths extracted from successful task completions, so a future run of a similar task can go directly to the answer instead of re-discovering it.
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Category 1 — Correction SOPs
+
+Extract a **Correction SOP** when ALL are true:
+1. The agent performed an action, assumption, or default behavior.
+2. The user signaled this behavior was incorrect, inefficient, or misaligned.
+3. The correction implies a **better default workflow** for similar future requests.
+
+### Valid Correction Signals
+Look for cross-turn causal patterns, not isolated messages.
+
+Valid signals include:
+* User correcting or rejecting the agent's approach
+* User redirecting the agent to a different mode or level of detail
+* User expressing dissatisfaction with how the agent behaved
+* User clarifying expectations that contradict the agent's behavior
+* Agent retrying a tool call with different inputs after getting poor or irrelevant results (self-correction)
+* Agent switching from one tool to another within the same task after inadequate results
+
+You MUST identify the triggering agent behavior
+(assumption made, default chosen, constraint ignored, or question not asked).
+
+### Trigger Quality
+
+A valid `trigger` describes the **problem or situation**, NOT the user's explicitly stated preference.
+* **BAD:** "User requests CLI tools." (Just restates the user's explicit ask.)
+* **GOOD:** "User reports timeout or performance failures on large data transfers (>10TB)."
+
+Both `trigger` and `content` must satisfy the joint grounded-and-generalized requirement defined in Content Grounding Rules below.
+
+### Tautology Check (Correction SOPs only)
+If the `trigger` can be reduced to "user asks for X" and the `content` is "do X", the SOP is tautological. Re-derive the real trigger as the *problem or situation* the agent encountered. This check does NOT apply to Success Path Recipes.
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Category 2 — Success Path Recipes
+
+Extract a **Success Path Recipe** when ALL are true:
+1. The agent successfully completed the task (produced final deliverables, resolved the user's request, or reached the intended end state).
+2. The original trajectory contained **removable inefficiency** — at least one of:
+   - A failed tool call before a successful retry
+   - Parameters that had to be tuned after returning wrong or incomplete results
+   - A tool swapped mid-task after the first choice did not work
+   - A redundant or dead-end step that did not contribute to the final answer
+   - Discovery work (reading docs, probing formats, sampling data) that a future agent, armed with what was learned, could skip
+3. The inefficiency is removable: given what the final working approach turned out to be, a future agent could go straight there.
+
+If the agent reached the answer on a clean first-try path with no retries, tuning, tool swaps, or detours, **do not emit a recipe** — there is nothing to optimize.
+
+A Success Path Recipe does NOT require a user-correction signal.
+
+### Success Path content format
+
+The `content` field is the **optimized, replayable path** — the straight-line sequence the original trajectory converged to, with detours removed. Name the tool category, the shape of parameters, and the order of operations (the dual grounded-and-generalized requirement applies — see Content Grounding Rules).
+
+Keep entries concise — a quick reference, not a recap. Omit restated user feedback, log excerpts, and summary preambles.
+
+End with one short line naming the detour from the original path that the reader should skip. A generic "follow best practices" is worthless; a step-by-step sequence plus the detour to skip is gold.
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Content Grounding Rules (CRITICAL)
+
+Every entry — both Correction SOPs and Success Path Recipes — must satisfy two joint requirements:
+
+1. **Grounded** — every claim in `content` is supported by the conversation or the agent context. Do NOT invent policies, escalation paths, tools, teams, or procedures.
+2. **Generalized** — the entry applies in a different repo with no access to this conversation. Restate repo-private artifacts (file paths, table names, module names, org-specific constants) in terms of their abstract role; original concretes may appear only as illustrative cues ("e.g., here it was the org-level config file").
+
+Grounding constrains the *source* of a claim (it must come from the conversation), not its *form*. An entry that faithfully cites a specific path or variable name is grounded but not generalized — it still fails. The conversation is the evidence; the entry is the distilled, transferable rule.
+
+**GOOD content** — grounded in evidence:
+- Describes what the agent did wrong (traceable to a specific agent turn)
+- Describes what the user wanted instead (traceable to a specific user turn)
+- States what the agent should avoid doing (the observed mistake)
+- If the agent lacks a capability, says so honestly without inventing a workaround
+
+**BAD content** — hallucinated:
+- Invents escalation paths ("transfer to the shipping team") when no such team was mentioned
+- Invents specific procedures ("check the confirmation email for tracking links") when the user never mentioned these exist
+- Prescribes solutions the agent has no evidence it can actually do
+- Adds generic customer-service advice not grounded in this specific interaction
+
+**When the agent doesn't know what to do:** Describe what to AVOID (the observed mistake) and state the limitation honestly. It is much better to say "do not fabricate order status — admit you cannot look it up" than to invent a specific alternative the agent may not actually have.
+
+**Rule of thumb (both checks must pass):**
+1. *Grounded* — if you remove the conversation and only read the `content`, could someone verify every claim by re-reading the conversation? If not, you've hallucinated.
+2. *Generalized* — could a future agent in a different repo, with no access to this conversation, apply the entry as written? If not, you've overfit — restate the pattern at the level of tool category, parameter shape, and order of operations.
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Reasoning Procedure (REQUIRED)
+
+For **Correction SOPs**:
+1. Identify user turns containing correction, rejection, or redirection
+2. Trace backwards to the exact agent behavior that triggered it
+3. Identify the violated implicit expectation
+4. Draft the `trigger` (the problem or situation)
+5. Tautology Check (see above)
+6. Draft `content`: reason through what the agent did wrong and what the user's feedback tells us the agent should do differently. Ground every statement in evidence from the conversation. If the user told the agent what to do, capture that. If the user only told the agent what NOT to do, capture the avoidance. Do not guess what the right action is if the conversation doesn't tell you.
+
+For **Success Path Recipes**:
+1. Identify whether the agent completed the task successfully
+2. Scan the trajectory for **removable inefficiency**: a failed tool call followed by a retry, parameters retuned after bad output, a tool swapped mid-task, redundant or dead-end steps, or discovery work a future agent could skip. If none are present, **stop — do not emit a recipe.**
+3. Enumerate the final working approach as a sequence of tool categories, parameter shapes, and ordered operations — translate any repo-private concretes (paths, column names, constants) into their abstract role
+4. Frame the trigger as a reusable task-type description (domain + action)
+5. Compose `content` as the **optimized straight-line path** — specific enough to replay without re-deriving anything, generalized enough to apply in a different repo — and add one short line naming the detour from the original trajectory that the reader should skip
+
+Repeat for **every distinct** policy or recipe the conversation supports.
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Context of user interactions
+{agent_context_prompt}
+
+When reviewing the conversation, pay special attention to whether the agent explored all available tools to address the user's stated needs before accepting a negative outcome (e.g., cancellation, downgrade, churn, rejection).
+
+## Playbook Focus
+{extraction_definition_prompt}
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Tool Usage Analysis
+Tool calls in the conversation appear as `[used tool: tool_name({{"param": "value"}})]` prefixes on agent messages. A single message may have multiple `[used tool: ...]` prefixes when the agent called several tools in one turn. Analyze them for these patterns:
+
+[Available Tools]
+{tool_can_use}
+
+1. **Wrong tool selected** — feeds Correction SOPs.
+2. **Suboptimal tool inputs** — feeds Correction SOPs.
+3. **Tool retry patterns** — the final successful call reveals what should have been done first. For Correction SOPs, extract the lesson. For Success Path Recipes, include the *final working parameters* as part of the recipe.
+4. **Missed tool usage** — feeds Correction SOPs.
+5. **Working tool sequences** — for Success Path Recipes, capture the *order* in which tools were called and *what each contributed*.
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Blocking Issue Detection
+
+When the agent could not complete the user's request because a capability was missing, populate `blocking_issue` to capture the root cause separately from the corrective action.
+
+Populate `blocking_issue` when:
+- The agent tried to use a tool that does not exist in its toolset
+- The agent was denied permission to perform an action
+- An external service or dependency was unavailable
+- A policy or configuration prevented the agent from acting
+
+Key principle: **Separate diagnosis from prescription.** The `blocking_issue` captures WHY the agent was blocked. The `content` should describe what the agent should avoid and what it should do instead — but ONLY actions grounded in the conversation, not invented workarounds.
+
+The 4 `kind` values:
+- `missing_tool` — A tool the agent needs does not exist in its current toolset
+- `permission_denied` — The agent lacks authorization to perform the required action
+- `external_dependency` — An external service, API, or resource is unavailable
+- `policy_restriction` — A policy or configuration rule prevents the action
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Output Format (Strict JSON)
+
+Return a JSON object with a single key `"playbooks"` whose value is a list of zero or more playbook entries. Correction SOPs and Success Path Recipes use the SAME schema — the `trigger` wording distinguishes them.
+
+{{
+    "playbooks": [
+        {{
+            "rationale": "1-2 sentence summary: for a Correction SOP, what implicit expectation was violated. For a Success Path Recipe, why this recipe captures transferable value.",
+            "trigger": "The problem or situation where the agent's default was wrong, OR the task type for a recipe.",
+            "blocking_issue": {{
+                "kind": "missing_tool | permission_denied | external_dependency | policy_restriction",
+                "details": "What capability is missing and why it blocks the request"
+            }},
+            "content": "The main actionable content — grounded in the conversation. For a Correction SOP: what the agent should do or avoid based on evidence from user feedback. For a Success Path Recipe: the step-by-step recipe with concrete values."
+        }}
+    ]
+}}
+
+Note: `"blocking_issue"` is OPTIONAL on each entry — include ONLY when the agent could not complete the user's request due to a missing capability or external constraint.
+
+**How many entries to return:**
+* Emit one entry per distinct Correction SOP.
+* Emit one entry per distinct Success Path Recipe **only when the trajectory contained removable inefficiency** (see Category 2, condition 2). Clean first-try successes yield zero recipes — padding the playbook with recipes that just restate an already-efficient path degrades its value.
+* Correction SOPs are independent of recipe emission: extract a SOP whenever a correction signal is present, regardless of whether any recipe qualifies.
+
+Return an empty list only when truly nothing applies:
+
+{{"playbooks": []}}
+
+**Never split a single policy across multiple entries; never merge two independent policies into one.**
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Examples
+
+**Example 1 — Correction SOP (grounded in user feedback):**
+* **User turn 2:** "Don't give me the code yet, explain the strategy first."
+* **Output:**
+{{
+  "playbooks": [
+    {{
+      "rationale": "The agent jumped straight to code, but the user wanted to understand the approach first before seeing implementation.",
+      "trigger": "User asks for help with complex implementations or architectural decisions.",
+      "content": "When users ask for help with complex implementations, present the high-level strategy first before generating code. The user explicitly asked for the approach to be explained before seeing code — jumping straight to implementation wastes effort if the approach is wrong."
+    }}
+  ]
+}}
+
+**Example 2 — Correction SOP (knowledge gap — grounded, no hallucinated fix):**
+* **Agent fabricated order tracking info. User called it out: "Did you actually look it up or are you just guessing?"**
+* **Output:**
+{{
+  "playbooks": [
+    {{
+      "rationale": "The agent fabricated specific order status details despite not having access to order tracking systems, causing the user to lose trust when the info contradicted their records.",
+      "trigger": "User asks agent to look up specific account or order data that requires system access the agent does not have.",
+      "blocking_issue": {{
+        "kind": "missing_tool",
+        "details": "Agent lacks access to order tracking or customer account lookup systems."
+      }},
+      "content": "Do not fabricate or guess specific data points (order status, tracking info, delivery dates) when you do not have access to the underlying system. If you cannot look something up, say so immediately rather than presenting assumptions as facts. The user's trust was broken because the agent presented made-up timelines as real data."
+    }}
+  ]
+}}
+Note: the content does NOT invent an escalation path or suggest "check your email" — it only describes what the agent should avoid (the observed mistake) and why, based on what happened in the conversation.
+
+**Example 3 — Success Path Recipe:**
+* **Agent successfully computed audit sample sizes from a tabular dataset.**
+* **Output:**
+{{
+  "playbooks": [
+    {{
+      "rationale": "Captures the audit-sample selection structure that the original trajectory converged to after a brief sampling-at-random detour.",
+      "trigger": "Selecting an audit sample from a tabular dataset using risk metrics, multi-criteria filtering, and period-over-period variance.",
+      "content": "(1) Load the dataset with a tabular reader. (2) Compute period-over-period variance per row. (3) Compute Cochran sample size (z=1.645, p=0.5) and apply finite-population correction. (4) Filter rows by risk thresholds (variance threshold, mandatory entities, target metric codes, all-zero rows). (5) Write the sample to a spreadsheet with separate Sample and Calculation tabs. Detour to skip: do not start by sampling at random — variance plus filter rules drive the selection."
+    }}
+  ]
+}}
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Rules for Output Fields
+
+* The top-level response MUST be a JSON object with a single `"playbooks"` key whose value is a list (possibly empty)
+* Each entry in `"playbooks"` MUST satisfy ALL of the following:
+  * "rationale" is REQUIRED — 1-2 sentence summary of why this entry captures reusable value
+  * "trigger" is REQUIRED — situation/condition for Correction SOPs OR task-type descriptor for Success Path Recipes (used as search key)
+  * "content" is REQUIRED — the main actionable content. MUST satisfy both joint requirements (grounded in conversation evidence AND generalized to apply in other repos). See Content Grounding Rules.
+* Each playbook MUST correspond to a triggering agent behavior OR a successful task completion in the trajectory
+* Vague, stylistic, or unanchored advice is invalid for BOTH categories
+* Each entry must describe a **distinct, independent** policy or recipe