@exaudeus/workrail 3.14.0 → 3.16.0

package/workflows/presentation-creation.json

@@ -1,165 +1,172 @@
 {
-    "id": "presentation-creation",
-    "name": "Presentation Creation Workflow",
-    "version": "1.0.0",
-    "description": "Guides you through creating a compelling, audience-grounded presentation. Covers audience analysis, content strategy, slide structure, content development, and delivery preparation. Tool-agnostic: output works with PowerPoint, Google Slides, Keynote, or any other presentation tool.",
-    "preconditions": [
-        "You have a clear presentation topic or objective.",
-        "You know roughly who your audience is.",
-        "You have access to any source materials or data you plan to reference."
-    ],
-    "clarificationPrompts": [
-        "What is the main objective or key message of your presentation?",
-        "Who is your target audience and what is their professional context?"
-    ],
-    "metaGuidance": [
-        "Ground every decision in your audience profile. Generic presentations fail because they are not written for anyone specific.",
-        "Each step should explicitly reference outputs from the previous step to avoid boilerplate drift.",
-        "Prioritize clarity over completeness. A tight presentation that lands one message beats a comprehensive one that loses the audience.",
-        "Build in engagement moments throughout, not just at the opening.",
-        "Every section should pass the 'so what?' test: if the audience cannot articulate why they should care, cut or reframe.",
-        "Always have a clear call-to-action. Tell the audience what you want them to do or believe after your presentation.",
-        "Test all technical elements well before your presentation day.",
-        "Prepare contingency plans for common problems: technology failures, timing overruns, tough questions."
-    ],
-    "steps": [
-        {
-            "id": "audience-and-context-analysis",
-            "title": "Audience & Context Analysis",
-            "promptBlocks": {
-                "goal": "Build a concrete audience profile and context map that every downstream step will rely on. Shallow audience analysis is the root cause of generic presentations.",
-                "constraints": [
-                    "Be specific, not categorical. 'Senior engineers at a fintech startup' is useful; 'technical professionals' is not.",
-                    "Address both explicit needs (what they asked for) and implicit needs (what they actually need to hear).",
-                    "Consider the broader context: what happens before and after your presentation? What mood will the audience be in?"
-                ],
-                "procedure": [
-                    "Define the audience: professional background, expertise level, role and seniority mix, and any relevant cultural or organizational context.",
-                    "Identify audience motivations: what do they want to learn or decide? What pain points or pressures are they carrying into the room?",
-                    "Analyze the presentation context: event type (conference, internal meeting, client pitch, webinar), setting (in-person, remote, hybrid), time constraints, and follow-up expectations.",
-                    "Define success: what does a successful outcome look like for both you and the audience? What specific action or belief shift are you aiming for?",
-                    "Identify risks: what might cause the audience to disengage, push back, or leave confused?"
-                ],
-                "outputRequired": {
-                    "audienceProfile": "A concise profile covering: demographics and expertise, motivations and pain points, context and setting, success definition, and key engagement risks."
-                },
-                "verify": [
-                    "Does every section contain specific, actionable detail rather than generic categories?",
-                    "Could you use this profile to make a real content decision right now?"
-                ]
-            },
-            "requireConfirmation": true
+  "id": "presentation-creation",
+  "name": "Presentation Creation Workflow",
+  "version": "1.0.0",
+  "description": "Use this to create a compelling presentation. Covers audience analysis, content strategy, slide structure, and delivery preparation. Output works with any presentation tool.",
+  "about": "## Presentation Creation Workflow\n\nUse this to build a compelling, audience-specific presentation from scratch -- whether for a conference talk, internal strategy review, client pitch, or team demo. The workflow grounds every content decision in a concrete audience profile, so the result is written for real people in a real context rather than a generic slide deck.\n\n### What it produces\n\n- An audience profile and context map.\n- A content strategy with a single core message, supporting arguments, and a call-to-action.\n- A numbered slide outline with content types and timing estimates.\n- Full slide content and speaker notes for every slide.\n- Backup slides for anticipated deep-dive questions.\n- A delivery preparation plan including practice schedule, Q&A prep, and technical checklist.\n\n### When to use it\n\n- You are building a presentation that needs to persuade, inform, or motivate a specific audience.\n- You want structured help moving from \"I have a topic\" to \"I have a complete, rehearsal-ready deck.\"\n- The presentation has real stakes -- a client pitch, a leadership review, a conference talk.\n\n### When NOT to use it\n\n- You just need to slap a few bullets onto slides quickly -- this workflow is for presentations where quality matters.\n\n### How to get good results\n\n- The more specific you are about your audience, the better the content strategy will be. \"Engineering managers at a Series B fintech\" beats \"technical people.\"\n- The workflow has two confirmation gates: after the audience profile and after the slide outline. Use these to redirect before content gets written.\n- Bring source materials, data, and any existing slides you want to incorporate -- the content development step can ingest these.",
+  "examples": [
+    "Create a 20-minute conference talk on migrating a monolith to microservices for a senior engineering audience",
+    "Build a 10-slide investor pitch deck for our Series A fundraise",
+    "Prepare a quarterly product roadmap presentation for internal stakeholders",
+    "Create a client workshop deck introducing our platform migration methodology"
+  ],
+  "preconditions": [
+    "You have a clear presentation topic or objective.",
+    "You know roughly who your audience is.",
+    "You have access to any source materials or data you plan to reference."
+  ],
+  "clarificationPrompts": [
+    "What is the main objective or key message of your presentation?",
+    "Who is your target audience and what is their professional context?"
+  ],
+  "metaGuidance": [
+    "Ground every decision in your audience profile. Generic presentations fail because they are not written for anyone specific.",
+    "Each step should explicitly reference outputs from the previous step to avoid boilerplate drift.",
+    "Prioritize clarity over completeness. A tight presentation that lands one message beats a comprehensive one that loses the audience.",
+    "Build in engagement moments throughout, not just at the opening.",
+    "Every section should pass the 'so what?' test: if the audience cannot articulate why they should care, cut or reframe.",
+    "Always have a clear call-to-action. Tell the audience what you want them to do or believe after your presentation.",
+    "Test all technical elements well before your presentation day.",
+    "Prepare contingency plans for common problems: technology failures, timing overruns, tough questions."
+  ],
+  "steps": [
+    {
+      "id": "audience-and-context-analysis",
+      "title": "Audience & Context Analysis",
+      "promptBlocks": {
+        "goal": "Build a concrete audience profile and context map that every downstream step will rely on. Shallow audience analysis is the root cause of generic presentations.",
+        "constraints": [
+          "Be specific, not categorical. 'Senior engineers at a fintech startup' is useful; 'technical professionals' is not.",
+          "Address both explicit needs (what they asked for) and implicit needs (what they actually need to hear).",
+          "Consider the broader context: what happens before and after your presentation? What mood will the audience be in?"
+        ],
+        "procedure": [
+          "Define the audience: professional background, expertise level, role and seniority mix, and any relevant cultural or organizational context.",
+          "Identify audience motivations: what do they want to learn or decide? What pain points or pressures are they carrying into the room?",
+          "Analyze the presentation context: event type (conference, internal meeting, client pitch, webinar), setting (in-person, remote, hybrid), time constraints, and follow-up expectations.",
+          "Define success: what does a successful outcome look like for both you and the audience? What specific action or belief shift are you aiming for?",
+          "Identify risks: what might cause the audience to disengage, push back, or leave confused?"
+        ],
+        "outputRequired": {
+          "audienceProfile": "A concise profile covering: demographics and expertise, motivations and pain points, context and setting, success definition, and key engagement risks."
         },
-        {
-            "id": "content-strategy",
-            "title": "Content Strategy",
-            "promptBlocks": {
-                "goal": "Define the core message and argument structure that will guide every slide and talking point. Using your audience profile from the previous step, build a content strategy grounded in their specific needs.",
-                "constraints": [
-                    "Start with one core message — a single, memorable sentence. Everything else should support it.",
-                    "Supporting arguments should directly address the audience motivations and pain points you identified.",
-                    "The narrative arc should feel natural for this audience in this context — not a generic template unless it actually fits."
-                ],
-                "procedure": [
-                    "State your core message: one clear, memorable sentence that captures the single most important thing you want the audience to take away.",
-                    "Define 3-5 supporting arguments that reinforce your core message. For each, identify the key evidence, example, or story you will use.",
-                    "Design the narrative arc: how will you take the audience from where they are now to where you want them to be? Map the logical and emotional journey.",
-                    "Plan your engagement hooks: surprising statistics, thought-provoking questions, or moments of genuine interaction that break up information delivery.",
-                    "Define your call-to-action: what specific thing do you want the audience to do, believe, or decide after your presentation?"
-                ],
-                "outputRequired": {
-                    "contentStrategy": "Core message (one sentence), supporting arguments with evidence, narrative arc description, engagement hooks, and call-to-action."
-                },
-                "verify": [
-                    "Does every supporting argument trace back to a specific audience need from your audience profile?",
-                    "Does the narrative arc feel designed for this audience, or does it feel like a template?"
-                ]
-            },
-            "requireConfirmation": false
+        "verify": [
+          "Does every section contain specific, actionable detail rather than generic categories?",
+          "Could you use this profile to make a real content decision right now?"
+        ]
+      },
+      "requireConfirmation": true
+    },
+    {
+      "id": "content-strategy",
+      "title": "Content Strategy",
+      "promptBlocks": {
+        "goal": "Define the core message and argument structure that will guide every slide and talking point. Using your audience profile from the previous step, build a content strategy grounded in their specific needs.",
+        "constraints": [
+          "Start with one core message — a single, memorable sentence. Everything else should support it.",
+          "Supporting arguments should directly address the audience motivations and pain points you identified.",
+          "The narrative arc should feel natural for this audience in this context — not a generic template unless it actually fits."
+        ],
+        "procedure": [
+          "State your core message: one clear, memorable sentence that captures the single most important thing you want the audience to take away.",
+          "Define 3-5 supporting arguments that reinforce your core message. For each, identify the key evidence, example, or story you will use.",
+          "Design the narrative arc: how will you take the audience from where they are now to where you want them to be? Map the logical and emotional journey.",
+          "Plan your engagement hooks: surprising statistics, thought-provoking questions, or moments of genuine interaction that break up information delivery.",
+          "Define your call-to-action: what specific thing do you want the audience to do, believe, or decide after your presentation?"
+        ],
+        "outputRequired": {
+          "contentStrategy": "Core message (one sentence), supporting arguments with evidence, narrative arc description, engagement hooks, and call-to-action."
         },
-        {
-            "id": "slide-structure",
-            "title": "Slide Structure & Flow",
-            "promptBlocks": {
-                "goal": "Turn your content strategy into a numbered slide outline with clear purpose, content type, and rough timing for each slide. This becomes the blueprint for content development.",
-                "constraints": [
-                    "One key idea per slide. If a slide is trying to say two things, split it.",
-                    "Plan for pacing: balance information-dense slides with breathing room and interaction moments.",
-                    "Think about how the slides will work if someone reads them later without you — titles should be informative, not just labels."
-                ],
-                "procedure": [
-                    "Opening (1-3 slides): attention-grabbing hook, context framing, and agenda or roadmap.",
-                    "Core content blocks: group your supporting arguments into logical sections. For each slide, specify: title, main content type (bullets, chart, image, diagram, quote), and whether it has an interaction moment.",
-                    "Transitions between major sections: a single bridging slide that signals the shift and re-grounds the audience.",
-                    "Closing (2-3 slides): synthesis of core message, call-to-action, next steps or contact information.",
-                    "For each slide, add an estimated time in minutes and mark which slides need significant visual design work."
-                ],
-                "outputRequired": {
-                    "slideOutline": "A numbered slide outline. Each entry: slide number, title, content type, estimated time, and any special notes."
-                },
-                "verify": [
-                    "Does the outline tell a coherent story from opening to close?",
-                    "Does the pacing feel right for the stated time budget?",
-                    "Is there at least one engagement moment in the first third of the presentation?"
-                ]
-            },
-            "requireConfirmation": true
+        "verify": [
+          "Does every supporting argument trace back to a specific audience need from your audience profile?",
+          "Does the narrative arc feel designed for this audience, or does it feel like a template?"
+        ]
+      },
+      "requireConfirmation": false
+    },
+    {
+      "id": "slide-structure",
+      "title": "Slide Structure & Flow",
+      "promptBlocks": {
+        "goal": "Turn your content strategy into a numbered slide outline with clear purpose, content type, and rough timing for each slide. This becomes the blueprint for content development.",
+        "constraints": [
+          "One key idea per slide. If a slide is trying to say two things, split it.",
+          "Plan for pacing: balance information-dense slides with breathing room and interaction moments.",
+          "Think about how the slides will work if someone reads them later without you — titles should be informative, not just labels."
+        ],
+        "procedure": [
+          "Opening (1-3 slides): attention-grabbing hook, context framing, and agenda or roadmap.",
+          "Core content blocks: group your supporting arguments into logical sections. For each slide, specify: title, main content type (bullets, chart, image, diagram, quote), and whether it has an interaction moment.",
+          "Transitions between major sections: a single bridging slide that signals the shift and re-grounds the audience.",
+          "Closing (2-3 slides): synthesis of core message, call-to-action, next steps or contact information.",
+          "For each slide, add an estimated time in minutes and mark which slides need significant visual design work."
+        ],
+        "outputRequired": {
+          "slideOutline": "A numbered slide outline. Each entry: slide number, title, content type, estimated time, and any special notes."
         },
-        {
-            "id": "content-development",
-            "title": "Content Development",
-            "promptBlocks": {
-                "goal": "Write the actual presentation content — slide text and speaker notes — following the approved outline. Every piece of content should be grounded in your audience profile and core message.",
-                "constraints": [
-                    "Write for the ear, not the eye. Slide text should be sparse; speaker notes should sound natural when spoken aloud.",
-                    "Use active voice and concrete language. Replace abstractions with specific examples.",
-                    "Prepare backup content for questions or extended time: 2-3 extra slides that can be shown if needed."
-                ],
-                "procedure": [
-                    "For each slide in your outline, write the visible slide content: headline, key bullets or visual description, and any data or quotes.",
-                    "Write speaker notes for each slide: talking points, transitions to the next slide, and timing cues.",
-                    "Develop your key stories and examples in full: the narrative, the specific detail that makes it vivid, and the connection back to your core message.",
-                    "Prepare interaction scripts: questions for audience polls or discussion, expected responses, and how you will synthesize them back into your presentation.",
-                    "Write backup slides for anticipated deep-dive questions on your most complex or contentious points."
-                ],
-                "outputRequired": {
-                    "slideContent": "Full slide content and speaker notes for every slide in the outline.",
-                    "backupSlides": "Backup slides for anticipated deep-dive questions."
-                },
-                "verify": [
-                    "Does every slide's content trace back to the core message and the audience's needs?",
-                    "Do the speaker notes sound like something you would actually say?"
-                ]
-            },
-            "askForFiles": true,
-            "requireConfirmation": false
+        "verify": [
+          "Does the outline tell a coherent story from opening to close?",
+          "Does the pacing feel right for the stated time budget?",
+          "Is there at least one engagement moment in the first third of the presentation?"
+        ]
+      },
+      "requireConfirmation": true
+    },
+    {
+      "id": "content-development",
+      "title": "Content Development",
+      "promptBlocks": {
+        "goal": "Write the actual presentation content — slide text and speaker notes — following the approved outline. Every piece of content should be grounded in your audience profile and core message.",
+        "constraints": [
+          "Write for the ear, not the eye. Slide text should be sparse; speaker notes should sound natural when spoken aloud.",
+          "Use active voice and concrete language. Replace abstractions with specific examples.",
+          "Prepare backup content for questions or extended time: 2-3 extra slides that can be shown if needed."
+        ],
+        "procedure": [
+          "For each slide in your outline, write the visible slide content: headline, key bullets or visual description, and any data or quotes.",
+          "Write speaker notes for each slide: talking points, transitions to the next slide, and timing cues.",
+          "Develop your key stories and examples in full: the narrative, the specific detail that makes it vivid, and the connection back to your core message.",
+          "Prepare interaction scripts: questions for audience polls or discussion, expected responses, and how you will synthesize them back into your presentation.",
+          "Write backup slides for anticipated deep-dive questions on your most complex or contentious points."
+        ],
+        "outputRequired": {
+          "slideContent": "Full slide content and speaker notes for every slide in the outline.",
+          "backupSlides": "Backup slides for anticipated deep-dive questions."
         },
-        {
-            "id": "delivery-preparation",
-            "title": "Delivery Preparation",
-            "promptBlocks": {
-                "goal": "Create a delivery preparation plan tailored to your specific presentation context: the format (in-person, remote, recorded), the venue, and your personal readiness.",
-                "constraints": [
-                    "Adapt this plan to the actual delivery context. Remote and in-person presentations have very different risk profiles.",
-                    "Practice advice should be actionable, not generic. 'Practice out loud three times with slides' is useful; 'be confident' is not.",
-                    "Q&A preparation matters as much as the main content for high-stakes presentations."
-                ],
-                "procedure": [
-                    "Define your practice schedule: how many run-throughs you need, at what level of realism (slides only vs. full setup), and target dates.",
-                    "Set timing benchmarks: target time for each major section with acceptable variance. Identify which sections you can expand or compress if needed.",
-                    "Prepare for technical setup: what equipment you need, what to test in advance, and what backup plans you have if something fails.",
-                    "Anticipate the top 5-10 questions you are likely to receive and draft short, confident responses for each.",
-                    "Plan your post-presentation follow-up: how will you share materials, continue conversations, and measure whether your call-to-action was effective?"
-                ],
-                "outputRequired": {
-                    "deliveryPlan": "Practice schedule, timing benchmarks, technical setup and backup plans, Q&A preparation, and follow-up plan."
-                },
-                "verify": [
-                    "Is this plan specific to your actual delivery context, or would it apply to any presentation?",
-                    "Have you accounted for the most likely failure modes given your setting?"
-                ]
-            },
-            "requireConfirmation": false
-        }
-    ]
-}
+        "verify": [
+          "Does every slide's content trace back to the core message and the audience's needs?",
+          "Do the speaker notes sound like something you would actually say?"
+        ]
+      },
+      "askForFiles": true,
+      "requireConfirmation": false
+    },
+    {
+      "id": "delivery-preparation",
+      "title": "Delivery Preparation",
+      "promptBlocks": {
+        "goal": "Create a delivery preparation plan tailored to your specific presentation context: the format (in-person, remote, recorded), the venue, and your personal readiness.",
+        "constraints": [
+          "Adapt this plan to the actual delivery context. Remote and in-person presentations have very different risk profiles.",
+          "Practice advice should be actionable, not generic. 'Practice out loud three times with slides' is useful; 'be confident' is not.",
+          "Q&A preparation matters as much as the main content for high-stakes presentations."
+        ],
+        "procedure": [
+          "Define your practice schedule: how many run-throughs you need, at what level of realism (slides only vs. full setup), and target dates.",
+          "Set timing benchmarks: target time for each major section with acceptable variance. Identify which sections you can expand or compress if needed.",
+          "Prepare for technical setup: what equipment you need, what to test in advance, and what backup plans you have if something fails.",
+          "Anticipate the top 5-10 questions you are likely to receive and draft short, confident responses for each.",
+          "Plan your post-presentation follow-up: how will you share materials, continue conversations, and measure whether your call-to-action was effective?"
+        ],
+        "outputRequired": {
+          "deliveryPlan": "Practice schedule, timing benchmarks, technical setup and backup plans, Q&A preparation, and follow-up plan."
+        },
+        "verify": [
+          "Is this plan specific to your actual delivery context, or would it apply to any presentation?",
+          "Have you accounted for the most likely failure modes given your setting?"
+        ]
+      },
+      "requireConfirmation": false
+    }
+  ]
+}

package/workflows/production-readiness-audit.json

@@ -1,8 +1,15 @@
 {
   "id": "production-readiness-audit",
-  "name": "Production Readiness Audit (v2 • Evidence-Driven Readiness Review)",
+  "name": "Production Readiness Audit (v2 \u2022 Evidence-Driven Readiness Review)",
   "version": "0.1.0",
-  "description": "Audit a bounded codebase scope for debugging risk, runtime readiness, stale or misleading implementation surfaces, technical debt, and anything else that would keep it from being honestly production-ready.",
+  "description": "Use this to audit a codebase scope for production readiness. Checks debugging correctness, runtime operability, artifact realism, technical debt, and anything that would prevent honest production deployment.",
+  "about": "## Production Readiness Audit\n\nThis workflow performs a structured, evidence-driven audit to answer one question honestly: is this code actually ready for production? It goes beyond style and lint -- it looks for debugging correctness, runtime operability under real conditions, artifact realism (stale code, fake completeness, placeholder behavior), maintainability debt, test and observability gaps, and security or performance risks.\n\n**What it does:**\nThe workflow bounds the audit scope, states a readiness hypothesis, freezes a neutral fact packet, then runs parallel reviewer families -- each specializing in a different readiness dimension. It reconciles contradictions through an evidence loop and produces a final verdict: `ready`, `ready_with_conditions`, `not_ready`, or `inconclusive`.\n\n**When to use it:**\n- Before shipping a new service, feature, or major refactor to production\n- When a codebase has been under rapid development and you want an honest readiness check before a launch deadline\n- When onboarding to a codebase and wanting a structured assessment of its production posture\n- When a post-incident review surfaces questions about whether the system was truly ready\n\n**What it produces:**\nA verdict with a confidence band, a prioritized list of blocker-grade and major findings, debugging leads, runtime and operational risk callouts, artifact-realism concerns (misleading completeness, stale docs, dead paths), a coverage ledger by audit domain, and a remediation order with specific follow-up recommendations.\n\n**How to get good results:**\nProvide a clear scope -- a service name, a module path, or a feature boundary. The narrower and more concrete the scope, the sharper the findings. If \"production-ready\" has a specific meaning for your team (e.g. SLA requirements, specific deployment constraints), mention it. The workflow will try to infer the production bar from repo patterns and context, but explicit criteria improve accuracy.",
+  "examples": [
+    "Audit the notifications service for production readiness before the Q3 launch",
+    "Check if the new checkout flow feature is ready to ship -- focus on runtime operability and error handling",
+    "Production readiness review of the auth module after the recent login refactor",
+    "Assess whether the data ingestion pipeline is ready for production given the volume targets in the launch brief"
+  ],
   "recommendedPreferences": {
     "recommendedAutonomy": "guided",
     "recommendedRiskPolicy": "conservative"
@@ -43,7 +50,10 @@
         "goal": "Build the minimum complete understanding needed to audit readiness honestly.",
         "constraints": [
           [
-            { "kind": "ref", "refId": "wr.refs.notes_first_durability" }
+            {
+              "kind": "ref",
+              "refId": "wr.refs.notes_first_durability"
+            }
           ],
           "Use tools first. Ask only for true scope or permission gaps you cannot resolve yourself.",
           "Separate in-scope code from adjacent noise before you classify rigor or risk."
@@ -67,8 +77,14 @@
       },
       "requireConfirmation": {
         "or": [
-          { "var": "scopeShape", "equals": "whole_codebase" },
-          { "var": "riskLevel", "equals": "High" }
+          {
+            "var": "scopeShape",
+            "equals": "whole_codebase"
+          },
+          {
+            "var": "riskLevel",
+            "equals": "High"
+          }
         ]
       }
     },
@@ -103,7 +119,10 @@
         "goal": "Freeze a neutral readiness fact packet and decide how much reviewer-family parallelism is warranted.",
         "constraints": [
           [
-            { "kind": "ref", "refId": "wr.refs.notes_first_durability" }
+            {
+              "kind": "ref",
+              "refId": "wr.refs.notes_first_durability"
+            }
           ],
           "The fact packet is the primary truth for downstream reviewer families.",
           "Keep `readinessHypothesis` as a hypothesis to challenge, not a frame to defend.",
@@ -131,12 +150,18 @@
       "promptFragments": [
         {
           "id": "phase-2-quick",
-          "when": { "var": "rigorMode", "equals": "QUICK" },
+          "when": {
+            "var": "rigorMode",
+            "equals": "QUICK"
+          },
           "text": "Keep the fact packet compact. QUICK should not manufacture a giant ceremony layer."
         },
         {
           "id": "phase-2-thorough",
-          "when": { "var": "rigorMode", "equals": "THOROUGH" },
+          "when": {
+            "var": "rigorMode",
+            "equals": "THOROUGH"
+          },
           "text": "For THOROUGH rigor, make the hidden-risk surfaces explicit: blind spots, fake confidence vectors, and production assumptions that would hurt if wrong."
         }
       ],
@@ -153,10 +178,16 @@
         "goal": "Run the selected reviewer families in parallel from the same readiness fact packet, then synthesize their output as evidence rather than conclusions.",
         "constraints": [
           [
-            { "kind": "ref", "refId": "wr.refs.notes_first_durability" }
+            {
+              "kind": "ref",
+              "refId": "wr.refs.notes_first_durability"
+            }
           ],
           [
-            { "kind": "ref", "refId": "wr.refs.synthesis_under_disagreement" }
+            {
+              "kind": "ref",
+              "refId": "wr.refs.synthesis_under_disagreement"
+            }
           ],
           "Each reviewer family must use `readinessFactPacket` as primary truth.",
           "Use `readinessHypothesis` only as comparison context.",
@@ -203,7 +234,10 @@
             "goal": "If contradictions, blind spots, or important coverage gaps remain, run only the smallest targeted follow-up needed.",
             "constraints": [
               [
-                { "kind": "ref", "refId": "wr.refs.parallelize_cognition_serialize_synthesis" }
+                {
+                  "kind": "ref",
+                  "refId": "wr.refs.parallelize_cognition_serialize_synthesis"
+                }
               ],
               "Prefer one compact targeted bundle over repeated broad delegation moments.",
               "Do not regather broad context unless a contradiction proves the original fact packet is insufficient.",
@@ -291,10 +325,16 @@
         "goal": "Stress-test the current readiness verdict before final handoff.",
         "constraints": [
           [
-            { "kind": "ref", "refId": "wr.refs.adversarial_challenge_rules" }
+            {
+              "kind": "ref",
+              "refId": "wr.refs.adversarial_challenge_rules"
+            }
           ],
           [
-            { "kind": "ref", "refId": "wr.refs.synthesis_under_disagreement" }
+            {
+              "kind": "ref",
+              "refId": "wr.refs.synthesis_under_disagreement"
+            }
           ],
           "Validation output is evidence to synthesize, not automatic authority."
         ],
@@ -319,8 +359,14 @@
       },
       "requireConfirmation": {
         "or": [
-          { "var": "finalConfidenceBand", "equals": "Low" },
-          { "var": "finalVerdict", "equals": "inconclusive" }
+          {
+            "var": "finalConfidenceBand",
+            "equals": "Low"
+          },
+          {
+            "var": "finalVerdict",
+            "equals": "inconclusive"
+          }
         ]
       }
     },

package/workflows/relocation-workflow-us.json

@@ -2,7 +2,14 @@
   "id": "relocation-workflow-us",
   "name": "US Relocation Decision Workflow (Evidence-Driven • AreaSpec • Ranked Dossier)",
   "version": "1.0.0",
-  "description": "An evidence-driven relocation workflow for the United States. Discovers preferences, generates a broad candidate pool with anti-anchoring discipline, screens with strict caps, deep-dives a shortlist, and produces a ranked dossier with per-location profiles and an explainable weighted ranking.",
+  "description": "Use this to evaluate US cities or regions for a potential relocation. Discovers your preferences, generates candidate areas, screens them, and produces a ranked dossier with evidence.",
+  "about": "## US Relocation Decision Workflow\n\nUse this to evaluate US cities and regions for a potential move. The workflow takes a structured, evidence-driven approach: it starts by calibrating your preferences and dealbreakers, generates a broad diverse pool of candidate areas (including non-obvious ones), screens them systematically, and produces a ranked dossier you can actually act on.\n\n### What it produces\n\n- A `RELOCATION_DOSSIER.md` with your full preference model, screening results, and comparison matrix.\n- Individual per-candidate profiles at `relocation-profiles/<slug>.md` covering housing, cost of living, taxes, safety, climate risk, schools, healthcare, commute, and any other modules you activate.\n- A scored ranking with explainable reasoning and an explicit disclosure of any data gaps.\n- A next-steps plan: visit recommendations, open questions per candidate, and pivot triggers.\n\n### When to use it\n\n- You are seriously considering a US relocation and want a rigorous, evidence-backed shortlist.\n- You want to surface non-obvious candidates you wouldn't have considered on your own.\n- You've been anchoring on a handful of cities and want a structured process to either validate or challenge that.\n\n### How to get good results\n\n- Be honest about dealbreakers upfront -- the workflow builds these into screening and filters candidates early.\n- The MaxDiff weight calibration exercise (offered in Phase 1) is worth doing if you're unsure how to weight competing priorities. It takes 5-10 minutes and produces more reliable weights than guessing.\n- The calibration deck in Phase 1 shows you lifestyle archetypes and asks for reactions -- engage with this seriously. Surprises in your reactions are valuable signal.\n- The workflow activates only the research modules you need. Keep it focused on what actually matters to your household.",
+  "examples": [
+    "Help me find the best US city to relocate my family, prioritizing top schools, low cost of living, and outdoor access",
+    "Evaluate mid-size metros in the Southeast as alternatives to Atlanta for a remote worker with a $400k housing budget",
+    "Find the best US cities for a couple relocating from San Francisco who need to stay within a 2-hour flight of NYC",
+    "Compare Denver, Austin, and Raleigh as relocation options and surface 5 non-obvious alternatives I haven't considered"
+  ],
   "recommendedPreferences": {
     "recommendedAutonomy": "guided",
     "recommendedRiskPolicy": "conservative"
@@ -145,17 +152,26 @@
       "promptFragments": [
         {
           "id": "no-red-flags",
-          "when": { "var": "redFlagCount", "equals": 0 },
+          "when": {
+            "var": "redFlagCount",
+            "equals": 0
+          },
           "text": "No red flags were detected. Record redFlagDecision = 'fyi' and redFlagDecisionNotes = 'No red flags detected in baseline due diligence.' Proceed to Phase 5."
         },
         {
           "id": "has-red-flags",
-          "when": { "var": "redFlagCount", "gt": 0 },
+          "when": {
+            "var": "redFlagCount",
+            "gt": 0
+          },
           "text": "Red flags were found. Summarize each: candidate name, category, one-line summary, source. Ask the user to choose exactly one action: (a) promote_to_dealbreakers — update the `dealbreakers` context variable AND the RELOCATION_DOSSIER.md Constraints section with the new/updated dealbreakers, then re-check screenResults for affected candidates; (b) add_weighted_criterion — ask the user how to weight it and which existing weights decrease so the `weights` array still sums to 100; (c) fyi — record the decision and move on. Record redFlagDecision and redFlagDecisionNotes. Append to RELOCATION_DOSSIER.md Red Flag Gate Decisions (append-only)."
         }
       ],
       "prompt": "Handle baseline red flags before selecting the shortlist.",
-      "requireConfirmation": { "var": "redFlagCount", "gt": 0 }
+      "requireConfirmation": {
+        "var": "redFlagCount",
+        "gt": 0
+      }
     },
     {
       "id": "phase-5-shortlist",
@@ -229,4 +245,4 @@
       "requireConfirmation": true
     }
   ]
-}
+}

package/workflows/routines/tension-driven-design.json

@@ -41,7 +41,7 @@
     {
       "id": "step-generate-candidates",
       "title": "Step 3: Generate Candidates from Tensions",
-      "prompt": "Generate design candidates that resolve the identified tensions differently.\n\nMANDATORY candidates:\n1. The simplest possible change that satisfies acceptance criteria. If the problem doesn't need an architectural solution, say so.\n2. Follow the existing repo pattern — adapt what the codebase already does for similar problems. Don't invent when you can adapt.\n\nAdditional candidates (1-2 more):\n- Each must resolve the identified tensions DIFFERENTLY, not just vary surface details\n- Each must be grounded in a real constraint or tradeoff, not an abstract perspective label\n- Consider philosophy conflicts: if the stated philosophy disagrees with repo patterns, one candidate could follow the stated philosophy and another could follow the established pattern\n\nFor each candidate, produce:\n- One-sentence summary of the approach\n- Which tensions it resolves and which it accepts\n- Boundary solved at, and why that boundary is the best fit\n- The specific failure mode you'd watch for\n- How it relates to existing repo patterns (follows / adapts / departs)\n- What you gain and what you give up\n- Impact surface beyond the immediate task\n- Scope judgment: too narrow / best-fit / too broad, with concrete evidence\n- Which philosophy principles it honors and which it conflicts with (by name)\n\nRules:\n- candidates must be genuinely different in shape, not just wording\n- if all candidates converge on the same approach, that's signal — note it honestly rather than manufacturing fake diversity\n- broader scope requires concrete evidence\n- cite specific files or patterns when they materially shape a candidate",
+      "prompt": "Generate design candidates that resolve the identified tensions differently.\n\nMANDATORY candidates:\n1. The simplest possible change that satisfies acceptance criteria. If the problem doesn't need an architectural solution, say so.\n2. Follow the existing repo pattern — adapt what the codebase already does for similar problems. Don't invent when you can adapt.\n\nAdditional candidates (1-2 more):\n- Each must resolve the identified tensions DIFFERENTLY, not just vary surface details\n- Each must be grounded in a real constraint or tradeoff, not an abstract perspective label\n- Consider philosophy conflicts: if the stated philosophy disagrees with repo patterns, one candidate could follow the stated philosophy and another could follow the established pattern\n\nFor each candidate, produce:\n- One-sentence summary of the approach\n- Which tensions it resolves and which it accepts\n- Boundary solved at, and why that boundary is the best fit\n- The specific failure mode you'd watch for\n- How it relates to existing repo patterns (follows / adapts / departs)\n- What you gain and what you give up\n- Impact surface beyond the immediate task\n- Scope judgment: too narrow / best-fit / too broad, with concrete evidence\n- Which philosophy principles it honors and which it conflicts with (by name)\n\nRules:\n- candidates must be genuinely different in shape, not just wording\n- if all candidates converge on the same approach, that's signal — note it honestly rather than manufacturing fake diversity\n- broader scope requires concrete evidence\n- cite specific files or patterns when they materially shape a candidate\n- specify each candidate at the level of concrete shape, not concept labels: 'tags' is not a candidate specification; 'per-workflow multi-labels drawn from a closed 9-value enum' is. If you find yourself using a concept label (tags, categories, events, hooks), you have not yet specified the candidate — name the data structure, the vocabulary or value set it uses, who maintains it, and how it is queried",
       "agentRole": "You are generating genuinely diverse design candidates grounded in real tensions.",
       "requireConfirmation": false
     },