@hailer/mcp 1.2.0 → 1.3.9

package/.claude/agents/agent-hailer-helper.md

@@ -0,0 +1,118 @@
+---
+name: agent-hailer-helper
+description: Onboarding assistant for new Hailer users - provides contextual UI guidance
+model: haiku
+tools: mcp__hailer__list_workflows, mcp__hailer__list_workflows_minimal, mcp__hailer__get_workflow_schema, mcp__hailer__list_workflow_phases, mcp__hailer__list_activities, mcp__hailer__show_activity_by_id, mcp__hailer__create_activity, mcp__hailer__update_activity, mcp__hailer__count_activities, mcp__hailer__search_workspace_users, mcp__hailer__list_my_discussions, mcp__hailer__fetch_discussion_messages, mcp__hailer__fetch_previous_discussion_messages, mcp__hailer__join_discussion, mcp__hailer__leave_discussion, mcp__hailer__add_discussion_message, mcp__hailer__invite_discussion_members, mcp__hailer__get_activity_from_discussion, mcp__hailer__create_insight, mcp__hailer__preview_insight, mcp__hailer__get_insight_data, mcp__hailer__update_insight, mcp__hailer__remove_insight, mcp__hailer__list_insights, mcp__hailer__upload_files, mcp__hailer__download_file, mcp__hailer__set_user_role, mcp__hailer__list_workflow_permissions, mcp__hailer__grant_workflow_permission, mcp__hailer__revoke_workflow_permission, mcp__hailer__check_user_permissions, mcp__hailer__install_workflow, mcp__hailer__remove_workflow, mcp__hailer__update_workflow_field, mcp__hailer__test_function_field, mcp__hailer__get_workspace_balance, mcp__hailer__core_init
+skills:
+  - hailer-ui-guide
+---
+
+<identity>
+I am a friendly assistant helping new Hailer users navigate the platform. I understand the UI deeply and give specific, actionable instructions like "click the blue Save button in the bottom right corner".
+</identity>
+
+<handles>
+- Explaining where to click and what buttons do
+- Guiding users through creating, editing, moving activities
+- Explaining Hailer concepts (workflow, phase, activity, field)
+- Troubleshooting "I can't find/see/do X" problems
+- Teaching users how Hailer works, not just giving commands
+</handles>
+
+<context-format>
+User context is provided as JSON with their current location and state:
+
+```typescript
+interface AIHelperContext {
+  location: {
+    section: 'activities' | 'discussions' | 'events' | 'feed' | 'people' | 'settings' | 'apps' | 'home';
+    url: string;
+  };
+  user: {
+    id: string;
+    name: string;
+    role: 'admin' | 'user' | 'guest';
+    workspaceId: string;
+    workspaceName: string;
+  };
+  view?: {
+    mode: 'kanban' | 'table' | 'calendar' | 'timeline' | 'map' | 'list';
+    workflowId: string;
+    workflowName: string;
+    phases: { id: string; name: string; position: number }[];
+  };
+  sidenav?: {
+    open: boolean;
+    type: 'activity' | 'discussion' | 'event' | 'user' | null;
+    mode: 'view' | 'edit' | 'create';
+    activeTab: 'detail' | 'participants' | 'discussion' | 'files' | 'location' | 'linkedFrom' | 'options' | null;
+    activity?: { id: string; name: string; phaseId: string; phaseName: string };
+    buttons: ('save' | 'cancel' | 'edit' | 'delete' | 'join')[];
+  };
+}
+```
+</context-format>
+
+<response-style>
+## How to respond
+
+**Be specific:** "Click the Save button in the bottom right" not "save the activity"
+
+**Reference visible elements:** Use context to mention what user can see:
+- If `sidenav.buttons` includes 'save' → "Click the Save button you see at the bottom"
+- If `view.phases` has data → "Drag to the '{phaseName}' column on the right"
+
+**Explain concepts simply:**
+- Phase = "column on the kanban board, like stages of work"
+- Activity = "a card or task in your workflow"
+- Workflow = "the whole board with all its columns"
+
+**One step at a time:** Don't overwhelm with long instructions
+
+**Be encouraging:** "Great question!" "That's easy to do"
+</response-style>
+
+<examples>
+## Example interactions
+
+**User asks:** "How do I close this deal?"
+**Context:** `view.workflowName: "Sales", sidenav.activity.phaseName: "Negotiation", view.phases: [{name:"New"}, {name:"Qualified"}, {name:"Negotiation"}, {name:"Closed Won"}, {name:"Closed Lost"}]`
+
+**Response:** "To close the deal, drag this card to the 'Closed Won' column on the right. Or click the phase badge at the top of this panel and select 'Closed Won' from the dropdown."
+
+---
+
+**User asks:** "Where do I save?"
+**Context:** `sidenav.mode: "edit", sidenav.buttons: ["save", "cancel"]`
+
+**Response:** "Click the blue 'Save' button in the bottom right corner of the panel. You'll see it next to the 'Cancel' button."
+
+---
+
+**User asks:** "I can't see any workflows"
+**Context:** `user.role: "user", location.section: "activities"`
+
+**Response:** "You might not have access to any workflows yet. Ask your workspace admin to add you to a workflow. They can do this in the workflow settings under 'Permissions'."
+
+---
+
+**User asks:** "What is a phase?"
+**Context:** `view.mode: "kanban", view.phases: [{name:"New"}, {name:"In Progress"}, {name:"Done"}]`
+
+**Response:** "Phases are the columns you see on this board - 'New', 'In Progress', and 'Done'. Think of them as stages of work. When a task moves forward, you drag it to the next column. It's like moving a sticky note across a whiteboard!"
+</examples>
+
+<rules>
+1. ALWAYS use context to give specific instructions
+2. NEVER say "go to settings" without checking user.role is admin
+3. ALWAYS mention visible buttons/elements from context
+4. Use phase names from context, not generic examples
+5. If user seems stuck, ask clarifying question
+6. Keep responses short - max 2-3 sentences unless explaining a concept
+7. Output conversational text, NOT JSON
+</rules>
+
+<protocol>
+Input: User question + AIHelperContext JSON
+Output: Friendly, specific guidance in plain text
+</protocol>

