synabun 1.3.0

package/skills/synabun/modules/idea.md

@@ -0,0 +1,144 @@
+# Idea — Memory-Powered Brainstorming
+
+You are now in **brainstorming mode**. Your job is to loop through SynaBun's persistent memory, find surprising connections between disparate memories, and synthesize novel ideas the user hasn't considered.
+
+**Input topic**: $ARGUMENTS
+
+If the input topic is empty, you are in **freeform mode** — explore the full memory landscape and surface the most interesting cross-domain connections you can find.
+
+## CRITICAL: SynaBun MCP Tool Quirks
+
+- Make ALL SynaBun MCP calls **sequentially** (never in parallel — one failure cascades)
+- `remember` accepts `tags` and `importance` directly and returns the full UUID.
+- `reflect` requires the **FULL UUID** (e.g., `8f7cab3b-644e-4cea-8662-de0ca695bdf2`). Use the UUID returned by `remember`, or `recall` to find existing memories.
+
+## Process
+
+Execute these phases in order. Do NOT skip phases or combine them.
+
+---
+
+### Phase 1 — Landscape Survey
+
+1. Call `category_list` with format `tree` to see all memory categories and their hierarchy.
+2. Call `memories` with mode `stats` to understand the memory landscape (counts, categories, projects).
+3. If a topic was provided, identify which categories are most relevant AND which are most distant (distant = higher cross-pollination potential).
+4. If freeform mode, note the top 3 categories by memory count and the most underexplored category.
+
+**Output to user**: Brief summary of what you found — how many memories exist, which domains are richest, and your brainstorming strategy for the rounds ahead.
+
+---
+
+### Phase 2 — Multi-Round Recall
+
+Execute **5 sequential recall rounds**. Each round uses a different query strategy. After each round, briefly note what you found before moving to the next.
+
+**IMPORTANT**: Make each `recall` call with `limit: 5` and `min_score: 0.2`. Do NOT filter by project unless the user's topic is clearly project-specific.
+
+#### Round 1 — Direct
+- If topic given: `recall` with the topic as the query
+- If freeform: `recall` with query "recent important work decisions architecture" and `min_importance: 7`
+- **Goal**: Establish the core memory cluster around the topic
+
+#### Round 2 — Adjacent Exploration
+- Extract 2-3 key concepts from Round 1 results (themes, technologies, patterns mentioned)
+- `recall` with a query built from these adjacent concepts — things related to but distinct from the original topic
+- **Goal**: Expand the radius beyond the obvious
+
+#### Round 3 — Problem Space
+- `recall` with query focused on challenges, bugs, constraints, pain points related to the topic area
+- Example: if topic is "caching", query "cache problems bugs race condition invalidation challenges"
+- If freeform: query "bugs challenges problems pain points unresolved"
+- **Goal**: Find the friction — where problems exist, ideas are needed most
+
+#### Round 4 — Solution Patterns
+- `recall` with query focused on past solutions, patterns, architectures, approaches
+- Example: if topic is "caching", query "caching strategy pattern architecture optimization solution"
+- If freeform: query "solutions patterns architecture decisions implementations"
+- **Goal**: Find the building blocks — proven approaches that can be recombined
+
+#### Round 5 — Cross-Domain Surprise
+- Pick a category that is **unrelated** to the topic (from Phase 1 landscape)
+- `recall` with an abstract version of the topic, filtered to this distant category
+- Example: if topic is "real-time notifications" and distant category is "deals", query "real-time updates synchronization" with `category: "deals"`
+- If freeform: pick the least-explored category and query "interesting patterns approaches"
+- **Goal**: Force unexpected connections — this is where the most creative ideas come from
+
+After all 5 rounds, you should have **15-25 memory snippets** across different categories and domains.
+
+---
+
+### Phase 3 — Connection Mapping & Synthesis
+
+Now synthesize. Do this internally (thinking), then produce ideas.
+
+For each pair of memories from **different categories or rounds**:
+1. What do they have in common at an abstract level?
+2. What tension or contradiction exists between them?
+3. What gap does one fill that the other exposes?
+4. Could the approach from one be applied to the domain of the other?
+
+Generate **3-5 concrete ideas**. Prioritize:
+- **Cross-category connections** (e.g., a bug-fix pattern applied to a feature design)
+- **Gap-filling** (a problem memory without a matching solution memory)
+- **Pattern transfer** (a solution from domain A adapted to domain B)
+- **Contradiction resolution** (two memories that suggest opposite approaches — the synthesis is often the best idea)
+
+---
+
+### Phase 4 — Present Ideas
+
+Present each idea in this format:
+
+```
+## Brainstorm Results: [Topic or "Freeform Exploration"]
+
+### Idea 1: [Concise Title]
+**Concept**: [1-2 sentence description of the idea]
+
+**Reasoning chain**:
+- Started from [short-id] — [brief content] (category)
+- Connected to [short-id] — [brief content] (different category)
+- [Gap/tension/pattern identified]
+- Synthesis: [How combining these produces the idea]
+
+**Inspired by**: [short-id] (category), [short-id] (category), ...
+**Next steps**: [2-3 concrete actions to explore or implement this idea]
+
+---
+```
+
+After presenting all ideas, add a brief **"Threads to Pull"** section listing 2-3 additional directions that showed promise but weren't fully developed — seeds for future brainstorming sessions.
+
+---
+
+### Phase 5 — Capture
+
+After presenting ideas, ask the user:
+
+> "Want me to save any of these ideas to your SynaBun memory? I can store them in an `ideas` category so they persist across sessions."
+
+If the user says yes:
+
+1. Call `category_list` (flat format) to check if an `ideas` category already exists
+2. If not, call `category_create` with:
+   - `name`: "ideas"
+   - `description`: "Brainstormed features, experiments, and creative explorations"
+   - `parent`: the current project's parent category (e.g., "criticalpixel") — or no parent if no project match
+3. For each idea the user wants saved, call `remember` with:
+   - `content`: The full idea text (title + concept + reasoning chain + next steps)
+   - `category`: "ideas"
+   - `project`: current project name
+   - `importance`: 6 for speculative ideas, 7 for actionable ones
+   - `tags`: ["brainstorm", topic keywords]
+
+---
+
+## Guidelines
+
+- **Be genuinely creative** — don't just summarize memories. The value is in the *connections* between them that the user hasn't seen.
+- **Cite specific memories** — every idea must trace back to at least 2 memories. This is what makes it different from generic brainstorming.
+- **Embrace surprises** — Round 5 (cross-domain) often produces the best ideas. Give it weight.
+- **Quality over quantity** — 3 excellent ideas beat 5 mediocre ones.
+- **Stay grounded** — ideas should be actionable, not abstract philosophy. Each needs concrete next steps.
+- **Acknowledge limits** — if the memory landscape is thin (< 10 total memories), say so and suggest the user build up memories first before brainstorming.

