claude-smart 0.2.41 → 0.2.43

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

@@ -0,0 +1,24 @@
+---
+active: false
+description: "Main prompt for extracting playbook entries from user interactions"
+changelog: "v1.1.0: guides action-vs-avoidance framing without requiring a polarity output field."
+variables:
+  - interactions
+---
+## Conversation
+{interactions}
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Action vs avoidance framing
+
+Write each playbook in the form that best matches its evidence:
+
+- Use direct action language for successful, neutral, or ambiguous evidence. This is the default and covers most entries.
+- Use avoidance language only when the specific rule is grounded in a clear failure pattern: user pushback, self-correction away from an approach, external refutation, or explicit dislike.
+
+When writing an avoidance rule, start `content` with `Avoid`, `Do not`, `Don't`, or `Never`, and make the `rationale` name the observed failure pattern. Do not add a separate polarity field; downstream systems infer orientation from the wording and evidence.
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Output
+
+Return ONLY the JSON object.

package/plugin/vendor/reflexio/reflexio/server/prompt/prompt_bank/playbook_extraction_main/v1.2.0.prompt.md

@@ -0,0 +1,29 @@
+---
+active: true
+description: "Main prompt for extracting playbook entries from user interactions"
+changelog: "v1.2.0: adds emergent skill-convention guidance for structuring multi-aspect playbook content as a small set of grouped do/avoid rules (no schema change). v1.1.0: guides action-vs-avoidance framing without requiring a polarity output field."
+variables:
+  - interactions
+---
+## Conversation
+{interactions}
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Action vs avoidance framing
+
+Write each playbook in the form that best matches its evidence:
+
+- Use direct action language for successful, neutral, or ambiguous evidence. This is the default and covers most entries.
+- Use avoidance language only when the specific rule is grounded in a clear failure pattern: user pushback, self-correction away from an approach, external refutation, or explicit dislike.
+
+When writing an avoidance rule, start `content` with `Avoid`, `Do not`, `Don't`, or `Never`, and make the `rationale` name the observed failure pattern. Do not add a separate polarity field; downstream systems infer orientation from the wording and evidence.
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Structuring multi-aspect content
+
+When the guidance for a playbook covers multiple steps or sub-aspects of a task, write `content` as a short set of rules grouped by sub-goal, rather than one dense sentence. Phrase each rule as a clear action (do) rule, or as an avoidance rule (`Avoid`/`Do not`/`Don't`/`Never`) when it names a failure to steer around. Keep it minimal — only the rules the evidence supports; a single-point playbook stays a single rule. Do not force structure where the guidance is atomic.
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Output
+
+Return ONLY the JSON object.

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

@@ -0,0 +1,11 @@
+---
+active: false
+description: "User prompt for expert-content playbook extraction, provides agent-vs-expert comparison pairs"
+variables:
+  - comparison_pairs
+---
+Below are comparisons between the agent's actual response and an expert's ideal response for the same user questions.
+
+{comparison_pairs}
+
+Analyze the differences and extract generalizable SOPs following the JSON format specified in your instructions. Return ONLY valid JSON, no other text.

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

@@ -0,0 +1,21 @@
+---
+active: false
+description: "User prompt for expert-content playbook extraction, provides agent-vs-expert comparison pairs"
+changelog: "v1.1.0: guides action-vs-avoidance framing without requiring a polarity output field."
+variables:
+  - comparison_pairs
+---
+Below are comparisons between the agent's actual response and an expert's ideal response for the same user questions.
+
+{comparison_pairs}
+
+## Action vs avoidance framing
+
+Write each playbook in the form that best matches its evidence:
+
+- Use direct action language for successful, neutral, or ambiguous evidence. This is the default and covers most entries.
+- Use avoidance language only when the specific rule is grounded in a clear failure pattern: the agent's approach failed relative to the expert response, the expert avoided a risky path the agent took, an external check refuted the agent, or the user explicitly disliked the outcome.
+
+When writing an avoidance rule, start `content` with `Avoid`, `Do not`, `Don't`, or `Never`, and make the `rationale` name the observed failure pattern. Do not add a separate polarity field; downstream systems infer orientation from the wording and evidence.
+
+Analyze the differences and extract generalizable SOPs following the JSON format specified in your instructions. Return ONLY valid JSON, no other text.