package/.claude/commands/debug-squad.md

@@ -1,303 +1,26 @@
 ---
 description: Parallel investigation squad for diagnosing bugs and incidents
 argument-hint: "bug or incident description"
-allowed-tools: Task, Bash, Read
+allowed-tools: Workflow, Bash, Read, Agent
 ---
-
 # Debug Squad
 
-Parallel investigation squad: diagnose bugs by examining data state, query patterns, code logic, and test reproduction simultaneously.
-
-**Roles:**
-- **Data Reader** - Data state (check relevant activities, field values, phases, linked records)
-- **SQL Insights** - Query patterns (is this isolated or widespread? run insights to find anomalies)
-- **Code Reviewer** - Code review (logic errors, missing validations, race conditions)
-- **Test Runner** - Test reproduction (create failing test to isolate the bug)
-
-**Goal:** $ARGUMENTS
-
-## Protocol
-
-### Step 1: Parse Bug Description
-
-Extract from `$ARGUMENTS`:
-- What is the reported issue?
-- Which workflow/activities/features are affected?
-- When was it first noticed?
-- What's the impact (severity)?
-
-Set `iteration = 1` and `max_iterations = 2`.
-
-### Step 2: Launch All 4 Agents in Parallel
-
-Spawn all agents simultaneously using multiple Task tool calls in a single message:
-
-**Data Reader:**
-```
-Task(prompt="Load sdk-ws-config-skill for understanding workflow and data structures.\n\nInvestigate the data state for this bug: $ARGUMENTS.\n\nYour job:\n1. Identify the affected workflow(s) and activities\n2. Look up the relevant activity records, field values, phases\n3. Check linked activities and relationships\n4. Compare expected vs actual data state\n5. Report any anomalies, missing data, or unexpected values\n\nReturn:\n- What the data SHOULD look like\n- What it ACTUALLY looks like\n- Which fields/relationships are affected")
-```
-
-**SQL Insights:**
-```
-Task(prompt="Load sdk-insight-queries skill for data pattern analysis.\n\nFind patterns for this bug: $ARGUMENTS.\n\nYour job:\n1. Run insight queries to determine: is this isolated to one activity or widespread?\n2. Query for similar data anomalies across the workflow\n3. Look for patterns: does it affect specific phases, teams, date ranges, field values?\n4. Check for recent changes that could correlate with the bug\n\nReturn:\n- Is this isolated or widespread? (scope)\n- Pattern: what data characteristics trigger it?\n- How many records/activities affected?\n- Timeline: when did anomalies start appearing?")
-```
-
-**Code Reviewer:**
-```
-Task(prompt="Review the code for this bug: $ARGUMENTS.\n\nYour job:\n1. Identify the relevant code sections (workflow logic, activity creation, field updates, phase transitions)\n2. Inspect for logic errors, missing validations, race conditions, null checks\n3. Look for assumptions that might break in edge cases\n4. Check for recent changes that could have introduced the bug\n\nReturn:\n- Suspected code sections with issues\n- Specific logic problems (race conditions, wrong field access, missing validation)\n- Edge cases not handled\n- Security implications if any")
-```
-
-**Test Runner:**
-```
-Task(prompt="Load testing-patterns skill for writing focused tests.\n\nCreate a failing test for this bug: $ARGUMENTS.\n\nYour job:\n1. Write a minimal test that reproduces the bug\n2. Set up the preconditions (data state, workflow, etc)\n3. Execute the action that triggers the bug\n4. Assert the bug is present (test FAILS with current code)\n5. Do NOT fix the bug - just demonstrate it\n\nReturn:\n- The failing test code\n- What the test proves about the bug\n- Failure output showing the bug is real")
-```
-
-If `$ARGUMENTS` contains `--skip-data`, skip Data Reader.
-If `$ARGUMENTS` contains `--skip-queries`, skip SQL Insights.
-
-### Step 3: Collect Results and Synthesize Root Cause
-
-Wait for all agents to complete. Aggregate findings:
-
-**From Data Reader:** What data is wrong?
-**From SQL Insights:** How widespread is it? What pattern triggers it?
-**From Code Reviewer:** What code is broken?
-**From Test Runner:** Can we reproduce it consistently?
-
-Look for convergence:
-- Does data anomaly match code logic error?
-- Does Code Reviewer's suspected code section align with SQL Insights' pattern?
-- Does Test Runner's test reproduce the exact issue Data Reader found?
-
-If **clear root cause** emerges → proceed to Step 4 (report).
-
-If **inconclusive** (no agent found clear cause OR agents disagree):
-- If `iteration < max_iterations`: Increment `iteration`, go to **Step 2b** (narrow scope)
-- If `iteration >= max_iterations`: Proceed to Step 4 with partial findings
-
-### Step 2b: Re-Investigation (Narrowed Scope)
+Parallel root-cause investigation via the native Workflow tool: four independent lenses, then convergence.
 
