@exaudeus/workrail 3.13.0 → 3.15.0

package/workflows/cross-platform-code-conversion.v2.json

@@ -2,7 +2,7 @@
   "id": "cross-platform-code-conversion",
   "name": "Cross-Platform Code Conversion",
   "version": "0.1.0",
-  "description": "Guides an agent through converting code from one platform to another (e.g., Android to iOS, iOS to Web). Triages files by difficulty, delegates easy literal translations to parallel subagents, then the main agent tackles platform-specific code requiring design decisions.",
+  "description": "Use this to convert code from one platform to another (e.g. Android to iOS, iOS to Web). Triages files by difficulty, parallelizes easy translations, and handles platform-specific design decisions.",
   "recommendedPreferences": {
     "recommendedAutonomy": "guided",
     "recommendedRiskPolicy": "conservative"
@@ -71,12 +71,15 @@
     {
       "id": "phase-1-understand-source",
       "title": "Phase 1: Understand Source Code",
-      "prompt": "Read and analyze the source code through a conversion lens — what will be easy to convert, what will be hard, and why.\n\nMap out:\n- Architecture and module structure\n- Key patterns used (MVI, MVVM, dependency injection, etc.)\n- External dependencies and what they do\n- Entry points and public API surface\n- Platform coupling depth: is the code cleanly layered or is platform-specific code smeared throughout? This directly determines how much falls into easy vs. hard buckets.\n- Concurrency model: Coroutines, Combine, RxJS, async/await? This is often the single hardest mapping decision.\n- DI approach: Dagger/Hilt, Swinject, Koin? DI frameworks rarely map 1:1.\n- Test coverage shape: unit tests on business logic (convert easily), UI tests (likely rewrite), integration tests (depends on infra).\n- Shared code boundaries: is there already a shared/common module that might not need conversion at all?\n- Non-trivial migration boundaries: public APIs, externally consumed module boundaries, and lifecycle/state/concurrency/resource boundaries that callers depend on.\n- Caller-visible guarantees for those boundaries. Examples include lifecycle/ownership, laziness vs eagerness, shared vs per-consumer behavior, cancellation/disposal, ordering/replay/buffering, failure behavior, threading/scheduling, or consistency/transaction guarantees.\n- Adaptation depth: classify whether the migration is `low`, `moderate`, or `high` adaptation based on architectural mismatch, missing target-side equivalents, lifecycle/state/concurrency mismatch, and the amount of adapter or redesign work needed.\n\nIdentify which files define or materially affect those boundaries and which of them will require target-repo integration analysis.\n\nCapture:\n- `sourceArchitecture`\n- `dependencies`\n- `publicApiSurface`\n- `platformCouplingAssessment`\n- `concurrencyModel`\n- `testCoverageShape`\n- `semanticBoundaryCandidates`\n- `boundaryCriticalFiles`\n- `adaptationProfile`",
+      "prompt": "Read and analyze the source code through a conversion lens \u2014 what will be easy to convert, what will be hard, and why.\n\nMap out:\n- Architecture and module structure\n- Key patterns used (MVI, MVVM, dependency injection, etc.)\n- External dependencies and what they do\n- Entry points and public API surface\n- Platform coupling depth: is the code cleanly layered or is platform-specific code smeared throughout? This directly determines how much falls into easy vs. hard buckets.\n- Concurrency model: Coroutines, Combine, RxJS, async/await? This is often the single hardest mapping decision.\n- DI approach: Dagger/Hilt, Swinject, Koin? DI frameworks rarely map 1:1.\n- Test coverage shape: unit tests on business logic (convert easily), UI tests (likely rewrite), integration tests (depends on infra).\n- Shared code boundaries: is there already a shared/common module that might not need conversion at all?\n- Non-trivial migration boundaries: public APIs, externally consumed module boundaries, and lifecycle/state/concurrency/resource boundaries that callers depend on.\n- Caller-visible guarantees for those boundaries. Examples include lifecycle/ownership, laziness vs eagerness, shared vs per-consumer behavior, cancellation/disposal, ordering/replay/buffering, failure behavior, threading/scheduling, or consistency/transaction guarantees.\n- Adaptation depth: classify whether the migration is `low`, `moderate`, or `high` adaptation based on architectural mismatch, missing target-side equivalents, lifecycle/state/concurrency mismatch, and the amount of adapter or redesign work needed.\n\nIdentify which files define or materially affect those boundaries and which of them will require target-repo integration analysis.\n\nCapture:\n- `sourceArchitecture`\n- `dependencies`\n- `publicApiSurface`\n- `platformCouplingAssessment`\n- `concurrencyModel`\n- `testCoverageShape`\n- `semanticBoundaryCandidates`\n- `boundaryCriticalFiles`\n- `adaptationProfile`",
       "promptFragments": [
         {
           "id": "phase-1-small-light",
-          "when": { "var": "conversionComplexity", "equals": "Small" },
-          "text": "For Small conversions, keep this lightweight. A quick read of the files in scope is enough — don't map the entire architecture. Focus on identifying any platform-specific code that would prevent a straight translation."
+          "when": {
+            "var": "conversionComplexity",
+            "equals": "Small"
+          },
+          "text": "For Small conversions, keep this lightweight. A quick read of the files in scope is enough \u2014 don't map the entire architecture. Focus on identifying any platform-specific code that would prevent a straight translation."
         }
       ],
       "requireConfirmation": {
@@ -89,11 +92,17 @@
       "title": "Small Conversion Fast Path",
       "runCondition": {
         "and": [
-          { "var": "conversionComplexity", "equals": "Small" },
-          { "var": "adaptationProfile", "equals": "low" }
+          {
+            "var": "conversionComplexity",
+            "equals": "Small"
+          },
+          {
+            "var": "adaptationProfile",
+            "equals": "low"
+          }
         ]
       },
-      "prompt": "For Small conversions, skip triage and planning — just convert.\n\n- Translate the files to the target platform idiomatically\n- Follow target platform naming and structure conventions\n- Map any dependencies to target equivalents\n- Convert tests if they exist\n- Run build or typecheck to verify\n\nIf something turns out harder than expected (deep platform coupling, no clean dependency equivalent, or meaningful architectural mismatch), update `conversionComplexity` to `Medium`, update `adaptationProfile` to `moderate` or `high` based on the newly discovered mismatch, and stop. The full triage and planning pipeline will activate for the remaining work.\n\nCapture:\n- `filesConverted`\n- `buildPassed`\n- `conversionComplexity`\n- `adaptationProfile`",
+      "prompt": "For Small conversions, skip triage and planning \u2014 just convert.\n\n- Translate the files to the target platform idiomatically\n- Follow target platform naming and structure conventions\n- Map any dependencies to target equivalents\n- Convert tests if they exist\n- Run build or typecheck to verify\n\nIf something turns out harder than expected (deep platform coupling, no clean dependency equivalent, or meaningful architectural mismatch), update `conversionComplexity` to `Medium`, update `adaptationProfile` to `moderate` or `high` based on the newly discovered mismatch, and stop. The full triage and planning pipeline will activate for the remaining work.\n\nCapture:\n- `filesConverted`\n- `buildPassed`\n- `conversionComplexity`\n- `adaptationProfile`",
       "requireConfirmation": false
     },
     {
@@ -101,11 +110,17 @@
       "title": "Phase 2: Triage & Sort",
       "runCondition": {
         "or": [
-          { "var": "conversionComplexity", "not_equals": "Small" },
-          { "var": "adaptationProfile", "not_equals": "low" }
+          {
+            "var": "conversionComplexity",
+            "not_equals": "Small"
+          },
+          {
+            "var": "adaptationProfile",
+            "not_equals": "low"
+          }
         ]
       },
-      "prompt": "Classify every file or module in scope into one of three buckets:\n\n**Bucket A — Literal translation**: Platform-agnostic business logic, data models, utilities, pure functions. These use no platform-specific APIs or libraries. Conversion is mechanical: translate the language syntax, follow target naming conventions, done. These will be delegated to subagents.\n\n**Bucket B — Library substitution**: Code that uses platform-specific libraries (networking, persistence, serialization, DI) but follows standard patterns. These need dependency mapping but the structure stays the same.\n\n**Bucket C — Platform-specific**: Code deeply tied to the platform (UI layer, lifecycle management, concurrency/threading, navigation, platform APIs). These need design decisions about target-platform idioms.\n\nFor each file or module, list:\n- File/module name\n- Bucket (A, B, or C)\n- One-line reason for classification\n- Dependencies it has on other files in scope (so we know conversion order)\n- Whether it is `boundaryCritical` for a non-trivial migration boundary\n- Which semantic boundaries it affects from `semanticBoundaryCandidates`\n- Whether it will require target-repo integration analysis\n\nBoundary-critical files must not be treated as blind mechanical translation just because the syntax looks simple. If a file materially affects a semantic boundary or destination-repo seam, keep it with main-agent review.\n\nSort the work items within each bucket by dependency order (convert dependencies first).\n\nGroup Bucket A files into parallel batches of 3-5 files each. Each batch should contain files with no cross-dependencies so subagents can work independently.\n\nGroup Bucket B and C files into sequential batches by dependency order.\n\nEach batch should have: `name` (short label), `bucket` (A, B, or C), and `files` (list of file paths).\n\nCapture:\n- `bucketABatches` (parallel batches for subagent delegation)\n- `bucketBCBatches` (sequential batches for main agent)\n- `bucketACounts`\n- `bucketBCounts`\n- `bucketCCounts`\n- `boundaryCriticalItems`",
+      "prompt": "Classify every file or module in scope into one of three buckets:\n\n**Bucket A \u2014 Literal translation**: Platform-agnostic business logic, data models, utilities, pure functions. These use no platform-specific APIs or libraries. Conversion is mechanical: translate the language syntax, follow target naming conventions, done. These will be delegated to subagents.\n\n**Bucket B \u2014 Library substitution**: Code that uses platform-specific libraries (networking, persistence, serialization, DI) but follows standard patterns. These need dependency mapping but the structure stays the same.\n\n**Bucket C \u2014 Platform-specific**: Code deeply tied to the platform (UI layer, lifecycle management, concurrency/threading, navigation, platform APIs). These need design decisions about target-platform idioms.\n\nFor each file or module, list:\n- File/module name\n- Bucket (A, B, or C)\n- One-line reason for classification\n- Dependencies it has on other files in scope (so we know conversion order)\n- Whether it is `boundaryCritical` for a non-trivial migration boundary\n- Which semantic boundaries it affects from `semanticBoundaryCandidates`\n- Whether it will require target-repo integration analysis\n\nBoundary-critical files must not be treated as blind mechanical translation just because the syntax looks simple. If a file materially affects a semantic boundary or destination-repo seam, keep it with main-agent review.\n\nSort the work items within each bucket by dependency order (convert dependencies first).\n\nGroup Bucket A files into parallel batches of 3-5 files each. Each batch should contain files with no cross-dependencies so subagents can work independently.\n\nGroup Bucket B and C files into sequential batches by dependency order.\n\nEach batch should have: `name` (short label), `bucket` (A, B, or C), and `files` (list of file paths).\n\nCapture:\n- `bucketABatches` (parallel batches for subagent delegation)\n- `bucketBCBatches` (sequential batches for main agent)\n- `bucketACounts`\n- `bucketBCounts`\n- `bucketCCounts`\n- `boundaryCriticalItems`",
       "requireConfirmation": true
     },
     {
@@ -113,27 +128,45 @@
       "title": "Phase 3a: Semantic Contract Inventory",
       "runCondition": {
         "or": [
-          { "var": "conversionComplexity", "not_equals": "Small" },
-          { "var": "adaptationProfile", "not_equals": "low" }
+          {
+            "var": "conversionComplexity",
+            "not_equals": "Small"
+          },
+          {
+            "var": "adaptationProfile",
+            "not_equals": "low"
+          }
         ]
       },
       "prompt": "Before planning implementation, create a compact semantic contract inventory for the non-trivial migration boundaries in scope.\n\nFocus on:\n- Public APIs\n- Externally consumed module boundaries\n- Lifecycle/state/concurrency/resource boundaries that callers rely on\n\nFor each boundary, record:\n- `boundary`: short identifier for the surface\n- `sourceSurface`: source API or construct\n- `keyGuarantees`: the caller-visible guarantees that must remain true\n- `targetConstruct`: chosen target type or pattern\n- `status`: `preserved`, `intentionally_changed`, or `uncertain`\n- `rationale`\n- `verificationPlan`\n\nUse examples of semantic dimensions as examples only, not a mandatory checklist: lifecycle/ownership, laziness vs eagerness, shared vs per-consumer behavior, cancellation/disposal, ordering/replay/buffering, failure behavior, threading/scheduling, or consistency/transaction guarantees.\n\nIf a boundary cannot be mapped confidently, mark it `uncertain` rather than guessing.\n\nCapture:\n- `semanticContractInventory`\n- `hasUncertainBoundaries`\n- `hasIntentionalBoundaryChanges`",
       "promptFragments": [
         {
           "id": "phase-3a-medium-focused",
-          "when": { "var": "conversionComplexity", "equals": "Medium" },
+          "when": {
+            "var": "conversionComplexity",
+            "equals": "Medium"
+          },
           "text": "For Medium conversions, inventory only the non-trivial boundaries actually touched by the scoped work. Don't expand this into a whole-system audit."
         },
         {
           "id": "phase-3a-high-adaptation",
-          "when": { "var": "adaptationProfile", "equals": "high" },
+          "when": {
+            "var": "adaptationProfile",
+            "equals": "high"
+          },
           "text": "For high-adaptation migrations, cover every touched non-trivial boundary and explicitly call out where the contract is likely to be preserved, intentionally changed, or under architectural pressure."
         }
       ],
       "requireConfirmation": {
         "or": [
-          { "var": "hasUncertainBoundaries", "equals": true },
-          { "var": "hasIntentionalBoundaryChanges", "equals": true }
+          {
+            "var": "hasUncertainBoundaries",
+            "equals": true
+          },
+          {
+            "var": "hasIntentionalBoundaryChanges",
+            "equals": true
+          }
         ]
       }
     },
@@ -142,20 +175,32 @@
       "title": "Phase 3b: Target Integration Analysis",
       "runCondition": {
         "or": [
-          { "var": "conversionComplexity", "not_equals": "Small" },
-          { "var": "adaptationProfile", "not_equals": "low" }
+          {
+            "var": "conversionComplexity",
+            "not_equals": "Small"
+          },
+          {
+            "var": "adaptationProfile",
+            "not_equals": "low"
+          }
         ]
       },
       "prompt": "For each touched non-trivial migration boundary, analyze how it should fit into the target repo.\n\nThis step is about destination-repo fit, not source semantic guarantees. `semanticContractInventory` defines what must remain true. This step defines where the migrated boundary belongs and what target seams it must satisfy.\n\nFocus only on touched boundaries, not the whole target repo.\n\nFor each boundary, record:\n- `boundary`\n- `targetArea`: target module/layer/package/file area it belongs in\n- `existingPattern`: nearest relevant target abstraction or convention\n- `integrationPoints`: callers, adapters, DI/state/navigation/lifecycle hooks, persistence/network seams, or other required target touchpoints\n- `constraints`: repo-specific rules this boundary must satisfy\n- `decision`: `reuse_as_is`, `reuse_with_adapter`, `extend_existing`, `introduce_new`, or `defer_pending_decision`\n- `fitAssessment`: why the nearest existing abstraction is appropriate, insufficient, or misleading\n- `integrationRisk`: `low`, `medium`, or `high`\n- `uncertain`: `true` or `false`\n- `evidenceFiles`: concrete target files observed\n- `evidenceSymbols`: concrete target symbols observed\n- `rationale`\n\nUse concrete evidence from the target repo. Existing target code is evidence, not authority.\n\nCapture:\n- `targetIntegrationAnalysis`\n- `hasUncertainIntegrationPoints`",
       "promptFragments": [
         {
           "id": "phase-3b-medium-focused",
-          "when": { "var": "conversionComplexity", "equals": "Medium" },
+          "when": {
+            "var": "conversionComplexity",
+            "equals": "Medium"
+          },
           "text": "For Medium conversions, analyze only the touched boundaries that need real destination-repo decisions. Do not expand this into a broad target-architecture survey."
         },
         {
           "id": "phase-3b-high-adaptation",
-          "when": { "var": "adaptationProfile", "equals": "high" },
+          "when": {
+            "var": "adaptationProfile",
+            "equals": "high"
+          },
           "text": "For high-adaptation migrations, compare at least one plausible alternative target area or seam for each important boundary and explain why the chosen fit is still the best one."
         }
       ],
@@ -204,20 +249,32 @@
       "title": "Phase 3f: Plan Platform-Specific Conversions",
       "runCondition": {
         "or": [
-          { "var": "conversionComplexity", "not_equals": "Small" },
-          { "var": "adaptationProfile", "not_equals": "low" }
+          {
+            "var": "conversionComplexity",
+            "not_equals": "Small"
+          },
+          {
+            "var": "adaptationProfile",
+            "not_equals": "low"
+          }
         ]
       },
       "prompt": "For Bucket B and Bucket C items, plan the conversion before writing code.\n\nUse both `semanticContractInventory` and `targetIntegrationAnalysis` as required inputs. If `adaptationProfile` is `high`, also use `architectureAdaptationPlan` as a required input. The implementation plan must preserve boundary contracts and fit the target repo's actual seams.\n\nFor Bucket B (library substitution):\n- Map each source dependency to its target-platform equivalent\n- If no equivalent exists, flag it and propose an alternative\n\nFor Bucket C (platform-specific):\n- Threading/concurrency model mapping\n- UI framework mapping\n- DI framework mapping\n- State management mapping\n- Error handling mapping\n- Navigation patterns\n- Lifecycle management approach\n- Testing framework mapping\n- Target module/layer placement and adapter seams\n\nFor anything with no clean target equivalent, propose an idiomatic solution and explain the tradeoff.\n\nBucket A items don't need a plan. They're mechanical translation handled by subagents.\n\nCapture:\n- `idiomMapping`\n- `dependencyMapping`\n- `tradeoffs`",
       "promptFragments": [
         {
           "id": "phase-3f-medium-focused",
-          "when": { "var": "conversionComplexity", "equals": "Medium" },
-          "text": "For Medium conversions, focus the plan on the items that actually need design decisions. Don't exhaustively map every dimension — only the ones relevant to the files in scope."
+          "when": {
+            "var": "conversionComplexity",
+            "equals": "Medium"
+          },
+          "text": "For Medium conversions, focus the plan on the items that actually need design decisions. Don't exhaustively map every dimension \u2014 only the ones relevant to the files in scope."
         },
         {
           "id": "phase-3f-high-adaptation",
-          "when": { "var": "adaptationProfile", "equals": "high" },
+          "when": {
+            "var": "adaptationProfile",
+            "equals": "high"
+          },
           "text": "For high-adaptation migrations, state clearly what is translated directly, what is adapted through seams or adapters, and what is intentionally redesigned."
         }
       ],
@@ -230,11 +287,20 @@
         "and": [
           {
             "or": [
-              { "var": "conversionComplexity", "not_equals": "Small" },
-              { "var": "adaptationProfile", "not_equals": "low" }
+              {
+                "var": "conversionComplexity",
+                "not_equals": "Small"
+              },
+              {
+                "var": "adaptationProfile",
+                "not_equals": "low"
+              }
             ]
           },
-          { "var": "bucketACounts", "not_equals": 0 }
+          {
+            "var": "bucketACounts",
+            "not_equals": 0
+          }
         ]
       },
       "promptBlocks": {
@@ -270,8 +336,14 @@
       "title": "Phase 5: Convert Bucket B & C (Main Agent)",
       "runCondition": {
         "or": [
-          { "var": "conversionComplexity", "not_equals": "Small" },
-          { "var": "adaptationProfile", "not_equals": "low" }
+          {
+            "var": "conversionComplexity",
+            "not_equals": "Small"
+          },
+          {
+            "var": "adaptationProfile",
+            "not_equals": "low"
+          }
         ]
       },
       "loop": {
@@ -331,14 +403,38 @@
           "title": "Verify Batch",
           "runCondition": {
             "or": [
-              { "var": "bucketDriftDetected", "equals": true },
-              { "var": "unexpectedDependency", "equals": true },
-              { "var": "buildBroke", "equals": true },
-              { "var": "contractDriftDetected", "equals": true },
-              { "var": "contractUncertain", "equals": true },
-              { "var": "integrationDriftDetected", "equals": true },
-              { "var": "integrationUncertain", "equals": true },
-              { "var": "architectureDriftDetected", "equals": true }
+              {
+                "var": "bucketDriftDetected",
+                "equals": true
+              },
+              {
+                "var": "unexpectedDependency",
+                "equals": true
+              },
+              {
+                "var": "buildBroke",
+                "equals": true
+              },
+              {
+                "var": "contractDriftDetected",
+                "equals": true
+              },
+              {
+                "var": "contractUncertain",
+                "equals": true
+              },
+              {
+                "var": "integrationDriftDetected",
+                "equals": true
+              },
+              {
+                "var": "integrationUncertain",
+                "equals": true
+              },
+              {
+                "var": "architectureDriftDetected",
+                "equals": true
+              }
             ]
           },
           "promptBlocks": {
@@ -370,9 +466,18 @@
           },
           "requireConfirmation": {
             "or": [
-              { "var": "contractUncertain", "equals": true },
-              { "var": "integrationUncertain", "equals": true },
-              { "var": "architectureDriftDetected", "equals": true }
+              {
+                "var": "contractUncertain",
+                "equals": true
+              },
+              {
+                "var": "integrationUncertain",
+                "equals": true
+              },
+              {
+                "var": "architectureDriftDetected",
+                "equals": true
+              }
             ]
           }
         }
@@ -384,8 +489,14 @@
       "title": "Phase 6: Final Verification",
       "runCondition": {
         "or": [
-          { "var": "conversionComplexity", "not_equals": "Small" },
-          { "var": "adaptationProfile", "not_equals": "low" }
+          {
+            "var": "conversionComplexity",
+            "not_equals": "Small"
+          },
+          {
+            "var": "adaptationProfile",
+            "not_equals": "low"
+          }
         ]
       },
       "loop": {
@@ -401,7 +512,7 @@
         {
           "id": "phase-6a-full-build",
           "title": "Full Build and Integration Check",
-          "prompt": "Run a full build or typecheck on the entire converted codebase — both subagent-converted and main-agent-converted code together.\n\nCheck for:\n- Build/compile errors from cross-batch integration issues\n- Inconsistencies between subagent output and main agent output (naming, patterns)\n- Non-idiomatic patterns that slipped through\n- Missing error handling at module boundaries\n- Threading or concurrency issues across modules\n- Broken public API contracts\n- Contract inventory drift: every row in `semanticContractInventory` is still accounted for, no `uncertain` rows remain, preserved contracts still look preserved, and intentional changes are still justified\n- Target integration drift: code landed in the intended target layer/module, reuse/adaptation decisions still fit the observed target seams, and no unresolved target integration uncertainties remain\n- High-adaptation architecture drift: if `adaptationProfile` is `high`, the final code still matches `architectureAdaptationPlan` and any deviations are explicit and justified\n\nFix each issue. If a fix is a band-aid over a deeper mapping problem, go back and fix the mapping.\n\nCapture:\n- `fullBuildPassed`\n- `integrationIssues`\n- `issuesFixed`",
+          "prompt": "Run a full build or typecheck on the entire converted codebase \u2014 both subagent-converted and main-agent-converted code together.\n\nCheck for:\n- Build/compile errors from cross-batch integration issues\n- Inconsistencies between subagent output and main agent output (naming, patterns)\n- Non-idiomatic patterns that slipped through\n- Missing error handling at module boundaries\n- Threading or concurrency issues across modules\n- Broken public API contracts\n- Contract inventory drift: every row in `semanticContractInventory` is still accounted for, no `uncertain` rows remain, preserved contracts still look preserved, and intentional changes are still justified\n- Target integration drift: code landed in the intended target layer/module, reuse/adaptation decisions still fit the observed target seams, and no unresolved target integration uncertainties remain\n- High-adaptation architecture drift: if `adaptationProfile` is `high`, the final code still matches `architectureAdaptationPlan` and any deviations are explicit and justified\n\nFix each issue. If a fix is a band-aid over a deeper mapping problem, go back and fix the mapping.\n\nCapture:\n- `fullBuildPassed`\n- `integrationIssues`\n- `issuesFixed`",
           "requireConfirmation": false
         },
         {
@@ -422,15 +533,24 @@
       "promptFragments": [
         {
           "id": "phase-7-small-summary",
-          "when": { "var": "conversionComplexity", "equals": "Small" },
-          "text": "For Small conversions, keep the summary brief — just list what was converted, build status, and any issues."
+          "when": {
+            "var": "conversionComplexity",
+            "equals": "Small"
+          },
+          "text": "For Small conversions, keep the summary brief \u2014 just list what was converted, build status, and any issues."
         },
         {
           "id": "phase-7-full-summary",
           "when": {
             "or": [
-              { "var": "conversionComplexity", "not_equals": "Small" },
-              { "var": "adaptationProfile", "not_equals": "low" }
+              {
+                "var": "conversionComplexity",
+                "not_equals": "Small"
+              },
+              {
+                "var": "adaptationProfile",
+                "not_equals": "low"
+              }
             ]
           },
           "text": "Also include: bucket breakdown (A/B/C counts), delegation results (how many files delegated, subagent quality, any reclassified), key idiom mapping decisions, dependency substitutions, notable preserved contracts, notable target integration decisions, any intentional semantic changes, the selected adaptation approach, any architecture adaptation choices, and any boundaries needing manual review."

package/workflows/document-creation-workflow.json

@@ -2,7 +2,7 @@
   "id": "document-creation-workflow",
   "name": "Document Creation Workflow",
   "version": "1.0.0",
-  "description": "Create broad or comprehensive documentation spanning multiple components or systems. Suited for project READMEs, complete API documentation, user guides covering multiple features, and technical specifications. Uses complexity triage (Simple/Standard/Complex) to adapt rigor. For single, bounded subjects (one class, one integration), use scoped-documentation-workflow instead.",
+  "description": "Use this to create broad or comprehensive documentation spanning multiple components or systems \u2014 project READMEs, complete API docs, user guides, or technical specifications.",
   "preconditions": [
     "User has a clear idea of the document type and purpose.",
     "Relevant project files or information are available for reference.",
@@ -12,9 +12,9 @@
   "metaGuidance": [
     "NOTES-FIRST DURABILITY: use output.notesMarkdown as the primary durable record. Do NOT create CONTEXT.md, doc_spec.md, or content_plan.md as workflow memory.",
     "DISCOVER BEFORE ASKING: use tools to explore the project before asking clarification questions. Only ask what tools cannot answer.",
-    "COMPLEXITY DRIVES BRANCHING: docComplexity=Simple uses the fast path; Standard/Complex uses the full path. If complexity changes during work, note it in notesMarkdown and adapt — no retriage ceremony needed.",
+    "COMPLEXITY DRIVES BRANCHING: docComplexity=Simple uses the fast path; Standard/Complex uses the full path. If complexity changes during work, note it in notesMarkdown and adapt \u2014 no retriage ceremony needed.",
     "CONTENT-FIRST: the deliverable is the document, not planning artifacts. Keep planning proportional to scope.",
-    "EVIDENCE-BASED QUALITY: each quality dimension in the review step requires a one-sentence evidence statement and a pass or needs-work verdict — not a numeric score."
+    "EVIDENCE-BASED QUALITY: each quality dimension in the review step requires a one-sentence evidence statement and a pass or needs-work verdict \u2014 not a numeric score."
   ],
   "steps": [
     {
@@ -31,11 +31,17 @@
       "title": "Phase 1: Project Analysis",
       "runCondition": {
         "or": [
-          { "var": "docComplexity", "equals": "Standard" },
-          { "var": "docComplexity", "equals": "Complex" }
+          {
+            "var": "docComplexity",
+            "equals": "Standard"
+          },
+          {
+            "var": "docComplexity",
+            "equals": "Complex"
+          }
         ]
       },
-      "prompt": "Analyze the project to inform documentation strategy. Limit this analysis to 1500 words; prioritize documentation-relevant insights.\n\nCover:\n1. **Existing documentation landscape** — current docs, style patterns, gaps\n2. **Project architecture** — key components relevant to this document\n3. **User or developer workflows** — how documentation fits into user journeys\n4. **Technical constraints** — APIs, systems, integrations to document\n5. **Style conventions** — terminology, formatting, naming patterns to follow\n6. **Audience** — who will use this documentation and what they need to accomplish\n\nNote any complexity indicators that might warrant reclassifying `docComplexity` upward.",
+      "prompt": "Analyze the project to inform documentation strategy. Limit this analysis to 1500 words; prioritize documentation-relevant insights.\n\nCover:\n1. **Existing documentation landscape** \u2014 current docs, style patterns, gaps\n2. **Project architecture** \u2014 key components relevant to this document\n3. **User or developer workflows** \u2014 how documentation fits into user journeys\n4. **Technical constraints** \u2014 APIs, systems, integrations to document\n5. **Style conventions** \u2014 terminology, formatting, naming patterns to follow\n6. **Audience** \u2014 who will use this documentation and what they need to accomplish\n\nNote any complexity indicators that might warrant reclassifying `docComplexity` upward.",
       "requireConfirmation": false
     },
     {
@@ -43,8 +49,14 @@
       "title": "Phase 2: Targeted Requirements",
       "runCondition": {
         "or": [
-          { "var": "docComplexity", "equals": "Standard" },
-          { "var": "docComplexity", "equals": "Complex" }
+          {
+            "var": "docComplexity",
+            "equals": "Standard"
+          },
+          {
+            "var": "docComplexity",
+            "equals": "Complex"
+          }
         ]
       },
       "prompt": "Based on your project analysis, ask 2 to 4 targeted questions that you genuinely cannot answer from the codebase or project files.\n\nFocus on clarifications that materially affect content or structure:\n- Specific scope boundaries (what to include or exclude)\n- Audience-specific requirements not evident from the code\n- Constraints, templates, or organizational standards to follow\n- Integration requirements with existing documentation systems\n\nDo not ask questions the analysis already answered.",
@@ -55,15 +67,24 @@
       "title": "Phase 3: Content Plan",
       "runCondition": {
         "or": [
-          { "var": "docComplexity", "equals": "Standard" },
-          { "var": "docComplexity", "equals": "Complex" }
+          {
+            "var": "docComplexity",
+            "equals": "Standard"
+          },
+          {
+            "var": "docComplexity",
+            "equals": "Complex"
+          }
         ]
       },
-      "prompt": "Create a content plan for this documentation in your notes.\n\nThe plan should cover:\n1. Document purpose and success criteria\n2. Target audience and their primary goals\n3. Section outline with one-line descriptions\n4. Writing strategy — tone, technical depth, key terminology\n5. Visual elements or code examples needed\n\nKeep the plan proportional to scope. The goal is a clear outline to execute against, not a heavyweight specification.",
+      "prompt": "Create a content plan for this documentation in your notes.\n\nThe plan should cover:\n1. Document purpose and success criteria\n2. Target audience and their primary goals\n3. Section outline with one-line descriptions\n4. Writing strategy \u2014 tone, technical depth, key terminology\n5. Visual elements or code examples needed\n\nKeep the plan proportional to scope. The goal is a clear outline to execute against, not a heavyweight specification.",
       "promptFragments": [
         {
           "id": "phase-3-plan-complex",
-          "when": { "var": "docComplexity", "equals": "Complex" },
+          "when": {
+            "var": "docComplexity",
+            "equals": "Complex"
+          },
           "text": "For Complex documentation, also include: integration strategy (how this doc connects to the existing documentation ecosystem), maintenance ownership, and any stakeholder review requirements."
         }
       ],
@@ -80,16 +101,25 @@
       "title": "Phase 5: Quality Review",
       "runCondition": {
         "or": [
-          { "var": "docComplexity", "equals": "Standard" },
-          { "var": "docComplexity", "equals": "Complex" }
+          {
+            "var": "docComplexity",
+            "equals": "Standard"
+          },
+          {
+            "var": "docComplexity",
+            "equals": "Complex"
+          }
         ]
       },
-      "prompt": "Review the documentation you just wrote using this rubric. For each dimension, provide a one-sentence evidence statement and a verdict of `pass` or `needs-work`.\n\n1. **Accuracy** — Does the content correctly describe the actual project or system? *(Evidence: cite one verified fact.)*\n2. **Completeness** — Does it cover all planned sections? *(Evidence: list planned vs completed sections.)*\n3. **Audience fit** — Is the technical depth right for the target reader? *(Evidence: identify one audience-appropriate choice made.)*\n4. **Usability** — Could a reader actually accomplish their goal using this doc? *(Evidence: trace one user journey through the doc.)*\n5. **Consistency** — Does it match project conventions for style, terminology, and format? *(Evidence: cite one convention followed.)*\n\nIf any dimension is `needs-work`, fix the issue immediately and re-assert the dimension as `pass` in your notes before continuing.",
+      "prompt": "Review the documentation you just wrote using this rubric. For each dimension, provide a one-sentence evidence statement and a verdict of `pass` or `needs-work`.\n\n1. **Accuracy** \u2014 Does the content correctly describe the actual project or system? *(Evidence: cite one verified fact.)*\n2. **Completeness** \u2014 Does it cover all planned sections? *(Evidence: list planned vs completed sections.)*\n3. **Audience fit** \u2014 Is the technical depth right for the target reader? *(Evidence: identify one audience-appropriate choice made.)*\n4. **Usability** \u2014 Could a reader actually accomplish their goal using this doc? *(Evidence: trace one user journey through the doc.)*\n5. **Consistency** \u2014 Does it match project conventions for style, terminology, and format? *(Evidence: cite one convention followed.)*\n\nIf any dimension is `needs-work`, fix the issue immediately and re-assert the dimension as `pass` in your notes before continuing.",
       "promptFragments": [
         {
           "id": "phase-5-quality-review-complex",
-          "when": { "var": "docComplexity", "equals": "Complex" },
-          "text": "Also review a sixth dimension:\n6. **Integration coherence** — Does the doc integrate correctly with the existing documentation ecosystem? *(Evidence: describe how it cross-links or relates to existing docs.)*"
+          "when": {
+            "var": "docComplexity",
+            "equals": "Complex"
+          },
+          "text": "Also review a sixth dimension:\n6. **Integration coherence** \u2014 Does the doc integrate correctly with the existing documentation ecosystem? *(Evidence: describe how it cross-links or relates to existing docs.)*"
         }
       ],
       "requireConfirmation": false

package/workflows/documentation-update-workflow.json

@@ -2,7 +2,7 @@
   "id": "documentation-update-workflow",
   "name": "Documentation Update & Maintenance Workflow",
   "version": "2.0.0",
-  "description": "Update and maintain existing documentation. Uses git history to detect staleness, maps sections to current code, and systematically refreshes outdated content while preserving valuable accurate sections. For updating existing docs — not for creating new documentation.",
+  "description": "Use this to update and maintain existing documentation. Uses git history to detect staleness, maps sections to current code, and refreshes outdated content while preserving what's still accurate.",
   "preconditions": [
     "Target documentation files are accessible",
     "Agent has git access to the repository containing both docs and code",
@@ -14,15 +14,15 @@
     "GIT-EVIDENCE-FIRST: staleness judgment must be grounded in actual git log output. Do not assert a doc is stale based on reading it alone. Run git log; record commit SHAs and messages as evidence.",
     "PRESERVATION-FIRST: keep accurate, well-written content unchanged. Only update what is demonstrably stale or incorrect. Targeted updates are better than wholesale rewrites.",
     "VERIFY AGAINST CODE: all updated technical content must be checked against current codebase state. Code examples and API references must match what is actually in the code today.",
-    "DEGRADE AND DISCLOSE: if git history is unavailable or shallow for some paths, classify staleness as medium and note what evidence is missing. Never block — proceed with what is available.",
+    "DEGRADE AND DISCLOSE: if git history is unavailable or shallow for some paths, classify staleness as medium and note what evidence is missing. Never block \u2014 proceed with what is available.",
     "SELF-EXECUTE: explore first with tools. Ask the user only what you genuinely cannot determine from the codebase and git history. The one real confirmation gate is the update plan before executing edits.",
-    "LOOP DISCIPLINE: the update loop runs without per-section gates — the plan was approved in phase-2. Only pause if a section requires changes beyond what the approved plan covers; note the deviation and ask."
+    "LOOP DISCIPLINE: the update loop runs without per-section gates \u2014 the plan was approved in phase-2. Only pause if a section requires changes beyond what the approved plan covers; note the deviation and ask."
   ],
   "steps": [
     {
       "id": "phase-0-assess",
       "title": "Phase 0: Assess Documentation & Establish Git Baseline",
-      "prompt": "Locate the target documentation and establish an evidence-based staleness assessment before you decide anything.\n\n**Step 1: Locate and inventory target docs**\n- Identify all documentation files in scope\n- Note file formats, structure, and rough section organization\n- Infer the code paths these docs reference (scopePaths)\n\n**Step 2: Git baseline**\n- Run `git log -1 <docPath>` for each target doc to get the last commit SHA and date\n- Run `git log <lastCommitSha>..HEAD -- <scopePaths>` to get all code changes since the doc was last updated\n- For each commit, classify impact: API/breaking (new exports, changed interfaces, removed functions), behavioral (changed logic), config (schema/option changes), or minor (refactor, rename, test-only)\n\n**Step 3: Staleness classification (rubric-based)**\n\nScore these three dimensions:\n- **Impact**: any API/breaking changes? any behavioral or config changes?\n- **Volume**: how many commits changed the relevant scope since last doc update?\n- **Age**: how many days since the doc was last committed?\n\nDerive `stalenessLevel`:\n- `high`: any API/breaking impact, OR volume > 5 commits AND age > 90 days\n- `medium`: volume > 2 commits, OR age > 60 days, OR behavioral/config changes present\n- `low`: few changes, nothing impacting documented behavior, age < 60 days\n- If git history is unavailable: `medium` — note what is missing\n\nDerive `updateUrgency`:\n- `high` staleness → `immediate`\n- `medium` staleness → `scheduled`\n- `low` staleness → `monitor` — if user did not request a forced update, document why and offer to exit\n\n**Capture:**\n- `targetDocPaths`, `scopePaths`\n- `gitLastDocCommitSha`, `gitLastDocCommitDate`\n- `stalenessLevel`, `updateUrgency`\n- `gitChangeSummary` — prose summary of what changed and why it matters for the docs",
+      "prompt": "Locate the target documentation and establish an evidence-based staleness assessment before you decide anything.\n\n**Step 1: Locate and inventory target docs**\n- Identify all documentation files in scope\n- Note file formats, structure, and rough section organization\n- Infer the code paths these docs reference (scopePaths)\n\n**Step 2: Git baseline**\n- Run `git log -1 <docPath>` for each target doc to get the last commit SHA and date\n- Run `git log <lastCommitSha>..HEAD -- <scopePaths>` to get all code changes since the doc was last updated\n- For each commit, classify impact: API/breaking (new exports, changed interfaces, removed functions), behavioral (changed logic), config (schema/option changes), or minor (refactor, rename, test-only)\n\n**Step 3: Staleness classification (rubric-based)**\n\nScore these three dimensions:\n- **Impact**: any API/breaking changes? any behavioral or config changes?\n- **Volume**: how many commits changed the relevant scope since last doc update?\n- **Age**: how many days since the doc was last committed?\n\nDerive `stalenessLevel`:\n- `high`: any API/breaking impact, OR volume > 5 commits AND age > 90 days\n- `medium`: volume > 2 commits, OR age > 60 days, OR behavioral/config changes present\n- `low`: few changes, nothing impacting documented behavior, age < 60 days\n- If git history is unavailable: `medium` \u2014 note what is missing\n\nDerive `updateUrgency`:\n- `high` staleness \u2192 `immediate`\n- `medium` staleness \u2192 `scheduled`\n- `low` staleness \u2192 `monitor` \u2014 if user did not request a forced update, document why and offer to exit\n\n**Capture:**\n- `targetDocPaths`, `scopePaths`\n- `gitLastDocCommitSha`, `gitLastDocCommitDate`\n- `stalenessLevel`, `updateUrgency`\n- `gitChangeSummary` \u2014 prose summary of what changed and why it matters for the docs",
       "requireConfirmation": {
         "var": "updateUrgency",
         "equals": "monitor"
@@ -31,13 +31,13 @@
     {
       "id": "phase-1-analyze",
       "title": "Phase 1: Section-by-Section Gap Analysis",
-      "prompt": "Now map each documentation section to current code and classify what needs to change.\n\nFor each section in the target docs:\n1. **Map to code** — which files, functions, APIs, or behaviors does this section describe?\n2. **Assess accuracy** — does the current code match what the section says? Check API signatures, config options, behavioral descriptions, examples, and file paths.\n3. **Classify the section action**:\n   - `preserve` — still accurate, well-written; keep unchanged\n   - `update` — needs correction or expansion; note specifically what changed\n   - `remove` — describes something that no longer exists\n\n4. **Assign update type** for sections marked `update`:\n   - `corrective` — fix inaccurate information\n   - `additive` — add missing coverage for new features\n   - `expansive` — expand thin explanations\n   - `reductive` — remove deprecated or removed content\n   - `structural` — reorganize while preserving content\n\n5. **Assign priority** for sections marked `update`:\n   - `critical` — inaccurate content that would cause errors or confusion for users\n   - `important` — missing or outdated content for significant features or workflows\n   - `beneficial` — improvements that add value but aren't blocking\n\n**Capture:**\n- `sectionInventory` — list of all sections with: sectionId, action (preserve/update/remove), updateType, priority, and a one-line reason\n\nEvery section must be classified before moving on.",
+      "prompt": "Now map each documentation section to current code and classify what needs to change.\n\nFor each section in the target docs:\n1. **Map to code** \u2014 which files, functions, APIs, or behaviors does this section describe?\n2. **Assess accuracy** \u2014 does the current code match what the section says? Check API signatures, config options, behavioral descriptions, examples, and file paths.\n3. **Classify the section action**:\n   - `preserve` \u2014 still accurate, well-written; keep unchanged\n   - `update` \u2014 needs correction or expansion; note specifically what changed\n   - `remove` \u2014 describes something that no longer exists\n\n4. **Assign update type** for sections marked `update`:\n   - `corrective` \u2014 fix inaccurate information\n   - `additive` \u2014 add missing coverage for new features\n   - `expansive` \u2014 expand thin explanations\n   - `reductive` \u2014 remove deprecated or removed content\n   - `structural` \u2014 reorganize while preserving content\n\n5. **Assign priority** for sections marked `update`:\n   - `critical` \u2014 inaccurate content that would cause errors or confusion for users\n   - `important` \u2014 missing or outdated content for significant features or workflows\n   - `beneficial` \u2014 improvements that add value but aren't blocking\n\n**Capture:**\n- `sectionInventory` \u2014 list of all sections with: sectionId, action (preserve/update/remove), updateType, priority, and a one-line reason\n\nEvery section must be classified before moving on.",
       "requireConfirmation": false
     },
     {
       "id": "phase-2-plan",
       "title": "Phase 2: Update Plan",
-      "prompt": "Build the ordered update plan based on the section inventory, then confirm it with me before you start editing anything.\n\nFrom `sectionInventory`, create `updatePlan` as an ordered list:\n1. All `critical` updates first\n2. `important` updates next\n3. `beneficial` updates last (may defer if scope is large)\n\nFor each entry in the plan:\n- Section name and location\n- Update type (corrective / additive / expansive / reductive / structural)\n- Specific description of what to change and why\n- What content to preserve unchanged\n\nAlso note:\n- Total sections to update vs total sections to preserve\n- Any `remove` entries that need explicit deletion\n- Any sections that are `beneficial` you recommend deferring\n\n**This step requires confirmation** — I need to review the plan before you make edits to the documentation files.\n\n**Capture:**\n- `updatePlan` — ordered list as described above\n- `sectionsRemaining` — total count of sections to update (for loop tracking)",
+      "prompt": "Build the ordered update plan based on the section inventory, then confirm it with me before you start editing anything.\n\nFrom `sectionInventory`, create `updatePlan` as an ordered list:\n1. All `critical` updates first\n2. `important` updates next\n3. `beneficial` updates last (may defer if scope is large)\n\nFor each entry in the plan:\n- Section name and location\n- Update type (corrective / additive / expansive / reductive / structural)\n- Specific description of what to change and why\n- What content to preserve unchanged\n\nAlso note:\n- Total sections to update vs total sections to preserve\n- Any `remove` entries that need explicit deletion\n- Any sections that are `beneficial` you recommend deferring\n\n**This step requires confirmation** \u2014 I need to review the plan before you make edits to the documentation files.\n\n**Capture:**\n- `updatePlan` \u2014 ordered list as described above\n- `sectionsRemaining` \u2014 total count of sections to update (for loop tracking)",
       "requireConfirmation": true
     },
     {
@@ -69,7 +69,7 @@
         {
           "id": "verify-section",
           "title": "Verify the Updated Section",
-          "prompt": "Verify that the update to `currentSection` is correct before moving on.\n\nCheck:\n1. **Technical accuracy** — does every technical claim match the current codebase? Check the code directly if needed.\n2. **Code examples** — are all code blocks in this section syntactically valid and behaviorally correct against current APIs?\n3. **Preservation** — what did you keep unchanged? Confirm the preserved content is still present and intact.\n4. **Cross-references** — are any internal links pointing to or from this section still working?\n\nDecrement `sectionsRemaining` by 1.\n\nRecord findings in notes: what you changed, what you preserved, any issues found.\n\n**Capture:** updated `sectionsRemaining`",
+          "prompt": "Verify that the update to `currentSection` is correct before moving on.\n\nCheck:\n1. **Technical accuracy** \u2014 does every technical claim match the current codebase? Check the code directly if needed.\n2. **Code examples** \u2014 are all code blocks in this section syntactically valid and behaviorally correct against current APIs?\n3. **Preservation** \u2014 what did you keep unchanged? Confirm the preserved content is still present and intact.\n4. **Cross-references** \u2014 are any internal links pointing to or from this section still working?\n\nDecrement `sectionsRemaining` by 1.\n\nRecord findings in notes: what you changed, what you preserved, any issues found.\n\n**Capture:** updated `sectionsRemaining`",
           "requireConfirmation": false
         },
         {
@@ -87,7 +87,7 @@
     {
       "id": "phase-4-validate",
       "title": "Phase 4: End-to-End Validation",
-      "prompt": "Read through all updated documentation as a fresh reader and validate it as a whole.\n\n1. **End-to-end consistency** — read the docs in order. Is terminology consistent? Does the logical flow make sense? Do sections refer to each other correctly?\n\n2. **Technical accuracy pass** — for any section you feel uncertain about, verify it against current code now. If verification reveals a remaining inaccuracy, note it explicitly: what is wrong, where it is, and what the correct information should be. Do not silently pass a section you are unsure about.\n\n3. **User journey test** — walk through the key documented workflows from start to finish using only the documentation. Do setup instructions work? Are the most important use cases covered correctly?\n\n4. **Navigation and structure** — are all cross-references working? Is the table of contents (if present) accurate? Can a user find what they need?\n\n5. **Completeness check** — look back at the original gap analysis. Were all critical and important updates completed? Note explicitly if any were deferred.\n\nDocument what you found: any remaining issues, any sections that still need work, and your overall assessment of the documentation quality after the update.",
+      "prompt": "Read through all updated documentation as a fresh reader and validate it as a whole.\n\n1. **End-to-end consistency** \u2014 read the docs in order. Is terminology consistent? Does the logical flow make sense? Do sections refer to each other correctly?\n\n2. **Technical accuracy pass** \u2014 for any section you feel uncertain about, verify it against current code now. If verification reveals a remaining inaccuracy, note it explicitly: what is wrong, where it is, and what the correct information should be. Do not silently pass a section you are unsure about.\n\n3. **User journey test** \u2014 walk through the key documented workflows from start to finish using only the documentation. Do setup instructions work? Are the most important use cases covered correctly?\n\n4. **Navigation and structure** \u2014 are all cross-references working? Is the table of contents (if present) accurate? Can a user find what they need?\n\n5. **Completeness check** \u2014 look back at the original gap analysis. Were all critical and important updates completed? Note explicitly if any were deferred.\n\nDocument what you found: any remaining issues, any sections that still need work, and your overall assessment of the documentation quality after the update.",
       "requireConfirmation": false
     },
     {

package/workflows/intelligent-test-case-generation.json

@@ -2,7 +2,7 @@
   "id": "intelligent-test-case-generation",
   "name": "Test Case Generation from Tickets",
   "version": "1.0.0",
-  "description": "Systematically extracts integration and end-to-end test cases from ticket requirements. Reads the ticket carefully, identifies boundary conditions and edge cases, traces affected code paths, and produces developer-readable test case descriptions ready for implementation.",
+  "description": "Use this to generate integration and end-to-end test cases from ticket requirements. Reads the ticket, traces affected code paths, identifies boundary conditions, and produces developer-readable test case descriptions.",
   "preconditions": [
     "User provides a ticket (title, description, acceptance criteria) in any standard format.",
     "Agent has read access to the codebase for tracing affected paths and finding existing test patterns.",
@@ -31,7 +31,7 @@
         "var": "ambiguities",
         "not_equals": []
       },
-      "prompt": "Before generating test scenarios, resolve the ambiguities you found.\n\nFor each ambiguity in `ambiguities`:\n1. State what is unclear and why it matters for test design\n2. Propose the most reasonable interpretation based on context\n3. Ask me to confirm, adjust, or provide the missing information\n\nKeep questions targeted. If the ticket, codebase, or docs can answer the question, answer it yourself first.\n\nIf the user's response significantly changes the scope or adds new acceptance criteria, revisit Phase 1 scenario identification before continuing — do not carry stale scenarios forward.\n\nCapture:\n- `resolvedAmbiguities` -- list of ambiguities with chosen interpretation\n- `openAmbiguities` -- ambiguities the user still needs to resolve (initialize as empty)",
+      "prompt": "Before generating test scenarios, resolve the ambiguities you found.\n\nFor each ambiguity in `ambiguities`:\n1. State what is unclear and why it matters for test design\n2. Propose the most reasonable interpretation based on context\n3. Ask me to confirm, adjust, or provide the missing information\n\nKeep questions targeted. If the ticket, codebase, or docs can answer the question, answer it yourself first.\n\nIf the user's response significantly changes the scope or adds new acceptance criteria, revisit Phase 1 scenario identification before continuing \u2014 do not carry stale scenarios forward.\n\nCapture:\n- `resolvedAmbiguities` -- list of ambiguities with chosen interpretation\n- `openAmbiguities` -- ambiguities the user still needs to resolve (initialize as empty)",
       "requireConfirmation": true
     },
     {