synabun 1.3.0 → 2.0.0-beta

package/skills/synabun/modules/changelog.md

@@ -10,9 +10,18 @@ You are now in **changelog mode**. Your job is to analyze the current session's
 ## 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.
+- `remember` requires `category` and `project` on every call, 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.
 
+## Runtime Compatibility
+
+- **Interactive choice prompt** means an interactive option card the user clicks — not plain text choices.
+  - **Claude Code (REQUIRED path):** `AskUserQuestion` is a deferred tool — its schema is not loaded by default. Before the first prompt in this skill, call `ToolSearch` with query `select:AskUserQuestion` to load it, then call `AskUserQuestion` with 2-4 options. NEVER write the choices as plain text — the sidepanel will render text as static markdown, not an interactive card.
+  - **OpenCode (REQUIRED path):** call the native `question` tool — the sidepanel renders it as an interactive card via the `/question.asked` event. NEVER write the choices as plain text.
+  - **Codex (REQUIRED path):** call `request_user_input` — the sidepanel renders it as an interactive card. NEVER write the choices as plain text.
+  - **Other runtimes:** only when no interactive tool exists, fall back to a concise plain-text multiple-choice question and wait for the user's reply.
+- **File operations** mean: use the runtime's available local file tools. In Claude environments that may be `Read` / `Write` / `Edit`; in Codex it may be shell reads plus `apply_patch` or equivalent editing tools.
+
 ---
 
 ## Process
@@ -106,7 +115,7 @@ Present the drafted entries to the user:
 
 Then output the full drafted entries exactly as they would appear in CHANGELOG.md — the `### Added/Fixed/Changed` sections with all bullet points.
 
-Then use `AskUserQuestion` with:
+Then use an interactive choice prompt with:
 
 - **Save as-is** — "Write these entries to CHANGELOG.md"
 - **Edit first** — "I want to adjust entries before saving"
@@ -124,11 +133,11 @@ Once the user confirms:
 
 1. Set the changelog path: `$PROJECT_ROOT/CHANGELOG.md`
 
-2. Check if the file exists by attempting to `Read` it.
+2. Check if the file exists by reading it with the runtime's available file tools.
 
 **If CHANGELOG.md does NOT exist:**
 
-Create a new file using the `Write` tool:
+Create a new file using the runtime's available file-editing tools:
 
 ```markdown
 # Project Changelog
@@ -151,7 +160,7 @@ Read the entire file, then determine the insertion point:
   - Insert a new `## YYYY-MM-DD` section immediately after the first `# ` title line (and any blank line after it), before any existing `## ` date entries.
   - Place all drafted entries under the new date header.
 
-Use the `Edit` tool for modifications to existing files.
+Use the runtime's available file-editing tools for modifications to existing files.
 
 After writing, confirm to the user:
 
@@ -176,7 +185,7 @@ Silently call `remember` with:
 - `tags`: `["changelog", "documentation", "session-summary"]`
 - `related_files`: `["CHANGELOG.md"]`
 
-Do NOT use `AskUserQuestion` here — auto-remember is mandatory per project rules.
+Do NOT use an interactive choice prompt here — auto-remember is mandatory per project rules.
 
 ---
 

package/skills/synabun/modules/idea.md

@@ -1,144 +1,148 @@
-# 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.
+# 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` requires `category` and `project` on every call, 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.
+
+## Runtime Compatibility
+
+- **Category management** means: use the runtime's available category tool surface, whether that is split helpers such as `category_list` / `category_create` or a unified `category` tool with actions like `list` / `create`.
+
+## Process
+
+Execute these phases in order. Do NOT skip phases or combine them.
+
+---
+
+### Phase 1 — Landscape Survey
+
+1. List categories in `tree` format to see the full memory hierarchy.
+2. Call `memories` with `action: "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. List categories in `flat` format to check if an `ideas` category already exists.
+2. If not, create it with the runtime's category-management tool using:
+   - `name`: "ideas"
+   - `description`: "Brainstormed features, experiments, and creative explorations"
+   - `parent`: the current project's parent category (e.g., "my-project") — 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

@@ -10,9 +10,18 @@ You are now in **memorize mode**. Your job is to analyze the full conversation c
 ## 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.
+- `remember` requires `category` and `project` on every call, 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.
 
+## Runtime Compatibility
+
+- **Interactive choice prompt** means an interactive option card the user clicks — not plain text choices.
+  - **Claude Code (REQUIRED path):** `AskUserQuestion` is a deferred tool — its schema is not loaded by default. Before the first prompt in this skill, call `ToolSearch` with query `select:AskUserQuestion` to load it, then call `AskUserQuestion` with 2-4 options. NEVER write the choices as plain text — the sidepanel will render text as static markdown, not an interactive card.
+  - **OpenCode (REQUIRED path):** call the native `question` tool — the sidepanel renders it as an interactive card via the `/question.asked` event. NEVER write the choices as plain text.
+  - **Codex (REQUIRED path):** call `request_user_input` — the sidepanel renders it as an interactive card. NEVER write the choices as plain text.
+  - **Other runtimes:** only when no interactive tool exists, fall back to a concise plain-text multiple-choice question and wait for the user's reply.
+- **Category management** means: use the runtime's available category tool surface, whether that is split helpers such as `category_list` / `category_create` or a unified `category` tool with actions like `list` / `create`.
+
 ---
 
 ## Process
@@ -88,7 +97,7 @@ Compose the memory as a structured markdown document. Follow this template preci
 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`.