-If first iteration was inconclusive, re-run agents with narrowed focus:
+**Bug:** $ARGUMENTS
+Flags: `--skip-data` (no workspace data lens), `--skip-queries` (no SQL lens).
 
-```
-Task(prompt="Load sdk-ws-config-skill for deep data investigation.\n\nRe-investigate (iteration [iteration]): $ARGUMENTS\n\nBased on initial findings:\n[SUMMARIZE WHAT FIRST PASS FOUND]\n\nNarrow your focus to: [MOST LIKELY AFFECTED AREA]\n\nDig deeper into the data state. Look for subtle issues.")
-```
+## Orchestration
 
-Similar narrowed prompts for SQL Insights, Code Reviewer, Test Runner agents.
+Parse the bug description (what, which workflow/feature, since when, severity). Then author a Workflow script (this command is your opt-in to call the Workflow tool) running four lens agents in parallel, each returning `{ findings, suspectedCause, confidence }`:
 
-### Step 4: Report
-
-```markdown
-## Debug Squad Investigation
-
-### Summary
-**Bug:** [Description]
-**Iterations:** [count] of [max_iterations]
-**Root Cause Status:** IDENTIFIED / INCONCLUSIVE
-
----
-
-### Data Reader
-**Affected Records:** [count/scope]
-- Expected state: [description]
-- Actual state: [description]
-- Anomalies found: [list]
-
-### SQL Insights
-**Scope:** Isolated / Widespread (X records affected)
-**Pattern:** [What triggers the bug]
-**Timeline:** [When did it start]
-- Similar anomalies detected: [yes/no, details]
-
-### Code Reviewer
-**Suspected Code:** [files and line numbers]
-**Issues Found:**
-- [Issue 1]: [file:line] - [description]
-- [Issue 2]: [file:line] - [description]
-**Risk Level:** [LOW/MEDIUM/HIGH]
-
-### Test Runner
-**Test Status:** CREATED / FAILED TO REPRODUCE
-**Reproducibility:** Consistent / Intermittent / Cannot reproduce
-- Test file: [path]
-- Failure output: [snippet]
-
----
-
-### Root Cause Analysis
-[Synthesize findings from all 4 agents]
-
-**Primary Cause:** [What's broken]
-**Contributing Factors:** [Secondary issues]
-**Why It Happens:** [Mechanism]
-
-### Recommended Fix
-[Based on root cause, what needs to be fixed]
-- File: [path]
-- Change: [description]
-- Rationale: [why this fixes it]
-
-### Next Steps
-1. [Fix applied by code reviewer/code editor]
-2. [Test to verify fix]
-3. [Deploy and monitor]
-```
-
-If any agent fails or times out, report partial results, note which failed, and offer to re-run individually.
-
-## Options
-
-| Flag | Effect |
-|------|--------|
-| `--skip-data` | Skip Data Reader (when data investigation not needed) |
-| `--skip-queries` | Skip SQL Insights (when pattern analysis not needed) |
-| `--bg` | Run all agents in background mode |
-| `--debate` | Debate mode: competing hypotheses instead of domain-split investigation |
-
-If `--bg` is present, launch all agents with `run_in_background: true` and tell the user they'll be notified when complete.
-
----
+- **Data state** — what does the affected data actually look like? Read `workspace/enums.ts` (via the agent, not main context) for IDs, then MCP `list_activities` / `show_activity_by_id` on affected records. Compare expected vs actual field values, phases, links.
+- **Scope via SQL** — isolated or widespread? MCP `run_insight` with ad-hoc queries (sources + query): count affected records, correlate by phase/team/date-range/field value, find when anomalies started. Timestamps in insights are SECONDS.
+- **Code logic** — read the relevant source: logic errors, missing validation, race conditions, unhandled edge cases, recent changes (`git log -p` on suspect files).
+- **Reproduction** — write a minimal failing test that demonstrates the bug (vitest). Do NOT fix it; the test proves the diagnosis.
 
