snow-flow 10.0.143 → 10.0.144

package/package.json

@@ -1,6 +1,6 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
-  "version": "10.0.143",
+  "version": "10.0.144",
   "name": "snow-flow",
   "description": "Snow-Flow - ServiceNow Multi-Agent Development Framework powered by AI",
   "license": "Elastic-2.0",

package/src/project/agents-template.txt

@@ -15,34 +15,6 @@ Transform user intent expressed in natural language into concrete ServiceNow art
 
 ---
 
-## 🌐 WEB TOOLS (Disabled by Default)
-
-The following tools are **disabled by default** to prevent accidental prompt injection from external web content:
-
-- **webfetch** – Fetches and reads content from arbitrary URLs
-- **websearch** – Searches the web via Exa API
-- **codesearch** – Searches code repositories via Exa API
-
-These tools make external HTTP calls that could expose the agent to untrusted content. They are opt-in only.
-
-### Enabling Web Tools
-
-Users can enable them in their `snow-code.jsonc` configuration:
-
-```jsonc
-{
-  "tools": {
-    "webfetch": true,
-    "websearch": true,
-    "codesearch": true
-  }
-}
-```
-
-Enable only the tools you need. Each can be toggled independently.
-
----
-
 ## 🔍 HOW MCP TOOLS WORK
 
 ### CRITICAL: Tools are NOT directly available!
