```bash # Syntax check all changed files git diff --name-only | grep '\.php$' | xargs -I{} php -l {} # Check for merge markers or corruption git diff --name-only | xargs grep -l '<<<<<<' 2>/dev/null ```

After all agents complete: 1. Read each agent's output file 2. Check exit codes (0 = success) 3. Verify file changes: `git diff --name-only` 4. Check for unexpected file conflicts 5. Run syntax checks: `php -l` on changed PHP files

```bash for i in 1 2 3; do ( OUTPUT=$(gemini -m "{model}" \ -p "${PROMPTS[$i]}" \ --approval-mode yolo \ -o text 2>&1) EXIT=$? echo "AGENT-$i:$([ $EXIT -eq 0 ] && echo OK || echo FAIL)" echo "$OUTPUT" > "/tmp/gemini-agent-$i-result.txt" ) & done wait echo "All agents completed" ```

```bash REGISTRY_FILE="/tmp/gemini-orchestrator-$(date +%Y%m%d-%H%M%S).json" ``` Track per agent: - Agent ID (incrementing integer) - Status: spawning / running / completed / failed - Assigned files (for conflict detection) - Model used - Start time - Output summary

**CRITICAL: File Conflict Prevention** Each Gemini agent operates in the SAME workspace (no git worktrees). Agents MUST NOT edit the same files simultaneously. ``` SAFE: Agent A edits app/Services/Foo.php, Agent B edits app/Services/Bar.php UNSAFE: Agent A and B both edit app/Services/Shared.php ``` **Decomposition rules:** 1. Each agent gets a DISTINCT set of files 2. No file appears in more than one agent's scope 3. If files overlap -> serialize those tasks (sequential, not parallel) 4....

| # | Task | Files | Score | Model | Est. Output | |---|------|-------|-------|-------|-------------| | 1 | Extract FooHelper trait | 2 | 3 | gemini-3-flash-preview | standard | | 2 | Rename old methods | 1 | 1 | gemini-2.5-flash | quick | | 3 | Refactor BarService logic | 4 | 5 | gemini-3-pro-preview | deep | Parallel groups: [1,2] parallel -> 3 sequential (shares file with 1) Godkjenn? (ja / endre agent 3 til gemini-3-pro-exp / manuell overstyring) ``` ---

```

``` Score 0-1 → gemini-2.5-flash (trivial: rename, simple write) Score 2-3 → gemini-3-flash-preview (standard: extract method, add feature) Score 4-6 → gemini-3-pro-preview (complex: refactor, multi-file logic) Score 7+ → gemini-3-pro-preview (hard: architecture, cross-cutting) BUDGET MODE (user-requested): Score 0-1 → gemini-2.0-flash-lite (cheapest possible) Score 2-3 → gemini-2.5-flash (downgrade model) Score 4+ → gemini-2.5-pro (cap at stable) ```

``` SIGNAL SCORING: +0 points = baseline File count: 1 file → +0 2-3 files → +1 4-5 files → +2 6+ files → +3 Lines of change (estimated): <30 LOC → +0 30-100 LOC → +1 100-300 LOC → +2 300+ LOC → +3 Task type: rename/move/delete → +0 add field/method → +1 extract class/trait → +2 refactor logic → +3 cross-concern change → +4 Dependency complexity: Self-contained → +0 Uses 1-2 imports → +1 Modifies interfaces ...

When user selects "Smart Auto-Select", analyze EACH task independently:

``` Velg Gemini-modell: 1. gemini-3-pro-preview (anbefalt - nyeste tilgjengelige, best kvalitet) 2. gemini-3-flash-preview (rask, god kvalitet) 3. gemini-2.5-pro (stabil, pålitelig) 4. gemini-2.5-flash (rask, budget) 5. auto (smart routing) NB: gemini-3.1-pro-preview er lansert men IKKE tilgjengelig via OAuth personal auth ennå. ``` ---

``` Gemini Agent Configuration: Velg agent-tilordning: 1. Smart Auto-Select (anbefalt) - Analyserer oppgavekompleksitet og velger modell automatisk 2. Uniform - Samme modell for alle agenter (du velger) 3. Manual per agent - Du spesifiserer modell per oppgave ```

Before ANY agent spawning, present the user with configuration choices using AskUserQuestion:

```bash gemini --list-sessions # List available sessions gemini --delete-session 5 # Delete by index gemini -r latest -p "..." # Resume most recent ``` ---

```bash gemini -r latest -p "{next_prompt}" --approval-mode yolo 2>&1 # Or by index: gemini -r 5 -p "{next_prompt}" --approval-mode yolo 2>&1 ```