-## Debate Mode (`--debate`)
-
-When `--debate` flag is present, the squad switches from domain-split investigation to **competing hypothesis investigation**. Instead of each agent checking their domain, agents are assigned competing theories and must find evidence for/against their hypothesis.
-
-### How It Differs from Normal Mode
-
-| Aspect | Normal Mode | Debate Mode |
-|--------|-------------|-------------|
-| Assignment | Each agent checks their domain (data, queries, code, tests) | Each agent investigates a specific hypothesis |
-| Evidence | Agents report what they find in their area | Agents argue FOR their hypothesis using any evidence |
-| Synthesis | Look for convergence across domains | Compare evidence strength, pick winner |
-| Best for | Well-scoped bugs with clear domain | Ambiguous problems with multiple plausible causes |
-
-### Debate Protocol
-
-**Replaces Steps 2-3 of the normal protocol.**
-
-#### Step D1: Generate Hypotheses
-
-Analyze the problem description and generate **2-3 competing hypotheses** about the root cause. Each hypothesis should be:
-- **Specific**: Not "something is wrong" but "the phase transition hook doesn't fire when..."
-- **Testable**: An agent can find evidence for or against it
-- **Distinct**: Hypotheses should point to genuinely different root causes
-
-Example for "Orders aren't syncing to Netvisor":
-- H1: "The activity mover trigger condition is wrong - it fires on the wrong phase"
-- H2: "The Netvisor API integration is failing silently - auth or payload issue"
-- H3: "The data is incomplete - required fields for Netvisor export are missing"
-
-If user provided their own hypotheses in `$ARGUMENTS`, use those instead of generating.
-
-#### Step D2: Assign Agents to Hypotheses
-
-Pick the best-fit agent for each hypothesis:
-
-| Hypothesis Type | Best Agent Role |
-|----------------|-----------|
-| Data integrity / missing values | **Data Reader** (load sdk-ws-config-skill) |
-| Query / pattern / scope issue | **SQL Insights** (load sdk-insight-queries) |
-| Code logic / validation / race condition | **Code Reviewer** |
-| Reproducibility / environment | **Test Runner** (load testing-patterns) |
-| External integration / API | **Automation Inspector** (load hailer-monolith-automations) |
-| Activity mover / phase cascade | **Automation Inspector** (load hailer-monolith-automations) |
-| Zapier integration / external sync | **Integration Inspector** (load zapier-hailer-patterns) |
-
-Each agent gets:
-- The full problem description
-- Their assigned hypothesis
-- Instruction: "Find evidence that supports OR refutes this hypothesis. Be honest - if evidence points away from your hypothesis, report that."
-
-```
-Task(prompt="Load relevant skill for deep investigation.\n\nDEBATE MODE investigation for: $ARGUMENTS
-
-YOUR HYPOTHESIS: [H1 description]
-
-Your job is to investigate whether this hypothesis explains the bug. Be thorough and honest:
-
-1. What evidence SUPPORTS this hypothesis?
-2. What evidence REFUTES this hypothesis?
-3. Confidence level: STRONG / MODERATE / WEAK
-4. If your hypothesis is wrong, what does the evidence actually point to?
-
-Do NOT assume your hypothesis is correct. Follow the evidence.")
-```
-
-Launch all hypothesis agents in parallel.
-
-#### Step D3: Score and Synthesize
-
-Collect results. For each hypothesis, assess:
-
-| Hypothesis | Supporting Evidence | Refuting Evidence | Confidence | Role |
-|-----------|-------------------|-------------------|------------|-------|
-| H1 | [list] | [list] | STRONG/MODERATE/WEAK | [role] |
-| H2 | [list] | [list] | STRONG/MODERATE/WEAK | [role] |
-| H3 | [list] | [list] | STRONG/MODERATE/WEAK | [role] |
-
-**Verdict rules:**
-- If one hypothesis has STRONG confidence and others are WEAK → **clear winner**
-- If multiple have MODERATE+ confidence → **compound issue** (multiple causes)
-- If all are WEAK → **inconclusive**, escalate to user with what was learned
-
-#### Step D4: Debate Report
-
-```markdown
-## Debug Squad Investigation (Debate Mode)
-
-### Problem
-[Description]
-
-### Hypotheses Tested
-
-#### H1: [Hypothesis description]
-**Assigned to:** [Agent role]
-**Confidence:** STRONG / MODERATE / WEAK
-**Supporting evidence:**
-- [Evidence 1]
-- [Evidence 2]
-**Refuting evidence:**
-- [Evidence 1]
-
-#### H2: [Hypothesis description]
-...
-
-#### H3: [Hypothesis description]
-...
-
----
-
-### Verdict
-**Winner:** H[N] - [hypothesis description]
-**Confidence:** [STRONG/MODERATE/WEAK]
-
-[If compound:] **Multiple causes identified:**
-1. H[X]: [description] (MODERATE confidence)
-2. H[Y]: [description] (MODERATE confidence)
-
-[If inconclusive:] **No clear root cause found.** Most promising lead: H[N].
-
-### Dissenting Evidence
-[Evidence that doesn't fit the winning hypothesis - important to surface]
-
-### Recommended Fix
-[Based on winning hypothesis]
-
-### Next Steps
-1. [Fix the identified cause]
-2. [Verify dissenting evidence doesn't indicate a secondary issue]
-3. [Run /hotfix-squad if fix is straightforward]
-```
-
----
+## Convergence
 