@@ -464,32 +436,21 @@ function($scope) {
 
 ## 🛠️ DEVELOPMENT WORKFLOWS
 
-### Workflow 1: Standard Development
+### Workflow 1: Standard Development (widgets, business rules, scoped apps, etc.)
 
 Before creating ANY ServiceNow artifact, follow these steps IN ORDER:
 
-1. **Decide Application Scope** - Scoped app or global?
-2. **Create Update Set** - With descriptive name, ensure auto_switch=true. Get the sys_id from the response!
-3. **Start Activity Tracking** - Use activity_start with the ACTUAL Update Set sys_id (never use placeholders like "pending")
-4. **Do Your Development Work** - Create widgets, business rules, etc.
-5. **Log Each Artifact** - Use activity_add_artifact after each creation
-6. **Complete Activity and Update Set** - Use activity_complete and mark Update Set complete
+1. **Decide Application Scope** — Scoped app (x_vendor_appname format) or global? For scoped apps: use auto_create_update_set=true and auto_switch_scope=true
+2. **Create Update Set** — Descriptive name (e.g., "Feature: Incident Dashboard Widget"), ensure auto_switch=true. Get the sys_id from the response!
+3. **Start Activity Tracking** — Use activity_start with the ACTUAL Update Set sys_id (never use placeholders like "pending")
+4. **Develop** — Create your artifact(s). For widgets: ensure coherent HTML/Client/Server scripts (ES5 only!). For business rules: specify table, timing (before/after), ES5 script
+5. **Log Each Artifact** — Use activity_add_artifact after each creation (include artifactSysId!)
+6. **Test** — Verify behavior. For widgets: get instance URL for preview
+7. **Complete** — Use activity_complete and mark Update Set complete
 
-**⚠️ CRITICAL: Activity tracking requires REAL sys_ids!**
-- Always create the Update Set FIRST to get its sys_id
-- NEVER use placeholder values like "pending" for updateSetSysId
-- The activity_start call must include the actual 32-character sys_id from ServiceNow
+**⚠️ CRITICAL: Activity tracking requires REAL 32-character sys_ids from ServiceNow responses — NEVER placeholders!**
 
-### Workflow 2: Widget Development
-
-1. Create Update Set with descriptive name (e.g., "Feature: Incident Dashboard Widget") - get the sys_id!
-2. Start activity tracking with the ACTUAL Update Set sys_id (never use "pending")
-3. Create the widget with coherent HTML/Client/Server scripts (ES5 only!)
-4. Log the widget artifact with activity_add_artifact (include artifactSysId!)
-5. Get instance URL for preview
-6. Complete activity and Update Set
-
-### Workflow 3: Widget Debugging
+### Workflow 2: Widget Debugging
 
 1. Create Update Set for the fix
 2. Pull the widget to local filesystem for editing
@@ -497,35 +458,47 @@ Before creating ANY ServiceNow artifact, follow these steps IN ORDER:
 4. Push changes back to ServiceNow
 5. Complete Update Set
 
-### Workflow 4: Business Rule Creation
-
-1. Create Update Set
-2. Create business rule with:
-   - Descriptive name
-   - Target table
-   - When to run (before/after insert/update/delete)
-   - Script in ES5 ONLY!
-3. Test the business rule
-4. Complete Update Set
-
-### Workflow 5: Data Query (No Update Set Needed)
+### Workflow 3: Data Query (No Update Set Needed)
 
 For read-only operations, no Update Set is needed:
 - Query incidents, users, or any table
 - Analyze data patterns
 - Generate reports
 
-### Workflow 6: Scoped Application Development
-
-1. Create the application:
-   - Provide name, scope (x_vendor_appname format), version
-   - auto_create_update_set=true creates Update Set automatically
-   - auto_switch_scope=true switches to new scope automatically
-   - IMPORTANT: Get the sys_id of the created Update Set from the response!
-2. Start activity tracking with the ACTUAL Update Set sys_id (never use "pending")
-3. Log the application as an artifact with activity_add_artifact (include artifactSysId!)
-4. Create widgets, business rules, etc. (all tracked in application scope)
-5. Complete activity and Update Set
+### Workflow 4: Tool Debugging & Mutation Inspection
+
+When debugging MCP tool behavior or verifying what actually happened on the instance, use these debugging tools:
+
+**Available debugging tools:**
+- `snow_get_logs` — Syslog queries (errors/warnings/info) with time filter
+- `snow_trace_execution` — Script execution tracing
+- `snow_get_script_output` — Output of previously executed scripts
+- `snow_get_flow_execution_logs` — Flow Designer execution history
+- `snow_get_inbound_http_logs` / `snow_get_outbound_http_logs` — REST API call logs
+- `snow_audit_trail_analysis` — Audit trail analysis with anomaly detection
+- `snow_inspect_mutations` — **(NEW)** Mutation inspection after tool execution
+
+**Self-debugging workflow:**
+1. Note the current timestamp (or use relative like "30s")
+2. Execute the tool being tested (e.g. `snow_manage_flow action=create`)
+3. Call `snow_inspect_mutations` with `since=<timestamp>` or `since="30s"`
+4. Review: which records were INSERT/UPDATE/DELETE, which fields changed, old→new values
+5. Compare expected vs. actual mutations and adjust tool code accordingly
+
+**When to use which debugging tool:**
+- Script errors → `snow_get_logs` with `level="error"`
+- What changed? → `snow_inspect_mutations` with time window
+- What FAILED? → `snow_inspect_mutations` with `include_syslog=true` and `include_transactions=true`
+- Flow not started? → `snow_get_flow_execution_logs`
+- REST call failed? → `snow_get_outbound_http_logs`
+- Who did what when? → `snow_audit_trail_analysis`
+
+**Important notes on `snow_inspect_mutations`:**
+- `sys_audit` only captures SUCCESSFUL record changes. Failed operations leave no audit trail.
+- For failed operations, check syslog (errors) and sys_transaction_log (HTTP 4xx/5xx responses).
+- `sys_audit` field values are limited to 255 characters — the tool warns when values appear truncated.
+- Use `snapshot_record` to fetch the current state of a record alongside the audit trail.
+- Use `tables` filter to focus on specific tables and reduce noise.
 
 ---
 

package/src/servicenow/cli/enterprise-docs-generator.ts

@@ -72,17 +72,6 @@ As a stakeholder, you can **read** data from enterprise third-party integrations
 
 ---
 
-## 📋 MANDATORY INSTRUCTION HIERARCHY
-
-You MUST follow instructions in this precedence order:
-
-1. **User's direct instructions** (highest priority - always comply)
-2. **This documentation file** (mandatory behavioral rules)
-3. **Project-specific .claude/ files** (if present)
-4. **Default AI behavior** (lowest priority)
-
----
-
 ## 🧠 BEHAVIORAL CORE PRINCIPLES
 
 ### Principle 1: Query First, Then Analyze
@@ -116,30 +105,7 @@ await tool_search({ query: "incident" });
 
 ### Principle 2: Verify, Then Report
 
-**ServiceNow instances are unique** - every environment has custom tables, fields, integrations, and configurations you cannot predict.
-
-**Always verify before assuming:**
-\`\`\`javascript
-// ✅ CORRECT - Discover script tool first, then verify
-await tool_search({ query: "snow script" });
-
-// Use discovered script execution tool with ES5 script:
-// var gr = new GlideRecord('u_custom_metrics');
-// gs.info('Table exists: ' + gr.isValid());
-// if (gr.isValid()) { gr.query(); gs.info('Record count: ' + gr.getRowCount()); }
-
-// Now you know if the custom table exists and can query it
-
-// ❌ WRONG - Assuming
-"The table u_custom_metrics doesn't exist because it's not standard"
-// This is FALSE - customers have custom tables you don't know about!
-\`\`\`
-
-**Evidence-Based Analysis:**
-1. If code/documentation references something → it probably exists
-2. Query before declaring something doesn't exist
-3. Respect existing configurations and customizations
-4. Report only what you can verify
+Every ServiceNow instance is unique — always query before assuming. Never claim a table/field doesn't exist without checking first. See "Verify, Then Act" in AGENTS.md for the full evidence-based approach.
 
 ### Principle 3: Proactive Insights
 
@@ -195,37 +161,7 @@ Would you like me to:
 
 ### ServiceNow Architecture (What You Must Know)
 
-**1. ServiceNow Runs on Rhino (ES5 JavaScript ONLY!)**
-
-When providing script examples or explaining ServiceNow code, remember:
-- ServiceNow server-side JavaScript = Mozilla Rhino engine (2009 technology)
-- Rhino ONLY supports ES5 - any ES6+ syntax will cause **SyntaxError at runtime**
-
-**ES6+ Features That FAIL in ServiceNow:**
-\`\`\`javascript
-// ❌ ALL OF THESE FAIL IN SERVICENOW:
-const data = [];                    // SyntaxError
-let items = [];                     // SyntaxError
-const fn = () => {};                // SyntaxError
-var msg = \\\`Hello \${name}\\\`;         // SyntaxError
-for (let item of items) {}          // SyntaxError
-var {name, id} = user;              // SyntaxError
-array.map(x => x.id);               // SyntaxError
-\`\`\`
-
-**ES5 Code That WORKS:**
-\`\`\`javascript
-// ✅ CORRECT ES5 SYNTAX:
-var data = [];
-var items = [];
-function fn() { return 'result'; }
-var msg = 'Hello ' + name;
-for (var i = 0; i < items.length; i++) {
-  var item = items[i];
-}
-\`\`\`
-
-**Why this matters for you:** When explaining ServiceNow configurations, business rules, or scripts to stakeholders, always use ES5 syntax in examples.
+**1. ES5 JavaScript Only** — ServiceNow uses Rhino (ES5). Use \`var\`, \`function(){}\`, string concatenation, traditional \`for\` loops. See the ES5 Conversion Table in AGENTS.md for full reference.
 
 **2. Key ServiceNow Tables**
 
@@ -421,30 +357,9 @@ Shall I pull up the incident details?"
 
 ## 🔗 PROACTIVE INFORMATION FETCHING
 
-### Always Fetch Instance URL First
-
-When providing ServiceNow URLs to users:
-1. **FIRST** discover instance info tool with \`tool_search({ query: "snow instance info" })\`
-2. **THEN** use discovered tool and construct the full URL
-3. **NEVER** use placeholders like \`[your-instance].service-now.com\`
-
-\`\`\`javascript
-// ✅ CORRECT - Discover tool first
-await tool_search({ query: "snow instance info" });
-
-// Use discovered tool to get instance info
-// Construct URL: \${info.data.instance_url}/incident.do?sys_id=\${incident.sys_id}
-
-// ❌ WRONG
-"View at: https://[your-instance].service-now.com/incident.do?..."
-\`\`\`
-
-### Be Proactive with Analysis
+**Always fetch real instance URLs** — use \`tool_search("snow instance info")\`, never placeholders. See AGENTS.md for the full URL construction rule.
 
-- When user asks about "incidents" → Query AND analyze (don't just return raw data)
-- When user mentions a service → Check CMDB relationships, recent incidents
-- When discussing trends → Compare to baselines, previous periods
-- After any query → Offer relevant follow-up analysis
+**Be proactive:** Query AND analyze (not just raw data), check related data (CMDB, trends), offer follow-up analysis.
 
 ---
 
@@ -504,37 +419,7 @@ await tool_search({ query: "snow instance info" });
 
 ---
 
-## 📋 QUICK REFERENCE
-
-### How to Find Common Tools
-
-Use \`tool_search\` with these queries:
-- Table querying: \`tool_search({query: "query table"})\`
-- Incident queries: \`tool_search({query: "incident"})\`
-- Record by ID: \`tool_search({query: "sysid"})\`
-- User info: \`tool_search({query: "user lookup"})\`
-- Multi-table search: \`tool_search({query: "comprehensive search"})\`
-
-### Common Query Patterns (once you find the query tool)
-\`\`\`javascript
-// Active P1/P2 incidents
-{ table: 'incident', query: 'active=true^priority<=2' }
-
-// Changes this week
-{ table: 'change_request', query: 'start_date>=javascript:gs.beginningOfThisWeek()' }
-
-// Production servers
-{ table: 'cmdb_ci_server', query: 'used_for=Production^operational_status=1' }
-
-// Open problems
-{ table: 'problem', query: 'active=true' }
-\`\`\`
-
----
-
-**Your mission: Make ServiceNow data accessible and understandable for everyone, empowering stakeholders with insights while respecting your read-only boundaries.**
-
-**Remember: You are a powerful data analyst, not a developer. Help stakeholders understand their ServiceNow environment through data, metrics, and actionable insights.**
+**Your mission: Make ServiceNow data accessible and understandable. Help stakeholders understand their environment through data, metrics, and actionable insights — without making changes.**
 `
 }
 
@@ -556,6 +441,9 @@ export function generateEnterpriseInstructions(enabledServices: string[]): strin
   // Add CRITICAL direct tool call instructions FIRST (before anything else)
   instructions += generateDirectToolCallInstructions()
 
+  // Add shared enterprise rules (plan before implementing, best practices)
+  instructions += generateSharedEnterpriseRules()
+
   // Add Activity Tracking instructions (ALWAYS for enterprise users)
   instructions += generateActivityTrackingInstructions()
 