package/plugin/vendor/reflexio/reflexio/server/prompt/prompt_bank/playbook_extraction_main_expert/v1.2.0.prompt.md

@@ -0,0 +1,25 @@
+---
+active: true
+description: "User prompt for expert-content playbook extraction, provides agent-vs-expert comparison pairs"
+changelog: "v1.2.0: adds emergent skill-convention guidance for structuring multi-aspect playbook content as a small set of grouped do/avoid rules (no schema change). v1.1.0: guides action-vs-avoidance framing without requiring a polarity output field."
+variables:
+  - comparison_pairs
+---
+Below are comparisons between the agent's actual response and an expert's ideal response for the same user questions.
+
+{comparison_pairs}
+
+## Action vs avoidance framing
+
+Write each playbook in the form that best matches its evidence:
+
+- Use direct action language for successful, neutral, or ambiguous evidence. This is the default and covers most entries.
+- Use avoidance language only when the specific rule is grounded in a clear failure pattern: the agent's approach failed relative to the expert response, the expert avoided a risky path the agent took, an external check refuted the agent, or the user explicitly disliked the outcome.
+
+When writing an avoidance rule, start `content` with `Avoid`, `Do not`, `Don't`, or `Never`, and make the `rationale` name the observed failure pattern. Do not add a separate polarity field; downstream systems infer orientation from the wording and evidence.
+
+## Structuring multi-aspect content
+
+When the guidance for a playbook covers multiple steps or sub-aspects of a task, write `content` as a short set of rules grouped by sub-goal, rather than one dense sentence. Phrase each rule as a clear action (do) rule, or as an avoidance rule (`Avoid`/`Do not`/`Don't`/`Never`) when it names a failure to steer around. Keep it minimal — only the rules the evidence supports; a single-point playbook stays a single rule. Do not force structure where the guidance is atomic.
+
+Analyze the differences and extract generalizable SOPs following the JSON format specified in your instructions. Return ONLY valid JSON, no other text.

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

@@ -0,0 +1,37 @@
+---
+id: playbook_optimizer_judge
+version: 1.0.0
+active: false
+description: Judge paired real-assistant rollouts for playbook optimization
+variables:
+  - source_window_json
+  - incumbent_playbook_json
+  - candidate_playbook_json
+  - incumbent_rollout_json
+  - candidate_rollout_json
+---
+You are judging whether a candidate playbook content change improves the real assistant's behavior.
+
+Use the source window as the ground-truth scenario context. Compare the incumbent rollout and candidate rollout. The user turns were held constant; only the injected playbook content changed.
+
+Source window:
+{source_window_json}
+
+Incumbent playbook:
+{incumbent_playbook_json}
+
+Candidate playbook:
+{candidate_playbook_json}
+
+Incumbent rollout:
+{incumbent_rollout_json}
+
+Candidate rollout:
+{candidate_rollout_json}
+
+Return structured JSON matching the requested schema:
+- verdict: "candidate", "incumbent", or "tie"
+- score: 1.0 for clear candidate win, 0.5 for tie, 0.0 for clear incumbent win; use intermediate values only for weak wins
+- likert: 1 to 5 quality score for candidate behavior
+- rationale: concise explanation
+- asi: actionable side information with failure_modes, regressions, winning_behaviors, missing_instruction, recommended_mutation

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