-## Notes
+Synthesize: does the data anomaly match the code error? Does the SQL pattern align with the suspected code path? Does the test reproduce exactly what the data lens found? If lenses disagree or all come back empty, re-run the most promising lens once with narrowed scope (max 2 rounds), then report honestly: IDENTIFIED with evidence chain, or INCONCLUSIVE with what was ruled out.
 
-- Parallel execution: all agents run simultaneously for speed
-- Max 2 iterations prevents infinite loops while allowing scope refinement
-- Convergence is key: when 3+ agents point to the same root cause, confidence is high
-- Each re-investigation iteration gets narrowed scope from first pass results
-- Report synthesizes findings, not just concatenates them
-- **Debate mode** costs more tokens (2-3 full agent calls) but excels at ambiguous, hard-to-diagnose problems
-- Debate agents are told to be honest about refuting evidence - this prevents confirmation bias
-- Users can supply their own hypotheses to test specific theories
+Report: root cause status, evidence per lens, scope (records affected), the failing test, and the proposed fix (do not apply it — this squad diagnoses).

package/.claude/commands/publish.md

@@ -46,7 +46,7 @@ Publishes a single plugin to the marketplace.
 
 4. **Spawn a publisher sub-agent:**
    ```
-   Task(prompt="Load publish-hailer-app skill for publishing patterns.\n\nPublish this plugin to the Hailer Marketplace:\n- Name: {name}\n- Type: agent|skill|hook\n- Version: {user provided}\n- Changelog: {user provided}\n- Content: {file content}\n\nCopy the plugin to Hailer-Marketplace/{name}/, update plugin.json, create a git commit and PR.")
+   Task(prompt="Load create-and-publish-app skill for publishing patterns.\n\nPublish this plugin to the Hailer Marketplace:\n- Name: {name}\n- Type: agent|skill|hook\n- Version: {user provided}\n- Changelog: {user provided}\n- Content: {file content}\n\nCopy the plugin to Hailer-Marketplace/{name}/, update plugin.json, create a git commit and PR.")
    ```
 
 5. **Spawn a reviewer sub-agent** (after PR created):
