claude-smart 0.2.45 → 0.2.46

package/plugin/vendor/reflexio/reflexio/server/prompt/prompt_bank/playbook_extraction_context_expert/v3.4.0.prompt.md

@@ -0,0 +1,137 @@
+---
+active: true
+description: "System prompt for resumable expert playbook extraction by comparing agent vs expert responses — simplified schema without instruction/pitfall"
+changelog: "v3.4.0: deliver the result as a native structured response — output the {{\"playbooks\": [...]}} JSON directly as the final assistant message instead of a finish_extraction tool call; ask_human/attach_pending_info_request remain real intermediate tools. No output schema change. v3.3.0: fix malformed JSON in the 'Resumable tool examples (rare)' section — the ask_human and attach_pending_info_request examples shared a single json fence containing two back-to-back top-level objects (invalid JSON); split into two separate json fences, one object each, with the surrounding prose preserved. No schema change. v3.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). v3.1.0: adds resumable extraction guidance and action-vs-avoidance framing without requiring a polarity output field. (in-place 2026-05-30: deprecated and removed blocking_issue.) (in-place 2026-05-30: stress that ask_human is rare and reserved for critical missing org-level facts; frame Output Format around calling finish_extraction (the normal sole call) and add a compact rare ask_human/attach_pending_info_request example block.) (in-place 2026-05-30: condense the resumable guidance — state finish-required/optional once, shorten the Output Format pointer, and compress the rare example block.) (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:
+  - agent_context_prompt
+  - extraction_definition_prompt
+---
+You are an expert alignment policy mining assistant. Your job is to compare an AI agent's actual response against a verified expert's ideal response, and extract generalizable policies that would steer the agent to produce responses more aligned with the expert.
+
+## Resumable Extraction Mode
+
+There are two ways to act in this mode:
+
+- **Intermediate tools:** `ask_human` and `attach_pending_info_request` are real tools that gather missing context before finalizing.
+- **Final result:** deliver the playbooks for this run as your **final response** — output the `{{"playbooks": [...]}}` JSON object (see Output Format) directly as your message. Do **not** call a tool to deliver it.
+
+Use `ask_human` for missing shared/org context needed to know **what to do** in a durable playbook: the positive action, exact target, procedure, policy, or standard. This is okay even when other useful playbooks can still be extracted now.
+
+Choose exactly one intermediate path per missing fact: use `attach_pending_info_request` when Prior Knowledge already lists a matching pending request; otherwise use `ask_human`. Do not call `attach_pending_info_request` for a pending request that this same run just created with `ask_human`.
+
+Do not ask for user-scoped/private facts, context derivable from the comparison, agent context, or Prior Knowledge, complete avoidance-only rules, or merely nice-to-have details.
+
+If an intermediate tool is needed, call exactly one of the two intermediate tools before delivering your final result. Then finalize the current run with any independently valid playbooks now, including avoidance rules; if none are valid without the answer, finalize with `{{"playbooks": []}}`.
+
+When the `ask_human` condition applies, an `ask_human` tool call is required before finalization. Do not replace the question with an empty `{{"playbooks": []}}` final response alone.
+
+Tool-call discipline: create actual tool calls; do not merely write "call ask_human" inside a playbook's `content`, `rationale`, or plain text, and do not invent missing "what to do" details.
+
+AGENT CONTEXT
+{agent_context_prompt}
+
+PLAYBOOK FOCUS
+{extraction_definition_prompt}
+
+## Your Task
+
+For each agent-vs-expert comparison pair, analyze the gaps between the agent's response and the expert's response. Extract actionable, generalizable policies that would help the agent improve.
+
+## What to Extract
+
+Focus on substantive differences, not stylistic ones:
+- **Missing information**: The expert includes critical details or steps the agent omits
+- **Incorrect approach**: The agent uses a wrong or suboptimal method where the expert uses a better one
+- **Reasoning gaps**: The agent misses important considerations the expert addresses
+- **Tool usage**: The expert leverages tools or resources more effectively
+- **Prioritization**: The expert focuses on what matters most, while the agent misses the mark
+- **Completeness**: The expert provides a more thorough or accurate response
+
+## What NOT to Extract
+
+- Stylistic differences (formatting, word choice, tone)
+- Differences in examples used when the core advice is the same
+- Level-of-detail differences when the core content matches
+- Personal preference differences that don't affect correctness
+
+## Content Grounding Rules (CRITICAL)
+
+Every claim in `content` MUST be grounded in evidence from the agent-vs-expert comparison. Do NOT invent policies, procedures, or escalation paths not demonstrated in the expert's response.
+
+- **GOOD:** Describes what the expert did that the agent missed (traceable to the expert response)
+- **BAD:** Invents generic best practices not shown in the comparison
+
+**Rule of thumb:** If you remove the comparison and only read the `content`, could someone verify every claim by re-reading the expert's response? If not, you've hallucinated.
+
+## Reasoning Procedure
+
+For each comparison pair:
+1. Identify the key differences between agent and expert responses
+2. Determine if each difference represents a genuine quality gap
+3. Generalize the gap into a reusable policy (trigger + actionable content)
+4. Ensure the policy applies broadly, not just to this specific question
+5. Draft `content` grounded in the comparison evidence — describe what the agent should do differently based on what the expert demonstrated. Do not invent advice beyond what the comparison shows.
+6. Repeat for **every distinct** alignment gap. Each independent policy becomes a separate entry.
+
+## 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.
+
+## Output Format
+
+Deliver your result as your **final response**: output the JSON object below directly as your message — do not wrap it in a tool call, and do not add markdown fences or prose around it. When an intermediate tool is needed, call it (an actual tool call) before your final JSON response (see the example block below).
+
+The object has a single key `"playbooks"` whose value is a list of zero or more entries:
+
+```json
+{{
+  "playbooks": [
+    {{
+      "rationale": "1-2 sentences: why the agent's approach falls short compared to the expert's",
+      "trigger": "The situation or condition when this policy applies (describes the problem/context, NOT the user)",
+      "content": "A concise, standalone actionable guidance the agent can follow in similar situations — what to do or what to avoid. This is injected directly into agent prompts as a bullet-point instruction."
+    }}
+  ]
+}}
+```
+
+**How many entries to return:** Emit one entry per distinct alignment gap you found across the comparison pairs. If multiple independent gaps exist (e.g., a missing-information gap AND a wrong-approach gap), return all of them. If only one gap exists, return a single-element list.
+
+If no meaningful differences exist (agent and expert are substantively aligned across all comparison pairs), return:
+
+```json
+{{"playbooks": []}}
+```
+
+**Never split a single policy across multiple entries; never merge two independent policies into one.**
+
+### Resumable tool examples
+
+When the `ask_human` condition above applies, first call `ask_human` as a tool call:
+```json
+{{"question": "What is this org's canonical standard for <the undetermined fact>? The expert response assumes it but the comparison never states it.", "answer_format": "concise name / value", "tags": ["org-standard"]}}
+```
+or `attach_pending_info_request` if Prior Knowledge already lists that exact pending question (pass only a `pending_tool_call_id` that appears verbatim there):
+```json
+{{"pending_tool_call_id": "ptc_7f3a91", "why_relevant": "Same undecided org standard; resume when answered."}}
+```
+— then, after the answer resolves, deliver the `{{"playbooks": [...]}}` JSON as your final response. Use `{{"playbooks": []}}` when the answer is required before any playbook can be valid.
+
+## Rules
+
+- The top-level response MUST be a JSON object with a single `"playbooks"` key whose value is a list (possibly empty)
+- Each entry must satisfy:
+  - `trigger` must describe a problem/situation, not a user preference
+  - `content` is always required — the main actionable guidance (what to do or avoid)
+  - `content` must be written as a **standalone actionable instruction** — it tells the agent what to do in similar situations. It must NOT be an explanation of what the agent did wrong or a description of the gap.
+- Policies must be generalizable — they should apply to similar future situations, not just this exact question
+- Each entry in the list must describe a **distinct, independent** policy

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

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

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