@@ -0,0 +1,40 @@
+---
+active: false
+description: Judge paired real-assistant rollouts for playbook optimization
+changelog: "v1.1.0: polarity-aware like-with-like comparison — opposing-polarity candidates trigger evidence re-examination instead of eloquence-based winner selection. Deprecated in v1.2.0: the polarity branch was inert (the judge payload never sent a polarity field) and removed under Option B."
+variables:
+  - source_window_json
+  - incumbent_playbook_json
+  - candidate_playbook_json
+  - incumbent_rollout_json
+  - candidate_rollout_json
+---
+You are judging whether a candidate playbook content change improves the real assistant's behavior.
+
+Use the source window as the ground-truth scenario context. Compare the incumbent rollout and candidate rollout. The user turns were held constant; only the injected playbook content changed.
+
+Source window:
+{source_window_json}
+
+Incumbent playbook:
+{incumbent_playbook_json}
+
+Candidate playbook:
+{candidate_playbook_json}
+
+Incumbent rollout:
+{incumbent_rollout_json}
+
+Candidate rollout:
+{candidate_rollout_json}
+
+Return structured JSON matching the requested schema:
+- verdict: "candidate", "incumbent", or "tie"
+- score: 1.0 for clear candidate win, 0.5 for tie, 0.0 for clear incumbent win; use intermediate values only for weak wins
+- likert: 1 to 5 quality score for candidate behavior
+- rationale: concise explanation
+- asi: actionable side information with failure_modes, regressions, winning_behaviors, missing_instruction, recommended_mutation
+
+## Polarity-aware judgment
+
+If the candidates differ in their `polarity` field (one positive, one negative), do not pick the more eloquent one. Re-examine the source evidence to determine which polarity is correct; then pick the best candidate of that polarity. If you cannot determine the correct polarity from the evidence, return `verdict = "tie"` (no winner) with `score = 0.5`.

package/plugin/vendor/reflexio/reflexio/server/prompt/prompt_bank/playbook_optimizer_judge/v1.2.0.prompt.md

@@ -0,0 +1,36 @@
+---
+active: true
+description: Judge paired real-assistant rollouts for playbook optimization
+changelog: "v1.2.0: removed the dead Polarity-aware judgment section. Under Option B, production no longer derives polarity mechanically and the judge payload (_playbook_payload) never sends a `polarity` field, so that branch was inert."
+variables:
+  - source_window_json
+  - incumbent_playbook_json
+  - candidate_playbook_json
+  - incumbent_rollout_json
+  - candidate_rollout_json
+---
+You are judging whether a candidate playbook content change improves the real assistant's behavior.
+
+Use the source window as the ground-truth scenario context. Compare the incumbent rollout and candidate rollout. The user turns were held constant; only the injected playbook content changed.
+
+Source window:
+{source_window_json}
+
+Incumbent playbook:
+{incumbent_playbook_json}
+
+Candidate playbook:
+{candidate_playbook_json}
+
+Incumbent rollout:
+{incumbent_rollout_json}
+
+Candidate rollout:
+{candidate_rollout_json}
+
+Return structured JSON matching the requested schema:
+- verdict: "candidate", "incumbent", or "tie"
+- score: 1.0 for clear candidate win, 0.5 for tie, 0.0 for clear incumbent win; use intermediate values only for weak wins
+- likert: 1 to 5 quality score for candidate behavior
+- rationale: concise explanation
+- asi: actionable side information with failure_modes, regressions, winning_behaviors, missing_instruction, recommended_mutation

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

@@ -0,0 +1,45 @@
+---
+active: false
+description: "Determines if playbook extraction should occur based on user interactions (deactivated by v2 which adds Success Path Recipe signal detection to match v3 playbook_extraction_context)"
+variables:
+  - agent_context_prompt
+  - extraction_definition_prompt
+  - new_interactions
+  - tool_can_use
+---
+You are a detector for GLOBAL AGENT LEARNING SIGNALS.
+
+Decide whether the conversation contains ANY signal that could justify
+changing permanent agent behavior for ALL users.
+
+Count as signal if the conversation or the agent's behavior reveals:
+• correction or criticism of agent behavior
+• re-steering of how the agent should respond
+• dissatisfaction, confusion, or friction
+• evidence of a better universal interaction default
+• an avoidable interaction mistake or inefficiency
+• agent had a relevant tool available but never used it when doing so could have improved the outcome (e.g., looking up options, gathering context, or checking information before responding)
+• agent addressed the surface request without using tools to explore whether a better solution exists for the user's stated underlying need
+• agent used suboptimal tool parameters (retry patterns, vague inputs)
+
+Ignore:
+• normal task content
+• factual corrections
+• personal preferences
+• domain-specific tips
+• task-local guidance
+
+AGENT CONTEXT
+{agent_context_prompt}
+
+PLAYBOOK DEFINITION
+{extraction_definition_prompt}
+
+[Available Tools]
+{tool_can_use}
+
+CONVERSATION
+{new_interactions}
+
+OUTPUT
+Return only true or false.

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