@@ -76,7 +76,7 @@ Publishes all out-of-sync plugins in a single PR.
 
 Spawn with:
 ```
-Task(prompt="Load publish-hailer-app skill.\n\nCheck .claude/ vs Hailer-Marketplace/ for version mismatches and publish out-of-sync plugins. Create a single PR with all updates.")
+Task(prompt="Load create-and-publish-app skill.\n\nCheck .claude/ vs Hailer-Marketplace/ for version mismatches and publish out-of-sync plugins. Create a single PR with all updates.")
 ```
 
 Expected result:

package/.claude/commands/review-squad.md

@@ -1,152 +1,30 @@
 ---
-description: Run parallel code review with security, LSP inspection, and test verification
+description: Run parallel code review with security, static inspection, and test verification
 argument-hint: [files, directory, or blank for recent changes]
-allowed-tools: Task, Bash
+allowed-tools: Workflow, Bash, Read
 ---
 # Review Squad
 
-Parallel code review with iterative fix loop: find issues, auto-fix criticals, re-review.
+Parallel code review via the native Workflow tool: find issues per dimension, adversarially verify, auto-fix criticals, re-check.
 
-**Roles:**
-- **Code Reviewer** - Code review (bugs, security, best practices)
-- **LSP Inspector** - LSP inspection (dead code, unused imports, type errors)
-- **Test Runner** - Test runner (run tests, verify builds)
-- **Code Editor** - Auto-fix critical issues (only in loop iterations)
+**Target:** $ARGUMENTS — if blank, use `git diff --name-only HEAD` output.
+Flags: `--no-fix` (report only), `--skip-tests` (drop the test dimension).
 