package/skills/synabun/modules/memorize.md

@@ -0,0 +1,188 @@
+# Memorize — Convert Context to Persistent Memory
+
+You are now in **memorize mode**. Your job is to analyze the full conversation context leading up to the `/synabun memorize` invocation, distill it into a well-structured markdown memory, and store it in SynaBun for future recall.
+
+**Input**: $ARGUMENTS
+
+- If the input is empty → analyze the entire conversation context
+- If the input contains text → use it as a focus hint (e.g., "memorize the redis discussion" → focus on that topic within the conversation)
+
+## CRITICAL: SynaBun MCP Tool Quirks
+
+- Make ALL SynaBun MCP calls **sequentially** (never in parallel — one failure cascades).
+- `remember` accepts `tags` and `importance` directly and returns the full UUID.
+- `reflect` requires the **FULL UUID**. Use the UUID returned by `remember`, or `recall` to find existing memories.
+
+---
+
+## Process
+
+Execute these phases in order. Do NOT skip phases or combine them.
+
+---
+
+### Phase 1 — Context Analysis
+
+Analyze the ENTIRE conversation history available in your context window. Extract:
+
+1. **Core topic(s)**: What was the conversation primarily about?
+2. **Key decisions made**: Any architectural, design, or implementation choices
+3. **Problems discussed**: Bugs, issues, blockers, pain points
+4. **Solutions found**: Fixes, workarounds, patterns discovered
+5. **Files touched**: Any files that were read, edited, or created
+6. **Code patterns**: Notable code snippets, configurations, or commands
+7. **Open threads**: Unfinished work, TODOs, things to revisit
+8. **User preferences**: Any stated preferences about tools, approaches, workflows
+
+**Do NOT output anything to the user during this phase** — this is internal analysis only.
+
+---
+
+### Phase 2 — Draft Memory
+
+Compose the memory as a structured markdown document. Follow this template precisely:
+
+```markdown
+## Context: [Descriptive Title — 5-10 words capturing the essence]
+**Date**: [YYYY-MM-DD]
+**Project**: [detected project]
+**Branch**: [current git branch if detectable]
+
+### Summary
+[2-4 sentences: What was discussed, what was accomplished, what was decided. Be specific — mention actual function names, file paths, error messages, not vague descriptions.]
+
+### Key Details
+[Bulleted list of the most important specifics. Include:]
+- Decisions and their reasoning
+- Technical details that would be hard to rediscover
+- Configuration values, API endpoints, command invocations
+- Error messages and their root causes
+- Patterns or approaches chosen (and alternatives rejected)
+
+### Files Referenced
+[Bulleted list of file paths that were relevant, with brief annotation]
+- `path/to/file.ts` — [what was done or discussed about it]
+
+### Open Items
+[If any — things left unfinished, TODOs, follow-ups needed]
+- [ ] [description of unfinished work]
+
+### Commands & Snippets
+[If any notable commands or code snippets were part of the conversation]
+```bash or ```typescript etc.
+[the command or snippet]
+```
+```
+
+**Rules for the draft:**
+- **Be specific, not generic** — "Fixed race condition in price aggregation by adding mutex lock" not "Fixed a bug"
+- **Include actual values** — file paths, function names, error messages, config keys
+- **Preserve technical detail** — the memory should let future-you reconstruct context without re-reading the conversation
+- **Omit sections that don't apply** — if there were no open items, skip that section. If no commands were notable, skip that section.
+- **Keep it dense** — target 200-500 words. Long enough to be useful, short enough to be scannable.
+
+---
+
+### Phase 3 — Metadata Selection
+
+Determine the appropriate metadata for this memory:
+
+#### Category Selection
+1. Check if the conversation topic fits an existing child category under `conversations` by calling `category_list` with format `tree`.
+2. If the conversation has a clear specialized topic that doesn't fit existing children, consider creating a new child category under `conversations` — but only if it represents a genuinely distinct recurring topic (not a one-off).
+3. **Default**: Use `conversations` as the category. Most context memories belong here.
+
+#### Tags
+Generate 3-5 lowercase tags. Include:
+- The primary topic (e.g., "redis", "auth", "forum")
+- The type of work (e.g., "bug-fix", "feature", "refactor", "investigation", "architecture")
+- Key technologies or systems involved (e.g., "supabase", "next-js", "lexical")
+- Always include `"context-memorize"` as a tag to distinguish these from auto-indexed session memories
+
+#### Importance
+- **5**: Routine work, standard feature additions, minor fixes
+- **6**: Significant decisions, non-obvious solutions, multi-file changes
+- **7**: Architectural decisions, hard-won debugging sessions, critical path work
+- **8+**: Foundational decisions that affect the entire project
+
+#### Related Files
+Collect all file paths that were read, edited, or discussed. These enable the `sync` tool to detect staleness later.
+
+---
+
+### Phase 4 — Review & Confirm
+
+Present the draft to the user for review:
+
+```
+══════════════════════════════════════════
+       MEMORIZE CONTEXT
+══════════════════════════════════════════
+```
+
+Then output the full drafted memory content (from Phase 2).
+
+Then output the metadata:
+
+```
+──────────────────────────────────────────
+ Category:    [category]
+ Project:     [project]
+ Importance:  [N] — [brief justification]
+ Tags:        [tag1, tag2, tag3, ...]
+ Files:       [count] referenced
+──────────────────────────────────────────
+```
+
+Then use `AskUserQuestion`:
+
+- **Save as-is** — "Store this memory exactly as drafted"
+- **Edit first** — "I want to adjust the content or metadata before saving"
+- **Cancel** — "Don't save anything"
+
+**If user picks "Edit first":**
+Use `AskUserQuestion` to ask what they want to change:
+
+- **Edit content** — "Change the memory text (tell me what to modify)"
+- **Change importance** — "Adjust the importance level"
+- **Change tags** — "Modify the tags"
+- **Change category** — "Use a different category"
+
+After the user provides edits, incorporate them and re-present the updated draft. Loop until the user is satisfied or picks "Save as-is".
+
+---
+
+### Phase 5 — Store
+
+Once the user confirms:
+
+1. Call `remember` with:
+   - `content`: The final markdown memory text
+   - `category`: The selected category (default: `conversations`)
+   - `project`: The detected project
+   - `importance`: The determined importance level
+   - `tags`: The generated tags (always including `"context-memorize"`)
+   - `related_files`: Array of file paths referenced
+   - `source`: `"user-told"`
+
+2. Confirm storage to the user:
+
+```
+══════════════════════════════════════════
+ Memory stored successfully.
+ ID:    [short-id from returned UUID]
+ Category: [category]
+ Tags:  [tags]
+══════════════════════════════════════════
+```
+
+---
+
+## Guidelines
+
+- **Density over length** — A 300-word memory with specific details is worth more than a 1000-word one full of filler.
+- **The user's conversation IS the source** — don't invent details. Only memorize what was actually discussed.
+- **Focus hints matter** — if the user said `/synabun memorize the pricing discussion`, zoom in on that topic even if the conversation covered other things too.
+- **Dedup awareness** — if the conversation has already been indexed via compaction auto-store (a `conversations` memory with the same session ID exists), note this to the user and offer to either update the existing memory or create a supplementary one.
+- **Sequential MCP calls only** — never call two SynaBun tools in the same parallel batch.
+- **Full UUIDs always** — use the complete UUID from `remember` output, never shortened.