@probelabs/visor 0.1.149 → 0.1.150-ee

package/dist/docs/event-triggers.md

@@ -185,6 +185,29 @@ The complete list of event triggers that can be used in the `on` field:
 | `manual` | Manual CLI invocation |
 | `schedule` | Scheduled execution (cron or workflow_dispatch) |
 | `webhook_received` | HTTP webhook was received (via http_input provider) |
+| `slack_message` | Slack message matched an `on_message` trigger (see [Scheduler - Message Triggers](./scheduler.md#message-triggers-on_message)) |
+
+### Slack Message Trigger Events (`slack_message`)
+
+When a Slack message matches a configured `on_message` trigger (defined in `scheduler.on_message`), the specified workflow is dispatched with event type `slack_message`. This allows reactive workflows based on message content in specific channels, without requiring an @mention.
+
+- **Trigger mapping**: `slack_message`
+- **Source**: `scheduler.on_message` filter match in Slack Socket Mode
+- **Log format**:
+  ```
+  [SlackSocket] Message trigger 'cicd-watcher' matched → workflow="handle-cicd" channel=C0CICD ts=1700.001
+  ```
+
+Steps can filter on this event type:
+```yaml
+steps:
+  handle-cicd-failure:
+    on: [slack_message]   # Only runs when triggered by on_message
+    type: ai
+    prompt: "Analyze the CI/CD failure."
+```
+
+See [Scheduler - Message Triggers](./scheduler.md#message-triggers-on_message) for configuration details.
 
 ## Configuration
 
@@ -241,6 +264,7 @@ The `goto_event` field accepts any valid `EventTrigger` value:
 - `pr_opened`, `pr_updated`, `pr_closed`
 - `issue_opened`, `issue_comment`
 - `manual`, `schedule`, `webhook_received`
+- `slack_message`
 
 For complete documentation on failure routing, retry policies, and loop control, see [Failure Routing](./failure-routing.md).
 
@@ -300,6 +324,7 @@ visor --check security --event pr_updated
 | `--event issue_comment` | Only runs checks with `on: [issue_comment]` | Test comment assistant |
 | `--event manual` | Only runs checks with `on: [manual]` | Test manual-triggered checks |
 | `--event schedule` | Only runs checks with `on: [schedule]` | Test scheduled/cron checks |
+| `--event slack_message` | Only runs checks with `on: [slack_message]` | Test message trigger workflows |
 | `--event all` | Runs all checks (except manual-only) | Default behavior, ignores `on:` filters |
 | (no flag) | Auto-detects based on schema | Smart default |
 

package/dist/docs/scheduler.md

@@ -63,6 +63,160 @@ scheduler:
         target: "#platform-team"
 ```
 
+## Message Triggers (`on_message`)
+
+Message triggers allow workflows to be executed reactively based on Slack messages, without requiring an @mention. This is useful for monitoring channels (e.g., CI/CD failure notifications) and automatically triggering workflows in response.
+
+### Configuration
+
+Add `on_message` alongside `cron` in the `scheduler` section:
+
+```yaml
+scheduler:
+  enabled: true
+
+  on_message:
+    cicd-watcher:
+      description: "React to CI/CD failure notifications"
+      channels: ["C0CICD"]           # Channel IDs (wildcard suffix supported, e.g., "CENG*")
+      from: ["U123BOT"]              # Optional: only from these user IDs
+      from_bots: true                # Allow bot messages (default: false)
+      contains: ["failed", "error"]  # Any keyword match, case-insensitive (OR)
+      match: "build.*failed"         # Regex pattern (optional)
+      threads: root_only             # root_only | thread_only | any (default: any)
+      workflow: handle-cicd-failure
+      inputs:
+        source: slack
+      output:
+        type: slack
+      enabled: true
+
+    thread-responder:
+      description: "Respond in threads about deployments"
+      channels: ["C0DEPLOY"]
+      threads: thread_only           # Only react to thread replies
+      contains: ["help", "stuck"]
+      workflow: deploy-help
+```
+
+### Filter Options
+
+| Option | Type | Default | Description |
+|--------|------|---------|-------------|
+| `channels` | string[] | (all) | Channel IDs to monitor. Supports wildcard suffix (e.g., `CENG*`) |
+| `from` | string[] | (all) | Only trigger on messages from these Slack user IDs |
+| `from_bots` | boolean | `false` | Allow bot messages to trigger. When false, bot messages are ignored |
+| `contains` | string[] | (all) | Keyword match — any keyword triggers (case-insensitive, OR logic) |
+| `match` | string | (none) | Regex pattern to match against message text (case-insensitive) |
+| `threads` | string | `any` | Thread scope: `root_only`, `thread_only`, or `any` |
+| `workflow` | string | **(required)** | Workflow/check ID to execute when triggered |
+| `inputs` | object | `{}` | Workflow inputs passed to the execution |
+| `output` | object | (none) | Output destination (`type`, `target`, `thread_id`) |
+| `description` | string | (none) | Description for logging |
+| `enabled` | boolean | `true` | Enable/disable this trigger |
+
+### Filter Logic
+
+- All specified filters must pass (**AND** logic between filters)
+- Within `contains`, any keyword match suffices (**OR** logic)
+- Omitted filters are not checked (they match everything)
+
+### Thread Scope
+
+| Value | Behavior |
+|-------|----------|
+| `root_only` | Only react to root channel messages (no `thread_ts` or `thread_ts === ts`) |
+| `thread_only` | Only react to thread replies (`thread_ts` exists and differs from `ts`) |
+| `any` | React to both root messages and thread replies (default) |
+
+When a triggered message is a thread reply, full thread conversation context is fetched via `SlackAdapter` and passed to the workflow as `slack_conversation`. When the message is a root channel message, only the single message is available.
+
+### Message Flow
+
+```
+Slack WebSocket Event
+  → Parse JSON, ACK
+  → Filter subtypes (edited, etc.)
+  → Filter self-bot messages
+  → Filter guests
+  → Evaluate message triggers ← NEW
+       → For each match: dispatch workflow async
+  → Mention gate (existing @mention path)
+  → Thread/allowlist/dedup gates
+  → Dispatch all checks (existing mention-based path)
+```
+
+Both paths can fire for the same message. A message that matches a trigger AND contains an @mention will dispatch the triggered workflow AND go through the normal mention-based dispatch. Each triggered workflow gets its own engine instance.
+
+### Webhook Context
+
+The triggered workflow receives via `webhookData`:
+
+| Field | Description |
+|-------|-------------|
+| `event.text` | Message text |
+| `event.user` | Sender user ID |
+| `event.channel` | Channel ID |
+| `event.ts` / `event.thread_ts` | Message timestamps |
+| `trigger.id` | Which trigger matched |
+| `trigger.type` | `on_message` |
+| `slack_conversation` | Full thread context (if thread reply) |
+
+The event type is `slack_message`, which can be used in step `on:` filters:
+
+```yaml
+steps:
+  handle-cicd-failure:
+    type: ai
+    on: [slack_message]
+    prompt: "Analyze this CI/CD failure and suggest fixes."
+```
+
+### Deduplication
+
+Each trigger match is deduplicated using the key `trigger:${triggerId}:${channel}:${ts}`. This prevents the same trigger from firing multiple times for duplicate Slack events.
+
+### Hot Reload
+
+Message triggers are rebuilt when configuration is hot-reloaded via `updateConfig()`. Adding, removing, or modifying triggers in `.visor.yaml` takes effect on the next config reload without restarting the bot.
+
+### Example: CI/CD Failure Monitor
+
+```yaml
+scheduler:
+  on_message:
+    cicd-failures:
+      channels: ["C0CICD"]
+      from_bots: true
+      contains: ["failed", "error", "broken"]
+      match: "build.*#\\d+.*(failed|error)"
+      threads: root_only
+      workflow: analyze-failure
+      inputs:
+        notify_team: true
+
+steps:
+  analyze-failure:
+    type: ai
+    on: [slack_message]
+    schema:
+      type: object
+      properties:
+        text:
+          type: string
+        severity:
+          type: string
+          enum: [low, medium, high, critical]
+      required: [text, severity]
+    prompt: |
+      A CI/CD failure was detected. Analyze the failure message and provide:
+      1. Root cause analysis
+      2. Suggested fix
+      3. Severity assessment
+
+      Failure message: {{ event.text }}
+```
+
 ## Static Cron Jobs
 
 Static cron jobs are defined in your configuration file and always run regardless of permission settings. They're ideal for recurring organizational tasks:
@@ -398,6 +552,7 @@ src/
 │   ├── schedule-parser.ts        # Natural language parsing utilities
 │   ├── scheduler.ts              # Generic scheduler daemon
 │   ├── schedule-tool.ts          # AI tool for schedule management
+│   ├── message-trigger.ts        # Slack message trigger evaluator
 │   ├── cli-handler.ts            # CLI command handlers
 │   └── store/                    # Storage backends
 │       ├── index.ts              # Backend factory
@@ -418,6 +573,7 @@ src/
 |-----------|---------|
 | `Scheduler` | Main daemon that checks for due schedules and executes them |
 | `ScheduleStore` | Singleton for persisting schedules to JSON |
+| `MessageTriggerEvaluator` | Evaluates Slack messages against `on_message` triggers |
 | `ScheduleOutputAdapter` | Interface for output destinations |
 | `SlackOutputAdapter` | Implements output posting for Slack |
 | `schedule-tool` | AI tool definition and handler |

package/dist/docs/slack-integration.md

@@ -9,6 +9,7 @@ Visor provides bidirectional Slack integration through Socket Mode, enabling int
 - [Configuration](#configuration)
 - [Features](#features)
 - [Example Workflows](#example-workflows)
+- [Message Triggers](#message-triggers)
 - [Troubleshooting](#troubleshooting)
 - [Related Documentation](#related-documentation)
 
@@ -474,6 +475,53 @@ Log messages include:
 - `[slack-frontend]` - Message posting and reactions
 - `[prompt-state]` - Human input state management
 
+## Message Triggers
+
+Message triggers allow Visor to react to Slack messages in specific channels without requiring an @mention. This is configured via `scheduler.on_message` and is ideal for monitoring bot notifications (e.g., CI/CD failures, deployment alerts).
+
+### Quick Example
+
+```yaml
+scheduler:
+  on_message:
+    cicd-watcher:
+      channels: ["C0CICD"]
+      from_bots: true
+      contains: ["failed", "error"]
+      workflow: handle-cicd-failure
+
+steps:
+  handle-cicd-failure:
+    type: ai
+    on: [slack_message]
+    prompt: "Analyze this CI/CD failure and suggest a fix."
+```
+
+When a message matching the filters appears in the specified channel, Visor dispatches the configured workflow asynchronously. The workflow receives the full Slack event context including message text, sender, channel, and thread conversation history (for thread replies).
+
+### Key Features
+
+- **No @mention required**: Triggers fire based on message content, channel, user, and thread scope
+- **Bot message support**: Set `from_bots: true` to react to messages from other bots (CI systems, monitoring tools)
+- **Coexists with @mention path**: A message can trigger both a message trigger workflow and the normal @mention-based dispatch
+- **Hot reload**: Trigger configuration is rebuilt on config hot-reload without restarting the bot
+- **Deduplication**: Built-in dedup prevents duplicate workflow dispatches for the same Slack event
+
+### Filter Options
+
+| Filter | Description |
+|--------|-------------|
+| `channels` | Channel IDs (wildcard suffix supported, e.g., `CENG*`) |
+| `from` | Specific user IDs |
+| `from_bots` | Allow bot messages (default: false) |
+| `contains` | Keyword match (case-insensitive, any = match) |
+| `match` | Regex pattern |
+| `threads` | `root_only`, `thread_only`, or `any` (default) |
+
+All specified filters must pass (AND). Within `contains`, any keyword suffices (OR). Omitted filters match everything.
+
+See [Scheduler - Message Triggers](./scheduler.md#message-triggers-on_message) for complete configuration reference.
+
 ## Scheduled Reminders
 
 The scheduler integrates with Slack to deliver scheduled reminders and workflow results. See [Scheduler](./scheduler.md) for full documentation.

package/dist/enterprise/scheduler/knex-store.d.ts

@@ -4,7 +4,7 @@
  * in compliance with the Elastic License 2.0.
  */
 import type { Schedule, ScheduleLimits } from '../../scheduler/schedule-store';
-import type { ScheduleStoreBackend, ScheduleStoreStats, StorageConfig, HAConfig } from '../../scheduler/store/types';
+import type { ScheduleStoreBackend, ScheduleStoreStats, StorageConfig, HAConfig, MessageTrigger } from '../../scheduler/store/types';
 /**
  * Enterprise Knex-backed store for PostgreSQL, MySQL, and MSSQL
  */
@@ -37,5 +37,11 @@ export declare class KnexStoreBackend implements ScheduleStoreBackend {
     releaseLock(lockId: string, lockToken: string): Promise<void>;
     renewLock(lockId: string, lockToken: string, ttlSeconds: number): Promise<boolean>;
     flush(): Promise<void>;
+    createTrigger(trigger: Omit<MessageTrigger, 'id' | 'createdAt'>): Promise<MessageTrigger>;
+    getTrigger(id: string): Promise<MessageTrigger | undefined>;
+    updateTrigger(id: string, patch: Partial<MessageTrigger>): Promise<MessageTrigger | undefined>;
+    deleteTrigger(id: string): Promise<boolean>;
+    getTriggersByCreator(creatorId: string): Promise<MessageTrigger[]>;
+    getActiveTriggers(): Promise<MessageTrigger[]>;
 }
 //# sourceMappingURL=knex-store.d.ts.map

package/dist/enterprise/scheduler/knex-store.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"knex-store.d.ts","sourceRoot":"","sources":["file:///home/runner/work/visor/visor/src/enterprise/scheduler/knex-store.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAYH,OAAO,KAAK,EAAE,QAAQ,EAAE,cAAc,EAAE,MAAM,gCAAgC,CAAC;AAC/E,OAAO,KAAK,EACV,oBAAoB,EACpB,kBAAkB,EAClB,aAAa,EACb,QAAQ,EAET,MAAM,6BAA6B,CAAC;AA+FrC;;GAEG;AACH,qBAAa,gBAAiB,YAAW,oBAAoB;IAC3D,OAAO,CAAC,IAAI,CAAqB;IACjC,OAAO,CAAC,MAAM,CAAmC;IACjD,OAAO,CAAC,UAAU,CAAyB;gBAGzC,MAAM,EAAE,YAAY,GAAG,OAAO,GAAG,OAAO,EACxC,aAAa,EAAE,aAAa,EAC5B,SAAS,CAAC,EAAE,QAAQ;IAMhB,UAAU,IAAI,OAAO,CAAC,IAAI,CAAC;IAkDjC,OAAO,CAAC,uBAAuB;IAW/B,OAAO,CAAC,oBAAoB;IAkB5B,OAAO,CAAC,gBAAgB;IA4BxB,OAAO,CAAC,eAAe;IAWjB,QAAQ,IAAI,OAAO,CAAC,IAAI,CAAC;YAOjB,aAAa;IA4C3B,OAAO,CAAC,OAAO;IAST,MAAM,CACV,QAAQ,EAAE,IAAI,CAAC,QAAQ,EAAE,IAAI,GAAG,WAAW,GAAG,UAAU,GAAG,cAAc,GAAG,QAAQ,CAAC,GACpF,OAAO,CAAC,QAAQ,CAAC;IAkBd,cAAc,CAAC,QAAQ,EAAE,QAAQ,GAAG,OAAO,CAAC,IAAI,CAAC;IAOjD,GAAG,CAAC,EAAE,EAAE,MAAM,GAAG,OAAO,CAAC,QAAQ,GAAG,SAAS,CAAC;IAM9C,MAAM,CAAC,EAAE,EAAE,MAAM,EAAE,KAAK,EAAE,OAAO,CAAC,QAAQ,CAAC,GAAG,OAAO,CAAC,QAAQ,GAAG,SAAS,CAAC;IAgB3E,MAAM,CAAC,EAAE,EAAE,MAAM,GAAG,OAAO,CAAC,OAAO,CAAC;IAYpC,YAAY,CAAC,SAAS,EAAE,MAAM,GAAG,OAAO,CAAC,QAAQ,EAAE,CAAC;IAMpD,kBAAkB,IAAI,OAAO,CAAC,QAAQ,EAAE,CAAC;IAMzC,eAAe,CAAC,GAAG,CAAC,EAAE,MAAM,GAAG,OAAO,CAAC,QAAQ,EAAE,CAAC;IAsBlD,cAAc,CAAC,SAAS,EAAE,MAAM,EAAE,YAAY,EAAE,MAAM,GAAG,OAAO,CAAC,QAAQ,EAAE,CAAC;IAW5E,MAAM,IAAI,OAAO,CAAC,QAAQ,EAAE,CAAC;IAM7B,QAAQ,IAAI,OAAO,CAAC,kBAAkB,CAAC;IA4BvC,cAAc,CAClB,SAAS,EAAE,MAAM,EACjB,WAAW,EAAE,OAAO,EACpB,MAAM,EAAE,cAAc,GACrB,OAAO,CAAC,IAAI,CAAC;IAqCV,cAAc,CAAC,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,UAAU,EAAE,MAAM,GAAG,OAAO,CAAC,MAAM,GAAG,IAAI,CAAC;IAmC1F,WAAW,CAAC,MAAM,EAAE,MAAM,EAAE,SAAS,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC;IAK7D,SAAS,CAAC,MAAM,EAAE,MAAM,EAAE,SAAS,EAAE,MAAM,EAAE,UAAU,EAAE,MAAM,GAAG,OAAO,CAAC,OAAO,CAAC;IAalF,KAAK,IAAI,OAAO,CAAC,IAAI,CAAC;CAG7B"}
+{"version":3,"file":"knex-store.d.ts","sourceRoot":"","sources":["file:///home/runner/work/visor/visor/src/enterprise/scheduler/knex-store.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAYH,OAAO,KAAK,EAAE,QAAQ,EAAE,cAAc,EAAE,MAAM,gCAAgC,CAAC;AAC/E,OAAO,KAAK,EACV,oBAAoB,EACpB,kBAAkB,EAClB,aAAa,EACb,QAAQ,EAER,cAAc,EACf,MAAM,6BAA6B,CAAC;AAkKrC;;GAEG;AACH,qBAAa,gBAAiB,YAAW,oBAAoB;IAC3D,OAAO,CAAC,IAAI,CAAqB;IACjC,OAAO,CAAC,MAAM,CAAmC;IACjD,OAAO,CAAC,UAAU,CAAyB;gBAGzC,MAAM,EAAE,YAAY,GAAG,OAAO,GAAG,OAAO,EACxC,aAAa,EAAE,aAAa,EAC5B,SAAS,CAAC,EAAE,QAAQ;IAMhB,UAAU,IAAI,OAAO,CAAC,IAAI,CAAC;IAkDjC,OAAO,CAAC,uBAAuB;IAW/B,OAAO,CAAC,oBAAoB;IAkB5B,OAAO,CAAC,gBAAgB;IA4BxB,OAAO,CAAC,eAAe;IAWjB,QAAQ,IAAI,OAAO,CAAC,IAAI,CAAC;YAOjB,aAAa;IAoE3B,OAAO,CAAC,OAAO;IAST,MAAM,CACV,QAAQ,EAAE,IAAI,CAAC,QAAQ,EAAE,IAAI,GAAG,WAAW,GAAG,UAAU,GAAG,cAAc,GAAG,QAAQ,CAAC,GACpF,OAAO,CAAC,QAAQ,CAAC;IAkBd,cAAc,CAAC,QAAQ,EAAE,QAAQ,GAAG,OAAO,CAAC,IAAI,CAAC;IAOjD,GAAG,CAAC,EAAE,EAAE,MAAM,GAAG,OAAO,CAAC,QAAQ,GAAG,SAAS,CAAC;IAM9C,MAAM,CAAC,EAAE,EAAE,MAAM,EAAE,KAAK,EAAE,OAAO,CAAC,QAAQ,CAAC,GAAG,OAAO,CAAC,QAAQ,GAAG,SAAS,CAAC;IAgB3E,MAAM,CAAC,EAAE,EAAE,MAAM,GAAG,OAAO,CAAC,OAAO,CAAC;IAYpC,YAAY,CAAC,SAAS,EAAE,MAAM,GAAG,OAAO,CAAC,QAAQ,EAAE,CAAC;IAMpD,kBAAkB,IAAI,OAAO,CAAC,QAAQ,EAAE,CAAC;IAMzC,eAAe,CAAC,GAAG,CAAC,EAAE,MAAM,GAAG,OAAO,CAAC,QAAQ,EAAE,CAAC;IAsBlD,cAAc,CAAC,SAAS,EAAE,MAAM,EAAE,YAAY,EAAE,MAAM,GAAG,OAAO,CAAC,QAAQ,EAAE,CAAC;IAW5E,MAAM,IAAI,OAAO,CAAC,QAAQ,EAAE,CAAC;IAM7B,QAAQ,IAAI,OAAO,CAAC,kBAAkB,CAAC;IA4BvC,cAAc,CAClB,SAAS,EAAE,MAAM,EACjB,WAAW,EAAE,OAAO,EACpB,MAAM,EAAE,cAAc,GACrB,OAAO,CAAC,IAAI,CAAC;IAqCV,cAAc,CAAC,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,UAAU,EAAE,MAAM,GAAG,OAAO,CAAC,MAAM,GAAG,IAAI,CAAC;IAmC1F,WAAW,CAAC,MAAM,EAAE,MAAM,EAAE,SAAS,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC;IAK7D,SAAS,CAAC,MAAM,EAAE,MAAM,EAAE,SAAS,EAAE,MAAM,EAAE,UAAU,EAAE,MAAM,GAAG,OAAO,CAAC,OAAO,CAAC;IAalF,KAAK,IAAI,OAAO,CAAC,IAAI,CAAC;IAMtB,aAAa,CAAC,OAAO,EAAE,IAAI,CAAC,cAAc,EAAE,IAAI,GAAG,WAAW,CAAC,GAAG,OAAO,CAAC,cAAc,CAAC;IAYzF,UAAU,CAAC,EAAE,EAAE,MAAM,GAAG,OAAO,CAAC,cAAc,GAAG,SAAS,CAAC;IAM3D,aAAa,CACjB,EAAE,EAAE,MAAM,EACV,KAAK,EAAE,OAAO,CAAC,cAAc,CAAC,GAC7B,OAAO,CAAC,cAAc,GAAG,SAAS,CAAC;IAmBhC,aAAa,CAAC,EAAE,EAAE,MAAM,GAAG,OAAO,CAAC,OAAO,CAAC;IAU3C,oBAAoB,CAAC,SAAS,EAAE,MAAM,GAAG,OAAO,CAAC,cAAc,EAAE,CAAC;IAMlE,iBAAiB,IAAI,OAAO,CAAC,cAAc,EAAE,CAAC;CAOrD"}

package/dist/examples/code-talk-as-tool.yaml

@@ -0,0 +1,76 @@
+# =============================================================================
+# Example: Using code-talk as an AI Custom Tool
+# =============================================================================
+#
+# This example shows how to use the code-talk workflow as an AI tool,
+# allowing an AI assistant to explore your codebase on demand.
+#
+# Usage:
+#   visor --config examples/code-talk-as-tool.yaml --message "Help me understand the codebase"
+#
+# =============================================================================
+
+version: "1.0"
+
+imports:
+  - visor://code-talk.yaml
+
+# Define a project-specific wrapper that can be used as a tool
+checks:
+  # Get user request
+  get-request:
+    type: human-input
+    prompt: "What would you like help with?"
+    placeholder: "e.g., Help me understand how the API endpoints work"
+
+  # AI assistant with code exploration tool
+  assistant:
+    type: ai
+    depends_on: [get-request]
+    ai:
+      skip_code_context: true
+      prompt_type: general
+    prompt: |
+      You are a helpful assistant for this project.
+
+      The user asked: {{ outputs['get-request'].text }}
+
+      You have access to the code-talk tool which can explore the codebase
+      and answer technical questions with code references.
+
+      Use the code-talk tool when you need to:
+      - Find specific implementations
+      - Understand how components work
+      - Locate relevant code files
+      - Answer technical questions about the codebase
+
+      After getting information from the tool, provide a clear and helpful response.
+
+    ai_custom_tools:
+      # Use code-talk directly as a tool
+      - workflow: code-talk
+        args:
+          # Pre-configure with your project settings
+          architecture: |
+            # Project Architecture
+            Describe your project here.
+
+          projects:
+            - id: my-project
+              repo: your-org/your-repo
+              description: Main project codebase
+
+          max_projects: 1
+
+  # Show the result
+  show-result:
+    type: log
+    depends_on: [assistant]
+    message: |
+      ===============================================================
+      Assistant Response
+      ===============================================================
+
+      {{ outputs['assistant'].content }}
+
+      ===============================================================

package/dist/examples/code-talk-workflow.yaml

@@ -0,0 +1,68 @@
+# =============================================================================
+# Example: Using code-talk as a Standard Workflow
+# =============================================================================
+#
+# This example shows how to use the code-talk workflow for interactive
+# code exploration in your project.
+#
+# Usage:
+#   visor --config examples/code-talk-workflow.yaml --message "How does auth work?"
+#
+# =============================================================================
+
+version: "1.0"
+
+imports:
+  - visor://code-talk.yaml
+
+checks:
+  # Get the user's question
+  get-question:
+    type: human-input
+    prompt: "What would you like to know about the codebase?"
+    placeholder: "e.g., How does the authentication system work?"
+
+  # Call code-talk with your project configuration
+  explore:
+    type: workflow
+    workflow: code-talk
+    criticality: internal
+    depends_on: [get-question]
+    args:
+      question: "{{ outputs['get-question'].text }}"
+
+      # Customize this for your project
+      architecture: |
+        # Project Architecture
+
+        ## Overview
+        Describe your project architecture here.
+
+        ## Key Components
+        - Component A: Description
+        - Component B: Description
+
+        ## Project IDs
+        | ID | Description |
+        |----|-------------|
+        | `my-project` | Main project codebase |
+
+        ## Key Directories
+        - `src/` - Source code
+        - `tests/` - Test files
+
+      # GitHub repository for docs (optional)
+      docs_repo: your-org/your-repo
+      docs_ref: main
+
+      # Define your projects
+      projects:
+        - id: my-project
+          repo: your-org/your-repo
+          description: |
+            Main project codebase:
+            - src/ - Source code
+            - tests/ - Test files
+
+      # Limit to single project for focused analysis
+      max_projects: 1

package/dist/examples/intent-router-workflow.yaml

@@ -0,0 +1,66 @@
+# =============================================================================
+# Example: Using intent-router for Assistant Routing
+# =============================================================================
+#
+# Usage:
+#   visor --config examples/intent-router-workflow.yaml --message "Summarize this thread"
+#
+# =============================================================================
+
+version: "1.0"
+
+imports:
+  - visor://intent-router.yaml
+
+checks:
+  ask:
+    type: human-input
+    prompt: "What should I do with this message?"
+    placeholder: "e.g., Summarize the thread and list action items"
+
+  route-intent:
+    type: workflow
+    workflow: intent-router
+    criticality: internal
+    depends_on: [ask]
+    args:
+      question: "{{ outputs['ask'].text }}"
+      intents:
+        - id: chat
+          description: general Q&A or small talk
+        - id: thread_summary
+          description: user explicitly asks for a summary of the thread
+        - id: code_help
+          description: questions about code, debugging, or implementation details
+      tags:
+        - id: jira
+          description: request references Jira tickets or needs Jira data
+        - id: confluence
+          description: request references Confluence pages or needs Confluence data
+        - id: codebase
+          description: request needs codebase or implementation details
+      routing_instructions: |
+        Prefer thread_summary when the user asks to summarize or extract action items.
+
+  chat-answer:
+    type: ai
+    depends_on: [route-intent]
+    if: "outputs['route-intent']?.intent === 'chat'"
+    prompt: |
+      Answer the user's question:
+      {{ outputs['route-intent'].topic }}
+
+  summarize-thread:
+    type: ai
+    depends_on: [route-intent]
+    if: "outputs['route-intent']?.intent === 'thread_summary'"
+    prompt: |
+      Summarize the thread and list action items.
+
+  code-help:
+    type: ai
+    depends_on: [route-intent]
+    if: "outputs['route-intent']?.intent === 'code_help'"
+    prompt: |
+      Provide a short technical explanation for:
+      {{ outputs['route-intent'].topic }}