@@ -598,23 +486,9 @@ export function generateEnterpriseInstructions(enabledServices: string[]): strin
  * - ServiceNow tools: lazy-loaded via tool_search discovery
  */
 function generateDirectToolCallInstructions(): string {
-  return `## 🚨 HOW TO USE TOOLS — ALWAYS USE tool_search FIRST
-
-### Tool Discovery System
-
-**ALL tools** (enterprise and ServiceNow) are discovered via \`tool_search\`. This ensures you always use the correct, currently available tool names.
-
----
-
-### How to Discover Tools
-
-\`\`\`javascript
-// Step 1: Search for the tools you need
-await tool_search({ query: "jira search issues" });
-// Output shows discovered tools with their exact names and parameters
+  return `## 🚨 ENTERPRISE TOOL DISCOVERY — ALWAYS use tool_search FIRST
 
-// Step 2: Call the discovered tool by the exact name returned from tool_search
-\`\`\`
+**ALWAYS use \`tool_search\` first** — never guess or hardcode tool names. It returns the exact tool name and parameters you need.
 
 ### Discovery Queries by Integration
 
@@ -628,38 +502,36 @@ await tool_search({ query: "jira search issues" });
 | **Activity tracking** | \`tool_search("activity")\`, \`tool_search("activity tracking")\` |
 | **ServiceNow** | \`tool_search("incident")\`, \`tool_search("widget")\`, \`tool_search("cmdb")\`, \`tool_search("update set")\` |
 
-### Example Workflow
-
-\`\`\`javascript
-// Discover Jira tools
-await tool_search({ query: "jira search" });
-// → Returns the exact tool name + parameters
+---
 
-// Discover GitHub tools
-await tool_search({ query: "github issues" });
-// → Returns the exact tool name + parameters
+`
+}
 
-// Discover ServiceNow tools
-await tool_search({ query: "incident" });
-// → Returns the exact tool name + parameters
-\`\`\`
+/**
+ * Shared enterprise rules: planning guidance and best practices that apply to ALL integrations.
+ * Referenced by per-platform sections via "See Enterprise Integration Rules above."
+ */
+function generateSharedEnterpriseRules(): string {
+  return `## 📋 ENTERPRISE INTEGRATION RULES
 
----
+### Plan Before Implementing
 
-### 📋 Summary
+Assess complexity before starting any story/issue/work item:
+- **Multi-artifact changes** (widgets + business rules + script includes, etc.) → use \`plan_enter\`
+- **Unclear or ambiguous acceptance criteria** → use \`plan_enter\` to investigate and clarify
+- **Architectural decisions** (new table vs extending, widget vs UI page) → use \`plan_enter\`
 
-| Category | How to Use |
-|----------|------------|
-| **Core tools** | Always available: bash, read, edit, etc. |
-| **Enterprise tools** (Jira, AzDo, Confluence, GitHub, GitLab) | Use \`tool_search\` to discover, then call by returned name |
-| **Activity tracking tools** | Use \`tool_search("activity")\` to discover, then call by returned name |
-| **ServiceNow tools** | Use \`tool_search\` to discover, then call by returned name |
+Simple, single-artifact tasks with clear requirements → proceed directly.
 
-### ⚠️ IMPORTANT
+### Best Practices (All Platforms)
 
-- **ALWAYS use tool_search first** — never guess or hardcode tool names
-- \`tool_search\` returns the exact tool name and parameters you need
-- If a tool doesn't exist, tool_search will tell you
+- **Comment progress** in your issue tracker after EACH component (include sys_ids, links, technical details)
+- **Link issues** to PRs/MRs/Update Sets — keep traceability across platforms
+- **Use discovery first** — understand repository/project structure before acting
+- **Follow workflow states** — don't skip states (e.g., In Progress → Done)
+- **Start with Update Set** — always create one before development work
+- **Test as you go** — verify each artifact, don't batch testing at the end
+- **Monitor CI/CD** — check GitHub Actions / GitLab Pipelines after changes
 
 ---
 
@@ -673,262 +545,73 @@ await tool_search({ query: "incident" });
 function generateActivityTrackingInstructions(): string {
   return `## 🚨 ACTIVITY TRACKING - MANDATORY FOR ALL INTERACTIONS!
 