@@ -0,0 +1,81 @@
+---
+active: false
+description: "Determines if playbook extraction should occur. v2 adds Success Path Recipe signal detection alongside the v1 correction signals — keeps the gate narrow enough to reject trivial content but wide enough to let clean successful trajectories through to the extractor."
+changelog: "v2: v1 explicitly told the LLM to IGNORE normal task content and task-local guidance, which blocked the v3 Success Path Recipe extractor (playbook_extraction_context/v3) from ever running. v2 adds a second accept-track for trajectories that completed a substantive domain task successfully, so the v3 extractor can produce a reusable recipe. Trivial chit-chat and no-op interactions still get rejected."
+variables:
+  - agent_context_prompt
+  - extraction_definition_prompt
+  - new_interactions
+  - tool_can_use
+---
+You are a detector for AGENT LEARNING SIGNALS. You accept a conversation
+for playbook extraction if it contains EITHER of two kinds of signal.
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Track 1 — Correction / Friction signal
+
+Accept if the conversation reveals any of:
+• correction or criticism of agent behavior
+• re-steering of how the agent should respond
+• dissatisfaction, confusion, or friction
+• evidence of a better universal interaction default
+• an avoidable interaction mistake or inefficiency
+• agent had a relevant tool available but never used it when doing so
+  could have improved the outcome (e.g., looking up options, gathering
+  context, or checking information before responding)
+• agent addressed the surface request without using tools to explore
+  whether a better solution exists for the user's stated underlying need
+• agent used suboptimal tool parameters (retry patterns, vague inputs)
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Track 2 — Success Path Recipe signal
+
+Also accept if the conversation shows the agent **successfully
+completed a substantive domain task** end-to-end. This is the signal
+the v3 Success Path Recipe extractor needs to produce a reusable
+solution cache that a future run of the same task can shortcut with.
+
+Accept when ALL of the following hold:
+1. The agent produced a concrete deliverable (file written, dataset
+   computed, report generated, problem solved with a final answer),
+   OR reached an explicit completion signal (`<COMPLETE>`, `Task
+   done`, final summary message).
+2. The work involved at least 3 meaningful steps — tool calls, file
+   reads/writes, shell commands, or substantive analytical turns. A
+   single-message response with no tool use is NOT enough.
+3. The trajectory contains ANY of these reusable artifacts:
+   - Domain-specific constants, formulas, or parameter values the
+     agent relied on (e.g. tax rates, sample size formulas,
+     acceptance thresholds, column schemas)
+   - A specific tool / shell command sequence that worked
+   - A file-format or output-layout decision that satisfied the task
+   - A computed final answer or discrete result
+   - Key decisions the agent made with clear rationale
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Reject when
+
+Reject (return false) if NEITHER track fires, specifically:
+• The conversation is chit-chat / trivially short (fewer than 3
+  meaningful interactions) with no deliverable produced
+• The agent made no tool calls AND produced no concrete artifact
+• The content is pure social acknowledgment or one-off factual Q&A
+  with no downstream reusable structure
+• The agent failed to reach any end state and left nothing useful
+  behind
+
+━━━━━━━━━━━━━━━━━━━━━━
+AGENT CONTEXT
+{agent_context_prompt}
+
+PLAYBOOK DEFINITION
+{extraction_definition_prompt}
+
+[Available Tools]
+{tool_can_use}
+
+CONVERSATION
+{new_interactions}
+
+OUTPUT
+Return only true or false.

package/plugin/vendor/reflexio/reflexio/server/prompt/prompt_bank/playbook_should_generate/v3.0.0.prompt.md

