@exaudeus/workrail 3.12.0 → 3.13.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/console/assets/{index-CRgjJiMS.js → index-EsSXrC_a.js} +11 -11
- package/dist/console/index.html +1 -1
- package/dist/di/container.js +8 -0
- package/dist/di/tokens.d.ts +1 -0
- package/dist/di/tokens.js +1 -0
- package/dist/infrastructure/session/HttpServer.js +2 -14
- package/dist/manifest.json +83 -43
- package/dist/mcp/boundary-coercion.d.ts +2 -0
- package/dist/mcp/boundary-coercion.js +73 -0
- package/dist/mcp/handler-factory.d.ts +1 -1
- package/dist/mcp/handler-factory.js +13 -6
- package/dist/mcp/handlers/v2-manage-workflow-source.d.ts +7 -0
- package/dist/mcp/handlers/v2-manage-workflow-source.js +50 -0
- package/dist/mcp/server.js +2 -0
- package/dist/mcp/tool-descriptions.js +20 -0
- package/dist/mcp/tools.js +6 -0
- package/dist/mcp/types/tool-description-types.d.ts +1 -1
- package/dist/mcp/types/tool-description-types.js +1 -0
- package/dist/mcp/types/workflow-tool-edition.d.ts +1 -1
- package/dist/mcp/types.d.ts +2 -0
- package/dist/mcp/v2/tool-registry.js +8 -0
- package/dist/mcp/v2/tools.d.ts +12 -0
- package/dist/mcp/v2/tools.js +7 -1
- package/dist/v2/infra/in-memory/managed-source-store/index.d.ts +8 -0
- package/dist/v2/infra/in-memory/managed-source-store/index.js +33 -0
- package/dist/v2/infra/local/data-dir/index.d.ts +2 -0
- package/dist/v2/infra/local/data-dir/index.js +6 -0
- package/dist/v2/infra/local/managed-source-store/index.d.ts +15 -0
- package/dist/v2/infra/local/managed-source-store/index.js +164 -0
- package/dist/v2/ports/data-dir.port.d.ts +2 -0
- package/dist/v2/ports/managed-source-store.port.d.ts +25 -0
- package/dist/v2/ports/managed-source-store.port.js +2 -0
- package/package.json +1 -1
- package/workflows/adaptive-ticket-creation.json +276 -282
- package/workflows/document-creation-workflow.json +70 -191
- package/workflows/documentation-update-workflow.json +59 -309
- package/workflows/intelligent-test-case-generation.json +37 -212
- package/workflows/personal-learning-materials-creation-branched.json +1 -21
- package/workflows/presentation-creation.json +143 -308
- package/workflows/relocation-workflow-us.json +161 -535
- package/workflows/scoped-documentation-workflow.json +110 -181
- package/workflows/workflow-for-workflows.v2.json +21 -5
- package/workflows/CHANGELOG-bug-investigation.md +0 -298
- package/workflows/bug-investigation.agentic.json +0 -212
- package/workflows/bug-investigation.json +0 -112
- package/workflows/mr-review-workflow.agentic.json +0 -538
- package/workflows/mr-review-workflow.json +0 -277
|
@@ -1,291 +1,285 @@
|
|
|
1
1
|
{
|
|
2
|
-
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
"
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
2
|
+
"id": "adaptive-ticket-creation",
|
|
3
|
+
"name": "Adaptive Ticket Creation Workflow",
|
|
4
|
+
"version": "1.0.0",
|
|
5
|
+
"description": "Create high-quality Jira tickets by automatically selecting the right complexity path (Simple, Standard, or Epic) based on request analysis. One polished ticket for simple requests; structured decomposition with estimates for epics.",
|
|
6
|
+
"preconditions": [
|
|
7
|
+
"User has provided a description of the feature, task, or work to be ticketed.",
|
|
8
|
+
"Agent has file system access for loading team preferences and persisting rules."
|
|
9
|
+
],
|
|
10
|
+
"metaGuidance": [
|
|
11
|
+
"ROLE: expert Product Manager and Mobile Tech Lead. Triage autonomously, write developer-ready tickets with full context, and produce objectively testable acceptance criteria — not user-story paraphrases.",
|
|
12
|
+
"EXPLORE FIRST: use tools to gather context before asking the user anything. Ask only for information you genuinely cannot determine with tools or from the request itself.",
|
|
13
|
+
"TEAM RULES: load and follow ./.workflow_rules/ticket_creation.md when it exists. Preferences there override your defaults. Rules are captured only on the Epic path — complex sessions are where durable conventions emerge and where the investment pays off.",
|
|
14
|
+
"AUTONOMOUS TRIAGE: decide pathComplexity (Simple / Standard / Epic) yourself from the request. Surface your reasoning, then wait for confirmation.",
|
|
15
|
+
"QUALITY FLOOR: every ticket must have a context-rich description, checkbox-style acceptance criteria that are objectively testable, and an effort estimate."
|
|
16
|
+
],
|
|
17
|
+
"steps": [
|
|
18
|
+
{
|
|
19
|
+
"id": "phase-0-triage",
|
|
20
|
+
"title": "Phase 0: Intelligent Triage and Path Selection",
|
|
21
|
+
"promptBlocks": {
|
|
22
|
+
"goal": "Analyze the request, gather available context, and select the right complexity path before doing any ticket work.",
|
|
23
|
+
"constraints": [
|
|
24
|
+
"Decide the path yourself — do not ask the user to choose.",
|
|
25
|
+
"Load ./.workflow_rules/ticket_creation.md if it exists and let it influence your triage. If the file does not exist, note this explicitly in your output so the user knows team conventions were not applied.",
|
|
26
|
+
"Set pathComplexity to exactly one of: Simple, Standard, or Epic."
|
|
27
|
+
],
|
|
28
|
+
"procedure": [
|
|
29
|
+
"Read any attached documents, linked PRDs, or referenced specs.",
|
|
30
|
+
"Identify complexity signals: scope breadth, number of distinct deliverables, cross-team dependencies, technical unknowns, and estimated ticket count.",
|
|
31
|
+
"Apply the triage rubric: Simple = single ticket, clear requirements, no blocking unknowns, minimal dependencies. Standard = multiple related tickets, moderate scope, some analysis needed. Epic = complex feature requiring decomposition, multiple teams or significant unknowns, likely 6+ tickets.",
|
|
32
|
+
"Upgrade triggers — escalate to Standard if: request implies more than one clearly separate work item. Escalate to Epic if: multiple teams are involved, architecture decisions are unresolved, or you estimate more than five tickets.",
|
|
33
|
+
"State your selected path and the top three reasons. Capture pathComplexity in context."
|
|
34
|
+
],
|
|
35
|
+
"outputRequired": {
|
|
36
|
+
"notesMarkdown": "Selected path (Simple/Standard/Epic), top three triage reasons, any complexity upgrade triggers observed."
|
|
31
37
|
},
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
"type": "length",
|
|
64
|
-
"min": 300,
|
|
65
|
-
"max": 2000,
|
|
66
|
-
"message": "Ticket should be between 300-2000 characters for adequate detail"
|
|
67
|
-
}
|
|
68
|
-
],
|
|
69
|
-
"guidance": [
|
|
70
|
-
"This is the complete fast track - workflow ends after this step",
|
|
71
|
-
"Focus on quality over quantity - one excellent ticket",
|
|
72
|
-
"Include all necessary context for the developer"
|
|
73
|
-
],
|
|
74
|
-
"requireConfirmation": true,
|
|
75
|
-
"hasValidation": true
|
|
38
|
+
"verify": [
|
|
39
|
+
"pathComplexity is set to Simple, Standard, or Epic.",
|
|
40
|
+
"Triage reasoning is explicit enough for the user to agree or push back.",
|
|
41
|
+
"Any loaded team rules are acknowledged if found."
|
|
42
|
+
]
|
|
43
|
+
},
|
|
44
|
+
"requireConfirmation": true
|
|
45
|
+
},
|
|
46
|
+
{
|
|
47
|
+
"id": "phase-1-simple-ticket",
|
|
48
|
+
"title": "Path A: Generate Single Ticket",
|
|
49
|
+
"runCondition": {
|
|
50
|
+
"var": "pathComplexity",
|
|
51
|
+
"equals": "Simple"
|
|
52
|
+
},
|
|
53
|
+
"promptBlocks": {
|
|
54
|
+
"goal": "Generate one complete, developer-ready Jira ticket for this request.",
|
|
55
|
+
"constraints": [
|
|
56
|
+
"Acceptance criteria must be phrased as observable, testable conditions — not user-story restatements.",
|
|
57
|
+
"Follow any team conventions from ./.workflow_rules/ticket_creation.md.",
|
|
58
|
+
"Include all fields a developer needs to start work without asking follow-up questions."
|
|
59
|
+
],
|
|
60
|
+
"procedure": [
|
|
61
|
+
"Write the ticket title: concise, action-oriented, following team naming conventions.",
|
|
62
|
+
"Write the description: what the feature/fix is, why it matters, any relevant context or constraints the developer should know.",
|
|
63
|
+
"Write acceptance criteria as a checkbox list. Each item must be verifiable: 'Given X, when Y, then Z' or an equivalent observable condition.",
|
|
64
|
+
"Add: priority, story points (Fibonacci or T-shirt size per team convention), relevant labels, and any links (PRD, design, related tickets).",
|
|
65
|
+
"Review the complete ticket. Would a developer who knows nothing about this request have everything needed to implement it?"
|
|
66
|
+
],
|
|
67
|
+
"outputRequired": {
|
|
68
|
+
"notesMarkdown": "Ticket title, brief summary of AC items, and story point estimate."
|
|
76
69
|
},
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
|
|
92
|
-
|
|
93
|
-
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
|
|
97
|
-
|
|
98
|
-
|
|
99
|
-
|
|
100
|
-
|
|
70
|
+
"verify": [
|
|
71
|
+
"Title is present and follows conventions.",
|
|
72
|
+
"Description provides enough context to start work.",
|
|
73
|
+
"At least two checkbox-style acceptance criteria are present and objectively testable.",
|
|
74
|
+
"Story points and priority are set."
|
|
75
|
+
]
|
|
76
|
+
},
|
|
77
|
+
"requireConfirmation": false
|
|
78
|
+
},
|
|
79
|
+
{
|
|
80
|
+
"id": "phase-1-context-and-gaps",
|
|
81
|
+
"title": "Path C, Phase 1: Gather Context and Surface Gaps",
|
|
82
|
+
"runCondition": {
|
|
83
|
+
"or": [
|
|
84
|
+
{ "var": "pathComplexity", "equals": "Standard" },
|
|
85
|
+
{ "var": "pathComplexity", "equals": "Epic" }
|
|
86
|
+
]
|
|
87
|
+
},
|
|
88
|
+
"promptBlocks": {
|
|
89
|
+
"goal": "Collect all available project context and identify what is still missing before planning begins.",
|
|
90
|
+
"constraints": [
|
|
91
|
+
"Do not ask the user for things you can find with tools.",
|
|
92
|
+
"Ask only for information that is genuinely missing and would materially affect planning.",
|
|
93
|
+
"If the rules file exists, extract relevant conventions now."
|
|
94
|
+
],
|
|
95
|
+
"procedure": [
|
|
96
|
+
"Read all linked or attached documents: PRDs, technical specs, design files, existing tickets.",
|
|
97
|
+
"Load ./.workflow_rules/ticket_creation.md and note any relevant team conventions.",
|
|
98
|
+
"Identify: key stakeholders, team dependencies, technical constraints, known risks, and any conflicting requirements.",
|
|
99
|
+
"Classify each gap as: Critical (blocks planning), Important (affects scope), or Nice-to-have (can proceed without it).",
|
|
100
|
+
"For Critical and Important gaps that tools cannot resolve, ask the user — in a single consolidated question block, not one at a time.",
|
|
101
|
+
"After receiving answers, check whether any response reveals scope that would change `pathComplexity` (e.g. the user confirms three teams are involved, or the feature is narrower than initially assessed). If so, state the new classification and reasoning, and ask the user to confirm before continuing to Phase 2."
|
|
102
|
+
],
|
|
103
|
+
"outputRequired": {
|
|
104
|
+
"notesMarkdown": "Context sources reviewed, critical/important gaps found, any questions asked."
|
|
101
105
|
},
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
|
|
107
|
-
|
|
108
|
-
|
|
109
|
-
|
|
110
|
-
|
|
111
|
-
|
|
112
|
-
|
|
113
|
-
|
|
114
|
-
|
|
115
|
-
|
|
116
|
-
|
|
117
|
-
|
|
118
|
-
|
|
119
|
-
|
|
120
|
-
|
|
121
|
-
|
|
122
|
-
|
|
123
|
-
|
|
124
|
-
|
|
106
|
+
"verify": [
|
|
107
|
+
"All provided documents and links have been read.",
|
|
108
|
+
"Any Critical gaps are surfaced before proceeding.",
|
|
109
|
+
"Questions, if any, are consolidated into a single block."
|
|
110
|
+
]
|
|
111
|
+
},
|
|
112
|
+
"requireConfirmation": false
|
|
113
|
+
},
|
|
114
|
+
{
|
|
115
|
+
"id": "phase-2-high-level-plan",
|
|
116
|
+
"title": "Path C, Phase 2: Create High-Level Plan",
|
|
117
|
+
"runCondition": {
|
|
118
|
+
"or": [
|
|
119
|
+
{ "var": "pathComplexity", "equals": "Standard" },
|
|
120
|
+
{ "var": "pathComplexity", "equals": "Epic" }
|
|
121
|
+
]
|
|
122
|
+
},
|
|
123
|
+
"promptBlocks": {
|
|
124
|
+
"goal": "Produce a structured plan that will drive ticket generation. This plan is the source of truth for scope.",
|
|
125
|
+
"constraints": [
|
|
126
|
+
"Be explicit about scope boundaries — ambiguous scope will produce ambiguous tickets.",
|
|
127
|
+
"Success criteria must be measurable, not just descriptive.",
|
|
128
|
+
"For Standard path: this plan feeds directly into batch ticket generation."
|
|
129
|
+
],
|
|
130
|
+
"procedure": [
|
|
131
|
+
"Write: Project Summary (2-3 sentences, what is being built and why).",
|
|
132
|
+
"Write: Key Deliverables (bulleted list of distinct components or features).",
|
|
133
|
+
"Write: In-Scope (explicit list — prevents scope creep).",
|
|
134
|
+
"Write: Out-of-Scope (explicit exclusions — prevents misunderstandings).",
|
|
135
|
+
"Write: Success Criteria (measurable definition of done — each item verifiable).",
|
|
136
|
+
"Write: High-Level Timeline (phases or milestones with rough sizing).",
|
|
137
|
+
"Review: does every deliverable map clearly to implementable work? Is anything in scope that should be out?"
|
|
138
|
+
],
|
|
139
|
+
"outputRequired": {
|
|
140
|
+
"notesMarkdown": "Plan summary, deliverable count, any scope decisions made."
|
|
125
141
|
},
|
|
126
|
-
|
|
127
|
-
|
|
128
|
-
|
|
129
|
-
|
|
130
|
-
|
|
131
|
-
|
|
132
|
-
|
|
133
|
-
|
|
134
|
-
|
|
135
|
-
|
|
136
|
-
|
|
137
|
-
|
|
138
|
-
|
|
139
|
-
|
|
140
|
-
|
|
141
|
-
|
|
142
|
-
|
|
143
|
-
|
|
144
|
-
|
|
145
|
-
|
|
146
|
-
|
|
147
|
-
|
|
148
|
-
|
|
149
|
-
|
|
150
|
-
|
|
151
|
-
|
|
152
|
-
|
|
153
|
-
|
|
154
|
-
|
|
155
|
-
|
|
156
|
-
|
|
157
|
-
|
|
158
|
-
},
|
|
159
|
-
{
|
|
160
|
-
"type": "regex",
|
|
161
|
-
"pattern": "(?i)##?\\s*Out-of-Scope:?",
|
|
162
|
-
"message": "Plan must explicitly define Out-of-Scope items"
|
|
163
|
-
},
|
|
164
|
-
{
|
|
165
|
-
"type": "regex",
|
|
166
|
-
"pattern": "(?i)##?\\s*Success Criteria:?",
|
|
167
|
-
"message": "Plan must include measurable Success Criteria"
|
|
168
|
-
},
|
|
169
|
-
{
|
|
170
|
-
"type": "regex",
|
|
171
|
-
"pattern": "(?i)##?\\s*High-Level Timeline:?",
|
|
172
|
-
"message": "Plan must include a High-Level Timeline section"
|
|
173
|
-
},
|
|
174
|
-
{
|
|
175
|
-
"type": "length",
|
|
176
|
-
"min": 800,
|
|
177
|
-
"message": "Plan should be at least 800 characters for comprehensive coverage"
|
|
178
|
-
}
|
|
179
|
-
],
|
|
180
|
-
"guidance": [
|
|
181
|
-
"This plan becomes the foundation for all ticket generation",
|
|
182
|
-
"Be explicit about scope to prevent misunderstandings",
|
|
183
|
-
"For Standard path, this leads directly to ticket generation"
|
|
184
|
-
],
|
|
185
|
-
"requireConfirmation": true,
|
|
186
|
-
"hasValidation": true
|
|
142
|
+
"verify": [
|
|
143
|
+
"All six sections are present: Summary, Deliverables, In-Scope, Out-of-Scope, Success Criteria, Timeline.",
|
|
144
|
+
"Success criteria are measurable.",
|
|
145
|
+
"Scope boundaries are explicit, not implied."
|
|
146
|
+
]
|
|
147
|
+
},
|
|
148
|
+
"requireConfirmation": true
|
|
149
|
+
},
|
|
150
|
+
{
|
|
151
|
+
"id": "phase-3-epic-decompose",
|
|
152
|
+
"title": "Path E, Phase 3: Epic Decomposition",
|
|
153
|
+
"runCondition": {
|
|
154
|
+
"var": "pathComplexity",
|
|
155
|
+
"equals": "Epic"
|
|
156
|
+
},
|
|
157
|
+
"promptBlocks": {
|
|
158
|
+
"goal": "Break the approved plan into a logical work hierarchy that development teams can execute.",
|
|
159
|
+
"constraints": [
|
|
160
|
+
"Every item in the plan's In-Scope list must map to at least one work item in the hierarchy.",
|
|
161
|
+
"Dependencies must be explicit — not implied by ordering alone.",
|
|
162
|
+
"Oversized stories (more than one sprint of work) should be split."
|
|
163
|
+
],
|
|
164
|
+
"procedure": [
|
|
165
|
+
"Define the top-level Epic: one ticket that is the container for all work, linked to the plan.",
|
|
166
|
+
"Identify Features or Story Groups: logical clusters of related functionality.",
|
|
167
|
+
"For each Story Group, list individual Stories: the smallest independently releasable work items.",
|
|
168
|
+
"For each Story, list any Tasks or sub-tasks if technical implementation steps are distinct enough to track.",
|
|
169
|
+
"Map dependencies: which stories must complete before others can start? Flag critical-path items.",
|
|
170
|
+
"Explain the grouping rationale: why are these stories together? Would the team organize them differently?"
|
|
171
|
+
],
|
|
172
|
+
"outputRequired": {
|
|
173
|
+
"notesMarkdown": "Epic name, story count, dependency summary, and any grouping decisions."
|
|
187
174
|
},
|
|
188
|
-
|
|
189
|
-
|
|
190
|
-
|
|
191
|
-
|
|
192
|
-
|
|
193
|
-
|
|
194
|
-
|
|
195
|
-
|
|
196
|
-
|
|
197
|
-
|
|
198
|
-
|
|
199
|
-
|
|
200
|
-
|
|
201
|
-
|
|
202
|
-
|
|
175
|
+
"verify": [
|
|
176
|
+
"Every In-Scope deliverable from the plan is represented in the hierarchy.",
|
|
177
|
+
"Dependencies are named, not just implied by order.",
|
|
178
|
+
"No story is so large it would span multiple sprints without a split."
|
|
179
|
+
]
|
|
180
|
+
},
|
|
181
|
+
"requireConfirmation": true
|
|
182
|
+
},
|
|
183
|
+
{
|
|
184
|
+
"id": "phase-4-epic-estimate",
|
|
185
|
+
"title": "Path E, Phase 4: Estimation and Dependency Mapping",
|
|
186
|
+
"runCondition": {
|
|
187
|
+
"var": "pathComplexity",
|
|
188
|
+
"equals": "Epic"
|
|
189
|
+
},
|
|
190
|
+
"promptBlocks": {
|
|
191
|
+
"goal": "Add effort estimates, risk assessments, and team assignments to each story in the hierarchy.",
|
|
192
|
+
"constraints": [
|
|
193
|
+
"Conservative estimates are better than optimistic ones — note uncertainty explicitly.",
|
|
194
|
+
"Justify each estimate with one sentence of reasoning.",
|
|
195
|
+
"Flag stories on the critical path."
|
|
196
|
+
],
|
|
197
|
+
"procedure": [
|
|
198
|
+
"For each Story, assign: effort estimate (Fibonacci or T-shirt size per team convention), brief justification.",
|
|
199
|
+
"Assess technical risk per story: Low / Medium / High, with one sentence of rationale.",
|
|
200
|
+
"Assign priority: must-have for MVP, should-have, nice-to-have.",
|
|
201
|
+
"Note suggested team or skill area for each story.",
|
|
202
|
+
"Identify critical path: which stories block the most downstream work? Surface these explicitly.",
|
|
203
|
+
"Flag any stories whose estimates feel uncertain — surface the unknowns rather than hiding them in a range."
|
|
204
|
+
],
|
|
205
|
+
"outputRequired": {
|
|
206
|
+
"notesMarkdown": "Total story point estimate, critical path items, high-risk stories."
|
|
203
207
|
},
|
|
204
|
-
|
|
205
|
-
|
|
206
|
-
|
|
207
|
-
|
|
208
|
-
|
|
209
|
-
|
|
210
|
-
|
|
211
|
-
|
|
212
|
-
|
|
213
|
-
|
|
214
|
-
|
|
215
|
-
|
|
216
|
-
|
|
217
|
-
|
|
218
|
-
|
|
208
|
+
"verify": [
|
|
209
|
+
"Every story has an estimate and a one-sentence justification.",
|
|
210
|
+
"Critical path items are named.",
|
|
211
|
+
"High-risk or highly uncertain stories are called out."
|
|
212
|
+
]
|
|
213
|
+
},
|
|
214
|
+
"requireConfirmation": false
|
|
215
|
+
},
|
|
216
|
+
{
|
|
217
|
+
"id": "phase-5-batch-tickets",
|
|
218
|
+
"title": "Path C/E, Phase 5: Batch Ticket Generation",
|
|
219
|
+
"runCondition": {
|
|
220
|
+
"or": [
|
|
221
|
+
{ "var": "pathComplexity", "equals": "Standard" },
|
|
222
|
+
{ "var": "pathComplexity", "equals": "Epic" }
|
|
223
|
+
]
|
|
224
|
+
},
|
|
225
|
+
"promptBlocks": {
|
|
226
|
+
"goal": "Generate the complete set of Jira tickets from the approved plan and decomposition.",
|
|
227
|
+
"constraints": [
|
|
228
|
+
"Every In-Scope deliverable from the plan must have at least one ticket.",
|
|
229
|
+
"Acceptance criteria must be checkbox-style and objectively testable.",
|
|
230
|
+
"Follow team conventions from ./.workflow_rules/ticket_creation.md.",
|
|
231
|
+
"Epic path: include the parent Epic ticket and set epic-link on all child stories."
|
|
232
|
+
],
|
|
233
|
+
"procedure": [
|
|
234
|
+
"For Epic path: generate the Epic ticket first (title, description, success criteria from the plan, no story points).",
|
|
235
|
+
"For each Story in the decomposition (or each deliverable for Standard): generate a complete ticket with title, description, checkbox-style AC, story points, priority, labels, and dependency links.",
|
|
236
|
+
"Verify coverage: compare generated tickets against the plan's In-Scope list. Every item should have a ticket.",
|
|
237
|
+
"Check consistency: ticket titles follow conventions, estimates are consistent with the estimation step, priorities are set.",
|
|
238
|
+
"Present the complete batch clearly labeled and organized."
|
|
239
|
+
],
|
|
240
|
+
"outputRequired": {
|
|
241
|
+
"notesMarkdown": "Ticket count, coverage confirmation (all In-Scope items represented), any gaps noted."
|
|
219
242
|
},
|
|
220
|
-
|
|
221
|
-
|
|
222
|
-
|
|
223
|
-
|
|
224
|
-
|
|
225
|
-
|
|
226
|
-
|
|
227
|
-
|
|
228
|
-
|
|
229
|
-
|
|
230
|
-
|
|
231
|
-
|
|
232
|
-
|
|
233
|
-
|
|
234
|
-
|
|
235
|
-
|
|
236
|
-
|
|
237
|
-
|
|
238
|
-
|
|
239
|
-
|
|
240
|
-
|
|
241
|
-
|
|
242
|
-
|
|
243
|
-
|
|
244
|
-
|
|
245
|
-
|
|
246
|
-
|
|
247
|
-
|
|
248
|
-
|
|
249
|
-
|
|
250
|
-
|
|
251
|
-
|
|
252
|
-
},
|
|
253
|
-
{
|
|
254
|
-
"type": "length",
|
|
255
|
-
"min": 1000,
|
|
256
|
-
"message": "Batch ticket output should be substantial (1000+ characters) for multiple tickets"
|
|
257
|
-
}
|
|
258
|
-
],
|
|
259
|
-
"guidance": [
|
|
260
|
-
"Automated batch generation saves significant time",
|
|
261
|
-
"Ensure consistency across all tickets",
|
|
262
|
-
"Include all necessary metadata and relationships"
|
|
263
|
-
],
|
|
264
|
-
"requireConfirmation": true,
|
|
265
|
-
"hasValidation": true
|
|
243
|
+
"verify": [
|
|
244
|
+
"Every In-Scope plan item has at least one ticket.",
|
|
245
|
+
"All tickets have checkbox-style AC with at least two testable criteria each.",
|
|
246
|
+
"Story points and priorities are set on all tickets.",
|
|
247
|
+
"Epic tickets are present and child tickets reference the parent (Epic path)."
|
|
248
|
+
]
|
|
249
|
+
},
|
|
250
|
+
"requireConfirmation": true
|
|
251
|
+
},
|
|
252
|
+
{
|
|
253
|
+
"id": "phase-6-capture-rules",
|
|
254
|
+
"title": "Path E, Phase 6: Capture Team Rules",
|
|
255
|
+
"runCondition": {
|
|
256
|
+
"var": "pathComplexity",
|
|
257
|
+
"equals": "Epic"
|
|
258
|
+
},
|
|
259
|
+
"promptBlocks": {
|
|
260
|
+
"goal": "Extract actionable team preferences from this session and persist them so future runs use them automatically.",
|
|
261
|
+
"constraints": [
|
|
262
|
+
"Only write rules that are genuinely reusable across future tickets — skip one-off project specifics.",
|
|
263
|
+
"Keep rules concise and actionable, not narrative.",
|
|
264
|
+
"Append to ./.workflow_rules/ticket_creation.md rather than replacing it."
|
|
265
|
+
],
|
|
266
|
+
"procedure": [
|
|
267
|
+
"Review what conventions, preferences, or requirements emerged during this session.",
|
|
268
|
+
"Identify patterns worth preserving: naming conventions, field usage, AC format preferences, estimation approach, labeling rules.",
|
|
269
|
+
"Draft new rules as short, imperative statements (e.g., 'Use T-shirt sizing not Fibonacci', 'Always include a Figma link in design tickets').",
|
|
270
|
+
"Check against existing rules — avoid duplicates or contradictions.",
|
|
271
|
+
"Append new rules to ./.workflow_rules/ticket_creation.md, creating the file if it does not exist."
|
|
272
|
+
],
|
|
273
|
+
"outputRequired": {
|
|
274
|
+
"notesMarkdown": "New rules added (count and examples), rules file location."
|
|
266
275
|
},
|
|
267
|
-
|
|
268
|
-
|
|
269
|
-
|
|
270
|
-
|
|
271
|
-
|
|
272
|
-
|
|
273
|
-
|
|
274
|
-
|
|
275
|
-
|
|
276
|
-
|
|
277
|
-
"Epic path only - creates persistent learning",
|
|
278
|
-
"Focus on actionable, specific rules",
|
|
279
|
-
"This makes the AI smarter over time"
|
|
280
|
-
],
|
|
281
|
-
"requireConfirmation": true
|
|
282
|
-
}
|
|
283
|
-
],
|
|
284
|
-
"metaGuidance": [
|
|
285
|
-
"Maintain the persona of an expert Product Manager and Mobile Tech Lead",
|
|
286
|
-
"Make autonomous decisions based on context analysis rather than asking users to choose",
|
|
287
|
-
"Always load and follow team-specific rules from ./.workflow_rules/ticket_creation.md when available",
|
|
288
|
-
"Focus on creating tickets that provide clear value to development teams",
|
|
289
|
-
"Ensure all tickets have measurable acceptance criteria and appropriate estimates"
|
|
290
|
-
]
|
|
291
|
-
}
|
|
276
|
+
"verify": [
|
|
277
|
+
"Rules file has been updated or created.",
|
|
278
|
+
"New rules are actionable and reusable.",
|
|
279
|
+
"No contradictions introduced with existing rules."
|
|
280
|
+
]
|
|
281
|
+
},
|
|
282
|
+
"requireConfirmation": false
|
|
283
|
+
}
|
|
284
|
+
]
|
|
285
|
+
}
|