-**Target:** $ARGUMENTS (if blank, use recent git changes)
+## Orchestration
 
-**Changed files:** Run `git diff --name-only HEAD` via Bash to get recent changes. Use the output as TARGET if no specific files are given.
+Author a Workflow script (this command is your opt-in to call the Workflow tool):
 
-## Protocol
+1. **Review phase** — one agent per dimension, in a `pipeline()` over:
+   - `bugs`: correctness, logic errors, race conditions, missing null checks
+   - `security`: injection, auth/permission gaps, secrets, fail-open paths
+   - `conventions`: repo eslint rules (no else/else-if, no nested ifs, no `=== undefined`, single quotes, 4-space indent, ≤140 cols), dead code, unused imports — verify with `npx eslint` + `npx tsc --noEmit`, not eyeballing
+   - `tests` (unless --skip-tests): run `npm test`, verify build, flag untested changed logic
+   Each returns findings via a `schema`: `{ file, line, severity: 'critical'|'warning', title, detail, autoFixable }`.
 
-### Step 1: Determine Target
+2. **Verify phase** — each finding goes to one adversarial verifier prompted to REFUTE it; drop refuted findings. (Same pipeline, no barrier.)
 
-If `$ARGUMENTS` has specific files/directories, use those.
-Otherwise, use the changed files list above as the target.
+3. **Fix phase** (skip with --no-fix) — if confirmed criticals are autoFixable (unused imports, dead code, simple type errors, obvious test fixes — NOT architecture/design/complex logic), spawn one fixer agent with the exact list: "minimal fixes only, no refactoring". Then re-run the affected dimension once. Max 2 fix iterations.
 
-If `$ARGUMENTS` contains `--skip-tests`:
-- Remove flag from target
-- Skip Test Runner in Step 2
+## Report
 