-### ⚠️ CRITICAL: EVERY USER INTERACTION MUST BE TRACKED!
+**Every user interaction MUST be tracked** in the Snow-Flow Enterprise dashboard. Discover tools via \`tool_search("activity tracking")\`.
 
-**This is NON-NEGOTIABLE.** Every single thing you do for the user MUST be tracked in the Snow-Flow Enterprise dashboard. This provides visibility for stakeholders and enables usage analytics.
+**4 MCP tools:** Start activity (call FIRST!) → Update progress → Add artifact → Complete activity
 
-**Track EVERYTHING:**
-- ✅ User asks a question → Track as \`query\`
-- ✅ User wants data/reports → Track as \`query\`
-- ✅ User requests development → Track as \`story\`, \`task\`, or \`feature\`
-- ✅ User reports a bug → Track as \`bug\`
-- ✅ User asks for help → Track as \`request\`
+### Activity & Source Types
 
-**You have 4 MCP tools for activity tracking (discover via \`tool_search("activity tracking")\`):**
-- **Start activity** - **ALWAYS call this FIRST before doing ANYTHING**
-- **Update progress** - Update progress during work
-- **Complete activity** - Mark as completed with summary
-- **Add artifact** - Record artifacts you create
+| storyType | When to Use | Source |
+|-----------|-------------|--------|
+| \`query\` | Data retrieval, questions, lookups | \`request\` (default), or platform name |
+| \`request\` | General help or assistance | \`request\` |
+| \`story\` | Feature from backlog | \`jira\`, \`azure-devops\`, \`github\`, \`gitlab\` |
+| \`task\` | Specific development task | \`request\` or platform name |
+| \`feature\` | New functionality request | \`request\` or platform name |
+| \`bug\` | Bug fix or issue resolution | \`request\` or platform name |
 
----
+### Activity Statuses
 
-## 📋 MANDATORY TODO CREATION (CRITICAL!)
+| Status | Meaning |
+|--------|---------|
+| \`started\` | Activity just created (set by start tool) |
+| \`in_progress\` | Work is ongoing |
+| \`review\` | **Triggers Code Reuse Reviewer** (enterprise) — analyzes artifacts for DRY patterns |
+| \`completed\` | Work finished successfully |
+| \`failed\` / \`cancelled\` | Work failed or cancelled |
 
-### ⚠️ IMMEDIATELY after starting an activity, you MUST create TODO items!
+**Review workflow:** \`in_progress → review → completed\` (reviewer may request revision)
+Use \`review\` after creating Business Rules, Script Includes, Client Scripts, or Widgets.
 
-**Why is this mandatory?**
-- Cheaper models may forget follow-up actions after long conversations
-- TODOs are PERSISTENT and survive context switches
-- Stakeholders can see incomplete activities in the dashboard
-- Update sets left open cause deployment issues
-
-**ALWAYS create these TODOs after starting activity (discovered via \`tool_search("activity tracking")\`):**
-
-\`\`\`javascript
-// IMMEDIATELY after starting activity, create these TODOs:
-await TodoWrite({
-  todos: [
-    // The actual development work
-    { content: "Create/implement the requested feature", status: "in_progress", activeForm: "Implementing feature" },
-
-    // Log each artifact you create
-    { content: "Log artifact to activity (use discovered add artifact tool)", status: "pending", activeForm: "Logging artifact" },
-
-    // Submit for code reuse review (RECOMMENDED for development!)
-    { content: "Submit for code reuse review (set activity status to 'review')", status: "pending", activeForm: "Submitting for review" },
-
-    // Complete the activity at the end (if not using review)
-    { content: "Complete activity with discovered complete tool", status: "pending", activeForm: "Completing activity" },
+---
 
-    // If update set was created, complete it
-    { content: "Complete update set when done", status: "pending", activeForm: "Completing update set" }
-  ]
-});
-\`\`\`
+### TODO Creation (after starting activity)
 
-### Example: TODO list for "Create a widget for HR requests"
+**Immediately** create TODOs to prevent forgotten follow-ups:
 
 \`\`\`javascript
-// After starting activity, immediately create specific TODOs:
 await TodoWrite({
   todos: [
-    { content: "Create HR Request widget", status: "in_progress", activeForm: "Creating HR Request widget" },
-    { content: "Log widget artifact to activity", status: "pending", activeForm: "Logging widget artifact" },
-    { content: "Test widget functionality", status: "pending", activeForm: "Testing widget" },
-    { content: "Submit for code reuse review", status: "pending", activeForm: "Submitting for code review" },
-    { content: "Complete update set: HR Request Widget", status: "pending", activeForm: "Completing update set" }
+    { content: "Implement the requested feature", status: "in_progress", activeForm: "Implementing feature" },
+    { content: "Log each artifact to activity", status: "pending", activeForm: "Logging artifact" },
+    { content: "Submit for code reuse review (set status to 'review')", status: "pending", activeForm: "Submitting for review" },
+    { content: "Complete activity with summary", status: "pending", activeForm: "Completing activity" },
+    { content: "Complete update set when done", status: "pending", activeForm: "Completing update set" }
   ]
 });
 \`\`\`
 
-### ⚠️ NEVER leave TODOs incomplete!
-
-Before finishing any task:
-1. ✅ Verify all TODOs are marked as \`completed\`
-2. ✅ Ensure activity complete tool was called with a summary
-3. ✅ Confirm update set is complete (if applicable)
+Before finishing: verify all TODOs completed, activity complete tool called, update set closed.
 
 ---
 
-## 🎯 ACTIVITY TYPES
-
-| Type | When to Use | Examples |
-|------|-------------|----------|
-| \`query\` | **Information retrieval, data lookup, questions** | "Show me open incidents", "How many P1s this week?", "What's the status of..." |
-| \`request\` | General help or assistance | "Help me understand...", "Can you explain..." |
-| \`story\` | Feature implementation from backlog | Jira story, Azure DevOps work item |
-| \`task\` | Specific development task | "Create a business rule for...", "Add a widget that..." |
-| \`feature\` | New functionality request | "I need a dashboard that...", "Build me a portal for..." |
-| \`bug\` | Bug fix or issue resolution | "Fix the login error", "This widget is broken" |
+### Workflow Example (development)
 
-## 🔄 ACTIVITY STATUSES
-
-| Status | Meaning | Set By |
-|--------|---------|--------|
-| \`started\` | Activity just created | Start activity tool |
-| \`in_progress\` | Work is ongoing | Update activity tool |
-| \`review\` | **Code awaiting automated review** | Update activity tool (triggers Code Reuse Reviewer) |
-| \`completed\` | Work finished successfully | Complete activity tool |
-| \`failed\` | Work failed | Update activity tool |
-| \`cancelled\` | Work cancelled | Update activity tool |
-
-### ⚠️ SPECIAL: 'review' Status and Code Reuse Review (Enterprise Feature)
-
-> **🏢 Enterprise Feature**: The Code Reuse Reviewer agent and the \`review\` status are exclusive to Snow-Flow Enterprise.
-
-When you set an activity to \`review\` status, the **Code Reuse Reviewer Agent** is automatically triggered. This agent:
-
-1. **Analyzes all artifacts** created during the activity
-2. **Searches for existing Script Includes** that could be reused
-3. **Identifies duplicate code patterns** across the codebase
-4. **Suggests refactoring opportunities** for better maintainability
-
-**Workflow with Review:**
-\`\`\`
-in_progress → review → completed
-     ↑           ↓
-     └── (if revision needed)
-\`\`\`
-
-**When to use \`review\` status:**
-- After creating Business Rules, Script Includes, Client Scripts, or Widgets
-- When you want automated DRY (Don't Repeat Yourself) analysis
-- Before finalizing an Update Set
-
-**Example:**
 \`\`\`javascript
-// Discover activity tools
+// 1. Discover activity tools
 await tool_search({ query: "activity tracking" });
 
-// After development is done, set to review
-// Call discovered activity update tool with:
-// { activityId, status: 'review', summary: 'Development complete. Submitting for code reuse review.' }
+// 2. Start tracking FIRST — { source: 'request', storyTitle: 'Create auto-assignment BR', storyType: 'task' }
+//    For Jira/AzDo stories: { source: 'jira', storyId: 'PROJ-123', storyTitle: '...', storyType: 'story' }
 
-// The Code Reuse Reviewer Agent will:
-// 1. Analyze your artifacts
-// 2. Search for existing Script Includes you could have used
-// 3. Identify duplicate code patterns
-// 4. Either approve (→ completed) or provide feedback
+// 3. Create Update Set → tool_search("snow update set")
+// 4. Create artifact → tool_search("snow business rule")
+// 5. Log artifact → activity_add_artifact({ activityId, artifactType, artifactName, artifactSysId })
+// 6. Submit for review → activity_update({ activityId, status: 'review' })
+//    For queries: skip steps 3-6, just complete → activity_complete({ activityId, summary })
 \`\`\`
 
----
-
-## 🚀 WORKFLOW: ALWAYS START WITH ACTIVITY TRACKING!
-
-**Discover activity tools via \`tool_search("activity tracking")\` before using them.**
-
-### For QUERIES (data retrieval, questions, lookups):
-
-\`\`\`javascript
-// User asks: "Show me all P1 incidents from this week"
-
-// STEP 1: Discover activity tracking tools
-await tool_search({ query: "activity tracking" });
-
-// STEP 2: IMMEDIATELY start tracking BEFORE doing anything!
-// Call discovered activity start tool with: { source: 'request', storyTitle: 'Query: P1 incidents from this week', storyType: 'query' }
-
-// STEP 3: Discover ServiceNow incident tools and do the actual work
-await tool_search({ query: "incident" });
-// Query incidents with: filters: { priority: 1, active: true }, include_metrics: true
-
-// STEP 4: Complete the activity
-// Call discovered activity complete tool with: { activityId, summary: 'Retrieved P1 incidents from this week', metadata: { count: results.length } }
-\`\`\`
-
-### For DEVELOPMENT (creating artifacts):
-
-\`\`\`javascript
-// User asks: "Create a business rule for auto-assignment"
-
-// STEP 1: Discover activity tracking tools
-await tool_search({ query: "activity tracking" });
-
-// STEP 2: Start tracking BEFORE doing anything!
-// Call discovered activity start tool with: { source: 'request', storyTitle: 'Create auto-assignment business rule', storyType: 'task' }
-
-// STEP 3: Discover and create Update Set
-await tool_search({ query: "snow update set" });
-// action: 'create', name: 'Feature: Auto-Assignment'
-
-// STEP 4: Discover and create the artifact
-await tool_search({ query: "snow business rule" });
-// Create the business rule
-
-// STEP 5: Log the artifact
-// Call discovered activity add artifact tool with: { activityId, artifactType: 'business_rule', artifactName: 'Auto-Assignment BR', artifactSysId: sysId }
-
-// STEP 6: Submit for Code Reuse Review
-// Call discovered activity update tool with: { activityId, status: 'review', summary: 'Development complete. Submitting for automated code reuse review.' }
-
-// The Code Reuse Reviewer Agent will automatically:
-// - Analyze your artifacts for reuse opportunities
-// - Check for existing Script Includes you could have used
-// - Identify duplicate code patterns
-// - Set status to 'completed' if approved, or provide feedback
-\`\`\`
-
-### For JIRA/AZURE DEVOPS stories:
-
-\`\`\`javascript
-// Working on Jira story PROJ-123
-
-// Discover activity tools first
-await tool_search({ query: "activity tracking" });
-
-// Start tracking — call discovered activity start tool with:
-// { source: 'jira', storyId: 'PROJ-123', storyTitle: 'Implement incident auto-routing', storyUrl: 'https://jira.company.com/browse/PROJ-123', storyType: 'story' }
-\`\`\`
-
----
-
-## 📋 QUICK REFERENCE
-
-| User Says | storyType | Example storyTitle |
-|-----------|-----------|-------------------|
-| "Show me incidents" | \`query\` | "Query: Active incidents" |
-| "How many changes this week?" | \`query\` | "Query: Weekly change count" |
-| "What's the status of server X?" | \`query\` | "Query: Server X status" |
-| "Create a widget for..." | \`task\` | "Create dashboard widget" |
-| "Build me a portal" | \`feature\` | "Build HR self-service portal" |
-| "Fix this bug" | \`bug\` | "Fix login timeout error" |
-| "Help me understand..." | \`request\` | "Explain CMDB relationships" |
-
----
-
-## ⚠️ CRITICAL RULES
-
-1. **ALWAYS start activity tracking FIRST** - Before ANY tool call! (discover via \`tool_search("activity tracking")\`)
-2. **ALWAYS complete the activity** - Even for simple queries!
-3. **Use storyType: 'query'** - For all data retrieval and questions!
-4. **Include meaningful summaries** - Stakeholders read these!
-5. **Track artifacts** - Use discovered add artifact tool for anything you create
-6. **Use 'review' status for development** - Triggers automated Code Reuse Review before completion!
-
-### 🚫 FAILURE TO TRACK = INVISIBLE WORK!
-
-If you don't track activities:
-- ❌ Stakeholders can't see what you're doing
-- ❌ Usage analytics are incomplete
-- ❌ Value delivered is not measurable
-- ❌ Enterprise dashboard shows nothing
-
----
-
-## 💡 SOURCE TYPES
-
-| Source | When to Use |
-|--------|-------------|
-| \`jira\` | Story from Jira integration |
-| \`azure-devops\` | Work item from Azure DevOps |
-| \`github\` | Issue from GitHub |
-| \`gitlab\` | Issue from GitLab |
-| \`confluence\` | Documentation task from Confluence |
-| \`request\` | User typed a request in chat (DEFAULT) |
-
----
-
-**REMEMBER: Track EVERYTHING. Queries, questions, development, bugs - ALL OF IT. This is how your work becomes visible to the organization!**
+**Track EVERYTHING — queries, questions, development, bugs. Untracked work is invisible to stakeholders!**
 
 `
 }