@@ -0,0 +1,80 @@
+---
+active: true
+description: "Determines if playbook extraction should occur. v3 broadens the v2 success-path track so that non-quantitative deliverables (articles, legal memos, SOAP notes, editorial content) also pass when the agent actually produced the deliverable. v2's 'reusable artifacts' list biased toward quantitative tasks (constants, formulas) and rejected clean narrative-task successes."
+changelog: "v3: v2 Track 2 required a 'domain-specific constant, formula, or parameter value' among its reusable-artifact options, which skewed acceptance toward data / finance / compliance tasks and rejected clean narrative successes like news articles (17 iter, 0.9 score) and pediatric SOAP notes. v3 rewrites the reusable-artifact list to also count produced document structure, quoted sources / citations, argumentative framing, or concrete editorial / clinical decisions. It also simplifies the success-path test to a single pass-condition (rather than v2's ALL-of-3) so the LLM gate is less likely to over-reject on technicalities. Trivial chit-chat, no-op interactions, and failed trajectories still get rejected."
+variables:
+  - agent_context_prompt
+  - extraction_definition_prompt
+  - new_interactions
+  - tool_can_use
+---
+You are a detector for AGENT LEARNING SIGNALS. You accept a conversation
+for playbook extraction if it contains EITHER of two kinds of signal.
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Track 1 — Correction / Friction signal
+
+Accept if the conversation reveals any of:
+• correction or criticism of agent behavior
+• re-steering of how the agent should respond
+• dissatisfaction, confusion, or friction
+• evidence of a better universal interaction default
+• an avoidable interaction mistake or inefficiency
+• agent had a relevant tool available but never used it when doing so
+  could have improved the outcome (e.g., looking up options, gathering
+  context, or checking information before responding)
+• agent addressed the surface request without using tools to explore
+  whether a better solution exists for the user's stated underlying need
+• agent used suboptimal tool parameters (retry patterns, vague inputs)
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Track 2 — Success Path Recipe signal
+
+Accept if the agent meaningfully worked a task, reached an end
+state, AND the trajectory contains something non-obvious worth
+learning:
+
+> ≥3 meaningful actions (tool calls, file ops, analytical steps)
+> AND the agent produced, decided, or resolved something the user
+> asked for (deliverable, answer, decision, recommendation, plan,
+> or completion signal)
+> AND the trajectory contains at least one non-obvious element a
+> future run could reuse: a specific decision with rationale, a
+> command / approach / sequence that isn't the first thing to try,
+> a domain fact the agent looked up or relied on, a structural or
+> format choice the agent committed to, or a recovery move after
+> a wrong turn.
+
+A purely routine completion — agent did the obvious thing, made
+no judgment calls, discovered nothing — does NOT pass. The bar
+is "a future run of a similar task could shortcut by remembering
+this," not just "the agent finished."
+
+Deliverable type is not restricted: quantitative, narrative,
+analytical, advisory, procedural, creative — all qualify, as long
+as the non-obvious element is present.
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Reject when
+
+Reject if neither Track 1 nor Track 2 fires. One explicit case to
+call out on top of that: reject infrastructure-failure loops
+(repeated tool / auth / sandbox / lookup errors with no actual task
+progress) even if the action count is high — a failure-recovery
+recipe is not worth caching.
+
+━━━━━━━━━━━━━━━━━━━━━━
+AGENT CONTEXT
+{agent_context_prompt}
+
+PLAYBOOK DEFINITION
+{extraction_definition_prompt}
+
+[Available Tools]
+{tool_can_use}
+
+CONVERSATION
+{new_interactions}
+
+OUTPUT
+Return only true or false.

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

@@ -0,0 +1,34 @@
+---
+active: true
+description: "Determines if expert-content playbook extraction should occur by checking for meaningful divergence between agent and expert responses"
+variables:
+  - agent_context_prompt
+  - comparison_pairs
+---
+You are a detector for MEANINGFUL DIVERGENCE between an agent's response and an expert's ideal response.
+
+Decide whether there is a substantive difference worth learning from.
+
+Count as signal (return true) if:
+- Expert uses a fundamentally different approach, reasoning, or methodology
+- Expert includes important information or steps the agent missed
+- Agent response contains inaccuracies or incorrect information that the expert avoids
+- Expert demonstrates better tool usage, prioritization, or completeness
+- Expert response addresses the user's underlying need more effectively
+- Agent's response could lead to suboptimal or incorrect outcomes compared to expert
+
+Do NOT count as signal (return false) if:
+- Agent and expert responses are substantively equivalent (same approach, same conclusions)
+- Differences are only stylistic or cosmetic (formatting, word choice, phrasing)
+- Both responses would lead to the same practical outcome
+- Differences are in level of detail but core content is the same
+- Expert simply uses different examples to illustrate the same point
+
+AGENT CONTEXT
+{agent_context_prompt}
+
+AGENT VS EXPERT COMPARISONS
+{comparison_pairs}
+
+OUTPUT
+Return only true or false.

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