+1. Check if the conversation topic fits an existing child category under `conversations` by listing categories in `tree` format.
 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.
 
@@ -134,14 +143,14 @@ Then output the metadata:
 ──────────────────────────────────────────
 ```
 
-Then use `AskUserQuestion`:
+Then use an interactive choice prompt:
 
 - **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:
+Use an interactive choice prompt to ask what they want to change:
 
 - **Edit content** — "Change the memory text (tell me what to modify)"
 - **Change importance** — "Adjust the importance level"

package/skills/synabun/modules/schedule.md

@@ -0,0 +1,198 @@
+# Schedule — Conversational Schedule Creation
+
+You are in **schedule mode**. The user wants to create a recurring SynaBun schedule with minimal friction. You greet once, let the user describe the automation in plain language, **infer everything you can**, ask **only** for genuine gaps (0–2 quick cards), confirm once, then create the loop-template + schedule (and a group if asked) in **one shot** via REST. The Schedules Studio refreshes itself over WebSocket — no reload needed.
+
+**Input hint**: $ARGUMENTS (optional free-text goal — may be empty).
+
+---
+
+## CRITICAL — Tool Quirks
+
+- All SynaBun MCP calls run **sequentially** (never parallel — one failure cascades).
+- `remember` requires `category` and `project` on every call, accepts `tags` + `importance` directly, and returns the full UUID; `reflect` needs the FULL UUID.
+- **Interactive choice prompt** = a clickable option card, never plain text:
+  - **Claude Code (REQUIRED):** `AskUserQuestion` is deferred — call `ToolSearch` with `select:AskUserQuestion` **before the first card**, then `AskUserQuestion` (2–4 options, ≤4 questions per card).
+  - **OpenCode:** native `question` tool. **Codex:** `request_user_input`. Never write choices as plain text.
+- **Stop-hook rule:** emit a card **alone** — never chain `Bash`/`Write` in the same turn as an `AskUserQuestion`; wait for the answer first.
+
+## CRITICAL — Model-Override Safety Rules (read before any write)
+
+These exist because group-level launch overrides historically clobbered per-schedule models. Follow them exactly so the schedule stays steerable:
+
+1. Write `model` and `profile` at the **schedule top level** in the POST body — that is exactly where the runtime reads them (`cliModel = schedule.model || group.model || template.model`).
+2. **Do NOT send `codexAccountId`** on a schedule or template unless the user explicitly named a ChatGPT/OpenAI account. An account only pins `CODEX_HOME`; it never selects the model and only adds confusion.
+3. **Do NOT create a group with `profile`/`model`/`effort`/`codexAccountId` set, and never set a group's launch fields,** unless the user explicitly wants *every* schedule in that group to share one model. Create groups with **name + color only**.
+4. Always choose a `model` that exists in the profile's option list (see the table below) so the Studio shows it pre-selected and the user can change it later.
+
+---
+
+## API (use `Bash` curl) — base `http://localhost:3344`
+
+| Endpoint | Method | Purpose |
+|----------|--------|---------|
+| `/api/loop/templates` | GET / POST | List / create automation templates |
+| `/api/schedules` | GET / POST | List / create schedules |
+| `/api/schedule-groups` | GET / POST | List / create groups |
+
+All bodies + responses are JSON. Capture the returned `id` from each POST.
+
+**Accepted fields (never invent others):**
+- **Template** — required `name`, `task`. Optional: `description, context, iterations(=10), maxMinutes(=30), usesBrowser, icon(=🔄), category(=custom), profile, model, effort, mcpProfile, folderId, codexAccountId`. Server generates `id`.
+- **Schedule** — required `name`, `templateId`, `cron` (exactly 5 whitespace fields). Optional top-level launch overrides: `profile, model, effort, mcpProfile, usesBrowser, codexAccountId`; plus `groupId, timezone, enabled, dayThemes, overrides`. Only `{iterations, maxMinutes}` go inside `overrides{}`.
+- **Group** — required `name`. Optional `color`. Returns `id` = `sg_…`.
+
+**Vocabularies:**
+- CLI profiles: `claude-code`, `codex`, `gemini`, `opencode`.
+- Default model per profile: `claude-code → claude-sonnet-4-6` · `codex → gpt-5.4-mini` · `gemini → gemini-2.5-pro` · `opencode → null` (last-used).
+- Categories (only these): `social`, `productivity`, `monitoring`, `custom`.
+- Icon keys: `twitter, x, instagram, facebook, linkedin, tiktok, youtube, whatsapp, discord, search, research, chart, mail, globe, monitor, code, pencil, chat, refresh, brain, clock, claude, openai, gemini, leonardo, pin, sparkle`.
+
+---
+
+## Phase 0 — Quick Boot (no card)
+
+Sequentially, quietly:
+1. `recall` query `"schedule loop template cadence platform"` `limit:5` — surface reusable patterns/templates.
+2. One `Bash` block fetching all three lists for inference + dedup:
+   ```bash
+   curl -s http://localhost:3344/api/loop/templates;   echo;
+   curl -s http://localhost:3344/api/schedule-groups;  echo;
+   curl -s http://localhost:3344/api/schedules
+   ```
+   Cache as `$TEMPLATES`, `$GROUPS`, `$SCHEDULES`.
+3. Detect timezone: `readlink /etc/localtime | sed -E 's|.*/zoneinfo/||'` — fallback `America/Sao_Paulo`.
+
+Then: if `$ARGUMENTS` already describes a goal, skip the greeting and go to **Phase 1**. Otherwise print exactly one line and **stop, awaiting the user's free-text reply**:
+
+> Sure — what do you need scheduled?
+
+## Phase 1 — Capture & Infer (no card)
+
+Read the user's free-text description and infer **every** field using the heuristics table below — this is plain reasoning, not a question:
+- **name** — short, human (e.g. "CP GSC Daily Indexing").
+- **template** — fuzzy-match the goal against `$TEMPLATES` (name+description+task). Strong match → **reuse** its `templateId`, create no template. Else draft a new template `task` block internally: goal sentence, platform/context, output rules, and a closing instruction telling the loop AI to `remember` its result each run.
+- **usesBrowser, icon, category** — from platform/intent cues.
+- **cron** — from the cadence phrase.
+- **profile / model** — default `claude-code` / `claude-sonnet-4-6` unless the text implies a CLI (e.g. "use Codex", "cheap/fast model") or an existing group/template convention says otherwise.
+- **effort** — default unset (off).
+- **group** — if the user names an existing group, map to its `groupId`. If they ask for a new group, plan a create with **name + color only**. If unmentioned → `groupId: null` (Ungrouped).
+
+Hold the three draft payloads in memory.
+
+## Phase 2 — Targeted Gaps (0–2 cards, conditional)
+
+Fire an interactive card **only** for genuinely ambiguous/critical fields. **At most one card**, bundling up to ~3 questions inside it. Skip this phase entirely when you can infer confidently. Ask only when:
+- **Cadence** — no time/frequency cue at all in the text.
+- **Platform/Browser** — the task clearly needs a site but none is named.
+- **Profile/Model** — the user signalled the model matters but didn't name one.
+- **Group** — ambiguous between an existing group and ungrouped.
+
+First option of every question is the recommended one (append " (Recommended)"). Emit the card alone; wait.
+
+## Phase 3 — Single Confirm Card (the only guaranteed card)
+
+One interactive card. Question text (use `\n` line breaks):
+
+```
+Ready to create:
+
+Name: <name>
+Automation: <template name> (<new|reuse>)
+Cron: <expr>  (<human description>)
+Group: <group name|Ungrouped>
+CLI: <profile> · Model: <model> · Think: <effort>
+Browser: <yes|no>
+
+Create it?
+```
+Header "Confirm" · options (single-select): **Create it (Recommended)** · **Tweak it** ("change a field first") · **Cancel**.
+- "Tweak it" → ask one open follow-up for which field, patch the draft, re-render this card.
+- "Cancel" → stop; tell the user nothing was created.
+
+## Phase 4 — Execute (one shot, sequential)
+
+In dependency order. After each curl, if the response is non-2xx or contains `error`, stop and surface it via a retry/cancel card.
+
+**4a. Group — only if the user wants a NEW group** (name + color only — Safety Rule 3):
+```bash
+curl -s -X POST http://localhost:3344/api/schedule-groups \
+  -H 'Content-Type: application/json' \
+  -d '{"name":"<group name>","color":"#4fc3f7"}'
+```
+Capture `id` → `$GROUP_ID`.
+
+**4b. Template — only if NOT reusing one:**
+```bash
+curl -s -X POST http://localhost:3344/api/loop/templates \
+  -H 'Content-Type: application/json' \
+  -d '{"name":"<name>","description":"<one-line>","task":"<full task block>","iterations":<n|10>,"maxMinutes":<n|30>,"usesBrowser":<true|false>,"icon":"<icon>","category":"<social|productivity|monitoring|custom>","profile":"<profile>","model":"<model>","effort":<"off"|null>,"mcpProfile":<"full"|null>}'
+```
+Capture `id` → `$TEMPLATE_ID`. (No `codexAccountId` unless the user named one.)
+
+**4c. Schedule — always:**
+```bash
+curl -s -X POST http://localhost:3344/api/schedules \
+  -H 'Content-Type: application/json' \
+  -d '{"name":"<name>","templateId":"<$TEMPLATE_ID|reused id>","cron":"<5-field>","timezone":"<IANA>","enabled":true,"groupId":<"$GROUP_ID"|"<existing>"|null>,"profile":"<profile>","model":"<model>","effort":<"off"|null>,"usesBrowser":<true|false>,"overrides":{"iterations":<n>,"maxMinutes":<n>},"dayThemes":{}}'
+```
+Rules baked in: `model`/`profile` **top level**; `{iterations,maxMinutes}` in `overrides`; **no `codexAccountId`** unless explicitly requested.
+
+## Phase 5 — Remember (one MCP call)
+
+`remember` `category:"schedules"` (if missing, `category` action `create` child under parent `synabun`), `project:"synabun"`, `importance:6`, `tags:["schedule","<platform/topic>","conversational-created"]`, content = 4–6 lines: name, template id, schedule id, cron, group, profile/model, date.
+
+## Phase 6 — Done (one line)
+
+> ✓ Schedule **`<name>`** created (`<model>`, `<cron-human>`). The Schedules Studio refreshed — open **Automations → Schedules** to view or change any field; the model is editable per-schedule there.
+
+---
+
+## Inference Heuristics (free-text cue → fields)
+
+| Cue (case-insensitive) | icon | category | usesBrowser |
+|---|---|---|---|
+| twitter / tweet / x.com / @handle | `twitter` | social | true |
+| instagram / ig / reels | `instagram` | social | true |
+| facebook / fb / fb group | `facebook` | social | true |
+| linkedin / li | `linkedin` | social | true |
+| tiktok | `tiktok` | social | true |
+| youtube / video upload | `youtube` | social | true |
+| whatsapp · discord | `whatsapp`·`discord` | social | true |
+| google / gsc / search console / indexing / seo | `globe` | productivity | true |
+| email / gmail / inbox | `mail` | productivity | false (unless web UI) |
+| research / scrape / lead / discover / monitor signals | `research`/`search` | productivity | true if a site is opened |
+| write article / publish / blog / generate post/report | `pencil`/`globe` | productivity | depends on publish target |
+| watch / alert me / check status / uptime / monitor X | `monitor`/`chart` | monitoring | false unless a page is checked |
+| code / repo / build / PR / commit / deploy | `code` | productivity | false |
+| anything unclear | `refresh` | custom | false |
+
+**Browser rule:** `true` whenever the task must open a website/app (social, GSC, any UI); `false` for pure-LLM / API / filesystem / shell tasks.
+
+**Cadence phrase → cron:**
+
+| Phrase | cron |
+|---|---|
+| every morning / daily ~9am | `0 9 * * *` |
+| twice a day | `0 9,18 * * *` |
+| 3× daily | `0 9,14,19 * * *` |
+| every hour | `0 * * * *` |
+| every 3 hours | `0 */3 * * *` |
+| every N hours | `0 */N * * *` |
+| weekdays at 9 | `0 9 * * 1-5` |
+| weekly Monday 9am | `0 9 * * 1` |
+
+Always validate a custom cron has exactly 5 whitespace fields; re-ask cadence only if invalid.
+
+---
+
+## Failure Handling
+
+- HTTP non-2xx → one card: **Retry** · **Edit and retry** · **Cancel**.
+- Bad cron → re-ask cadence only; do not advance.
+- Network down → "Neural Interface unreachable on `:3344` — is the dev server running?" then stop.
+
+## Guidelines
+
+- **≤3 stop-the-turn cards total** (optional Phase 2, the Phase 3 confirm, plus at most one error/tweak). Default to inference over asking.
+- Never invent template/schedule fields; always quote IDs; IANA timezones only (no "EST").
+- Re-state the Model-Override Safety Rules to yourself before Phase 4: schedule `model`/`profile` top-level; no `codexAccountId` unless named; groups are name+color only unless the user wants a shared group model.