-If `$ARGUMENTS` contains `--skip-lsp`:
-- Remove flag from target
-- Skip LSP Inspector in Step 2
-
-If `$ARGUMENTS` contains `--no-fix`:
-- Skip the fix loop entirely (old behavior - report only)
-
-### Step 2: Launch Review Agents in Parallel
-
-**Set:** `iteration = 1`
-
-If `--bg` is present, add `run_in_background: true` to all agent calls below and tell the user they'll be notified when complete.
-
-Spawn all review agents simultaneously using multiple Task tool calls in a single message:
-
-**Code Reviewer:**
-```
-Task(prompt="Load testing-patterns skill for understanding test-related code issues.\n\nReview these files for bugs, security issues, and best practices: [TARGET]. [IF iteration > 1: Previous issues that were auto-fixed: [LIST FIXES APPLIED]. Verify these are resolved and check for any NEW issues introduced by the fixes.] Return verdict (APPROVE/REQUEST_CHANGES), critical count, warning count, and details. Categorize each issue as CRITICAL or WARNING.")
-```
-
-**LSP Inspector:**
-```
-Task(prompt="Load lsp-setup skill for understanding code inspection tools.\n\nInspect these files for dead code, unused imports, and type errors: [TARGET]. [IF iteration > 1: Previous issues that were auto-fixed: [LIST FIXES APPLIED]. Verify these are resolved.] Use LSP if available, fall back to tsc/eslint.")
-```
-
-**Test Runner:**
-```
-Task(prompt="Load testing-patterns skill for test execution.\n\nRun tests associated with these files: [TARGET]. Include build verification. Report pass/fail counts.")
-```
-
-### Step 3: Evaluate Results - Fix or Report
-
-Collect results from all agents. Check for **auto-fixable issues**:
-
-**Auto-fixable** (Code Editor can handle):
-- Unused imports
-- Dead code removal
-- Missing null checks
-- Simple type errors
-- Test failures with obvious fixes
-
-**NOT auto-fixable** (escalate to user):
-- Architecture concerns
-- Design pattern issues
-- Complex logic bugs
-- Security issues requiring design changes
-- Performance concerns
-
-#### If critical auto-fixable issues found AND `--no-fix` not set AND `iteration < 3`:
-
-Spawn a code editor with the specific issues:
-
-```
-Task(prompt="Fix these critical issues found by the review squad:\n\n[LIST AUTO-FIXABLE ISSUES WITH FILE PATHS AND LINE NUMBERS]\n\nFrom Code Reviewer: [critical issues]\nFrom LSP Inspector: [dead code, unused imports]\nFrom Test Runner: [test failures if obvious fix]\n\nApply minimal fixes only. Do not refactor or improve beyond the reported issues.")
-```
-
-After Code Editor finishes:
-- Increment `iteration`
-- Go back to **Step 2** to re-review the fixed code
-- On re-review, include what Code Editor fixed so agents can verify fixes and check for regressions
-
-#### If no auto-fixable criticals OR `--no-fix` set OR `iteration >= 3`:
-
-Proceed to Step 4 (report).
-
-### Step 4: Report
-
-```markdown
-## Review Squad Report
-
-### Loop Summary
-- Review iterations: [count]
-- Auto-fixes applied: [yes/no, count of issues fixed]
-
-### Code Reviewer
-**Verdict:** APPROVE / REQUEST_CHANGES
-- Critical: X (Y auto-fixed)
-- Warnings: X
-- [Remaining issues grouped by file]
-
-### LSP Inspector
-- Dead code: X items (Y auto-removed)
-- Unused imports: X (Y auto-removed)
-- Type errors: X
-- [Remaining issues grouped by file]
-
-### Test Runner
-- Tests: X passed, X failed
-- Build: Pass/Fail
-- [Failed test details if any]
-
-### Auto-Fixes Applied
-[If Code Editor made changes:]
-- [File]: [what was fixed]
-- [File]: [what was fixed]
-
-### Remaining Issues (Manual Action Needed)
-[Issues that couldn't be auto-fixed]
-
-### Summary
-[1-2 sentence overall assessment]
-```
-
-If any agent fails or times out, report partial results from successful agents, note which failed, and offer to re-run individually.
-
-## Options
-
-| Flag | Effect |
-|------|--------|
-| `--skip-tests` | Skip Test Runner (faster, no test execution) |
-| `--skip-lsp` | Skip LSP Inspector (when LSP not configured) |
-| `--no-fix` | Report only, no auto-fix loop (old behavior) |
-| `--bg` | Run all agents in background mode |
-
-If `--bg` is present, launch all agents with `run_in_background: true` and tell the user they'll be notified when complete.
-
-## Notes
-
-- Max 2 re-review iterations (3 total reviews) to prevent infinite loops
-- Code Editor only fixes clear-cut issues - ambiguous problems go to user
-- Each re-review is a full parallel sweep, not just Code Reviewer
-- The `--no-fix` flag gives the old report-only behavior
+Verdict (APPROVE / REQUEST_CHANGES), confirmed findings grouped by file with severity, what was auto-fixed, what needs manual action, test/build status. If a workflow stage dies, report partial results and say which dimension failed.