@exaudeus/workrail 3.14.0 → 3.16.0

package/workflows/scoped-documentation-workflow.json

@@ -2,7 +2,14 @@
   "id": "scoped-documentation-workflow",
   "name": "Scoped Documentation Workflow",
   "version": "2.0.0",
-  "description": "Create documentation for a SINGLE, BOUNDED subject with strict scope enforcement. Perfect for: one class/component, one integration point, one mechanism, one architecture decision. Prevents documentation sprawl through continuous boundary validation.",
+  "description": "Use this to create documentation for a single, bounded subject — one class, one integration point, one mechanism, or one architecture decision. Enforces strict scope discipline to prevent documentation sprawl.",
+  "about": "## Scoped Documentation Workflow\n\nUse this when you need to document **one specific, bounded subject** -- a single class, one integration contract, a particular algorithm, an architecture decision, or a single workflow step. The defining feature of this workflow is strict scope discipline: it explicitly defines what is \"in scope\" (explained in detail) vs. \"out of scope\" (referenced only, never explained), and enforces that boundary throughout analysis and writing.\n\n### What it produces\n\n- A focused documentation file covering the subject in depth.\n- A `SCOPE_MAP.md` that shows what is documented here vs. referenced elsewhere.\n- An optional `MAINTENANCE_NOTES.md` with guidance on when to update.\n\n### When to use it\n\n- You want docs for one class, module, mechanism, or concept -- not a whole system.\n- You've had documentation sprawl problems before and want enforced boundaries.\n- You're building a documentation set incrementally, one subject at a time.\n- The subject has clear integration points with other systems that should be referenced, not re-explained.\n\n### When NOT to use it\n\n- You need documentation that intentionally spans multiple components -- use the Document Creation workflow instead.\n- You're updating an existing doc -- use the Documentation Update workflow.\n\n### How to get good results\n\n- The first step asks you to review and approve a scope contract. Be precise here -- the whole workflow defends this boundary.\n- Out-of-scope items should already have their own documentation. If they don't, note that so the scope map can reflect it.\n- If you find the approved scope was too narrow or too broad during the workflow, you can request a scope renegotiation.",
+  "examples": [
+    "Document the RateLimiter class: its API, configuration options, and failure behavior",
+    "Write docs for the OAuth token refresh mechanism, scoped to our implementation only",
+    "Document the ADR for our choice to use event sourcing in the orders domain",
+    "Create a focused reference for the retry policy configuration in the HTTP client"
+  ],
   "clarificationPrompts": [
     "What specifically do you want to document? (feature, component, library, mechanism, interaction, architecture, process, etc.)",
     "Who will read this documentation? (team members, external users, new developers, architects, etc.)",
@@ -178,4 +185,4 @@
       "hasValidation": true
     }
   ]
-}
+}

package/workflows/test-artifact-loop-control.json