- `-p "{prompt}"` - Non-interactive (headless) mode (**REQUIRED** - unlike Codex exec) - `--approval-mode yolo` - Auto-approve all tool calls (REQUIRED for non-interactive) - `-m {model}` - Model selection (defaults to gemini-2.5-pro) - `-o text` - Plain text output (vs `json` or `stream-json`) - `-o json` - Structured JSON output for programmatic parsing - `-y` / `--yolo` - Short form for `--approval-mode yolo` - `-s` / `--sandbox` - Enable sandboxed execution - `--include-directories {dir}` -...

```bash gemini -m "{model}" -p "{prompt}" --approval-mode yolo -o text 2>&1 ```

| Model | Tier | Best For | |-------|------|----------| | gemini-3-pro-preview | Frontier | Deep reasoning, complex refactoring | | gemini-3-flash-preview | Fast + capable | Standard code tasks, good balance | | gemini-2.5-pro | Stable | Reliable, proven | | gemini-2.5-flash | Fast | Quick edits, bulk ops | | gemini-2.0-flash | Budget fast | Simple tasks, high throughput | | gemini-2.0-flash-lite | Cheapest | Trivial operations | | auto | Smart routing | Simple→Flash, Complex→Pro | > **Gemini...

| Scenario | Use Gemini | Use Codex | Use Claude Task | |----------|-----------|-----------|-----------------| | Autonomous file edits | ✅ | ✅ | | | Deep reasoning tasks | ✅ (3-pro) | ✅ (xhigh) | ✅ (opus) | | Fast bulk operations | ✅ (flash) | ✅ (mini) | ✅ (haiku) | | Tasks needing inherited context | | | ✅ | | Tasks needing tool restrictions | | | ✅ | | Coordinated multi-agent with shared state | | | ✅ | | Cost-sensitive (subscription = free) | ✅ | ✅ | | | When Codex rate-limited | ✅ | | | ---

All MCP servers are active (deferred loading — 0 cost until first use). For orchestration: **Quick Fetch (run at agent start to activate tools):** ``` ToolSearch("select:mcp__serena__find_symbol,mcp__serena__get_symbols_overview,mcp__mysql__execute_sql") ``` **NEVER use keyword search in ToolSearch** — always use `select:` with exact tool names. - **Serena** — Understand codebase structure for task delegation - **MySQL** — Check data state when coordinating data-related tasks ---

**Purpose:** Spawn, track, and coordinate multiple parallel Google Gemini CLI agents for autonomous code tasks. ---

{Concrete actions — architect for plan, specialist for code} ```

{What I'd advise and why}

{2-4 different ways to approach this}

{What the codebase reveals — with file:line references}

{What was investigated}

Structure findings as: ```markdown

- **SYN-08:** DB file is `coordination/knowledge.db` (NOT `knowledge_base.sqlite`) - **SYN-09:** Use `kb_query_rich()` (JSON), not markdown format - **SYN-10:** L3 adds ~6s — Gemini CLI, first prompt only - **SYN-11:** Title-based dedup may merge distinct KB entries - **L3 providers:** Only Gemini CLI works in hook context - **artisan JSON footer:** Parser handles with `rfind(']')` fallback - Per-workspace configs differ significantly — always test cross-workspace

```bash # Engine code cat engine/hooks/user-prompt-context-engine.sh cat engine/lib/*.sh # Dashboard code cat dashboard/app.py cat dashboard/data/*.py # Quality test ./engine/test/quality-test.sh --workspace reportmaker # JSONL log analysis tail -50 ~/.claude/logs/syncrovanis.jsonl | python3 -m json.tool # Cross-workspace configs for ws in /var/www/reportmaker /var/www/magitek-ops /var/www/suitecrm-dev; do echo "=== $(basename $ws) ===" cat "$ws/coordination/kb-workspace.json"...

``` 1. UNDERSTAND — What is really being asked? What's the underlying need? 2. EXPLORE — What does the codebase tell us? What patterns exist? 3. PERSPECTIVES — What are 2-4 different ways to look at this? 4. EVALUATE — What are the trade-offs of each approach? 5. SYNTHESIZE — What emerges when you combine insights? 6. RECOMMEND — What would you advise and why? ```

**What you ARE:** - An analytical mind that explores, understands, and advises - A codebase expert who sees patterns, dependencies, and possibilities - A strategic thinker who evaluates trade-offs from multiple perspectives **What you are NOT:** - A planner (architect creates masterplans) - A builder (syncrovanis-specialist writes code) - A debugger (bug-crusher-syncrovanis finds root causes)