@@ -0,0 +1,116 @@
+---
+active: true
+description: "Identifies and merges duplicate profiles across NEW extractions and EXISTING profiles in the database"
+changelog: "Added Last Modified date to profile format and temporal conflict resolution guidance — prefer newer information when profiles contradict."
+variables:
+  - new_profile_count
+  - new_profiles
+  - existing_profile_count
+  - existing_profiles
+---
+[Goal]
+You are a profile deduplication assistant. Your job is to identify and merge duplicate profiles across NEW extractions and EXISTING profiles in the database.
+
+[Input]
+You will receive two groups of profiles:
+- {new_profile_count} NEW profiles (just extracted, not yet saved)
+- {existing_profile_count} EXISTING profiles (already in the database)
+
+Each profile includes: Content, TTL, Source, and Last Modified date.
+
+[NEW Profiles]
+{new_profiles}
+
+[EXISTING Profiles]
+{existing_profiles}
+
+[Your Task]
+1. Analyze ALL profiles (both NEW and EXISTING) and identify groups of duplicates
+2. A duplicate group can contain ANY mix of NEW and EXISTING items — when a NEW profile is about the same topic as an EXISTING one, they should be grouped together
+3. For each duplicate group:
+   - List the item_ids (e.g., "NEW-0", "EXISTING-1") of all items in this group
+   - Create a merged_content that combines the best/most specific information from all members
+   - Choose an appropriate merged_time_to_live (prefer the longest to preserve information)
+4. List unique_ids of NEW profiles that are truly unique (no duplicates found in either NEW or EXISTING)
+5. Identify deletion directives — NEW profiles whose content is a meta-request to forget an EXISTING profile (see [Deletion Directives vs. Fact Updates] below) — and emit them in `deletions` instead of `duplicate_groups` or `unique_ids`
+
+[Guidelines for Identifying Duplicates]
+- Profiles about the SAME topic/entity/preference are duplicates even if worded differently
+- Example: "User likes Python" and "User prefers Python programming" are duplicates
+- Example: "User's name is John" and "The user is called John Smith" are duplicates (merge to include full name)
+- A NEW profile that refines or updates an EXISTING profile should be grouped with it
+- Profiles about DIFFERENT topics are NOT duplicates even if similar in structure
+- Example: "User likes pizza" and "User likes sushi" are NOT duplicates
+
+[Guidelines for Merging]
+- Combine all unique information from duplicates
+- Remove redundancy but keep all facts
+- Use clear, concise language
+- Choose the most specific/detailed wording when there's overlap
+- The merged result should be the best version combining insights from all group members
+- Each profile includes a "Last Modified" date. When NEW and EXISTING profiles conflict (e.g., "likes beef" vs "is vegetarian"), prefer the more recent information as it reflects the user's latest state
+- When merging conflicting profiles, use the newer profile's content as the primary basis and supplement with non-contradictory details from the older profile
+
+[Time to Live Selection]
+When merging, choose the longest TTL from the group:
+- infinity > one_year > one_quarter > one_month > one_week > one_day
+
+[Deletion Directives vs. Fact Updates]
+A NEW profile is a **deletion directive** when its content is about the ACT of
+forgetting, removing, or no-longer-storing an existing fact — not a new fact
+about the user. Signals:
+- Content begins with (or contains) the literal phrase **"Requested removal of"** — the upstream extractor emits this marker for every deletion request, so its presence is the strongest signal
+- Content refers to the profile-storage system itself: "Asked to forget X", "Wants us to stop remembering X"
+- Verbs like "removal", "forget", "delete", "stop storing" applied to an existing topic
+- Content describes an intention about the stored memory rather than the user's own state
+
+When a NEW profile is a deletion directive AND it matches an EXISTING profile
+on the same topic:
+- Emit it in `deletions` with `new_id` and the matched `existing_ids`
+- Do NOT include it in `duplicate_groups` or `unique_ids`
+- Do NOT create a merged profile like "Previously interested in X, but requested
+  removal of this interest" — that is a zombie profile. The correct outcome is:
+  the EXISTING profile is gone and no replacement is written.
+
+Contrast with **fact updates** (keep existing merge behavior):
+- "User is now vegetarian" (previously "likes beef") → duplicate_group, merge with newest-wins. This is a replacement of one fact with another.
+- "User no longer works at Acme" (previously "works at Acme") → duplicate_group. The user is stating a new fact about themselves.
+
+If a NEW deletion directive does not match any EXISTING profile, still emit it
+in `deletions` with an empty `existing_ids: []` — do not add it to `unique_ids`,
+because it is not a fact worth storing on its own.
+
+Example — deletion directive:
+- NEW-0: "Requested removal of interest in self-improving agents from stored profiles"
+- EXISTING-0: "User is interested in self-improving agents"
+```json
+{{
+  "duplicate_groups": [],
+  "unique_ids": [],
+  "deletions": [
+    {{
+      "new_id": "NEW-0",
+      "existing_ids": ["EXISTING-0"],
+      "reasoning": "NEW-0 is a meta-request to forget the stored fact in EXISTING-0, not a new fact about the user. Delete EXISTING-0 without writing a replacement."
+    }}
+  ]
+}}
+```
+
+[Output Format]
+Return a JSON object with:
+- duplicate_groups: Array of objects, each containing:
+  - item_ids: Array of strings (IDs matching the [PREFIX-N] format, e.g., "NEW-0", "EXISTING-2")
+  - merged_content: String (the merged profile text)
+  - merged_time_to_live: String (one of: one_day, one_week, one_month, one_quarter, one_year, infinity)
+- unique_ids: Array of strings (IDs of unique NEW profiles, e.g., "NEW-2")
+- deletions: Array of objects, each containing:
+  - new_id: String (ID of the NEW profile that is a deletion directive, e.g., "NEW-0")
+  - existing_ids: Array of strings (IDs of EXISTING profiles to delete, e.g., ["EXISTING-0"]; may be empty)
+  - reasoning: String (why this was classified as a deletion directive)
+
+[Important]
+- Every NEW profile must appear EXACTLY ONCE — either in a duplicate_group's item_ids, in unique_ids, or as the new_id of a deletion directive
+- EXISTING profiles appear in duplicate_groups when superseded by a merge, or in a deletion directive's existing_ids when erased without replacement
+- Be conservative — only group true duplicates, and only classify as a deletion directive when the NEW is clearly a memory-erasure request rather than a fact update
+- If there are no EXISTING profiles, just deduplicate among the NEW profiles

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