@@ -59,8 +59,7 @@
       "assessmentConsequences": [
         {
           "when": {
-            "dimensionId": "confidence",
-            "equalsLevel": "low"
+            "anyEqualsLevel": "low"
           },
           "effect": {
             "kind": "require_followup",

package/workflows/ui-ux-design-workflow.json

@@ -0,0 +1,334 @@
+{
+  "id": "ui-ux-design-workflow",
+  "name": "UI/UX Design Workflow (v1 \u2022 Process-Enforced \u2022 Evidence-Driven)",
+  "version": "0.1.0",
+  "description": "Design UI/UX from scratch with enforced process. Makes problem framing structurally required before solution proposals, forces exploration of multiple design directions before convergence, and applies reviewer families for information architecture, UX laws, accessibility, edge cases, and content. Output: a design spec concrete enough to implement or review.",
+  "about": "## UI/UX Design Workflow\n\nThis workflow produces a design spec for a new feature, screen, component, or interaction. It is built around a single principle: problem framing must happen before any solutions are proposed. The workflow makes this structurally impossible to skip, which prevents the most common failure mode in AI-assisted design  -- going straight from \"I need a settings screen\" to a layout without ever asking who uses it or what they are trying to do.\n\n**What it does:**\nPhase 0 frames the problem by reading existing code patterns and asking only what tools cannot answer. Phase 1 generates 2-3 genuinely different design directions before any one is chosen. Phases 2-5 run parallel reviewer families  -- information architecture, UX laws (Hick's Law, Miller's Law, Fitts's Law, and others), accessibility (specific WCAG requirements, not just \"follow WCAG\"), edge cases (empty, error, loading, first-use), and content quality  -- then synthesize their findings, resolve contradictions, and write a spec only after all hard quality gates pass.\n\n**When to use it:**\n- You need to design a new screen, feature, or non-trivial component\n- You want explicit coverage of accessibility, edge states, and UX laws, not just a layout sketch\n- You need a spec concrete enough for an engineer to implement or a designer to review\n- Simple single-component changes also work through a lighter direct-spec path\n\n**What it produces:**\nA design spec with 8 sections: design decision, information architecture, interaction design, all element states, specific accessibility requirements, content copy, reviewer findings with citations, and open questions that still require human visual review.\n\n**How to get good results:**\nPoint the workflow to your codebase so it can read existing components and patterns. Provide the design system location if it is not in the repo. Share any known user pain points or research. The workflow will surface what it cannot determine on its own.",
+  "examples": [
+    "Design the empty state and onboarding flow for a new team dashboard feature",
+    "Design a settings panel for notification preferences with accessibility requirements",
+    "Design the error and loading states for the file upload component",
+    "Redesign the search results screen to reduce cognitive load for first-time users"
+  ],
+  "recommendedPreferences": {
+    "recommendedAutonomy": "guided",
+    "recommendedRiskPolicy": "conservative"
+  },
+  "features": [
+    "wr.features.subagent_guidance"
+  ],
+  "preconditions": [
+    "User has a UI/UX design task: a new feature, screen, component, or interaction to design.",
+    "Agent has enough context about the product or codebase to understand existing patterns.",
+    "A human will review the design spec before implementation begins."
+  ],
+  "metaGuidance": [
+    "PROCESS IS THE VALUE: the biggest failure mode in AI-assisted design is skipping to solutions before understanding the problem. This workflow makes that structurally impossible. Do not shortcut Phase 0.",
+    "EVIDENCE OVER PLATITUDES: every finding must cite a specific element from the context packet. 'Consider reducing cognitive load' is not a finding. 'The settings panel has 14 options, violating Miller\u2019s Law (7\u00b12)' is a finding.",
+    "SIMPLE CRITERIA: designComplexity=Simple is only valid for a single existing component with a minor change, no new user flows, no information architecture changes, and no new interaction patterns. If uncertain, classify upward.",
+    "HONEST LIMITS: this workflow produces a text-based design spec. It cannot produce visual mockups, conduct usability testing, or verify visual quality. Say so explicitly in the handoff and flag what still needs human visual review.",
+    "CONTEXT BLINDNESS: if the user has not provided design system, existing component patterns, or platform conventions, surface this gap in Phase 0 and ask. Do not silently design without this context.",
+    "V2 DURABILITY: use output.notesMarkdown as the primary durable record. Do not create DESIGN_CONTEXT.md or other sidecar files.",
+    "OWNERSHIP: the main agent owns synthesis, design decision, and final spec. Reviewer families provide independent perspectives only.",
+    "EDGE CASES ARE NOT OPTIONAL: every interactive design must address empty state, error state, loading state, and first-use. If any of these are not addressed in the spec, the spec is incomplete."
+  ],
+  "steps": [
+    {
+      "id": "phase-0-problem-framing",
+      "title": "Phase 0: Frame the Problem and Establish Design Context",
+      "promptBlocks": {
+        "goal": "Understand the design problem, the users it serves, and the context it exists in before proposing any solutions.",
+        "constraints": [
+          "Explore the codebase to find existing patterns, components, and conventions before asking questions.",
+          "Ask only for information tools cannot answer: design system location, target platform if ambiguous, user research or known pain points.",
+          "Do not propose any design solutions in this phase."
+        ],
+        "procedure": [
+          "Read the codebase to understand: existing UI components and patterns, platform (web/iOS/Android/cross-platform), tech stack constraints that affect UI, and any existing design documentation.",
+          "Identify the primary user and their goal: who will use this feature, what are they trying to accomplish, and what context are they in when they use it?",
+          "Identify constraints: technical limitations, existing design system components to use, platform conventions to follow, accessibility requirements, and any stated non-goals.",
+          "Identify the existing design context: what screens or components does this new design connect to? What does the user do before and after?",
+          "Surface any context you could not determine from tools: missing design system information, unknown user research, unclear platform target.",
+          "Classify designComplexity: Simple = single existing component, minor change, no new flows, no IA changes. Standard = new screen or component, moderate scope. Complex = new user flows, significant IA changes, multiple screens or interaction patterns.",
+          "Set needsReviewerBundle = true for Standard and Complex; false for Simple."
+        ],
+        "outputRequired": {
+          "notesMarkdown": "User and goal, design constraints, existing context, gaps that need human input, and complexity classification with rationale.",
+          "context": "Capture userGoals, userConstraints, existingDesignContext, designComplexity, needsReviewerBundle, designContextGaps, and openQuestions."
+        },
+        "verify": [
+          "The user and their goal are explicit before any design work begins.",
+          "designComplexity is classified with a concrete reason, not a guess.",
+          "Any missing context (design system, platform, user research) is surfaced, not silently assumed."
+        ]
+      },
+      "requireConfirmation": true
+    },
+    {
+      "id": "phase-1-design-directions",
+      "title": "Phase 1: Explore Design Directions",
+      "runCondition": {
+        "var": "needsReviewerBundle",
+        "equals": true
+      },
+      "promptBlocks": {
+        "goal": "Generate 2-3 genuinely different design directions before committing to any one of them.",
+        "constraints": [
+          "Directions must be genuinely different \u2014 not variations of the same pattern with different labels.",
+          "Each direction needs an information architecture sketch: how is content organized, what is the primary navigation path, what is the visual hierarchy?",
+          "Do not select a direction in this phase. Exploration comes before convergence."
+        ],
+        "procedure": [
+          "Generate Direction A: the most conventional approach that follows existing platform patterns and design system. Low risk, familiar to users.",
+          "Generate Direction B: an approach that prioritizes the primary user goal differently \u2014 different IA, different entry point, or different interaction model.",
+          "Generate Direction C (if designComplexity=Complex): a third direction that challenges the assumptions in A and B \u2014 a more radical rethinking of the problem.",
+          "For each direction, describe: (1) the primary IA sketch (main sections, navigation path, content hierarchy), (2) the core interaction model (how does the user accomplish their goal?), (3) the key tradeoffs relative to user goals and constraints.",
+          "After describing all directions, restate which user goals each direction serves well and where each direction is weakest."
+        ],
+        "outputRequired": {
+          "notesMarkdown": "All design directions with IA sketches and explicit tradeoffs. No recommendation yet.",
+          "context": "Capture designDirections (array of direction objects with name, iaSketch, interactionModel, tradeoffs)."
+        },
+        "verify": [
+          "At least 2 directions are genuinely different in IA or interaction model, not just surface styling.",
+          "Each direction has an explicit IA sketch and tradeoff analysis.",
+          "No direction has been selected or recommended yet."
+        ]
+      },
+      "requireConfirmation": true
+    },
+    {
+      "id": "phase-2-freeze-context-packet",
+      "title": "Phase 2: Freeze Context Packet and Select Reviewer Families",
+      "runCondition": {
+        "var": "needsReviewerBundle",
+        "equals": true
+      },
+      "promptBlocks": {
+        "goal": "Assemble a neutral context packet that all reviewer families will use as shared truth, then declare which reviewers are needed.",
+        "constraints": [
+          "The context packet is neutral \u2014 it presents the design problem and directions without advocating for any one.",
+          "Select the direction to develop further before running reviewers \u2014 reviewers evaluate a specific direction, not an abstract problem.",
+          "All 5 reviewer families are active for Complex designs; IA and UX laws reviewers are always included for Standard."
+        ],
+        "procedure": [
+          "Select the design direction to develop: based on the user goals and constraints from Phase 0, choose the direction from Phase 1 that best fits. State which direction and the specific reason it was chosen over the others.",
+          "Assemble the designContextPacket containing: (1) the selected direction's IA sketch and interaction model, (2) user goals and constraints from Phase 0, (3) existing design context (what connects to this), (4) platform and tech constraints, (5) any known user pain points or requirements.",
+          "Select reviewer families: IA reviewer (always), UX laws reviewer (always), accessibility reviewer (Standard and Complex), edge cases reviewer (Standard and Complex), content reviewer (Complex or when copy is a significant design concern).",
+          "Set selectedReviewerFamilies and needsReviewerBundle context."
+        ],
+        "outputRequired": {
+          "notesMarkdown": "Selected direction with rationale, frozen context packet summary, and selected reviewer families with justification.",
+          "context": "Capture designContextPacket, selectedDirection, selectedReviewerFamilies, contradictionCount (init 0), evidenceWeakCount (init 0)."
+        },
+        "verify": [
+          "A specific direction is selected with a concrete reason.",
+          "The context packet is complete enough that a reviewer can evaluate the design without regathering context.",
+          "Reviewer family selection is justified by designComplexity."
+        ]
+      },
+      "requireConfirmation": false
+    },
+    {
+      "id": "phase-3-reviewer-bundle",
+      "title": "Phase 3: Parallel Reviewer Bundle",
+      "runCondition": {
+        "var": "needsReviewerBundle",
+        "equals": true
+      },
+      "promptBlocks": {
+        "goal": "Run the selected reviewer families in parallel against the frozen context packet, then synthesize their findings as evidence rather than verdicts.",
+        "constraints": [
+          [
+            {
+              "kind": "ref",
+              "refId": "wr.refs.synthesis_under_disagreement"
+            }
+          ],
+          "Every finding must cite a specific element, component, or decision from the designContextPacket. Generic UX advice without a specific reference is not a valid finding.",
+          "Reviewer output is raw evidence. The main agent owns synthesis and design decisions."
+        ],
+        "procedure": [
+          "Before delegating, restate the selected direction and the user goal it serves best.",
+          "Spawn one WorkRail Executor per selected reviewer family simultaneously. Each executor receives: the designContextPacket, their specific reviewer mission, and the finding format requirement.",
+          "Reviewer family missions: (1) IA reviewer \u2014 evaluate content hierarchy, navigation paths, grouping logic, and information scent against user goals; cite specific IA decisions; (2) UX laws reviewer \u2014 check each relevant law: Hick's Law (decision count), Miller's Law (working memory), Jakob's Law (familiar patterns), Fitts's Law (target size and distance), Peak-End Rule (emotional journey), Tesler's Law (irreducible complexity), Von Restorff Effect (visual differentiation of important elements); cite specific violations or confirmations; (3) accessibility reviewer \u2014 check WCAG requirements: color contrast ratios (4.5:1 normal, 3:1 large text), keyboard navigation path, touch target sizes (44x44px minimum), screen reader labels, focus indicators, animation controls; produce specific requirements not 'follow WCAG'; (4) edge cases reviewer \u2014 for each interactive element, explicitly address: empty state (no data), error state (failed action), loading state, first-use/onboarding, offline or degraded state, destructive actions; flag any state not addressed in the current design; (5) content reviewer \u2014 evaluate every label, button copy, placeholder, error message, and helper text against clarity, user language vs. technical jargon, and actionability of error messages.",
+          "After receiving all executor outputs, synthesize explicitly: what was confirmed, what was new, what looks weak or generic, and what has citations vs. what is speculation.",
+          "Set evidenceWeakCount to the number of findings without specific citations."
+        ],
+        "outputRequired": {
+          "notesMarkdown": "Per-family synthesis, contradiction flags, evidence quality assessment, and overall finding count.",
+          "context": "Capture reviewerFindings (per-family), contradictionCount, evidenceWeakCount."
+        },
+        "verify": [
+          "Every declared reviewer family has at least one substantive finding.",
+          "Reviewer output was synthesized by the main agent, not adopted verbatim.",
+          "Findings with specific citations are distinguished from generic advice."
+        ]
+      },
+      "requireConfirmation": false
+    },
+    {
+      "id": "phase-4-synthesis-loop",
+      "type": "loop",
+      "title": "Phase 4: Synthesis and Contradiction Resolution",
+      "loop": {
+        "type": "while",
+        "conditionSource": {
+          "kind": "artifact_contract",
+          "contractRef": "wr.contracts.loop_control",
+          "loopId": "design_synthesis_loop"
+        },
+        "maxIterations": 2
+      },
+      "body": [
+        {
+          "id": "phase-4a-resolve",
+          "title": "Resolve Contradictions and Strengthen Weak Evidence",
+          "promptBlocks": {
+            "goal": "Resolve any contradictions between reviewer findings and strengthen evidence-weak findings before finalizing the design decision.",
+            "constraints": [
+              "Contradiction resolution is main-agent work. Do not delegate synthesis.",
+              "If two reviewers disagree about the same design element, explicitly adjudicate which evidence is stronger."
+            ],
+            "procedure": [
+              "List any contradictions: cases where two reviewer families disagree about the same design element or recommendation.",
+              "Adjudicate each contradiction: which evidence is more specific, which is better grounded in the design context packet?",
+              "For any finding with evidenceWeak=true, either find the specific citation yourself or downgrade the finding to advisory.",
+              "Update reviewerFindings with resolved contradictions and strengthened evidence.",
+              "Update contradictionCount to 0 when resolved; update evidenceWeakCount."
+            ],
+            "outputRequired": {
+              "notesMarkdown": "Contradictions resolved, evidence-weak findings addressed, updated finding summary.",
+              "context": "Capture contradictionCount, evidenceWeakCount, reviewerFindings."
+            },
+            "verify": [
+              "Each resolved contradiction names which evidence won and why.",
+              "No unresolved contradictions remain."
+            ]
+          },
+          "requireConfirmation": false
+        },
+        {
+          "id": "phase-4b-loop-decision",
+          "title": "Synthesis Loop Decision",
+          "promptBlocks": {
+            "goal": "Decide whether another synthesis pass is needed.",
+            "constraints": [
+              "Use trigger rules, not vibes."
+            ],
+            "procedure": [
+              "Continue if contradictionCount > 0.",
+              "Otherwise continue if evidenceWeakCount > 3 (more than 3 findings still lack specific citations).",
+              "Otherwise stop."
+            ],
+            "outputRequired": {
+              "artifact": "Emit a `wr.loop_control` artifact for `design_synthesis_loop` with `decision` set to `continue` or `stop`."
+            },
+            "verify": [
+              "The loop does not stop while material contradictions remain unresolved."
+            ]
+          },
+          "outputContract": {
+            "contractRef": "wr.contracts.loop_control"
+          },
+          "requireConfirmation": false
+        }
+      ],
+      "runCondition": {
+        "var": "needsReviewerBundle",
+        "equals": true
+      }
+    },
+    {
+      "id": "phase-5-hard-gate",
+      "title": "Phase 5: Hard Gate Check",
+      "runCondition": {
+        "var": "needsReviewerBundle",
+        "equals": true
+      },
+      "promptBlocks": {
+        "goal": "Verify all quality gates pass before writing the design spec.",
+        "constraints": [
+          "If any gate fails, fix the underlying issue before advancing \u2014 do not write the spec over known gaps."
+        ],
+        "procedure": [
+          "Gate 1 \u2014 Evidence citations: confirm every finding in reviewerFindings cites a specific design element from the context packet. Flag any finding that is generic advice without a specific reference and either improve it or mark it advisory-only.",
+          "Gate 2 \u2014 Reviewer coverage: confirm every declared reviewer family has at least one substantive finding. If a family has no findings, state explicitly why (e.g., 'IA reviewer found no issues \u2014 the single-screen design has no navigation structure to evaluate').",
+          "Gate 3 \u2014 Edge case coverage: confirm empty state, error state, loading state, and first-use are addressed for each interactive element in the selected design direction. List any that are not yet addressed.",
+          "Gate 4 \u2014 Accessibility specificity: confirm accessibility requirements are listed as specific constraints (color contrast ratios, touch target sizes, keyboard tab order), not as a generic 'follow WCAG' instruction."
+        ],
+        "outputRequired": {
+          "notesMarkdown": "Gate check results: which passed, which failed, what was fixed.",
+          "context": "Capture hardGatesPassed, hardGateFailures."
+        },
+        "verify": [
+          "hardGatesPassed = true before advancing to spec writing.",
+          "Any gate failures were fixed, not silently accepted."
+        ]
+      },
+      "requireConfirmation": false
+    },
+    {
+      "id": "phase-5-design-spec-handoff",
+      "title": "Phase 5: Design Spec",
+      "promptBlocks": {
+        "goal": "Produce a complete design spec ready for engineering review and implementation.",
+        "constraints": [
+          "Every interactive element must have its edge cases addressed in the spec.",
+          "Accessibility requirements must be specific, not 'follow WCAG'.",
+          "The spec must acknowledge what still requires human visual review and what requires usability testing.",
+          "Do not drift into implementation planning (specific component libraries, code) unless explicitly asked."
+        ],
+        "procedure": [
+          "Write the design spec covering: (1) Design Decision \u2014 which direction was chosen and the specific reason it was chosen over the others; (2) Information Architecture \u2014 content hierarchy, navigation structure, primary user path; (3) Interaction Design \u2014 how each interactive element works, what triggers what, what feedback the user gets; (4) States \u2014 for each element: default, hover/focus, loading, error, empty, first-use, disabled; (5) Accessibility Requirements \u2014 specific requirements (color contrast ratios, keyboard tab order, touch target sizes, screen reader labels); (6) Content \u2014 all copy, labels, error messages, placeholders, and onboarding text; (7) Reviewer Findings \u2014 per-dimension findings with citations that the design should address or has already addressed; (8) Open Questions \u2014 what still needs human input (visual design, usability testing, design system component availability).",
+          "Close the spec by naming: what visual review a human designer should perform, and what this workflow cannot verify (visual quality, usability, emotional feel)."
+        ],
+        "outputRequired": {
+          "notesMarkdown": "Complete design spec with all 8 sections. Open questions and human-review items explicitly listed."
+        },
+        "verify": [
+          "All 8 spec sections are present and substantive.",
+          "Every interactive element has states addressed.",
+          "Accessibility requirements are specific, not generic.",
+          "Open questions acknowledge the limits of agent-generated design specs."
+        ]
+      },
+      "requireConfirmation": false,
+      "runCondition": {
+        "var": "needsReviewerBundle",
+        "equals": true
+      }
+    },
+    {
+      "id": "phase-simple-design",
+      "title": "Simple Path: Direct Design Spec",
+      "runCondition": {
+        "var": "needsReviewerBundle",
+        "equals": false
+      },
+      "promptBlocks": {
+        "goal": "Produce a focused design spec for a simple, bounded change without the full reviewer pipeline.",
+        "constraints": [
+          "Simple means: single existing component, minor change, no new flows, no IA changes.",
+          "If during spec writing you discover the change is more complex than classified, stop, update designComplexity to Standard, set needsReviewerBundle=true, and return to Phase 1.",
+          "Even simple changes must address: error state, empty state if applicable, accessibility."
+        ],
+        "procedure": [
+          "Write the design spec: what changes, why, the specific interaction or visual change, any states affected, and the accessibility impact.",
+          "Apply quick UX checks: does the change violate any obvious UX laws (Fitts's Law for target size, consistency with nearby elements)? Is the copy clear and in user language?",
+          "Note what a human reviewer should visually verify."
+        ],
+        "outputRequired": {
+          "notesMarkdown": "Focused design spec: what changes, why, states, accessibility impact, and what needs visual review."
+        },
+        "verify": [
+          "The change is genuinely simple by the stated criteria.",
+          "Error and empty states are addressed if applicable.",
+          "Accessibility impact is stated."
+        ]
+      },
+      "requireConfirmation": false
+    }
+  ],
+  "validatedAgainstSpecVersion": 3
+}

package/workflows/workflow-diagnose-environment.json

@@ -2,7 +2,13 @@
   "id": "workflow-diagnose-environment",
   "name": "Diagnostic: Environment & Subagents",
   "version": "1.0.0",
-  "description": "Automated capability detection for Agentic IDEs. Probes for subagent access and generates a local configuration file.",
+  "description": "Use this to diagnose MCP server, tool availability, or environment configuration issues. Probes for subagent access and generates a local configuration file.",
+  "about": "## Environment Diagnostic Workflow\n\nThis is a short, self-contained diagnostic that checks what capabilities are actually available in the current workspace  -- specifically whether subagent delegation works and whether WorkRail tools are accessible to those subagents.\n\n**What it does:**\nThe workflow actively probes for subagent access by attempting to contact a subagent and have it list available tools. Based on the result, it classifies the environment into one of three tiers: full delegation (Tier 3), proxy mode where subagents exist but lack tool access (Tier 2), or solo mode with no subagents available (Tier 1). It then writes a `.workrail/config.json` file recording the detected capability tier so other workflows can make informed delegation decisions.\n\n**When to use it:**\n- You are setting up WorkRail in a new workspace for the first time\n- A workflow that relies on subagent delegation is not working as expected\n- You suspect MCP server configuration is wrong but are not sure what tier you are in\n- You want a persistent record of what the current environment can actually do\n\n**What it produces:**\nA `.workrail/config.json` file with the detected mode (`delegate`, `proxy`, or `solo`) and subagent names if discovered. A summary of what capabilities were found.\n\n**How to get good results:**\nRun this workflow before starting complex multi-agent workflows. It takes only two steps and requires no input from you beyond starting it.",
+  "examples": [
+    "Check if subagent delegation is available in this workspace",
+    "Set up WorkRail config for a new project environment",
+    "Diagnose why delegation-dependent workflows are falling back to solo mode"
+  ],
   "steps": [
     {
       "id": "step-0-probe-capabilities",