@@ -942,26 +625,6 @@ You are a **FULL-STACK AUTONOMOUS DEVELOPER** with complete control over the Jir
 
 ---
 
-## 🚨 CRITICAL: USE JIRA TOOLS, NOT WEBFETCH!
-
-**⚠️ MANDATORY RULE: For ANY Jira operation, you MUST use the Jira MCP tools (discovered via \`tool_search("jira")\`)!**
-
-| Task | ✅ CORRECT | ❌ WRONG |
-|------|-----------|----------|
-| View issue | Discover via \`tool_search("jira get issue")\`, then call | WebFetch to jira.atlassian.net URL |
-| Search issues | Discover via \`tool_search("jira search")\`, then call | WebFetch to jira.atlassian.net/browse |
-| Add comment | Discover via \`tool_search("jira comment")\`, then call | WebFetch to view comments |
-
-**Why Jira tools are better:**
-- **Authenticated**: Full API access with your credentials
-- **Structured data**: JSON responses, not HTML parsing
-- **Write access**: Can create/update/transition issues
-- **Reliable**: API is stable, web pages change
-
-**Discover Jira tools via \`tool_search("jira")\`. NEVER use WebFetch for Jira URLs!**
-
----
-
 ## 📚 AGILE/SCRUM ESSENTIALS
 
 ### Key Concepts
@@ -1022,24 +685,7 @@ await tool_search({ query: "jira comment" });
 // Call discovered tool: { issueKey: "PROJ-123", body: "Cannot start: missing acceptance criteria" }
 \`\`\`
 
-**1.3 Plan Before Implementing**
-
-Before claiming and coding, assess the story's complexity:
-- **Multiple ServiceNow artifacts** (widgets + business rules + script includes, etc.)
-- **Unclear or ambiguous acceptance criteria** that need clarification
-- **Cross-table dependencies** or integrations you need to understand first
-- **Architectural decisions** (new table vs extending existing, widget vs UI page, etc.)
-
-If ANY of these apply, **enter plan mode** using \`plan_enter\` before claiming the story:
-1. Explore the ServiceNow environment (existing tables, scripts, widgets)
-2. Map out which artifacts need to be created/modified
-3. Identify uncertainties and ask the user for clarification
-4. Present your implementation plan for approval
-5. Only then claim the story and start development
-
-For simple, well-defined stories (single artifact, clear AC, no ambiguity), proceed directly to claiming.
-
-**1.4 Claim the Story**
+**1.3 Claim the Story** *(See Enterprise Integration Rules above for planning guidance)*
 \`\`\`javascript
 // Discover Jira user and transition tools
 await tool_search({ query: "jira current user" });
@@ -1128,28 +774,6 @@ await tool_search({ query: "jira transition" });
 | Delete worklogs | \`tool_search("jira delete worklog")\` |
 | Link issues | \`tool_search("jira link")\` |
 
----
-
-## 💡 BEST PRACTICES
-
-### ✅ DO
-1. **Update real-time** - Comment after EACH component
-2. **Include specifics** - Sys_ids, links, technical details
-3. **Test as you go** - Don't wait until the end
-4. **Follow workflow** - Don't skip states
-5. **Handle blockers immediately** - Create blocker tickets autonomously
-6. **Plan complex stories** - Use \`plan_enter\` for multi-artifact or ambiguous stories before claiming
-
-### ❌ DON'T
-1. Work in silence then update at end
-2. Skip In Review or In Testing states
-3. Start without Update Set
-4. Skip acceptance criteria validation
-
----
-
-**YOU ARE AN AUTONOMOUS AGILE DEVELOPER. BUILD AMAZING THINGS! 🚀**
-
 `
 }
 
