claude-smart 0.2.45 → 0.2.47

package/plugin/vendor/reflexio/reflexio/server/prompt/prompt_bank/memory_reflection/v1.6.0.prompt.md

@@ -1,5 +1,5 @@
 ---
-active: true
+active: false
 description: "Sliding-window critique-and-revise pass over user-profile / user-playbook items the agent cited within the recent interaction window. Adds per-citation post-horizon context; playbook flips are expressed by rewriting the rule in the opposite orientation (polarity is derived from wording, never a separate field). When a cited item holds multiple rules, localizes the edit to the rule(s) the window's evidence bears on. Any playbook content rewrite (tighten / widen / rewrite / flip) must carry a new_rationale. Defaults strongly to no_change."
 changelog: "v1.6.0: add an explicit 'Change profile TTL' revision-mode bullet instructing the model to set new_profile_time_to_live when the window shows the profile's current time-to-live is wrong for the stability of the fact (TTL-only edits remain exempt from the new_rationale rule). Closes an instruction gap: ReflectionDecision already supported new_profile_time_to_live and Hard constraints already allowed ttl on profiles, but Revision modes never told the model to use it. No output schema, variable, or other mode changed. v1.5.0: uniform rationale rule — whenever a playbook revision sets new_content (tighten / widen / rewrite / flip), it MUST also set new_rationale naming why; trigger-only and TTL-only edits stay exempt. This aligns the prompt with the validator (which rejects any new_content playbook revision lacking new_rationale). Cited-playbook JSON no longer carries a derived polarity hint — orientation is read from the rule wording. No output schema, variable, or mode changed."
 variables:

package/plugin/vendor/reflexio/reflexio/server/prompt/prompt_bank/memory_reflection/v1.7.0.prompt.md