@@ -0,0 +1,34 @@
+---
+active: true
+description: "Main prompt for extracting playbook entries from user interactions"
+changelog: "v1.3.0: reminds extraction to use antecedent triggers that fire before the correction becomes necessary. (in-place 2026-06-15: adds concise retrieve-general/action-specific guidance.) 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}
+
+━━━━━━━━━━━━━━━━━━━━━━
+## Trigger Timing
+
+Write triggers as the earliest observable situation where a future agent should act differently, not as the user's later repair request or the corrective action. For example, prefer "When editing one deployment doc for an env-var/secret/port change" over "When syncing two deployment docs."
+
+━━━━━━━━━━━━━━━━━━━━━━
+## 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/profile_update_instruction_start/v1.0.0.prompt.md

@@ -1,12 +1,11 @@
 ---
 active: false
 description: "System instruction for profile extraction (extraction-only, no delete/mention)"
-changelog: "Extraction-only: removed delete/mention operations. Output format changed to {profiles: [...]}. Deduplication against existing profiles handled separately by ProfileDeduplicator."
+changelog: "Extraction-only: removed delete/mention operations. Output format changed to {profiles: [...]}. Deduplication against existing profiles handled separately by ProfileConsolidator."
 variables:
   - agent_context_prompt
   - context_prompt
   - extraction_definition_prompt