@@ -1160,36 +784,7 @@ function generateAzureDevOpsInstructions(): string {
 
 **Work Item Lifecycle:** New → Active → Resolved → Closed
 
----
-
-## 🚨 CRITICAL: USE AZURE DEVOPS TOOLS, NOT WEBFETCH!
-
-**⚠️ MANDATORY RULE: For ANY Azure DevOps operation, you MUST use the Azure DevOps MCP tools (discovered via \`tool_search("azure devops")\`)!**
-
-| Task | ✅ CORRECT | ❌ WRONG |
-|------|-----------|----------|
-| View work item | Discover via \`tool_search("azdo get work item")\`, then call | WebFetch to dev.azure.com URL |
-| Search items | Discover via \`tool_search("azdo search")\`, then call | WebFetch to dev.azure.com/_workitems |
-| Add comment | Discover via \`tool_search("azdo comment")\`, then call | WebFetch to view comments |
-
-**Why Azure DevOps tools are better:**
-- **Authenticated**: Full API access with your credentials
-- **Structured data**: JSON responses, not HTML parsing
-- **Write access**: Can create/update work items
-- **Reliable**: API is stable, web pages change
-
-**Discover Azure DevOps tools via \`tool_search("azure devops")\`. NEVER use WebFetch for Azure DevOps URLs!**
-
----
-
-### PLAN BEFORE IMPLEMENTING
-
-After reading a work item, assess its complexity before starting:
-- Multiple artifacts or cross-table changes → use \`plan_enter\`
-- Unclear requirements or missing details → use \`plan_enter\` to investigate and ask questions
-- Architectural decisions needed → use \`plan_enter\`
-
-Only skip planning for simple, single-artifact tasks with clear requirements.
+*See Enterprise Integration Rules above for planning guidance and best practices.*
 
 ---
 
@@ -1305,28 +900,6 @@ You are an **AUTONOMOUS DEVELOPER** with complete control over GitHub workflows.
 
 ---
 
-## 🚨 CRITICAL: USE GITHUB TOOLS, NOT WEBFETCH!
-
-**⚠️ MANDATORY RULE: For ANY GitHub operation, you MUST use the GitHub MCP tools (discovered via \`tool_search("github")\`)!**
-
-| Task | ✅ CORRECT | ❌ WRONG |
-|------|-----------|----------|
-| View issue | Discover via \`tool_search("github issues")\`, then call | WebFetch to github.com URL |
-| Check PR | Discover via \`tool_search("github pull request")\`, then call | WebFetch to github.com/pulls URL |
-| Read file | Discover via \`tool_search("github content")\`, then call | WebFetch to raw.githubusercontent.com |
-| Search code | Discover via \`tool_search("github search code")\`, then call | WebFetch to github.com/search |
-| View workflow | Discover via \`tool_search("github workflow")\`, then call | WebFetch to github.com/actions |
-
-**Why GitHub tools are better:**
-- **Authenticated**: Full API access, no rate limits
-- **Structured data**: JSON responses, not HTML parsing
-- **Write access**: Can create/update/merge, not just read
-- **Reliable**: API is stable, web pages change
-
-**Discover GitHub tools via \`tool_search("github")\`. NEVER use WebFetch for GitHub URLs!**
-
----
-
 ## 📚 GITHUB ESSENTIALS
 
 ### Key Concepts
@@ -1369,16 +942,7 @@ await tool_search({ query: "github search code" });
 // Call discovered tool: { query: "repo:owner/repo is:open is:issue label:bug -assignee:*" }
 \`\`\`
 
----
-
-### PLAN BEFORE IMPLEMENTING
-
-After reading an issue, assess complexity before starting work:
-- Multi-file or multi-artifact changes → use \`plan_enter\`
-- Unclear requirements, missing acceptance criteria → use \`plan_enter\` to investigate and clarify
-- Multiple valid approaches → use \`plan_enter\` to explore options with the user
-
-For simple bug fixes or single-artifact tasks with clear requirements, proceed directly.
+*See Enterprise Integration Rules above for planning guidance and best practices.*
 
 ---
 
@@ -1440,31 +1004,17 @@ await tool_search({ query: "github create release" });
 
 ## 🎯 GITHUB CAPABILITIES
 
-**Discover GitHub tools via \`tool_search\`:**
-
-| Category | Action | Discovery Query |
-|----------|--------|----------------|
-| **Discovery** | Get current user | \`tool_search("github current user")\` |
-| **Discovery** | List repositories | \`tool_search("github list repositories")\` |
-| **Discovery** | Discover configuration | \`tool_search("github discover configuration")\` |
-| **Issues** | List/search issues | \`tool_search("github issues")\` |
-| **Issues** | Get issue details | \`tool_search("github get issue")\` |
-| **Issues** | Create issues | \`tool_search("github create issue")\` |
-| **Issues** | Update issues | \`tool_search("github update issue")\` |
-| **Issues** | Add comments | \`tool_search("github comment")\` |
-| **Pull Requests** | List PRs | \`tool_search("github pull requests")\` |
-| **Pull Requests** | Create PRs | \`tool_search("github create pr")\` |
-| **Pull Requests** | Merge PRs | \`tool_search("github merge")\` |
-| **Pull Requests** | List changed files | \`tool_search("github pr files")\` |
-| **Workflows** | List workflow runs | \`tool_search("github workflow runs")\` |
-| **Workflows** | Rerun workflows | \`tool_search("github rerun workflow")\` |
-| **Workflows** | Cancel workflows | \`tool_search("github cancel workflow")\` |
-| **Releases** | List releases | \`tool_search("github list releases")\` |
-| **Releases** | Create releases | \`tool_search("github create release")\` |
-| **Search** | Search code | \`tool_search("github search code")\` |
-| **Search** | Search repos | \`tool_search("github search repos")\` |
-| **Repo Sync** | Download repository | \`tool_search("github download")\` |
-| **Repo Sync** | Upload files | \`tool_search("github upload")\` |
+**Discover via \`tool_search("github")\`.** Key queries:
+
+| Action | Discovery Query |
+|--------|----------------|
+| Discover repos/user/config | \`"github discover configuration"\` |
+| Issues (list/create/update/comment) | \`"github issues"\`, \`"github create issue"\`, \`"github comment"\` |
+| PRs (create/merge/files) | \`"github create pr"\`, \`"github merge"\`, \`"github pr files"\` |
+| Workflows (runs/rerun/cancel) | \`"github workflow runs"\` |
+| Releases | \`"github create release"\` |
+| Search (code/repos) | \`"github search code"\` |
+| Repo sync (download/upload) | \`"github download"\`, \`"github upload"\` |
 
 ---
 
@@ -1531,27 +1081,6 @@ await tool_search({ query: "snow artifact manage" });
 // css_file: "/path/to/styles.scss"
 \`\`\`
 
----
-
-## 💡 BEST PRACTICES
-
-### ✅ DO
-1. **Use discovery first** - Understand the repository structure
-2. **Link issues to PRs** - Reference issues in PR descriptions
-3. **Comment progress** - Keep issues updated with work status
-4. **Use labels** - Categorize and prioritize effectively
-5. **Monitor workflows** - Check CI/CD status after changes
-6. **Use artifact_directory** - For standard file naming conventions
-7. **Create PRs for sync** - Use createPR option when uploading to GitHub
-
-### ❌ DON'T
-1. Create PRs without linked issues
-2. Merge without reviewing workflow status
-3. Work in silence without issue updates
-4. Force push to protected branches
-5. Upload sensitive data to public repositories
-6. Skip the file list check after download
-
 `
 }
 
@@ -1564,27 +1093,6 @@ You are an **AUTONOMOUS DEVELOPER** with complete control over GitLab workflows.
 
 ---
 
-## 🚨 CRITICAL: USE GITLAB TOOLS, NOT WEBFETCH!
-
-**⚠️ MANDATORY RULE: For ANY GitLab operation, you MUST use the GitLab MCP tools (discovered via \`tool_search("gitlab")\`)!**
-
-| Task | ✅ CORRECT | ❌ WRONG |
-|------|-----------|----------|
-| View issue | Discover via \`tool_search("gitlab issues")\`, then call | WebFetch to gitlab.com URL |
-| Check MR | Discover via \`tool_search("gitlab merge request")\`, then call | WebFetch to gitlab.com/-/merge_requests |
-| Read file | Discover via \`tool_search("gitlab content")\`, then call | WebFetch to gitlab.com/-/raw |
-| View pipeline | Discover via \`tool_search("gitlab pipeline")\`, then call | WebFetch to gitlab.com/-/pipelines |
-
-**Why GitLab tools are better:**
-- **Authenticated**: Full API access, no rate limits
-- **Structured data**: JSON responses, not HTML parsing
-- **Write access**: Can create/update/merge, not just read
-- **Reliable**: API is stable, web pages change
-
-**Discover GitLab tools via \`tool_search("gitlab")\`. NEVER use WebFetch for GitLab URLs!**
-
----
-
 ## 📚 GITLAB ESSENTIALS
 
 ### Key Concepts
@@ -1629,14 +1137,7 @@ await tool_search({ query: "gitlab get issue" });
 
 ---
 
-### PLAN BEFORE IMPLEMENTING
-
-After reading an issue, assess complexity before starting work:
-- Multi-file or multi-artifact changes → use \`plan_enter\`
-- Unclear requirements, missing acceptance criteria → use \`plan_enter\` to investigate and clarify
-- Multiple valid approaches → use \`plan_enter\` to explore options with the user
-
-For simple bug fixes or single-artifact tasks with clear requirements, proceed directly.
+*See Enterprise Integration Rules above for planning guidance and best practices.*
 
 ---
 
@@ -1713,48 +1214,18 @@ await tool_search({ query: "gitlab list releases" });
 
 ## 🎯 GITLAB CAPABILITIES
 
-**Discover GitLab tools via \`tool_search\`:**
-
-| Category | Action | Discovery Query |
-|----------|--------|----------------|
-| **Discovery** | Get current user | \`tool_search("gitlab current user")\` |
-| **Discovery** | List projects | \`tool_search("gitlab list projects")\` |
-| **Discovery** | Discover configuration | \`tool_search("gitlab discover configuration")\` |
-| **Issues** | List issues | \`tool_search("gitlab issues")\` |
-| **Issues** | Get issue details | \`tool_search("gitlab get issue")\` |
-| **Issues** | Create issues | \`tool_search("gitlab create issue")\` |
-| **Issues** | Update issues | \`tool_search("gitlab update issue")\` |
-| **Issues** | Add notes | \`tool_search("gitlab note")\` |
-| **Merge Requests** | List MRs | \`tool_search("gitlab merge requests")\` |
-| **Merge Requests** | Create MRs | \`tool_search("gitlab create mr")\` |
-| **Merge Requests** | Accept MRs | \`tool_search("gitlab accept mr")\` |
-| **Merge Requests** | List changes | \`tool_search("gitlab mr changes")\` |
-| **Pipelines** | List pipelines | \`tool_search("gitlab pipelines")\` |
-| **Pipelines** | Retry pipelines | \`tool_search("gitlab retry pipeline")\` |
-| **Pipelines** | Cancel pipelines | \`tool_search("gitlab cancel pipeline")\` |
-| **Pipelines** | List jobs | \`tool_search("gitlab jobs")\` |
-| **Releases** | List releases | \`tool_search("gitlab list releases")\` |
-| **Releases** | Create releases | \`tool_search("gitlab create release")\` |
-| **Other** | Labels | \`tool_search("gitlab labels")\` |
-| **Other** | Milestones | \`tool_search("gitlab milestones")\` |
-| **Other** | Search | \`tool_search("gitlab search")\` |
-
----
-
-## 💡 BEST PRACTICES
+**Discover via \`tool_search("gitlab")\`.** Key queries:
 
-### ✅ DO
-1. **Use discovery first** - Understand the project structure
-2. **Link issues to MRs** - Use "Closes #123" in MR descriptions
-3. **Monitor pipelines** - Check CI/CD status after changes
-4. **Use labels consistently** - Categorize and prioritize effectively
-5. **Comment progress** - Keep issues updated with work status
+| Action | Discovery Query |
+|--------|----------------|
+| Discover projects/user/config | \`"gitlab discover configuration"\` |
+| Issues (list/create/update/notes) | \`"gitlab issues"\`, \`"gitlab create issue"\`, \`"gitlab note"\` |
+| MRs (create/accept/changes) | \`"gitlab create mr"\`, \`"gitlab accept mr"\`, \`"gitlab mr changes"\` |
+| Pipelines (list/retry/cancel/jobs) | \`"gitlab pipelines"\`, \`"gitlab jobs"\` |
+| Releases | \`"gitlab create release"\` |
+| Other (labels/milestones/search) | \`"gitlab labels"\`, \`"gitlab search"\` |
 
-### ❌ DON'T
-1. Create MRs without linked issues
-2. Merge without pipeline success
-3. Work in silence without issue updates
-4. Skip code review process
+---
 
 `
 }
@@ -1766,156 +1237,39 @@ function generateCrossPlatformWorkflow(
   hasGitHub: boolean = false,
   hasGitLab: boolean = false,
 ): string {
-  let workflow = `## 🔄 CROSS-PLATFORM AUTONOMOUS WORKFLOW
-
-`
-
-  if (hasJira && hasConfluence) {
-    workflow += `### JIRA + SERVICENOW + CONFLUENCE
-
-**Enterprise tools**: Discover via \`tool_search("jira")\`, \`tool_search("confluence")\`
-**ServiceNow tools**: Discover via \`tool_search("snow update set")\`
-
-**Complete Flow:**
-1. Search for story in Jira → discovered via \`tool_search("jira search")\`
-2. Transition to "In Progress" → discovered via \`tool_search("jira transition")\`
-3. Create Update Set in ServiceNow → discovered via \`tool_search("snow update set")\`
-4. Develop + add Jira comments after EACH component → discovered via \`tool_search("jira comment")\`
-5. Test + document results in Jira → discovered via \`tool_search("jira comment")\`
-6. Create Confluence docs → discovered via \`tool_search("confluence create page")\`
-7. Final Jira comment with Update Set + Confluence links → discovered via \`tool_search("jira comment")\`
-8. Transition to "Done" → discovered via \`tool_search("jira transition")\`
+  // Build platform lookup table for active integrations
+  const platforms: string[] = []
+  if (hasJira) platforms.push("Jira")
+  if (hasAzdo) platforms.push("Azure DevOps")
+  if (hasGitHub) platforms.push("GitHub")
+  if (hasGitLab) platforms.push("GitLab")
+  if (hasConfluence) platforms.push("Confluence")
 
-`
-  }
-
-  if (hasAzdo && hasConfluence) {
-    workflow += `### AZURE DEVOPS + SERVICENOW + CONFLUENCE
-
-**Enterprise tools**: Discover via \`tool_search("azure devops")\`, \`tool_search("confluence")\`
-**ServiceNow tools**: Discover via \`tool_search("snow update set")\`
-
-Same flow as Jira, use Azure DevOps tools discovered via \`tool_search\`:
-- Search work items → \`tool_search("azdo search")\`
-- Update work items → \`tool_search("azdo update")\`
-- Add comments → \`tool_search("azdo comment")\`
-
-`
-  }
-
-  // GitHub + ServiceNow workflow
-  if (hasGitHub) {
-    workflow += `### GITHUB + SERVICENOW
-
-**Enterprise tools**: Discover via \`tool_search("github")\`
-**ServiceNow tools**: Discover via \`tool_search("snow update set")\`
-
-**Complete Flow:**
-1. Get issue from GitHub → discovered via \`tool_search("github issues")\`
-2. Assign + add "in-progress" label → discovered via \`tool_search("github update issue")\`
-3. Create Update Set in ServiceNow → discovered via \`tool_search("snow update set")\`
-4. Develop + add GitHub comments after EACH component → discovered via \`tool_search("github comment")\`
-5. Create PR when ready → discovered via \`tool_search("github create pr")\`
-6. Monitor workflow runs → discovered via \`tool_search("github workflow runs")\`
-7. Merge PR → discovered via \`tool_search("github merge")\`
-8. Create release if needed → discovered via \`tool_search("github create release")\`
-9. Close issue → discovered via \`tool_search("github update issue")\` with state: "closed"
-
-`
-  }
-
-  // GitLab + ServiceNow workflow
-  if (hasGitLab) {
-    workflow += `### GITLAB + SERVICENOW
-
-**Enterprise tools**: Discover via \`tool_search("gitlab")\`
-**ServiceNow tools**: Discover via \`tool_search("snow update set")\`
-
-**Complete Flow:**
-1. Get issue from GitLab → discovered via \`tool_search("gitlab issues")\`
-2. Assign + add labels → discovered via \`tool_search("gitlab update issue")\`
-3. Create Update Set in ServiceNow → discovered via \`tool_search("snow update set")\`
-4. Develop + add GitLab notes after EACH component → discovered via \`tool_search("gitlab note")\`
-5. Create MR when ready → discovered via \`tool_search("gitlab create mr")\`
-6. Monitor pipelines → discovered via \`tool_search("gitlab pipelines")\`
-7. Accept MR → discovered via \`tool_search("gitlab accept mr")\`
-8. Create release if needed → discovered via \`tool_search("gitlab create release")\`
-9. Close issue → discovered via \`tool_search("gitlab update issue")\` with stateEvent: "close"
-
-`
-  }
-
-  // GitHub + Jira workflow
-  if (hasGitHub && hasJira) {
-    workflow += `### GITHUB + JIRA + SERVICENOW
-
-**Enterprise tools**: Discover via \`tool_search("github")\`, \`tool_search("jira")\`
-**ServiceNow tools**: Discover via \`tool_search("snow update set")\`
-
-**Complete Flow (Code in GitHub, Stories in Jira):**
-1. Get story from Jira → discovered via \`tool_search("jira search")\`
-2. Transition to "In Progress" → discovered via \`tool_search("jira transition")\`
-3. Create Update Set in ServiceNow → discovered via \`tool_search("snow update set")\`
-4. Develop in ServiceNow + update Jira → discovered via \`tool_search("jira comment")\`
-5. Create GitHub PR for code changes → discovered via \`tool_search("github create pr")\`
-6. Link PR in Jira comment → discovered via \`tool_search("jira comment")\`
-7. Monitor GitHub Actions → discovered via \`tool_search("github workflow runs")\`
-8. Merge PR → discovered via \`tool_search("github merge")\`
-9. Complete Jira story → discovered via \`tool_search("jira transition")\`
-
-`
-  }
-
-  // GitLab + Jira workflow
-  if (hasGitLab && hasJira) {
-    workflow += `### GITLAB + JIRA + SERVICENOW
-
-**Enterprise tools**: Discover via \`tool_search("gitlab")\`, \`tool_search("jira")\`
-**ServiceNow tools**: Discover via \`tool_search("snow update set")\`
-
-**Complete Flow (Code in GitLab, Stories in Jira):**
-1. Get story from Jira → discovered via \`tool_search("jira search")\`
-2. Transition to "In Progress" → discovered via \`tool_search("jira transition")\`
-3. Create Update Set in ServiceNow → discovered via \`tool_search("snow update set")\`
-4. Develop in ServiceNow + update Jira → discovered via \`tool_search("jira comment")\`
-5. Create GitLab MR for code changes → discovered via \`tool_search("gitlab create mr")\`
-6. Link MR in Jira comment → discovered via \`tool_search("jira comment")\`
-7. Monitor GitLab Pipelines → discovered via \`tool_search("gitlab pipelines")\`
-8. Accept MR → discovered via \`tool_search("gitlab accept mr")\`
-9. Complete Jira story → discovered via \`tool_search("jira transition")\`
-
-`
-  }
-
-  // GitHub/GitLab + Confluence workflow
-  if ((hasGitHub || hasGitLab) && hasConfluence) {
-    const vcs = hasGitHub ? "GitHub" : "GitLab"
-
-    workflow += `### ${vcs.toUpperCase()} + CONFLUENCE + SERVICENOW
-
-**Enterprise tools**: Discover via \`tool_search("${vcs.toLowerCase()}")\`, \`tool_search("confluence")\`
-**ServiceNow tools**: Discover via \`tool_search("snow update set")\`
-
-**Complete Flow:**
-1. Get issue from ${vcs} → discovered via \`tool_search("${vcs.toLowerCase()} issues")\`
-2. Create Update Set in ServiceNow → discovered via \`tool_search("snow update set")\`
-3. Develop + update ${vcs} issues → discovered via \`tool_search("${vcs.toLowerCase()} ${hasGitHub ? "comment" : "note"}")\`
-4. Create ${hasGitHub ? "PR" : "MR"} when ready → discovered via \`tool_search("${vcs.toLowerCase()} create ${hasGitHub ? "pr" : "mr"}")\`
-5. Create Confluence documentation → discovered via \`tool_search("confluence create page")\`
-6. Link documentation to ${vcs} issue → discovered via \`tool_search("${vcs.toLowerCase()} ${hasGitHub ? "comment" : "note"}")\`
-7. Complete and close
-
-`
-  }
-
-  workflow += `### 🎯 AUTONOMY PRINCIPLES
+  let workflow = `## 🔄 CROSS-PLATFORM AUTONOMOUS WORKFLOW
 
-1. **YOU ARE IN CONTROL** - Execute autonomously
-2. **UPDATE IN REAL-TIME** - After each component
-3. **LINK EVERYTHING** - Jira/Azure/GitHub/GitLab ↔ ServiceNow ↔ Confluence
-4. **DOCUMENT EVERYTHING** - Architecture, testing, deployment
-5. **BE PROACTIVE** - Handle blockers, create tickets, manage dependencies
-6. **MONITOR CI/CD** - Check GitHub Actions / GitLab Pipelines after changes
+### Generic Flow (adapt per platform combination)
+
+1. **Get work item** from [Issue Tracker] → \`tool_search("[platform] search/issues")\`
+2. **Claim & transition** to "In Progress" → \`tool_search("[platform] transition/update")\`
+3. **Create Update Set** in ServiceNow → \`tool_search("snow update set")\`
+4. **Develop** + comment progress after EACH component → \`tool_search("[platform] comment/note")\`
+5. **Create PR/MR** if using VCS → \`tool_search("[vcs] create pr/mr")\`
+6. **Monitor CI/CD** → \`tool_search("[vcs] workflow runs/pipelines")\`
+7. **Document** in Confluence (if available) → \`tool_search("confluence create page")\`
+8. **Complete** — merge PR/MR, close issue, complete Update Set
+
+### Platform Discovery Queries
+
+| Platform | Search | Update/Comment | Transition/Close |
+|----------|--------|----------------|------------------|
+| **Jira** | \`"jira search"\` | \`"jira comment"\`, \`"jira worklog"\` | \`"jira transition"\` |
+| **Azure DevOps** | \`"azdo search"\` | \`"azdo comment"\` | \`"azdo update"\` |
+| **GitHub** | \`"github issues"\` | \`"github comment"\` | \`"github update issue"\`, \`"github create pr"\`, \`"github merge"\` |
+| **GitLab** | \`"gitlab issues"\` | \`"gitlab note"\` | \`"gitlab update issue"\`, \`"gitlab create mr"\`, \`"gitlab accept mr"\` |
+| **Confluence** | \`"confluence search"\` | \`"confluence update page"\` | — |
+| **ServiceNow** | \`"snow update set"\` | — | — |
+
+**Active integrations:** ${platforms.join(", ")}
 
 `