@@ -0,0 +1,33 @@
+---
+active: true
+description: "Determines if profile extraction should occur based on user interactions"
+variables:
+  - agent_context_prompt
+  - should_extract_profile_prompt
+  - new_interactions
+---
+You are an user signal detection filter.
+
+Determine whether the following user interactions contain ANY user profile signal
+as defined below. A profile signal includes explicit facts, preferences, constraints,
+corrections, feedback, dislikes, habitual behaviors, or inferred patterns that could
+reasonably personalize future responses.
+
+AGENT CONTEXT
+{agent_context_prompt}
+
+[Profile Signal Definition]
+{should_extract_profile_prompt}
+
+[User Interactions]
+{new_interactions}
+
+Decision rules:
+- Return true if there is any signal about how the user prefers, behaves, thinks,
+  corrects the agent, or should be treated differently in the future.
+- Return true even if the signal is implicit, partial or inferred.
+- Return false if the content is only about completing the current task with no reusable
+  user-level signal (such as one-off formatting, situational details, generic chit-chat).
+
+Output:
+true or false only.

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

@@ -0,0 +1,16 @@
+---
+active: true
+description: "Override prompt for profile extraction decision with custom instructions"
+variables:
+  - instruction_override
+  - new_interactions
+---
+[INSTRUCTION]
+{instruction_override}
+
+[User interactions start]
+{new_interactions}
+[User interactions end]
+
+[Output]
+Output just a boolean value, true if it contains any information based on the definition, false otherwise.