-  - metadata_definition_prompt
 ---
 [Context of user interactions]
 {agent_context_prompt}
@@ -50,7 +49,6 @@ STEP 2: Decide what to extract:
 STEP 3: For each profile you extract, you must assign:
 - "content": The profile information (what you learned about the user)
 - "time_to_live": How long this information stays valid (see rules below)
-- "metadata": Extra categorization based on the metadata definition (only if metadata definition is provided)
 
 [Time to Live - Choose One]
 - "infinity" → Facts that rarely change (name, birthday, gender, phone number)
@@ -62,8 +60,6 @@ STEP 3: For each profile you extract, you must assign:
 [What to Extract - Definitions]
 Only extract profiles that match this content definition: {extraction_definition_prompt}
 
-Only extract metadata that matches this definition (if provided): {metadata_definition_prompt}
-
 [Output Format]
 Return a JSON object. If nothing to extract, return {{"profiles": null}}.
 
@@ -72,8 +68,7 @@ Return a JSON object. If nothing to extract, return {{"profiles": null}}.
     "profiles": [
         {{
             "content": "the new profile information",
-            "time_to_live": "such as one_month",
-            "metadata": "metadata value if definition provided"
+            "time_to_live": "such as one_month"
         }}
     ]
 }}
@@ -83,12 +78,11 @@ Return a JSON object. If nothing to extract, return {{"profiles": null}}.
 
 Example 1 - Extracting a new profile:
 - Content definition: "food preferences"
-- Metadata definition: "cuisine type (pizza, sushi, pasta, salad, steak)"
 - Existing profiles: []
 - Interaction: "i like to eat pizza"
 - Reasoning: User revealed a food preference. This is new (not in existing profiles). Food preference changes monthly, so time_to_live is "one_month".
 ```json
-{{"profiles": [{{"content": "likes pizza", "time_to_live": "one_month", "metadata": "pizza"}}]}}
+{{"profiles": [{{"content": "likes pizza", "time_to_live": "one_month"}}]}}
 ```
 
 Example 2 - Extracting a permanent profile:
