@exaudeus/workrail 3.7.3 → 3.8.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/config/feature-flags.js +2 -2
- package/dist/console/assets/index-C5C4nDs4.css +1 -0
- package/dist/console/assets/index-CSUqsoQl.js +28 -0
- package/dist/console/index.html +13 -0
- package/dist/manifest.json +16 -4
- package/dist/v2/usecases/console-routes.js +9 -6
- package/package.json +1 -1
- package/workflows/workflow-for-workflows.v2.json +40 -16
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
<!DOCTYPE html>
|
|
2
|
+
<html lang="en">
|
|
3
|
+
<head>
|
|
4
|
+
<meta charset="UTF-8" />
|
|
5
|
+
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
|
6
|
+
<title>WorkRail Console</title>
|
|
7
|
+
<script type="module" crossorigin src="/console/assets/index-CSUqsoQl.js"></script>
|
|
8
|
+
<link rel="stylesheet" crossorigin href="/console/assets/index-C5C4nDs4.css">
|
|
9
|
+
</head>
|
|
10
|
+
<body>
|
|
11
|
+
<div id="root"></div>
|
|
12
|
+
</body>
|
|
13
|
+
</html>
|
package/dist/manifest.json
CHANGED
|
@@ -358,8 +358,20 @@
|
|
|
358
358
|
"bytes": 1512
|
|
359
359
|
},
|
|
360
360
|
"config/feature-flags.js": {
|
|
361
|
-
"sha256": "
|
|
362
|
-
"bytes":
|
|
361
|
+
"sha256": "aabbaca7582a27fb7e2b47df88218e6e96d26b8fb8799cab6d25808685bd9196",
|
|
362
|
+
"bytes": 7686
|
|
363
|
+
},
|
|
364
|
+
"console/assets/index-C5C4nDs4.css": {
|
|
365
|
+
"sha256": "a3fdfc902967452fbad38abc323e3d164bd4359c3e89c00a6d44052a590fb2e3",
|
|
366
|
+
"bytes": 34096
|
|
367
|
+
},
|
|
368
|
+
"console/assets/index-CSUqsoQl.js": {
|
|
369
|
+
"sha256": "70957146018d67bf1307ca71333f186dccf4348b55b43ef2e5f6701415c05b2e",
|
|
370
|
+
"bytes": 545520
|
|
371
|
+
},
|
|
372
|
+
"console/index.html": {
|
|
373
|
+
"sha256": "202664a02de7ea2820e872fe573dff19f0587b7e18031a7e8780b2ef5ff814e5",
|
|
374
|
+
"bytes": 417
|
|
363
375
|
},
|
|
364
376
|
"core/error-handler.d.ts": {
|
|
365
377
|
"sha256": "80451f12ac8e185133ec3dc4c57285491a785f27525ed21e729db1da3f61010d",
|
|
@@ -2438,8 +2450,8 @@
|
|
|
2438
2450
|
"bytes": 204
|
|
2439
2451
|
},
|
|
2440
2452
|
"v2/usecases/console-routes.js": {
|
|
2441
|
-
"sha256": "
|
|
2442
|
-
"bytes":
|
|
2453
|
+
"sha256": "0a466d35a2b002e87e2ff38f5dd583a4d4d26e66d1732a8ac4f3e303ddad6356",
|
|
2454
|
+
"bytes": 2935
|
|
2443
2455
|
},
|
|
2444
2456
|
"v2/usecases/console-service.d.ts": {
|
|
2445
2457
|
"sha256": "88bf7eb84bad74c048f76038b0d2631d49f2256587e42907fe2df14fc58f67e1",
|
|
@@ -8,12 +8,15 @@ const express_1 = __importDefault(require("express"));
|
|
|
8
8
|
const path_1 = __importDefault(require("path"));
|
|
9
9
|
const fs_1 = __importDefault(require("fs"));
|
|
10
10
|
function resolveConsoleDist() {
|
|
11
|
-
const
|
|
12
|
-
if (fs_1.default.existsSync(
|
|
13
|
-
return
|
|
14
|
-
const
|
|
15
|
-
if (fs_1.default.existsSync(
|
|
16
|
-
return
|
|
11
|
+
const releasedDist = path_1.default.join(__dirname, '../../console');
|
|
12
|
+
if (fs_1.default.existsSync(releasedDist))
|
|
13
|
+
return releasedDist;
|
|
14
|
+
const fromSourceBuild = path_1.default.join(__dirname, '../../../dist/console');
|
|
15
|
+
if (fs_1.default.existsSync(fromSourceBuild))
|
|
16
|
+
return fromSourceBuild;
|
|
17
|
+
const legacyConsoleDist = path_1.default.join(__dirname, '../../../console/dist');
|
|
18
|
+
if (fs_1.default.existsSync(legacyConsoleDist))
|
|
19
|
+
return legacyConsoleDist;
|
|
17
20
|
return null;
|
|
18
21
|
}
|
|
19
22
|
function mountConsoleRoutes(app, consoleService) {
|
package/package.json
CHANGED
|
@@ -2,27 +2,27 @@
|
|
|
2
2
|
"id": "workflow-for-workflows",
|
|
3
3
|
"name": "Workflow Authoring Workflow (Lean, References-First)",
|
|
4
4
|
"version": "2.0.0",
|
|
5
|
-
"description": "Guides an agent through
|
|
5
|
+
"description": "Guides an agent through authoring or modernizing a WorkRail workflow: understand the task, choose the shape, draft or revise the JSON, validate with real validators, review the method, and optionally refine.",
|
|
6
6
|
"recommendedPreferences": {
|
|
7
7
|
"recommendedAutonomy": "guided",
|
|
8
8
|
"recommendedRiskPolicy": "conservative"
|
|
9
9
|
},
|
|
10
10
|
"preconditions": [
|
|
11
|
-
"User has a recurring task or problem
|
|
11
|
+
"User has a recurring task or problem a workflow should solve, or an existing workflow that should be modernized.",
|
|
12
12
|
"Agent has access to file creation, editing, and terminal tools.",
|
|
13
13
|
"Agent can run workflow validators (npm run validate:registry or equivalent)."
|
|
14
14
|
],
|
|
15
15
|
"metaGuidance": [
|
|
16
16
|
"REFERENCE HIERARCHY: treat workflow-schema as legal truth for structure. Treat authoring-spec as canonical current guidance for what makes a workflow good. Treat authoring-provenance as optional maintainer context only.",
|
|
17
|
-
"META DISTINCTION: you are
|
|
18
|
-
"DEFAULT BEHAVIOR: self-execute with tools. Only ask the user for business decisions about the workflow being
|
|
19
|
-
"AUTHORED VOICE: prompts in the
|
|
20
|
-
"VOICE ADAPTATION: the lean coding workflow is one voice example, not the universal template. Adapt vocabulary and tone to the
|
|
17
|
+
"META DISTINCTION: you are authoring or modernizing a workflow, not executing one. Keep the authored workflow's concerns separate from this meta-workflow's execution.",
|
|
18
|
+
"DEFAULT BEHAVIOR: self-execute with tools. Only ask the user for business decisions about the workflow being authored or modernized, not things you can learn from the schema, authoring spec, or example workflows.",
|
|
19
|
+
"AUTHORED VOICE: prompts in the authored workflow must be user-voiced. No middleware narration, no pseudo-DSL, no tutorial framing, no teaching-product language.",
|
|
20
|
+
"VOICE ADAPTATION: the lean coding workflow is one voice example, not the universal template. Adapt vocabulary and tone to the authored workflow's domain.",
|
|
21
21
|
"VOICE EXAMPLES: Coding: 'Review the changes in this MR.' Ops: 'Check whether the pipeline is healthy.' Content: 'Read the draft and check the argument.' NOT: 'The system will now perform a comprehensive analysis of...'",
|
|
22
22
|
"VALIDATION GATE: validate with real validators, not regex approximations. When validator output and authoring assumptions conflict, runtime wins.",
|
|
23
23
|
"ARTIFACT STRATEGY: the workflow JSON file is the primary output. Intermediate notes go in output.notesMarkdown. Do not create extra planning artifacts unless the workflow is genuinely complex.",
|
|
24
24
|
"V2 DURABILITY: use output.notesMarkdown as the primary durable record. Do not mirror execution state into CONTEXT.md or markdown checkpoint files.",
|
|
25
|
-
"ANTI-PATTERNS TO AVOID IN
|
|
25
|
+
"ANTI-PATTERNS TO AVOID IN AUTHORED WORKFLOWS: no pseudo-function metaGuidance, no learning-path branching, no satisfaction-score loops, no heavy clarification batteries, no regex-as-primary-validation, no celebration phases.",
|
|
26
26
|
"NEVER COMMIT MARKDOWN FILES UNLESS USER EXPLICITLY ASKS."
|
|
27
27
|
],
|
|
28
28
|
"references": [
|
|
@@ -50,6 +50,30 @@
|
|
|
50
50
|
"purpose": "Source-of-truth map showing what is canonical, derived, and non-canonical in workflow authoring guidance. Optional maintainer context.",
|
|
51
51
|
"authoritative": false
|
|
52
52
|
},
|
|
53
|
+
{
|
|
54
|
+
"id": "authoring-guide-v2",
|
|
55
|
+
"title": "Workflow Authoring Guide (v2)",
|
|
56
|
+
"source": "docs/authoring-v2.md",
|
|
57
|
+
"resolveFrom": "workspace",
|
|
58
|
+
"purpose": "Current v2 authoring principles, references guidance, and durable execution patterns.",
|
|
59
|
+
"authoritative": true
|
|
60
|
+
},
|
|
61
|
+
{
|
|
62
|
+
"id": "workflow-authoring-reference",
|
|
63
|
+
"title": "Workflow Authoring Reference",
|
|
64
|
+
"source": "docs/design/workflow-authoring-v2.md",
|
|
65
|
+
"resolveFrom": "workspace",
|
|
66
|
+
"purpose": "Detailed v2 workflow authoring patterns for loops, conditions, references, and workflow structure.",
|
|
67
|
+
"authoritative": true
|
|
68
|
+
},
|
|
69
|
+
{
|
|
70
|
+
"id": "routines-guide",
|
|
71
|
+
"title": "Routines Guide",
|
|
72
|
+
"source": "docs/design/routines-guide.md",
|
|
73
|
+
"resolveFrom": "workspace",
|
|
74
|
+
"purpose": "Current guide for deciding when to use delegation, direct execution, or template injection in authored workflows.",
|
|
75
|
+
"authoritative": false
|
|
76
|
+
},
|
|
53
77
|
{
|
|
54
78
|
"id": "lean-coding-workflow",
|
|
55
79
|
"title": "Lean Coding Workflow (Modern Example)",
|
|
@@ -62,8 +86,8 @@
|
|
|
62
86
|
"steps": [
|
|
63
87
|
{
|
|
64
88
|
"id": "phase-0-understand",
|
|
65
|
-
"title": "Phase 0: Understand the Workflow to
|
|
66
|
-
"prompt": "Before you write anything, understand what you're
|
|
89
|
+
"title": "Phase 0: Understand the Workflow to Author or Modernize",
|
|
90
|
+
"prompt": "Before you write anything, understand what you're working on.\n\nStart by reading:\n- `workflow-schema` reference (legal structure)\n- `authoring-spec` reference (canonical authoring rules)\n- `authoring-guide-v2` reference (current v2 authoring principles)\n- `workflow-authoring-reference` reference (detailed structure patterns)\n- `lean-coding-workflow` reference (modern example to inspect)\n\nRead `routines-guide` too if you think the authored workflow may need delegation or template injection.\n\nThen decide what kind of authoring task this is:\n- `authoringMode`: `create` or `modernize_existing`\n\nIf `authoringMode = create`, understand:\n- What recurring task or problem should this workflow solve?\n- Who runs it and how often?\n- What does success look like?\n- What constraints exist (tools, permissions, domain rules)?\n\nIf `authoringMode = modernize_existing`, understand:\n- Which workflow file is being updated?\n- What should stay the same about its purpose?\n- What feels stale, legacy, repetitive, or misaligned with current authoring guidance?\n- What constraints apply to the modernization (keep file path, preserve compatibility, avoid broad rewrites, etc.)?\n\nExplore first. Use tools to understand the existing workflow, surrounding docs, and relevant domain context. Ask the user only what you genuinely cannot figure out yourself.\n\nThen classify:\n- `workflowComplexity`: Simple (linear, few steps) / Medium (branches, loops, or moderate step count) / Complex (multiple loops, delegation, extension points, many steps)\n- `rigorMode`: QUICK (simple linear workflow, low risk) / STANDARD (moderate complexity or domain risk) / THOROUGH (complex architecture, high stakes, needs review loops)\n\nCapture:\n- `authoringMode`\n- `workflowComplexity`\n- `rigorMode`\n- `taskDescription`\n- `intendedAudience`\n- `successCriteria`\n- `domainConstraints`\n- `targetWorkflowPath` (required for `modernize_existing`, otherwise empty)\n- `modernizationGoals` (required for `modernize_existing`, otherwise empty)\n- `openQuestions` (only real questions that need user input)",
|
|
67
91
|
"requireConfirmation": true
|
|
68
92
|
},
|
|
69
93
|
{
|
|
@@ -73,7 +97,7 @@
|
|
|
73
97
|
"var": "workflowComplexity",
|
|
74
98
|
"not_equals": "Simple"
|
|
75
99
|
},
|
|
76
|
-
"prompt": "Decide the architecture before you write JSON.\n\nBased on what you learned in Phase 0, decide:\n\n1. **Step structure**: how many phases, what each one does, what order\n2. **Loops**: does any phase need iteration? If so, what are the exit rules and max iterations?\n\nLoop design heuristics:\n- Add a loop ONLY when: (a) a quality gate may fail on first pass (validation, review), (b) each pass adds measurable value (progressive refinement), or (c) external feedback requires re-execution.\n- Do NOT loop when: (a) the agent can get it right in one pass with sufficient context, or (b) the full workflow is cheap enough to re-run entirely.\n- Every loop needs: an explicit exit condition (not vibes), a bounded maxIterations, and a decision step with outputContract.\n- Sensible defaults: validation ≈ 2-3, review/refinement ≈ 2, user-feedback ≈ 2-3 with confirmation gate. Go higher only with explicit justification in your notes.\n3. **Confirmation gates**: where does the user genuinely need to approve before proceeding? Don't add confirmations as ceremony.\n4. **Delegation**: does any step benefit from subagent routines? If so, which ones and why? Keep delegation bounded.\n5. **Prompt composition**: will any steps need promptFragments for rigor-mode branching? Will any steps share enough structure to use templates?\n6. **Extension points**: are there customizable slots that projects might want to override (e.g., a verification routine, a review routine)?\n7. **References**: should the
|
|
100
|
+
"prompt": "Decide the architecture before you write JSON.\n\nBased on what you learned in Phase 0, decide:\n\n1. **Step structure**: how many phases, what each one does, what order\n2. **Loops**: does any phase need iteration? If so, what are the exit rules and max iterations?\n\nLoop design heuristics:\n- Add a loop ONLY when: (a) a quality gate may fail on first pass (validation, review), (b) each pass adds measurable value (progressive refinement), or (c) external feedback requires re-execution.\n- Do NOT loop when: (a) the agent can get it right in one pass with sufficient context, or (b) the full workflow is cheap enough to re-run entirely.\n- Every loop needs: an explicit exit condition (not vibes), a bounded maxIterations, and a decision step with outputContract.\n- Sensible defaults: validation ≈ 2-3, review/refinement ≈ 2, user-feedback ≈ 2-3 with confirmation gate. Go higher only with explicit justification in your notes.\n3. **Confirmation gates**: where does the user genuinely need to approve before proceeding? Don't add confirmations as ceremony.\n4. **Delegation**: does any step benefit from subagent routines? If so, which ones and why? Keep delegation bounded.\n5. **Prompt composition**: will any steps need promptFragments for rigor-mode branching? Will any steps share enough structure to use templates?\n6. **Extension points**: are there customizable slots that projects might want to override (e.g., a verification routine, a review routine)?\n7. **References**: should the authored workflow declare its own references to external docs?\n8. **Artifacts**: what does each step produce? Which artifact is canonical for which concern?\n9. **metaGuidance**: what persistent behavioral rules should the agent see on start and resume?\n\nIf `authoringMode = modernize_existing`, also decide:\n- should this workflow be preserved mostly in place, restructured selectively, or rewritten more substantially?\n- which existing steps, loops, references, or metaGuidance should stay because they still fit the workflow's purpose?\n- which legacy patterns or repetitive sections should be removed or reshaped?\n- whether the file path should stay the same or whether a new variant/file is genuinely warranted\n\nWrite the shape as a structured outline in your notes. Include:\n- Phase list with titles and one-line goals\n- Which phases loop and why\n- Which phases have confirmation gates and why\n- Context variables that flow between phases\n- Artifact ownership (which artifact is canonical for what)\n- for `modernize_existing`: whether the plan is preserve-in-place, restructure, or rewrite-biased and why\n\nDon't write JSON yet.\n\nCapture:\n- `workflowOutline`\n- `loopDesign`\n- `confirmationDesign`\n- `delegationDesign`\n- `artifactPlan`\n- `contextModel` (the context variables the workflow will use and where they're set)\n- `voiceStrategy` (domain vocabulary, authority posture: directive/collaborative/supervisory, density calibration)\n- `modernizationStrategy` (for `modernize_existing`: preserve_in_place / restructure / rewrite, otherwise empty)",
|
|
77
101
|
"requireConfirmation": {
|
|
78
102
|
"or": [
|
|
79
103
|
{ "var": "workflowComplexity", "not_equals": "Simple" },
|
|
@@ -83,8 +107,8 @@
|
|
|
83
107
|
},
|
|
84
108
|
{
|
|
85
109
|
"id": "phase-2-draft",
|
|
86
|
-
"title": "Phase 2: Draft the Workflow",
|
|
87
|
-
"prompt": "Write the workflow JSON file.\n\nUse the outline from Phase 1 and
|
|
110
|
+
"title": "Phase 2: Draft or Revise the Workflow",
|
|
111
|
+
"prompt": "Write the workflow JSON file.\n\nUse the outline from Phase 1 and produce the best first pass you can. If `authoringMode = create`, draft a new workflow. If `authoringMode = modernize_existing`, revise the existing workflow so it keeps the right intent while removing stale structure, legacy patterns, or unnecessary repetition. Phase 3 will catch structural issues, so focus on getting the shape and voice right. Follow these rules:\n\n1. The schema (`workflow-schema` reference) defines what is structurally legal. Do not invent fields.\n2. The authoring spec (`authoring-spec` reference) defines what is good. Follow its active rules.\n3. Write prompts in the user's voice. The opening sentence of each step should sound like a direct ask, not system narration.\n4. Calibrate prompt density to the step's needs. Not all steps need the same level of detail:\n - Sparse (expert audience, clear task): direct ask + capture footer only.\n - Focused (expert audience, ambiguous task): direct ask + key criteria or trade-offs + capture.\n - Guided (broad audience, clear task): direct ask + enumerated sub-steps + capture.\n - Scaffolded (broad audience, ambiguous task): direct ask + context frame + sub-steps + heuristic + capture.\n Default to Focused if unsure. Vary density across steps -- uniform density is a smell.\n5. Keep protocol requirements explicit. If a step must emit a specific artifact or capture specific context, say that plainly.\n6. Use promptFragments for conditional rigor-mode branches instead of duplicating entire steps.\n7. Loop decision steps must use `outputContract` with `wr.contracts.loop_control` and allow both `continue` and `stop` in the output example.\n8. Loops must have explicit exit rules, bounded maxIterations, and a clear reason for another pass.\n9. Confirmation gates are for real human decisions, not routine ceremony.\n10. metaGuidance should be clean behavioral rules, not pseudo-functions or teaching prose.\n11. Do not use regex validationCriteria as the primary quality gate. Use real validators.\n12. If you are modernizing, preserve what still fits the workflow's purpose. Do not rewrite just because a workflow is old.\n\nIf `authoringMode = create`, ask the user what filename to use if they haven't specified one.\nIf `authoringMode = modernize_existing`, default to editing `targetWorkflowPath` unless there is a strong reason to create a new variant or file.\n\nWrite the file. Do not explain the JSON back to the user field by field.\n\nCapture:\n- `workflowFilePath`\n- `draftComplete`",
|
|
88
112
|
"promptFragments": [
|
|
89
113
|
{
|
|
90
114
|
"id": "phase-2-simple-fast",
|
|
@@ -139,13 +163,13 @@
|
|
|
139
163
|
"var": "validationPassed",
|
|
140
164
|
"equals": false
|
|
141
165
|
},
|
|
142
|
-
"prompt": "Validation did not pass after the maximum number of attempts.\n\nCheck whether the last validation run actually passed. If `validationPassed` is false or if you're uncertain, list the remaining errors and your assessment of their severity.\n\nThen present the options:\n1. Proceed with known issues documented in handoff notes.\n2. Stop
|
|
166
|
+
"prompt": "Validation did not pass after the maximum number of attempts.\n\nCheck whether the last validation run actually passed. If `validationPassed` is false or if you're uncertain, list the remaining errors and your assessment of their severity.\n\nThen present the options:\n1. Proceed with known issues documented in handoff notes.\n2. Stop here so the user can intervene manually.\n\nDo not silently continue with a broken workflow.",
|
|
143
167
|
"requireConfirmation": true
|
|
144
168
|
},
|
|
145
169
|
{
|
|
146
170
|
"id": "phase-4-review",
|
|
147
171
|
"title": "Phase 4: Method Review",
|
|
148
|
-
"prompt": "The workflow is valid. Now check whether it's actually good.\n\nScore each dimension 0-2 with one sentence of evidence:\n\n- `voiceClarity`: 0 = prompts are direct user-voiced asks in the workflow's domain vocabulary, 1 = mostly user-voiced but borrows vocabulary from other domains or has middleware narration, 2 = reads like system documentation or sounds like a different domain\n- `ceremonyLevel`: 0 = confirmations only at real decision points, 1 = one or two unnecessary gates, 2 = over-asks the user or adds routine ceremony\n- `loopSoundness`: 0 = loops have explicit exit rules, bounded iterations, and real decision steps, 1 = minor issues with exit clarity, 2 = vibes-only exit conditions or unbounded loops (score 0 if no loops)\n- `delegationBoundedness`: 0 = delegation is bounded and explicit or absent, 1 = one delegation could be tighter, 2 = open-ended or ownership-transferring delegation (score 0 if no delegation)\n- `legacyPatterns`: 0 = no legacy anti-patterns, 1 = minor legacy residue, 2 = pseudo-DSL, learning paths, satisfaction loops, or regex-as-gate present\n- `artifactClarity`: 0 = clear what each artifact is for and which is canonical, 1 = mostly clear, 2 = ambiguous artifact ownership\n\nIf the total score is 0-
|
|
172
|
+
"prompt": "The workflow is valid. Now check whether it's actually good.\n\nScore each dimension 0-2 with one sentence of evidence:\n\n- `voiceClarity`: 0 = prompts are direct user-voiced asks in the workflow's domain vocabulary, 1 = mostly user-voiced but borrows vocabulary from other domains or has middleware narration, 2 = reads like system documentation or sounds like a different domain\n- `ceremonyLevel`: 0 = confirmations only at real decision points, 1 = one or two unnecessary gates, 2 = over-asks the user or adds routine ceremony\n- `loopSoundness`: 0 = loops have explicit exit rules, bounded iterations, and real decision steps, 1 = minor issues with exit clarity, 2 = vibes-only exit conditions or unbounded loops (score 0 if no loops)\n- `delegationBoundedness`: 0 = delegation is bounded and explicit or absent, 1 = one delegation could be tighter, 2 = open-ended or ownership-transferring delegation (score 0 if no delegation)\n- `legacyPatterns`: 0 = no legacy anti-patterns, 1 = minor legacy residue, 2 = pseudo-DSL, learning paths, satisfaction loops, or regex-as-gate present\n- `artifactClarity`: 0 = clear what each artifact is for and which is canonical, 1 = mostly clear, 2 = ambiguous artifact ownership\n- `modeFit`: 0 = the workflow fits the selected `authoringMode`, 1 = minor creation/modernization mismatch remains, 2 = the workflow still reads like the wrong mode entirely\n\nIf the total score is 0-3: the workflow is ready.\nIf the total score is 4-6: fix the worst dimensions before proceeding.\nIf the total score is 7+: this needs significant rework. Fix the worst dimensions here, re-validate, and record what you would change if you could redraft from scratch.\n\nIf `authoringMode = modernize_existing`, check explicitly:\n- does the updated workflow preserve the right purpose?\n- did you remove legacy structure without rewriting valuable behavior away?\n- do any prompts, captures, or handoff notes still assume this was a brand-new workflow?\n\nFix any issues directly in the workflow file. Re-run validation if you changed structure.\n\nCapture:\n- `reviewScores`\n- `reviewPassed`\n- `fixesApplied`",
|
|
149
173
|
"promptFragments": [
|
|
150
174
|
{
|
|
151
175
|
"id": "phase-4-quick-skip",
|
|
@@ -172,13 +196,13 @@
|
|
|
172
196
|
"var": "rigorMode",
|
|
173
197
|
"not_equals": "QUICK"
|
|
174
198
|
},
|
|
175
|
-
"prompt": "The workflow is valid and reviewed. Check whether any of these improvements are worth making:\n\n1. **Prompt fragments**: are there steps with near-identical prompts that differ only by rigor mode
|
|
199
|
+
"prompt": "The workflow is valid and reviewed. Check whether any of these improvements are worth making:\n\n1. **Prompt fragments**: are there steps with near-identical prompts that differ only by rigor mode or `authoringMode`? Extract the differences into promptFragments.\n2. **Extension points**: are there slots that different teams or projects would want to customize? Declare them.\n3. **References**: should the workflow point at external documents the agent should be aware of during execution?\n4. **Deduplication**: is there repeated prose across steps that could be moved to metaGuidance or a shared pattern?\n5. **Context templates**: are there simple variable substitutions that would make prompts cleaner?\n\nOnly make changes that genuinely improve the workflow. Do not refine for the sake of refining.\n\nIf `authoringMode = modernize_existing`, prefer refinements that remove leftover legacy wording or mismatched structure over cosmetic rewrites.\n\nIf you change anything, re-run validation.\n\nCapture:\n- `refinementsApplied`\n- `finalValidationPassed`",
|
|
176
200
|
"requireConfirmation": false
|
|
177
201
|
},
|
|
178
202
|
{
|
|
179
203
|
"id": "phase-6-handoff",
|
|
180
204
|
"title": "Phase 6: Handoff",
|
|
181
|
-
"prompt": "Summarize what
|
|
205
|
+
"prompt": "Summarize what you authored or updated.\n\nInclude:\n- workflow file path and name\n- whether you created a new workflow or modernized an existing one\n- what the workflow does (one sentence)\n- step count and structure overview\n- loops, confirmations, and delegation if any\n- validation status\n- for modernization: the main improvements and any legacy residue still left intentionally\n- any known limitations or future improvements\n- how to test it: where to place the file and how to run it\n\nKeep it concise. The workflow file is the deliverable, not the summary.",
|
|
182
206
|
"notesOptional": true,
|
|
183
207
|
"requireConfirmation": false
|
|
184
208
|
}
|