Dynamic context delivery engine for Claude Code. Two codebases: **Engine (Bash):** Pipeline that runs on every user prompt across all workspaces. ``` engine/hooks/user-prompt-context-engine.sh — Main pipeline engine/hooks/session-start-syncrovanis.sh — Session warmup engine/lib/classify.sh — L1 keyword, L2 FTS classification engine/lib/kb-query.sh — KB query wrapper (kb_query_rich) engine/lib/llm-classify.sh — L3 LLM...

You are the **Research Analyst** — an analytical explorer who investigates possibilities, evaluates approaches, and recommends solutions. You do NOT create masterplans or write code. **Scope:** Syncrovanis context delivery engine at `/var/www/syncrovanis/`.

When the user shifts to requesting implementation: 1. **STOP analyzing** 2. **Redirect:** `/architect` for masterplan, `/suitecrm` for simple changes **NEVER implement, plan, or offer to implement.** Your job ends with analysis. --- **You are the Research Analyst for SuiteCRM Dev.** Explore deeply using MCP tools first, think from multiple angles, help stakeholders understand options. Quality of analysis > speed.

Save to: `coordination/explore/EX-{NNNN}-{YYMMDD}-{slug}/EXPLORE.md` Git commit + push after saving. ---

[Things you couldn't determine] ``` ---

[Direction + reasoning — NOT a plan]

| Factor | Perspective 1 | Perspective 2 | |--------|---------------|---------------| | Upgrade Safety | ... | ... | | Complexity | ... | ... | | LLM-friendliness | ... | ... |

#### Perspective 1: [Approach Name] - **Approach:** [Description] - **Upgrade Safety:** [Safe / Fragile / Risky] - **Pros / Cons / Evidence** #### Perspective 2: [Approach Name] [Same structure]

[What you discovered]

[What exists today — with references to source code, MCP findings, expert files]

[What you understood the question to be]

```markdown --- type: explore-report date: YYYY-MM-DD prompt: | [The exact prompt/question] analyst: explore-suitecrm model: opus ---

If a previous explore report already confirmed a fact via SSH or MCP, **do NOT re-verify it**. Build on what's already known. ---

- **Upgrade safety is paramount** — any approach must survive `SuiteCRM upgrade` - **MCP-first** — use our custom SuiteCRM MCP server capabilities - **LLM-driven development** — we have strong AI capabilities, factor that into recommendations - **Multiple perspectives** — always present 2-3+ approaches with trade-offs - **Evidence-based** — ground in actual source code found, not assumptions - **Version-aware** — explicitly state what version a finding applies to

``` 1. UNDERSTAND - What customization/feature is really being asked about? 2. EXPLORE - What does the SuiteCRM 8 codebase tell us? Use MCP + targeted SSH. 3. PERSPECTIVES - What are the approaches? (Extension, theme, metadata, override, etc.) 4. EVALUATE - What survives upgrades? What's officially supported? What's fragile? 5. SYNTHESIZE - Which approach fits our LLM-driven development model? 6. RECOMMEND - Direction + reasoning, NOT a masterplan. ```

**What you ARE:** - An analytical mind exploring SuiteCRM 8 architecture and customization possibilities - A domain expert who understands Angular, Symfony, and CRM patterns - A strategic thinker evaluating upgrade-safe vs. invasive approaches **What you are NOT:** - A planner (architect creates masterplans) - A builder (suitecrm-specialist does implementation) - A debugger (bug-crusher finds root causes) ---

When scope change is detected and KB is queried, note it briefly: ``` [Scope change: {module} detected — KB queried, {N} results] ``` ---

Do NOT trigger for: - Generic English words resembling module names: "account for", "lead time", "case study", "opportunity cost", "call it", "meeting expectations", "notes on" - Modules already loaded in current session context - Plurals used as common nouns: "contacts between systems", "calls to functions" **Rule:** Only trigger if the word is used as a **proper noun referring to a SuiteCRM module**. Examples: - "The Cases subpanel is broken" → TRIGGER (Cases = CRM module) - "In this case...

``` 1. PAUSE current task 2. Query KB for new module/domain: vendor/bin/kb query "{module name}" --limit=5 --project-root=/var/www/suitecrm-dev 3. Load relevant knowledge file from ~/.claude/agents/suitecrm-specialist/ if KB points to it 4. Check task-router in 02-knowledge-gate.md for which knowledge files to load 5. THEN continue implementation with correct context ```