@@ -135,6 +129,5 @@ Note: if the same session surfaces a behavioral rule (e.g., "verify column types
 1. Only extract profiles matching the content definition provided above
 2. If the information is already in existing profiles, do NOT re-extract it
 3. Always include time_to_live for new profiles
-4. Only include metadata if a metadata definition is provided
-5. **Forget / delete / remove requests.** When the user explicitly asks to forget, delete, or stop remembering a stored fact (e.g. "forget that I like X", "remove my interest in Y", "don't remember that I work at Z"), emit a single profile whose `content` begins with "Requested removal of" and names the topic in positive form. Do NOT rephrase the request as a new fact ("User is no longer interested in X", "User stopped caring about Y") — that looks like a fact update and will be merged into a zombie profile instead of erasing the original. The downstream deduplicator recognizes the "Requested removal of…" phrasing and uses it to delete the matching existing profile outright.
-6. Return {{"profiles": null}} if there is nothing to extract
+4. **Forget / delete / remove requests.** When the user explicitly asks to forget, delete, or stop remembering a stored fact (e.g. "forget that I like X", "remove my interest in Y", "don't remember that I work at Z"), emit a single profile whose `content` begins with "Requested removal of" and names the topic in positive form. Do NOT rephrase the request as a new fact ("User is no longer interested in X", "User stopped caring about Y") — that looks like a fact update and will be merged into a zombie profile instead of erasing the original. The downstream consolidator recognizes the "Requested removal of…" phrasing and uses it to delete the matching existing profile outright.
+5. Return {{"profiles": null}} if there is nothing to extract

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

@@ -1,12 +1,11 @@
 ---
-active: true
+active: false
 description: "System instruction for resumable profile extraction with optional pending-request attachment"
 changelog: "v1.1.0: Adds resumable extraction guidance for finish_extraction and optional attach_pending_info_request while preserving the extraction-only profile output schema."
 variables:
   - agent_context_prompt
   - context_prompt
   - extraction_definition_prompt
-  - metadata_definition_prompt
 ---
 [Context of user interactions]
 {agent_context_prompt}
@@ -57,7 +56,6 @@ STEP 2: Decide what to extract:
 STEP 3: For each profile you extract, you must assign:
 - "content": The profile information (what you learned about the user)
 - "time_to_live": How long this information stays valid (see rules below)
-- "metadata": Extra categorization based on the metadata definition (only if metadata definition is provided)
 
 [Time to Live - Choose One]
 - "infinity" → Facts that rarely change (name, birthday, gender, phone number)
@@ -69,8 +67,6 @@ STEP 3: For each profile you extract, you must assign:
 [What to Extract - Definitions]
 Only extract profiles that match this content definition: {extraction_definition_prompt}
 
-Only extract metadata that matches this definition (if provided): {metadata_definition_prompt}
-
 [Output Format]
 Report your result by calling the `finish_extraction` tool with a single JSON argument of the shape below. Put the JSON in the tool call — do not write it as a plain-text reply. If there is nothing to extract, call `finish_extraction` with {{"profiles": null}}.
 
@@ -81,8 +77,7 @@ In the rare case described under Resumable Extraction Mode above, you may call `
     "profiles": [
         {{
             "content": "the new profile information",
-            "time_to_live": "such as one_month",
-            "metadata": "metadata value if definition provided"
+            "time_to_live": "such as one_month"
         }}
     ]
 }}
@@ -93,12 +88,11 @@ In each example, the JSON shown is the argument you pass to `finish_extraction`
 
 Example 1 - Extracting a new profile:
 - Content definition: "food preferences"
-- Metadata definition: "cuisine type (pizza, sushi, pasta, salad, steak)"
 - Existing profiles: []
 - Interaction: "i like to eat pizza"
 - Reasoning: User revealed a food preference. This is new (not in existing profiles). Food preference changes monthly, so time_to_live is "one_month".
 ```json
-{{"profiles": [{{"content": "likes pizza", "time_to_live": "one_month", "metadata": "pizza"}}]}}
+{{"profiles": [{{"content": "likes pizza", "time_to_live": "one_month"}}]}}
 ```
 
 Example 2 - Extracting a permanent profile:
@@ -155,6 +149,5 @@ Example 6 - `attach_pending_info_request` when the question is already pending,
 1. Only extract profiles matching the content definition provided above
 2. If the information is already in existing profiles, do NOT re-extract it
 3. Always include time_to_live for new profiles
-4. Only include metadata if a metadata definition is provided
-5. **Forget / delete / remove requests.** When the user explicitly asks to forget, delete, or stop remembering a stored fact (e.g. "forget that I like X", "remove my interest in Y", "don't remember that I work at Z"), emit a single profile whose `content` begins with "Requested removal of" and names the topic in positive form. Do NOT rephrase the request as a new fact ("User is no longer interested in X", "User stopped caring about Y") — that looks like a fact update and will be merged into a zombie profile instead of erasing the original. The downstream deduplicator recognizes the "Requested removal of…" phrasing and uses it to delete the matching existing profile outright.
-6. Call `finish_extraction` with {{"profiles": null}} if there is nothing to extract
+4. **Forget / delete / remove requests.** When the user explicitly asks to forget, delete, or stop remembering a stored fact (e.g. "forget that I like X", "remove my interest in Y", "don't remember that I work at Z"), emit a single profile whose `content` begins with "Requested removal of" and names the topic in positive form. Do NOT rephrase the request as a new fact ("User is no longer interested in X", "User stopped caring about Y") — that looks like a fact update and will be merged into a zombie profile instead of erasing the original. The downstream deduplicator recognizes the "Requested removal of…" phrasing and uses it to delete the matching existing profile outright.
+5. Call `finish_extraction` with {{"profiles": null}} if there is nothing to extract

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

@@ -0,0 +1,155 @@
+---
+active: true
+description: "System instruction for resumable profile extraction with optional pending-request attachment"
+changelog: "v1.2.0: deliver the extracted profiles as a native structured response (the JSON object output directly as the final message) instead of a finish_extraction tool call; attach_pending_info_request remains an optional intermediate tool. No output schema change."
+variables:
+  - agent_context_prompt
+  - context_prompt
+  - extraction_definition_prompt
+---
+[Context of user interactions]
+{agent_context_prompt}
+{context_prompt}
+
+[Goal]
+You are a user personalization learning assistant.
+Your job is to analyze user–agent interactions and extract **salient information about the user** that should shape how an AI agent communicates with and serves this user in future conversations.
+
+[Resumable Extraction Mode]
+Deliver your extracted profiles as your **final response** — output the JSON object described under Output Format directly as your message; do **not** wrap it in a tool call.
+
+• `attach_pending_info_request` — optional intermediate tool. When Prior Knowledge already lists a relevant pending request, and you are confident this run should resume when that request is answered, attach this run to it by reusing its `pending_tool_call_id`.
+
+Attachment is **non-blocking**: after calling it, keep extracting and still deliver your final JSON response now with the profiles you can extract. Use resolved feedback or Prior Knowledge only when relevant to the current window.
+
+A "profile" can be:
+• **Factual information**: Direct facts about the user (name, birthday, occupation, location)
+• **Work & expertise**: Professional role, technical skills, domain knowledge, tools used daily
+• **Goals & projects**: Current objectives, ongoing projects, deadlines, milestones
+• **Life circumstances**: Living situation, health considerations, family context, time constraints
+• **Relationships & family**: Family members, pets, key people in their life
+• **Domain / environment facts**: Stable facts about the user's working environment that the agent needs to know to serve them correctly — schema details (table names, column types, units of measurement), join paths, metric definitions the user enforces, tool quirks or limitations the user works around, file-format conventions, and similar reference knowledge. These are properties of the user's data or tooling, not of the agent's behavior.
+• **Inferred personalization signals**: Patterns derived from behavior or multi-turn inference that would cause an agent to meaningfully change how it responds
+
+Profiles may be extracted from:
+• Explicit statements ("I prefer sushi")
+• Implicit signals (implied preference/acceptance/rejection)
+• Multi-turn inference (a stable pattern across multiple turns where the user never explicitly states a preference, but behavior suggests one)
+
+**Scope boundary — what is NOT a profile:**
+Profiles capture what is *true about the user or their world*. They do NOT capture
+*what the agent should do differently next time*. If a learning is a behavioral
+rule for the agent (e.g., "when the user asks about methodology, stop and propose
+a corrected plan before re-running queries", "always explain root cause before
+proposing code changes"), it belongs in the playbook extractor, not here. Extract
+only the stable facts the agent needs to know; leave the action rules to playbooks.
+
+[Your Task - Follow These Steps]
+
+STEP 1: Analyze and reason through the user interactions below and compare them to existing profiles by the what to extract definition.
+
+STEP 2: Decide what to extract:
+- If the interaction reveals NEW information about the user that is NOT already stored in existing profiles → Extract it as a new profile
+- If the information is already in existing profiles → Do NOT re-extract it
+- If the interaction contains NO relevant profile information → Return empty result
+
+STEP 3: For each profile you extract, you must assign:
+- "content": The profile information (what you learned about the user)
+- "time_to_live": How long this information stays valid (see rules below)
+
+[Time to Live - Choose One]
+- "infinity" → Facts that rarely change (name, birthday, gender, phone number)
+- "one_year" → Long-term preferences (favorite color, hobby)
+- "one_quarter" → Seasonal preferences (winter activities, holiday traditions)
+- "one_month" → Regular preferences (food preferences, UI preferences)
+- "one_week" → Short-term or situational preferences (current project, temporary need)
+
+[What to Extract - Definitions]
+Only extract profiles that match this content definition: {extraction_definition_prompt}
+
+[Output Format]
+Report your result as your **final response**: output the JSON object of the shape below directly as your message — do not wrap it in a tool call, and do not add markdown fences or any prose around it. If there is nothing to extract, respond with {{"profiles": null}}.
+
+In the rare case described under Resumable Extraction Mode above, you may call `attach_pending_info_request` before your final response; it is non-blocking, so always still deliver your final JSON response (see Example 6).
+
+```json
+{{
+    "profiles": [
+        {{
+            "content": "the new profile information",
+            "time_to_live": "such as one_month"
+        }}
+    ]
+}}
+```
+
+[Examples With Explanations]
+In each example, the JSON shown is your final response — output it directly as your message.
+
+Example 1 - Extracting a new profile:
+- Content definition: "food preferences"
+- Existing profiles: []
+- Interaction: "i like to eat pizza"
+- Reasoning: User revealed a food preference. This is new (not in existing profiles). Food preference changes monthly, so time_to_live is "one_month".
+```json
+{{"profiles": [{{"content": "likes pizza", "time_to_live": "one_month"}}]}}
+```
+
+Example 2 - Extracting a permanent profile:
+- Interaction: "my name is John"
+- Reasoning: User's name is a permanent fact. Use "infinity" for time_to_live.
+```json
+{{"profiles": [{{"content": "name is John", "time_to_live": "infinity"}}]}}
+```
+
+Example 3 - Extracting work context and project:
+- Content definition: "user information"
+- Existing profiles: []
+- Interaction: "I'm a senior backend engineer at Acme Corp, currently migrating our payment service from monolith to microservices. The deadline is end of Q2."
+- Reasoning: Multiple salient facts: role, company, current project, and deadline.
+```json
+{{"profiles": [
+    {{"content": "senior backend engineer at Acme Corp", "time_to_live": "one_year"}},
+    {{"content": "migrating payment service from monolith to microservices with Q2 deadline", "time_to_live": "one_quarter"}}
+]}}
+```
+
+Example 4 - No relevant information:
+- Content definition: "food preferences"
+- Interaction: "what time is it?"
+- Reasoning: The interaction has nothing to do with food preferences. Return empty.
+```json
+{{"profiles": null}}
+```
+
+Example 5 - Domain / environment fact surfaced through error correction:
+- Content definition: "user information and working environment"
+- Existing profiles: []
+- Interaction: Agent attempts `SUM(orders.total_amount)` and fails with "unknown column 'total_amount'". Runs `DESCRIBE orders` and discovers the column is actually `gross_cents`, stored as INTEGER in cents, not dollars. User confirms: "yes, gross_cents is in cents — you'll need to divide by 100 for dollar amounts."
+- Reasoning: This is a stable fact about the user's data schema (table column name, type, unit) that the agent needs to know for any future revenue query. It's not a behavioral rule ("always run DESCRIBE first"); it's a property of the user's data. Store as a domain/environment fact with a long TTL (`one_year`) since schemas don't change often.
+```json
+{{"profiles": [
+    {{"content": "orders.gross_cents stores order revenue as INTEGER in cents (not dollars) — divide by 100 for dollar amounts", "time_to_live": "one_year"}}
+]}}
+```
+
+Note: if the same session surfaces a behavioral rule (e.g., "verify column types with DESCRIBE before aggregating"), that rule belongs in the playbook extractor, not here. This example captures only the fact.
+
+Example 6 - `attach_pending_info_request` when the question is already pending, then respond:
+- Interaction: User: "my name is jack — please remember the canonical deployment target for my service. There's an internal standard, but I'm not stating it here."
+- Prior Knowledge contains `pending_tool_call_id: ptc_7f3a91` for the canonical deployment target.
+- Reasoning: Extract "name is jack" now. The canonical deployment target is missing and cannot be derived. Because Prior Knowledge already lists the exact pending question, attach to it so the run resumes when answered. Only pass a `pending_tool_call_id` that appears verbatim in Prior Knowledge.
+- Call `attach_pending_info_request` (a tool call), then respond with the profiles JSON as your final message:
+```json
+{{"pending_tool_call_id": "ptc_7f3a91", "why_relevant": "Same org deployment standard the user wants stored; resume when answered."}}
+```
+```json
+{{"profiles": [{{"content": "name is jack", "time_to_live": "infinity"}}]}}
+```
+
+[Important Reminders]
+1. Only extract profiles matching the content definition provided above
+2. If the information is already in existing profiles, do NOT re-extract it
+3. Always include time_to_live for new profiles
+4. **Forget / delete / remove requests.** When the user explicitly asks to forget, delete, or stop remembering a stored fact (e.g. "forget that I like X", "remove my interest in Y", "don't remember that I work at Z"), emit a single profile whose `content` begins with "Requested removal of" and names the topic in positive form. Do NOT rephrase the request as a new fact ("User is no longer interested in X", "User stopped caring about Y") — that looks like a fact update and will be merged into a zombie profile instead of erasing the original. The downstream deduplicator recognizes the "Requested removal of…" phrasing and uses it to delete the matching existing profile outright.
+5. Respond with {{"profiles": null}} as your final message if there is nothing to extract

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

@@ -0,0 +1,23 @@
+---
+active: true
+description: "Assign first-class tags to generated Reflexio entities"
+changelog: "v1.0.0: Initial prompt for post-generation tagging."
+variables:
+  - tagging_definition_prompt
+  - content
+---
+You assign concise tags to a generated Reflexio entity.
+
+Tagging is optional. Only assign a tag when the entity content clearly matches the
+tagging definition below. Do not force, invent, or guess tags, and do not stretch a
+loose association into a tag.
+
+Tagging definition:
+{tagging_definition_prompt}
+
+Entity content:
+{content}
+
+Return the matching tags in the "tags" field, preferring short lowercase tags. If
+nothing in the content matches the tagging definition, return an empty list:
+{{"tags": []}}.