@@ -0,0 +1,85 @@
+---
+active: true
+description: "Sliding-window critique-and-revise pass over user-profile / user-playbook items the agent cited within the recent interaction window. Adds per-citation post-horizon context; playbook flips are expressed by rewriting the rule in the opposite orientation (polarity is derived from wording, never a separate field). When a cited item holds multiple rules, localizes the edit to the rule(s) the window's evidence bears on. Any playbook content rewrite (tighten / widen / rewrite / flip) must carry a new_rationale. Defaults strongly to no_change except when post-citation evidence directly shows the cited item caused a correction or became stale."
+changelog: "v1.7.0: adds a carve-out from the no_change default when the post-citation window contains explicit correction against a cited rule or same-window evidence that the cited rule is stale. v1.6.0: add an explicit 'Change profile TTL' revision-mode bullet instructing the model to set new_profile_time_to_live when the window shows the profile's current time-to-live is wrong for the stability of the fact (TTL-only edits remain exempt from the new_rationale rule). Closes an instruction gap: ReflectionDecision already supported new_profile_time_to_live and Hard constraints already allowed ttl on profiles, but Revision modes never told the model to use it. No output schema, variable, or other mode changed. v1.5.0: uniform rationale rule — whenever a playbook revision sets new_content (tighten / widen / rewrite / flip), it MUST also set new_rationale naming why; trigger-only and TTL-only edits stay exempt. This aligns the prompt with the validator (which rejects any new_content playbook revision lacking new_rationale). Cited-playbook JSON no longer carries a derived polarity hint — orientation is read from the rule wording. No output schema, variable, or mode changed."
+variables:
+  - agent_context
+  - window_interactions_json
+  - cited_profiles_json
+  - cited_user_playbooks_json
+  - per_citation_context_json
+---
+You are reviewing how the agent applied a small set of remembered facts and rules across a recent slice of conversation, with the benefit of seeing what happened *after* the agent used them. Your job is to decide, for each cited item, whether to leave it alone, tighten its phrasing, widen its scope, rewrite it, or — for playbooks only — flip its polarity.
+
+[Agent context]
+{agent_context}
+
+[Recent interaction window (oldest first; each interaction may include `citations` showing which items it relied on)]
+{window_interactions_json}
+
+[Per-citation context]
+For each citation below, a JSON object indicating whether we have a full post-citation horizon. When `has_full_horizon` is false, the post-citation context for that citation is incomplete; bias even more strongly toward no_change for it.
+{per_citation_context_json}
+
+[Cited user profile rows that are still current]
+{cited_profiles_json}
+
+[Cited user playbook rows that are still current]
+For each cited playbook you receive its `content`, `trigger`, and `rationale`. Read the rule's **orientation** (whether it tells the agent to do something or to avoid something) directly from the wording of `content` — there is no separate polarity field.
+{cited_user_playbooks_json}
+
+# Decision rules
+
+For each cited item above, emit one ReflectionDecision in `decisions`. A decision is either **no_change** (default) or a **revision** — there is no `action` enum; the LLM signals revision by setting one or more of the optional fields. Default is no_change.
+
+Apply the **minimal-edit principle** to every revision: make the smallest edit the window demonstrates, preserve the parts of the item the window did not touch, and avoid accreting detail the window does not support.
+
+Do not default to `no_change` when the full post-citation window directly shows the cited item caused or survived a correction. If, after the citation, the user explicitly corrects the agent for following or relying on that cited rule, choose the smallest matching revision: flip when the rule points in the wrong direction, rewrite substance when the rule is factually wrong, or tighten when the rule is valid only in a narrower context. Likewise, if same-window code/config/doc changes make the cited rule factually outdated, rewrite or tighten it instead of leaving stale guidance in place. Keep the strong `no_change` default for ambiguous evidence and keep the `has_full_horizon=false` bias unless the correction is explicit in the available context.
+
+## Rationale rule for playbook content edits (all modes)
+
+Whenever you set `new_content` on a **playbook** revision — for *any* mode: tighten, widen, rewrite, or flip — you MUST also set `new_rationale` naming the window observation (misapplication, pushback, self-correction, external check, outdated fact, failure trap) that motivates the edit. This is a uniform rule across all content edits, not just flips. A `new_content` playbook revision without `new_rationale` is invalid. Trigger-only and TTL-only edits (no `new_content`) are exempt — they require no `new_rationale`.
+
+## When a cited item contains multiple rules
+
+A cited playbook may hold several rules — a few do/avoid points covering the steps of a task. The agent pulled in the whole item because it was relevant, then chose which rules to act on. Identify which rule(s) the window's evidence actually bears on — read the agent's responses, its tool calls, and what happened after it relied on the item (pushback, self-correction, an external check) — and revise only those rule(s), leaving the rest of the content unchanged (minimal-edit).
+
+- If the window does not clearly show which rule was applied or how it fared, return `no_change` rather than editing the wrong rule.
+- When you change a rule's orientation (a "do" rule becomes an "avoid" rule or vice versa), set `new_rationale` naming the failure/observation that motivates the flip.
+
+## no_change
+
+Set only `target_kind` and `target_id`. Leave every other field null/empty. Choose this whenever you are not sure, AND whenever `has_full_horizon` is false unless the cited turn itself contains very clear evidence (e.g., user explicitly pushed back inside the cited turn's exchange, or the cited row contradicted what the user said earlier in the window).
+
+## Revision modes (set the appropriate fields; the LLM does not emit a category label)
+
+- **Tighten (substance preserved).** Set `new_trigger` (playbook) or rewrite `new_content` keeping the same meaning. Use when the row was over-retrieved or misapplied but the underlying rule/fact is still correct. Narrow *just enough* to address what the window demonstrates, and keep the rule general enough to cover the cases the window still supports. Do not change orientation. If you set `new_content`, set `new_rationale` (see rule above).
+- **Widen (substance preserved).** Set `new_trigger` (playbook) or rewrite `new_content` keeping the same meaning, broadening the trigger/scope. Use when the window shows the rule applies *more broadly* than its current trigger captures — for example, a profile says "likes spicy ramen" but the window shows the user ordering spicy food across multiple cuisines, or a playbook trigger fires on one phrasing the user clearly uses interchangeably with others. Broaden *just enough* to cover what the window actually demonstrates, and keep it within what the window shows. Do not change orientation. If you set `new_content`, set `new_rationale` (see rule above).
+- **Rewrite substance.** Set `new_content` (and `new_rationale` for playbooks). Use when the row is factually wrong or outdated. Edit *just enough* to correct what the window demonstrates, and preserve the still-correct parts of the row. Do not change orientation unless this is also a flip (then follow flip rules below).
+- **Change profile TTL** (profiles only). Set `new_profile_time_to_live` when the window shows the profile's current time-to-live is wrong for the stability of the fact (e.g. a fact that proved durable should persist longer; a fact that already went stale should expire sooner). Do not also change the profile content unless the window separately demonstrates a content correction. (This is a TTL-only edit when no `new_content` is set — exempt from the `new_rationale` rule.)
+- **Flip orientation** (playbooks only). To flip a rule, **rewrite `new_content`** as the opposite-orientation rule:
+  - For a **success → failure** flip, write `new_content` as avoidance guidance starting with `Avoid`, `Do not`, `Don't`, or `Never`.
+  - For a **failure → success** flip, write `new_content` as affirmative action guidance.
+  Always **set `new_rationale`** naming the failure/observation in the post-citation context that motivates the flip. There is no separate polarity field — the flip is recognized from the rewritten wording plus the failure named in `new_rationale`.
+
+Use flip only when the post-citation window shows the cited rule pushed the agent into a failure trap: user pushback against the recommended action, agent self-correction away from it, an external check refuting it, or the user explicitly disliking the outcome.
+
+Use no_change when evidence is unclear or absent.
+
+# Over-specialization guard (tighten and rewrite)
+
+When you tighten or rewrite, edit *just enough* to address what the window demonstrates, and keep the rule applicable to the cases the window still supports. Frame the result as the smallest correct generalization the window justifies. Keep the rule covering the range of situations the window shows it applies to.
+
+# Evidence bar for widening
+
+Widen only when multiple interactions in the window demonstrate the broader pattern; treat a single occurrence as insufficient and choose no_change instead. Keep the broadened scope within what the window demonstrates.
+
+# Hard constraints
+
+- Do **not** flip a profile's orientation (profiles have no polarity) — only rewrite/tighten/widen/ttl apply to profiles.
+- Do **not** invent new playbook rules or profile rows. If something new should be remembered, that is a different system's job — return no_change here.
+- Do **not** generalize beyond what the window actually demonstrates.
+- Do **not** propose decisions for items not present in the cited lists above.
+- If both cited lists are empty, return `decisions: []`.
+
+Output strictly conforming to the `ReflectionOutput` schema (a JSON object with a single key `decisions`).

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

@@ -1,5 +1,5 @@
 ---
-active: true
+active: false
 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:

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

@@ -0,0 +1,253 @@
+---
+active: true
+description: "Generates agent playbook entries from user playbook entries by combining them into actionable policies — structured trigger + markdown-bullet content"
+changelog: "v2.3.0: adds antecedent-not-reaction trigger guidance so aggregated policies retrieve before the omission or correction has already happened. (in-place 2026-06-18: make consolidated triggers future-user-query-like retrieval keys.) 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
+  - aggregation_prompt_extra_instructions
+---
+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 …".
+- Name the **antecedent situation** where a future agent should act before the correction is needed. Do not make the trigger the user's later repair request or the already-failed state.
+- Shape the trigger like the future user-facing question or task request that should retrieve this playbook. Use "When/If/For a user asks..." phrasing when the policy should fire from a user question.
+- 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 — task, metric, artifact, action, and common synonyms, not just the
+  literal conversational vocabulary of the inputs.
+- Do not make the trigger an internal post-hoc event such as "user corrected
+  the agent", "data contradicts estimate", or "agent made an error".
+- 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.
+- ❌ `"User provides a data point that contradicts a quantitative estimate the agent just delivered."` — post-hoc; misses the original finance question.
+- ✅ `"When reviewing code — pull requests, inline comments, pre-merge checks, or any code-review activity."`
+- ✅ `"When editing one deployment doc for an env-var, secret, port, or task-definition change."`
+- ✅ `"When a user asks how to estimate total returns, ROI, performance, or cumulative gains for debt funds, hybrid funds, or investments with recurring distributions."`
+- ❌ `"When syncing two deployment docs."`
+
+### `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.
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Privacy and Identifier Generalization
+
+Agent playbooks are shared organization-wide rules. They must capture reusable
+agent behavior, not source-user identity or private source context.
+
+Apply these rules to all source fields shown to you, including triggers, rationales, and any freeform content or observations in the clustered input:
+
+- Never carry user-specific or source-specific direct identifiers into
+  `trigger`, `content`, or `rationale`.
+- Direct identifiers include person names; emails; phone numbers; addresses;
+  usernames or handles; government, employee, customer, account, ticket, and
+  similar exact identifiers; URLs or strings containing values tied to a person,
+  account, session, or secret; and named private customers, users, or
+  organization-specific people when the exact name is unnecessary for reusable
+  behavior.
+{aggregation_prompt_extra_instructions}
+- Preserve the reusable procedure whenever possible by replacing direct
+  identifiers with generalized functional roles, resource types, or
+  relationships inferred from the clustered source playbooks.
+- Secrets and credentials must not be copied or generalized as values. Remove
+  secret values entirely, keeping only the non-secret procedural lesson if one
+  remains.
+- Do not turn one user's personal preference into an organization-wide rule
+  unless the cluster supports it as shared behavior.
+- If removing or generalizing identifiers leaves no useful reusable agent
+  behavior, Return {{"playbook": null}}.
+
+## 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
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Final Privacy Self-Check
+
+Before returning JSON:
+
+- Verify `trigger`, `content`, and `rationale` contain no direct identifiers, secrets, raw contact details, or exact IDs.
+- Verify the rule remains grounded in the clustered source playbooks and reusable
+  across users in the organization.
+- If either check fails and cannot be fixed by generalization, Return
+  {{"playbook": null}}.
+
+## 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/v2.3.2.prompt.md

@@ -1,5 +1,5 @@
 ---
-active: true
+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.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:

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

@@ -0,0 +1,74 @@
+---
+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.3: adds antecedent-not-reaction trigger guidance for unified and differentiated triggers. (in-place 2026-06-15: adds concise anti-overmerge guard for concrete operational surfaces; restates the numeric id fields (`superseded_by_existing_id`, `existing_id`, `archive_existing_ids`) as EXISTING list-position integers — e.g. emit `0` for `[EXISTING-0]` — superseding the prior 'bare DB id, labels never valid' framing.) 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.
+
+When you write any final `trigger`, `refined_new_trigger`, or `refined_existing_trigger`, frame it as the antecedent situation where a future agent can act before the mistake recurs, not as the user's later repair request. For example, prefer "When editing one AWS deployment doc for an env-var/secret/port change" over "When syncing two AWS deployment docs."
+
+[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 winning EXISTING row's list-position integer via `superseded_by_existing_id` (for `[EXISTING-0]`, emit `0`). 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.
+- Preserve concrete operational surfaces (target groups, SGs, health checks, task defs); do not merge fanout rules into generic sweep/audit rules unless those surfaces remain explicit.
+- 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 EXISTING list-position integers, not display labels or bracketed row prefixes. For `[EXISTING-0]`, emit `0`; for `[EXISTING-3]`, emit `3`.
+- 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 list-position 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 EXISTING list-position integer only; optional `reason` may explain the decision.
+- `differentiate`: include `existing_id` as an EXISTING list-position 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.2.3.prompt.md

@@ -1,5 +1,5 @@
 ---
-active: true
+active: false
 description: "Context setting prompt for resumable playbook extraction. Every claim must be grounded in the conversation and generalized to a reusable task context; both requirements apply jointly to Correction SOPs and Success Path Recipes."
 changelog: "v4.2.3: strengthens strict tool-call discipline so plain-text/no-tool responses are explicitly invalid, including empty extraction outcomes. v4.2.2: replaces output examples with compact tool-call and JSON-shape guidance, while preserving the resumable extraction contract. v4.2.1: negative/avoid guidance cannot contradict the final verified implementation or final evaluation. v4.2.0: adds emergent skill-convention guidance for structuring multi-aspect playbook content as a small set of grouped do/avoid rules (no schema change). v4.1.7: adds resumable extraction guidance, names legacy fallback and malformed-input branches in boundary-change recipes, and avoids a polarity output field. (in-place 2026-05-30: tool-oriented finish_extraction output framing; deprecated and removed blocking_issue.) (in-place 2026-05-30: clarify in the Output Format section that finish_extraction may be preceded by ask_human/attach_pending_info_request; restructure examples into one no-tool example plus a worked ask_human and attach_pending_info_request example; stress that ask_human is rare and reserved for critical missing org-level facts — finish_extraction alone is the norm.) (in-place 2026-05-30: condense the resumable guidance — state finish-required/optional once, replace the duplicated Output Format block with a one-line pointer, and trim example prose.) (in-place 2026-06-03: consolidate and shorten the ask_human condition: ask only for missing shared context needed to know what to do, while still finishing extraction.) (in-place 2026-06-03: frame finish_extraction as the final completion tool and pending-info tools as intermediate.) (in-place 2026-06-03: clarify that empty finish_extraction alone must not replace ask_human when the ask_human condition applies.) (in-place 2026-06-04: clarify ask_human and attach_pending_info_request are alternatives for the same gap, not a sequence.)"
 variables: