@bridge_gpt/mcp-server 0.1.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/LICENSE +21 -0
- package/README.md +178 -0
- package/build/index.js +1630 -0
- package/build/pipeline-utils.js +175 -0
- package/build/pipelines.generated.js +722 -0
- package/package.json +47 -0
|
@@ -0,0 +1,722 @@
|
|
|
1
|
+
// AUTO-GENERATED — do not edit manually. Regenerate with: npm run build
|
|
2
|
+
// This file is produced by scripts/bundle-pipelines.js
|
|
3
|
+
export const PIPELINES = {
|
|
4
|
+
"check-ci-ticket": {
|
|
5
|
+
"name": "check-ci-ticket",
|
|
6
|
+
"description": "Commit changes, create a pull request, and monitor CI checks.",
|
|
7
|
+
"variables": [
|
|
8
|
+
"ticket_key"
|
|
9
|
+
],
|
|
10
|
+
"steps": [
|
|
11
|
+
{
|
|
12
|
+
"type": "mcp_call",
|
|
13
|
+
"tool": "ping",
|
|
14
|
+
"params": {},
|
|
15
|
+
"description": "Verify Bridge API connectivity"
|
|
16
|
+
},
|
|
17
|
+
{
|
|
18
|
+
"type": "agent_task",
|
|
19
|
+
"instruction_file": "commit-and-push.md",
|
|
20
|
+
"description": "Stage, commit, and push changes",
|
|
21
|
+
"requires_approval": true
|
|
22
|
+
},
|
|
23
|
+
{
|
|
24
|
+
"type": "mcp_call",
|
|
25
|
+
"tool": "create_pull_request",
|
|
26
|
+
"params": {
|
|
27
|
+
"head_branch": "feature/{ticket_key}",
|
|
28
|
+
"base_branch": "main",
|
|
29
|
+
"title": "{ticket_key}: Implementation"
|
|
30
|
+
},
|
|
31
|
+
"description": "Create a pull request",
|
|
32
|
+
"requires_approval": true
|
|
33
|
+
},
|
|
34
|
+
{
|
|
35
|
+
"type": "agent_task",
|
|
36
|
+
"instruction_file": "monitor-ci-checks.md",
|
|
37
|
+
"description": "Monitor CI checks and report results"
|
|
38
|
+
}
|
|
39
|
+
]
|
|
40
|
+
},
|
|
41
|
+
"full-lifecycle": {
|
|
42
|
+
"name": "full-lifecycle",
|
|
43
|
+
"description": "Complete ticket lifecycle: clarify, critique, rewrite, plan, implement, commit, PR, and CI.",
|
|
44
|
+
"variables": [
|
|
45
|
+
"ticket_key",
|
|
46
|
+
"docs_dir"
|
|
47
|
+
],
|
|
48
|
+
"steps": [
|
|
49
|
+
{
|
|
50
|
+
"type": "mcp_call",
|
|
51
|
+
"tool": "ping",
|
|
52
|
+
"params": {},
|
|
53
|
+
"description": "Verify Bridge API connectivity"
|
|
54
|
+
},
|
|
55
|
+
{
|
|
56
|
+
"type": "mcp_call",
|
|
57
|
+
"tool": "request_clarifying_questions",
|
|
58
|
+
"params": {
|
|
59
|
+
"ticket_number": "{ticket_key}",
|
|
60
|
+
"wait_for_result": true,
|
|
61
|
+
"save_locally": true,
|
|
62
|
+
"provider": "{provider}"
|
|
63
|
+
},
|
|
64
|
+
"description": "Generate clarifying questions (initial)",
|
|
65
|
+
"on_error": "warn_and_continue"
|
|
66
|
+
},
|
|
67
|
+
{
|
|
68
|
+
"type": "mcp_call",
|
|
69
|
+
"tool": "request_ticket_critique",
|
|
70
|
+
"params": {
|
|
71
|
+
"ticket_number": "{ticket_key}",
|
|
72
|
+
"wait_for_result": true,
|
|
73
|
+
"save_locally": true,
|
|
74
|
+
"provider": "{provider}"
|
|
75
|
+
},
|
|
76
|
+
"description": "Generate ticket quality critique (initial)",
|
|
77
|
+
"on_error": "warn_and_continue"
|
|
78
|
+
},
|
|
79
|
+
{
|
|
80
|
+
"type": "mcp_call",
|
|
81
|
+
"tool": "request_clarifying_questions",
|
|
82
|
+
"params": {
|
|
83
|
+
"ticket_number": "{ticket_key}",
|
|
84
|
+
"second_opinion": "auto",
|
|
85
|
+
"wait_for_result": true,
|
|
86
|
+
"save_locally": true,
|
|
87
|
+
"provider": "{provider}"
|
|
88
|
+
},
|
|
89
|
+
"description": "Generate clarifying questions (second opinion)",
|
|
90
|
+
"on_error": "warn_and_continue"
|
|
91
|
+
},
|
|
92
|
+
{
|
|
93
|
+
"type": "mcp_call",
|
|
94
|
+
"tool": "request_ticket_critique",
|
|
95
|
+
"params": {
|
|
96
|
+
"ticket_number": "{ticket_key}",
|
|
97
|
+
"second_opinion": "auto",
|
|
98
|
+
"wait_for_result": true,
|
|
99
|
+
"save_locally": true,
|
|
100
|
+
"provider": "{provider}"
|
|
101
|
+
},
|
|
102
|
+
"description": "Generate ticket quality critique (second opinion)",
|
|
103
|
+
"on_error": "warn_and_continue"
|
|
104
|
+
},
|
|
105
|
+
{
|
|
106
|
+
"type": "agent_task",
|
|
107
|
+
"instruction_file": "update-ticket-rewrite.md",
|
|
108
|
+
"description": "Rewrite ticket description using critique and clarifying questions"
|
|
109
|
+
},
|
|
110
|
+
{
|
|
111
|
+
"type": "mcp_call",
|
|
112
|
+
"tool": "update_ticket_description",
|
|
113
|
+
"params": {
|
|
114
|
+
"ticket_number": "{ticket_key}",
|
|
115
|
+
"file_path": "{docs_dir}/tickets/{ticket_key}.md"
|
|
116
|
+
},
|
|
117
|
+
"description": "Push rewritten description to Jira"
|
|
118
|
+
},
|
|
119
|
+
{
|
|
120
|
+
"type": "mcp_call",
|
|
121
|
+
"tool": "request_plan_generation",
|
|
122
|
+
"params": {
|
|
123
|
+
"ticket_number": "{ticket_key}",
|
|
124
|
+
"wait_for_result": true,
|
|
125
|
+
"save_locally": true,
|
|
126
|
+
"provider": "{provider}"
|
|
127
|
+
},
|
|
128
|
+
"description": "Generate implementation plan"
|
|
129
|
+
},
|
|
130
|
+
{
|
|
131
|
+
"type": "agent_task",
|
|
132
|
+
"instruction_file": "execute-plan.md",
|
|
133
|
+
"description": "Execute the implementation plan"
|
|
134
|
+
},
|
|
135
|
+
{
|
|
136
|
+
"type": "agent_task",
|
|
137
|
+
"instruction_file": "commit-and-push.md",
|
|
138
|
+
"description": "Stage, commit, and push changes",
|
|
139
|
+
"requires_approval": true
|
|
140
|
+
},
|
|
141
|
+
{
|
|
142
|
+
"type": "mcp_call",
|
|
143
|
+
"tool": "create_pull_request",
|
|
144
|
+
"params": {
|
|
145
|
+
"head_branch": "feature/{ticket_key}",
|
|
146
|
+
"base_branch": "main",
|
|
147
|
+
"title": "{ticket_key}: Implementation"
|
|
148
|
+
},
|
|
149
|
+
"description": "Create a pull request",
|
|
150
|
+
"requires_approval": true
|
|
151
|
+
},
|
|
152
|
+
{
|
|
153
|
+
"type": "agent_task",
|
|
154
|
+
"instruction_file": "monitor-ci-checks.md",
|
|
155
|
+
"description": "Monitor CI checks and report results"
|
|
156
|
+
}
|
|
157
|
+
]
|
|
158
|
+
},
|
|
159
|
+
"implement-ticket": {
|
|
160
|
+
"name": "implement-ticket",
|
|
161
|
+
"description": "Full implementation lifecycle: review and rewrite ticket, generate plan, execute, commit, open PR, and monitor CI.",
|
|
162
|
+
"variables": [
|
|
163
|
+
"ticket_key",
|
|
164
|
+
"docs_dir"
|
|
165
|
+
],
|
|
166
|
+
"steps": [
|
|
167
|
+
{
|
|
168
|
+
"type": "mcp_call",
|
|
169
|
+
"tool": "ping",
|
|
170
|
+
"params": {},
|
|
171
|
+
"description": "Verify Bridge API connectivity"
|
|
172
|
+
},
|
|
173
|
+
{
|
|
174
|
+
"type": "mcp_call",
|
|
175
|
+
"tool": "request_clarifying_questions",
|
|
176
|
+
"params": {
|
|
177
|
+
"ticket_number": "{ticket_key}",
|
|
178
|
+
"wait_for_result": true,
|
|
179
|
+
"save_locally": true,
|
|
180
|
+
"provider": "{provider}"
|
|
181
|
+
},
|
|
182
|
+
"description": "Generate clarifying questions",
|
|
183
|
+
"on_error": "warn_and_continue"
|
|
184
|
+
},
|
|
185
|
+
{
|
|
186
|
+
"type": "mcp_call",
|
|
187
|
+
"tool": "request_ticket_critique",
|
|
188
|
+
"params": {
|
|
189
|
+
"ticket_number": "{ticket_key}",
|
|
190
|
+
"wait_for_result": true,
|
|
191
|
+
"save_locally": true,
|
|
192
|
+
"provider": "{provider}"
|
|
193
|
+
},
|
|
194
|
+
"description": "Generate ticket quality critique",
|
|
195
|
+
"on_error": "warn_and_continue"
|
|
196
|
+
},
|
|
197
|
+
{
|
|
198
|
+
"type": "agent_task",
|
|
199
|
+
"instruction_file": "update-ticket-rewrite.md",
|
|
200
|
+
"description": "Rewrite ticket description using critique and clarifying questions"
|
|
201
|
+
},
|
|
202
|
+
{
|
|
203
|
+
"type": "mcp_call",
|
|
204
|
+
"tool": "update_ticket_description",
|
|
205
|
+
"params": {
|
|
206
|
+
"ticket_number": "{ticket_key}",
|
|
207
|
+
"file_path": "{docs_dir}/tickets/{ticket_key}.md"
|
|
208
|
+
},
|
|
209
|
+
"description": "Push rewritten description to Jira"
|
|
210
|
+
},
|
|
211
|
+
{
|
|
212
|
+
"type": "mcp_call",
|
|
213
|
+
"tool": "request_plan_generation",
|
|
214
|
+
"params": {
|
|
215
|
+
"ticket_number": "{ticket_key}",
|
|
216
|
+
"wait_for_result": true,
|
|
217
|
+
"save_locally": true,
|
|
218
|
+
"provider": "{provider}"
|
|
219
|
+
},
|
|
220
|
+
"description": "Generate implementation plan"
|
|
221
|
+
},
|
|
222
|
+
{
|
|
223
|
+
"type": "agent_task",
|
|
224
|
+
"instruction_file": "execute-plan.md",
|
|
225
|
+
"description": "Execute the implementation plan"
|
|
226
|
+
},
|
|
227
|
+
{
|
|
228
|
+
"type": "agent_task",
|
|
229
|
+
"instruction_file": "commit-and-push.md",
|
|
230
|
+
"description": "Stage, commit, and push changes",
|
|
231
|
+
"requires_approval": true
|
|
232
|
+
},
|
|
233
|
+
{
|
|
234
|
+
"type": "mcp_call",
|
|
235
|
+
"tool": "create_pull_request",
|
|
236
|
+
"params": {
|
|
237
|
+
"head_branch": "feature/{ticket_key}",
|
|
238
|
+
"base_branch": "main",
|
|
239
|
+
"title": "{ticket_key}: Implementation"
|
|
240
|
+
},
|
|
241
|
+
"description": "Create a pull request",
|
|
242
|
+
"requires_approval": true
|
|
243
|
+
},
|
|
244
|
+
{
|
|
245
|
+
"type": "agent_task",
|
|
246
|
+
"instruction_file": "monitor-ci-checks.md",
|
|
247
|
+
"description": "Monitor CI checks and report results"
|
|
248
|
+
}
|
|
249
|
+
]
|
|
250
|
+
},
|
|
251
|
+
"learn-repository": {
|
|
252
|
+
"name": "learn-repository",
|
|
253
|
+
"description": "Learn and document all configuration fields for the repository by running sequential research agents.",
|
|
254
|
+
"variables": [
|
|
255
|
+
"docs_dir"
|
|
256
|
+
],
|
|
257
|
+
"steps": [
|
|
258
|
+
{
|
|
259
|
+
"type": "mcp_call",
|
|
260
|
+
"tool": "ping",
|
|
261
|
+
"params": {},
|
|
262
|
+
"description": "Verify Bridge API connectivity"
|
|
263
|
+
},
|
|
264
|
+
{
|
|
265
|
+
"type": "agent_task",
|
|
266
|
+
"instruction": "Create the required output directories by running: mkdir -p {docs_dir}/standards {docs_dir}/tmp",
|
|
267
|
+
"description": "Create output directories for standards drafts"
|
|
268
|
+
},
|
|
269
|
+
{
|
|
270
|
+
"type": "mcp_call",
|
|
271
|
+
"tool": "get_config_field",
|
|
272
|
+
"params": {
|
|
273
|
+
"field_name": "architecture_instructions"
|
|
274
|
+
},
|
|
275
|
+
"description": "Fetch current architecture_instructions value",
|
|
276
|
+
"on_error": "warn_and_continue"
|
|
277
|
+
},
|
|
278
|
+
{
|
|
279
|
+
"type": "agent_task",
|
|
280
|
+
"instruction_file": "learn-architecture.md",
|
|
281
|
+
"description": "Learn and document architecture instructions"
|
|
282
|
+
},
|
|
283
|
+
{
|
|
284
|
+
"type": "mcp_call",
|
|
285
|
+
"tool": "update_config_field",
|
|
286
|
+
"params": {
|
|
287
|
+
"field_name": "architecture_instructions",
|
|
288
|
+
"file_path": "{docs_dir}/standards/architecture_instructions.md"
|
|
289
|
+
},
|
|
290
|
+
"description": "Upload architecture_instructions to config",
|
|
291
|
+
"requires_approval": true
|
|
292
|
+
},
|
|
293
|
+
{
|
|
294
|
+
"type": "mcp_call",
|
|
295
|
+
"tool": "get_config_field",
|
|
296
|
+
"params": {
|
|
297
|
+
"field_name": "review_instructions"
|
|
298
|
+
},
|
|
299
|
+
"description": "Fetch current review_instructions value",
|
|
300
|
+
"on_error": "warn_and_continue"
|
|
301
|
+
},
|
|
302
|
+
{
|
|
303
|
+
"type": "agent_task",
|
|
304
|
+
"instruction_file": "learn-review-instructions.md",
|
|
305
|
+
"description": "Learn and document review instructions"
|
|
306
|
+
},
|
|
307
|
+
{
|
|
308
|
+
"type": "mcp_call",
|
|
309
|
+
"tool": "update_config_field",
|
|
310
|
+
"params": {
|
|
311
|
+
"field_name": "review_instructions",
|
|
312
|
+
"file_path": "{docs_dir}/standards/review_instructions.md"
|
|
313
|
+
},
|
|
314
|
+
"description": "Upload review_instructions to config",
|
|
315
|
+
"requires_approval": true
|
|
316
|
+
},
|
|
317
|
+
{
|
|
318
|
+
"type": "mcp_call",
|
|
319
|
+
"tool": "get_config_field",
|
|
320
|
+
"params": {
|
|
321
|
+
"field_name": "documentation_instructions"
|
|
322
|
+
},
|
|
323
|
+
"description": "Fetch current documentation_instructions value",
|
|
324
|
+
"on_error": "warn_and_continue"
|
|
325
|
+
},
|
|
326
|
+
{
|
|
327
|
+
"type": "agent_task",
|
|
328
|
+
"instruction_file": "learn-documentation-instructions.md",
|
|
329
|
+
"description": "Learn and document documentation instructions"
|
|
330
|
+
},
|
|
331
|
+
{
|
|
332
|
+
"type": "mcp_call",
|
|
333
|
+
"tool": "update_config_field",
|
|
334
|
+
"params": {
|
|
335
|
+
"field_name": "documentation_instructions",
|
|
336
|
+
"file_path": "{docs_dir}/standards/documentation_instructions.md"
|
|
337
|
+
},
|
|
338
|
+
"description": "Upload documentation_instructions to config",
|
|
339
|
+
"requires_approval": true
|
|
340
|
+
},
|
|
341
|
+
{
|
|
342
|
+
"type": "mcp_call",
|
|
343
|
+
"tool": "get_config_field",
|
|
344
|
+
"params": {
|
|
345
|
+
"field_name": "unit_testing_instructions"
|
|
346
|
+
},
|
|
347
|
+
"description": "Fetch current unit_testing_instructions value",
|
|
348
|
+
"on_error": "warn_and_continue"
|
|
349
|
+
},
|
|
350
|
+
{
|
|
351
|
+
"type": "agent_task",
|
|
352
|
+
"instruction_file": "learn-unit-testing.md",
|
|
353
|
+
"description": "Learn and document unit testing instructions"
|
|
354
|
+
},
|
|
355
|
+
{
|
|
356
|
+
"type": "mcp_call",
|
|
357
|
+
"tool": "update_config_field",
|
|
358
|
+
"params": {
|
|
359
|
+
"field_name": "unit_testing_instructions",
|
|
360
|
+
"file_path": "{docs_dir}/standards/unit_testing_instructions.md"
|
|
361
|
+
},
|
|
362
|
+
"description": "Upload unit_testing_instructions to config",
|
|
363
|
+
"requires_approval": true
|
|
364
|
+
},
|
|
365
|
+
{
|
|
366
|
+
"type": "mcp_call",
|
|
367
|
+
"tool": "get_config_field",
|
|
368
|
+
"params": {
|
|
369
|
+
"field_name": "e2e_testing_instructions"
|
|
370
|
+
},
|
|
371
|
+
"description": "Fetch current e2e_testing_instructions value",
|
|
372
|
+
"on_error": "warn_and_continue"
|
|
373
|
+
},
|
|
374
|
+
{
|
|
375
|
+
"type": "agent_task",
|
|
376
|
+
"instruction_file": "learn-e2e-testing.md",
|
|
377
|
+
"description": "Learn and document E2E testing instructions"
|
|
378
|
+
},
|
|
379
|
+
{
|
|
380
|
+
"type": "mcp_call",
|
|
381
|
+
"tool": "update_config_field",
|
|
382
|
+
"params": {
|
|
383
|
+
"field_name": "e2e_testing_instructions",
|
|
384
|
+
"file_path": "{docs_dir}/standards/e2e_testing_instructions.md"
|
|
385
|
+
},
|
|
386
|
+
"description": "Upload e2e_testing_instructions to config",
|
|
387
|
+
"requires_approval": true
|
|
388
|
+
},
|
|
389
|
+
{
|
|
390
|
+
"type": "mcp_call",
|
|
391
|
+
"tool": "get_config_field",
|
|
392
|
+
"params": {
|
|
393
|
+
"field_name": "frontend_correctness_standards"
|
|
394
|
+
},
|
|
395
|
+
"description": "Fetch current frontend_correctness_standards value",
|
|
396
|
+
"on_error": "warn_and_continue"
|
|
397
|
+
},
|
|
398
|
+
{
|
|
399
|
+
"type": "agent_task",
|
|
400
|
+
"instruction_file": "learn-frontend-correctness.md",
|
|
401
|
+
"description": "Learn and document frontend_correctness standards"
|
|
402
|
+
},
|
|
403
|
+
{
|
|
404
|
+
"type": "mcp_call",
|
|
405
|
+
"tool": "update_config_field",
|
|
406
|
+
"params": {
|
|
407
|
+
"field_name": "frontend_correctness_standards",
|
|
408
|
+
"file_path": "{docs_dir}/standards/frontend_correctness_standards.md"
|
|
409
|
+
},
|
|
410
|
+
"description": "Upload frontend_correctness_standards to config",
|
|
411
|
+
"requires_approval": true
|
|
412
|
+
},
|
|
413
|
+
{
|
|
414
|
+
"type": "mcp_call",
|
|
415
|
+
"tool": "get_config_field",
|
|
416
|
+
"params": {
|
|
417
|
+
"field_name": "backend_correctness_standards"
|
|
418
|
+
},
|
|
419
|
+
"description": "Fetch current backend_correctness_standards value",
|
|
420
|
+
"on_error": "warn_and_continue"
|
|
421
|
+
},
|
|
422
|
+
{
|
|
423
|
+
"type": "agent_task",
|
|
424
|
+
"instruction_file": "learn-backend-correctness.md",
|
|
425
|
+
"description": "Learn and document backend_correctness standards"
|
|
426
|
+
},
|
|
427
|
+
{
|
|
428
|
+
"type": "mcp_call",
|
|
429
|
+
"tool": "update_config_field",
|
|
430
|
+
"params": {
|
|
431
|
+
"field_name": "backend_correctness_standards",
|
|
432
|
+
"file_path": "{docs_dir}/standards/backend_correctness_standards.md"
|
|
433
|
+
},
|
|
434
|
+
"description": "Upload backend_correctness_standards to config",
|
|
435
|
+
"requires_approval": true
|
|
436
|
+
},
|
|
437
|
+
{
|
|
438
|
+
"type": "mcp_call",
|
|
439
|
+
"tool": "get_config_field",
|
|
440
|
+
"params": {
|
|
441
|
+
"field_name": "template_correctness_standards"
|
|
442
|
+
},
|
|
443
|
+
"description": "Fetch current template_correctness_standards value",
|
|
444
|
+
"on_error": "warn_and_continue"
|
|
445
|
+
},
|
|
446
|
+
{
|
|
447
|
+
"type": "agent_task",
|
|
448
|
+
"instruction_file": "learn-template-correctness.md",
|
|
449
|
+
"description": "Learn and document template_correctness standards"
|
|
450
|
+
},
|
|
451
|
+
{
|
|
452
|
+
"type": "mcp_call",
|
|
453
|
+
"tool": "update_config_field",
|
|
454
|
+
"params": {
|
|
455
|
+
"field_name": "template_correctness_standards",
|
|
456
|
+
"file_path": "{docs_dir}/standards/template_correctness_standards.md"
|
|
457
|
+
},
|
|
458
|
+
"description": "Upload template_correctness_standards to config",
|
|
459
|
+
"requires_approval": true
|
|
460
|
+
},
|
|
461
|
+
{
|
|
462
|
+
"type": "mcp_call",
|
|
463
|
+
"tool": "get_config_field",
|
|
464
|
+
"params": {
|
|
465
|
+
"field_name": "style_correctness_standards"
|
|
466
|
+
},
|
|
467
|
+
"description": "Fetch current style_correctness_standards value",
|
|
468
|
+
"on_error": "warn_and_continue"
|
|
469
|
+
},
|
|
470
|
+
{
|
|
471
|
+
"type": "agent_task",
|
|
472
|
+
"instruction_file": "learn-style-correctness.md",
|
|
473
|
+
"description": "Learn and document style_correctness standards"
|
|
474
|
+
},
|
|
475
|
+
{
|
|
476
|
+
"type": "mcp_call",
|
|
477
|
+
"tool": "update_config_field",
|
|
478
|
+
"params": {
|
|
479
|
+
"field_name": "style_correctness_standards",
|
|
480
|
+
"file_path": "{docs_dir}/standards/style_correctness_standards.md"
|
|
481
|
+
},
|
|
482
|
+
"description": "Upload style_correctness_standards to config",
|
|
483
|
+
"requires_approval": true
|
|
484
|
+
}
|
|
485
|
+
]
|
|
486
|
+
},
|
|
487
|
+
"pr-ticket": {
|
|
488
|
+
"name": "pr-ticket",
|
|
489
|
+
"description": "Commit changes and create a pull request.",
|
|
490
|
+
"variables": [
|
|
491
|
+
"ticket_key"
|
|
492
|
+
],
|
|
493
|
+
"steps": [
|
|
494
|
+
{
|
|
495
|
+
"type": "mcp_call",
|
|
496
|
+
"tool": "ping",
|
|
497
|
+
"params": {},
|
|
498
|
+
"description": "Verify Bridge API connectivity"
|
|
499
|
+
},
|
|
500
|
+
{
|
|
501
|
+
"type": "agent_task",
|
|
502
|
+
"instruction_file": "commit-and-push.md",
|
|
503
|
+
"description": "Stage, commit, and push changes",
|
|
504
|
+
"requires_approval": true
|
|
505
|
+
},
|
|
506
|
+
{
|
|
507
|
+
"type": "mcp_call",
|
|
508
|
+
"tool": "create_pull_request",
|
|
509
|
+
"params": {
|
|
510
|
+
"head_branch": "feature/{ticket_key}",
|
|
511
|
+
"base_branch": "main",
|
|
512
|
+
"title": "{ticket_key}: Implementation"
|
|
513
|
+
},
|
|
514
|
+
"description": "Create a pull request",
|
|
515
|
+
"requires_approval": true
|
|
516
|
+
}
|
|
517
|
+
]
|
|
518
|
+
},
|
|
519
|
+
"quick-implement": {
|
|
520
|
+
"name": "quick-implement",
|
|
521
|
+
"description": "Generate plan, execute implementation, commit, open PR, and monitor CI — skipping ticket review.",
|
|
522
|
+
"variables": [
|
|
523
|
+
"ticket_key",
|
|
524
|
+
"docs_dir"
|
|
525
|
+
],
|
|
526
|
+
"steps": [
|
|
527
|
+
{
|
|
528
|
+
"type": "mcp_call",
|
|
529
|
+
"tool": "ping",
|
|
530
|
+
"params": {},
|
|
531
|
+
"description": "Verify Bridge API connectivity"
|
|
532
|
+
},
|
|
533
|
+
{
|
|
534
|
+
"type": "mcp_call",
|
|
535
|
+
"tool": "request_plan_generation",
|
|
536
|
+
"params": {
|
|
537
|
+
"ticket_number": "{ticket_key}",
|
|
538
|
+
"wait_for_result": true,
|
|
539
|
+
"save_locally": true,
|
|
540
|
+
"provider": "{provider}"
|
|
541
|
+
},
|
|
542
|
+
"description": "Generate implementation plan"
|
|
543
|
+
},
|
|
544
|
+
{
|
|
545
|
+
"type": "agent_task",
|
|
546
|
+
"instruction_file": "execute-plan.md",
|
|
547
|
+
"description": "Execute the implementation plan"
|
|
548
|
+
},
|
|
549
|
+
{
|
|
550
|
+
"type": "agent_task",
|
|
551
|
+
"instruction_file": "commit-and-push.md",
|
|
552
|
+
"description": "Stage, commit, and push changes",
|
|
553
|
+
"requires_approval": true
|
|
554
|
+
},
|
|
555
|
+
{
|
|
556
|
+
"type": "mcp_call",
|
|
557
|
+
"tool": "create_pull_request",
|
|
558
|
+
"params": {
|
|
559
|
+
"head_branch": "feature/{ticket_key}",
|
|
560
|
+
"base_branch": "main",
|
|
561
|
+
"title": "{ticket_key}: Implementation"
|
|
562
|
+
},
|
|
563
|
+
"description": "Create a pull request",
|
|
564
|
+
"requires_approval": true
|
|
565
|
+
},
|
|
566
|
+
{
|
|
567
|
+
"type": "agent_task",
|
|
568
|
+
"instruction_file": "monitor-ci-checks.md",
|
|
569
|
+
"description": "Monitor CI checks and report results"
|
|
570
|
+
}
|
|
571
|
+
]
|
|
572
|
+
},
|
|
573
|
+
"review-only": {
|
|
574
|
+
"name": "review-only",
|
|
575
|
+
"description": "Review and rewrite a ticket: generate clarifying questions, critique, rewrite description, and push to Jira.",
|
|
576
|
+
"variables": [
|
|
577
|
+
"ticket_key",
|
|
578
|
+
"docs_dir"
|
|
579
|
+
],
|
|
580
|
+
"steps": [
|
|
581
|
+
{
|
|
582
|
+
"type": "mcp_call",
|
|
583
|
+
"tool": "ping",
|
|
584
|
+
"params": {},
|
|
585
|
+
"description": "Verify Bridge API connectivity"
|
|
586
|
+
},
|
|
587
|
+
{
|
|
588
|
+
"type": "mcp_call",
|
|
589
|
+
"tool": "request_clarifying_questions",
|
|
590
|
+
"params": {
|
|
591
|
+
"ticket_number": "{ticket_key}",
|
|
592
|
+
"wait_for_result": true,
|
|
593
|
+
"save_locally": true,
|
|
594
|
+
"provider": "{provider}"
|
|
595
|
+
},
|
|
596
|
+
"description": "Generate clarifying questions",
|
|
597
|
+
"on_error": "warn_and_continue"
|
|
598
|
+
},
|
|
599
|
+
{
|
|
600
|
+
"type": "mcp_call",
|
|
601
|
+
"tool": "request_ticket_critique",
|
|
602
|
+
"params": {
|
|
603
|
+
"ticket_number": "{ticket_key}",
|
|
604
|
+
"wait_for_result": true,
|
|
605
|
+
"save_locally": true,
|
|
606
|
+
"provider": "{provider}"
|
|
607
|
+
},
|
|
608
|
+
"description": "Generate ticket quality critique",
|
|
609
|
+
"on_error": "warn_and_continue"
|
|
610
|
+
},
|
|
611
|
+
{
|
|
612
|
+
"type": "agent_task",
|
|
613
|
+
"instruction_file": "update-ticket-rewrite.md",
|
|
614
|
+
"description": "Rewrite ticket description using critique and clarifying questions"
|
|
615
|
+
},
|
|
616
|
+
{
|
|
617
|
+
"type": "mcp_call",
|
|
618
|
+
"tool": "update_ticket_description",
|
|
619
|
+
"params": {
|
|
620
|
+
"ticket_number": "{ticket_key}",
|
|
621
|
+
"file_path": "{docs_dir}/tickets/{ticket_key}.md"
|
|
622
|
+
},
|
|
623
|
+
"description": "Push rewritten description to Jira"
|
|
624
|
+
}
|
|
625
|
+
]
|
|
626
|
+
},
|
|
627
|
+
"review-ticket": {
|
|
628
|
+
"name": "review-ticket",
|
|
629
|
+
"description": "Review a ticket with two rounds of analysis (initial + second opinion), rewrite the description, and push to Jira.",
|
|
630
|
+
"variables": [
|
|
631
|
+
"ticket_key",
|
|
632
|
+
"docs_dir"
|
|
633
|
+
],
|
|
634
|
+
"steps": [
|
|
635
|
+
{
|
|
636
|
+
"type": "mcp_call",
|
|
637
|
+
"tool": "ping",
|
|
638
|
+
"params": {},
|
|
639
|
+
"description": "Verify Bridge API connectivity"
|
|
640
|
+
},
|
|
641
|
+
{
|
|
642
|
+
"type": "mcp_call",
|
|
643
|
+
"tool": "request_clarifying_questions",
|
|
644
|
+
"params": {
|
|
645
|
+
"ticket_number": "{ticket_key}",
|
|
646
|
+
"wait_for_result": true,
|
|
647
|
+
"save_locally": true,
|
|
648
|
+
"provider": "{provider}"
|
|
649
|
+
},
|
|
650
|
+
"description": "Generate clarifying questions (initial)",
|
|
651
|
+
"on_error": "warn_and_continue"
|
|
652
|
+
},
|
|
653
|
+
{
|
|
654
|
+
"type": "mcp_call",
|
|
655
|
+
"tool": "request_ticket_critique",
|
|
656
|
+
"params": {
|
|
657
|
+
"ticket_number": "{ticket_key}",
|
|
658
|
+
"wait_for_result": true,
|
|
659
|
+
"save_locally": true,
|
|
660
|
+
"provider": "{provider}"
|
|
661
|
+
},
|
|
662
|
+
"description": "Generate ticket quality critique (initial)",
|
|
663
|
+
"on_error": "warn_and_continue"
|
|
664
|
+
},
|
|
665
|
+
{
|
|
666
|
+
"type": "mcp_call",
|
|
667
|
+
"tool": "request_clarifying_questions",
|
|
668
|
+
"params": {
|
|
669
|
+
"ticket_number": "{ticket_key}",
|
|
670
|
+
"second_opinion": "auto",
|
|
671
|
+
"wait_for_result": true,
|
|
672
|
+
"save_locally": true,
|
|
673
|
+
"provider": "{provider}"
|
|
674
|
+
},
|
|
675
|
+
"description": "Generate clarifying questions (second opinion)",
|
|
676
|
+
"on_error": "warn_and_continue"
|
|
677
|
+
},
|
|
678
|
+
{
|
|
679
|
+
"type": "mcp_call",
|
|
680
|
+
"tool": "request_ticket_critique",
|
|
681
|
+
"params": {
|
|
682
|
+
"ticket_number": "{ticket_key}",
|
|
683
|
+
"second_opinion": "auto",
|
|
684
|
+
"wait_for_result": true,
|
|
685
|
+
"save_locally": true,
|
|
686
|
+
"provider": "{provider}"
|
|
687
|
+
},
|
|
688
|
+
"description": "Generate ticket quality critique (second opinion)",
|
|
689
|
+
"on_error": "warn_and_continue"
|
|
690
|
+
},
|
|
691
|
+
{
|
|
692
|
+
"type": "agent_task",
|
|
693
|
+
"instruction_file": "update-ticket-rewrite.md",
|
|
694
|
+
"description": "Rewrite ticket description using critique and clarifying questions"
|
|
695
|
+
},
|
|
696
|
+
{
|
|
697
|
+
"type": "mcp_call",
|
|
698
|
+
"tool": "update_ticket_description",
|
|
699
|
+
"params": {
|
|
700
|
+
"ticket_number": "{ticket_key}",
|
|
701
|
+
"file_path": "{docs_dir}/tickets/{ticket_key}.md"
|
|
702
|
+
},
|
|
703
|
+
"description": "Push rewritten description to Jira"
|
|
704
|
+
}
|
|
705
|
+
]
|
|
706
|
+
}
|
|
707
|
+
};
|
|
708
|
+
export const INSTRUCTIONS = {
|
|
709
|
+
"commit-and-push.md": "Stage all changed files and create a commit for ticket {ticket_key}.\n\n1. Run `git add` on all files modified or created during implementation. Do not stage unrelated files.\n2. Create a commit with the message: `{ticket_key}: Implementation`\n3. Push the current branch to the remote.\n",
|
|
710
|
+
"execute-plan.md": "Execute the AI-generated implementation plan for ticket {ticket_key}.\n\n1. Read the plan from `{docs_dir}/plans/{ticket_key}-plan.md`.\n2. Execute each step in the plan sequentially, making code changes as directed.\n3. Run any tests or checks specified in the plan's review steps.\n4. Do NOT run `git commit` or `git push` — leave all changes uncommitted for developer review.\n5. If a step is ambiguous or blocked, note the issue clearly and continue with the next step.\n",
|
|
711
|
+
"learn-architecture.md": "You are a Senior Technical Architect researching a codebase to produce detailed, evidence-based architecture instructions.\n\n## Objective\n\nExplore the codebase to identify architectural principles, directory conventions, design patterns, and data flow, then draft `architecture_instructions` for the project config.\n\n## Instructions\n\n### Phase 1 — Principles Research\n\nResearch the codebase to identify architectural principles and conventions. For each area below, examine at least 5 representative files. Cite file paths for every pattern. Include code examples (5-15 lines) showing correct usage. Where relevant, include a WRONG example showing the common mistake.\n\nFor each pattern, classify its evidence level:\n- `ENFORCED` — consistently followed across the codebase, violations would be bugs\n- `CONVENTION` — commonly observed, occasional deviations exist\n- `ASPIRATIONAL` — intended direction, not yet consistently applied\n\nResearch areas:\n1. **Architectural coding patterns**: Separation of concerns, layer boundaries, function-vs-class decisions. Document module naming suffix conventions (`_lib.py`, `_utils.py`, `_helpers.py`).\n2. **Design patterns**: Factory, strategy, observer, middleware chains, dependency injection, registry pattern. Cite concrete usage with file path and function name.\n3. **Dependency management**: How dependencies are declared, imported, organized. Package management tooling and constraints.\n4. **Error handling architecture**: System-wide error propagation strategy — which layers catch, propagate, or report to Sentry. Document the Sentry function contract.\n5. **Configuration management**: How config values, environment variables, and secrets are handled. Document the two-tier system (env vars vs. database config).\n6. **Tech stack detection**: Identify primary language(s), framework(s), and key libraries. Use WebSearch to confirm current best practices.\n7. **Security architecture**: Authentication and authorization design, session model, bot protection, data protection principles.\n8. **Agent prompting conventions**: How AI agents in `src/python/llms/agents/` are structured — prompt construction, section headers, dynamic content delimiters, role-based personas.\n\nScope exclusion: Do NOT document testing patterns. Skip the `tests/` directory entirely.\n\nWrite findings to `{docs_dir}/tmp/architecture-principles.md`.\n\n### Phase 2 — Structure & Data Flow Research\n\n1. Call the `regenerate_directory_map` MCP tool to get a fresh directory map.\n2. Read the principles document from Phase 1.\n3. Research and document:\n - **Directory conventions**: For each major directory, document purpose, file naming, internal structure, and an example file.\n - **Module boundaries and import patterns**: Which directories are distinct modules and how they interact. Document import restrictions.\n - **Data flow patterns**: Trace 2-3 complete request paths (synchronous, async background task, agent orchestration).\n - **Integration patterns**: How external services (Jira, GitHub/Bitbucket, LLMs, Pinecone, PostgreSQL) are integrated.\n - **Background task patterns**: The async task lifecycle with `asyncio.create_task`, semaphores, and error reporting.\n\nWrite findings to `{docs_dir}/tmp/architecture-structure.md`.\n\n### Phase 3 — Draft\n\n1. Read both research documents.\n2. Combine into a single `architecture_instructions` draft with these required sections:\n - **1. Core Principles** — Each principle with evidence level and explanation.\n - **2. Layered Architecture** — Layer separation, dependency rule, agent vs orchestration logic.\n - **3. Directory Conventions** — Purpose, naming, structure for each major directory.\n - **4. Data Flow Patterns** — Complete request path traces with file paths.\n - **5. Technical Standards** — Coding style, async patterns, database, schema, LLM integration, config, dependencies.\n - **6. Error Handling & Monitoring** — Error propagation strategy, Sentry integration, Langfuse tracing.\n - **7. Security & Authentication** — Auth architecture, session model, permission model.\n - **8. Agent Prompting Conventions** — Prompt construction, section headers, content delimiters.\n - **9. Integration Points** — External service clients and their calling patterns.\n - **10. AI Code Generation Guidelines** — Anti-patterns, duplication avoidance, pattern compliance checklist.\n\n3. Write the draft to `{docs_dir}/standards/architecture_instructions.md`.\n",
|
|
712
|
+
"learn-backend-correctness.md": "You are a Senior Technical Architect researching a codebase to produce detailed correctness standards for backend code.\n\n## Objective\n\nExplore the codebase to identify correctness standards for backend code, then draft the corresponding correctness standards document.\n\n## Target Type\n\n- **Type**: `backend_correctness`\n- **Field name**: `backend_correctness_standards`\n- **Scope**: Server-side code: Python, Ruby, Go, Java, C#, Node.js server code, API routes, business logic.\n\n## Instructions\n\n### Phase 1 — Explore Correctness Patterns\n\nFocus on implementation correctness: how to write code that is correct, idiomatic, and robust within this project's conventions.\n\n1. **File Type Detection**: Use Glob to find files of the relevant type. If very few or no files exist, note this and draft minimal instructions.\n\n2. **Convention Analysis**: Examine 3-5 representative files to identify:\n - Structure patterns (imports, exports, class structure, function ordering)\n - Naming conventions (variables, functions, classes, files)\n - Framework conventions and idioms\n - Best practices followed\n - Issues and inconsistencies\n\n Also examine:\n - Error handling implementation (try/except ordering, Sentry calls) with CORRECT/WRONG examples\n - Authentication implementation (auth check sequence) with code examples\n - Database call patterns (`postgres_helpers` (bool, result) tuple handling) with CORRECT/WRONG examples\n - Input validation patterns (Pydantic models, naming conventions)\n - HTTP client patterns (error handling, JiraError sanitization)\n - Async implementation patterns (`asyncio.to_thread()` for blocking code)\n\n3. **Best Practices Research**: Use WebSearch to confirm current correctness standards for the detected framework/language. Focus on code quality, security, performance, and accessibility.\n\n### Phase 2 — Draft\n\nDraft correctness standards as clear, actionable instructions for an AI code generation agent. Cover:\n- Code structure and organization requirements\n- Naming conventions to follow\n- Framework-specific patterns and idioms\n- Security requirements relevant to this code type\n- Performance considerations\n- Common mistakes to avoid\n- Guards against common AI weaknesses: duplicative code, verbose implementations, security vulnerabilities\n\nAlso include:\n- Route handler boilerplate (auth -> validation -> business logic -> error handling)\n- Database interaction patterns with CORRECT/WRONG examples\n- Exception handling pattern (specific first, HTTPException re-raise, generic with Sentry)\n- Sentry reporting patterns and common mistakes\n- Input sanitization rules (JiraError headers, raw exception messages)\n\nWrite the draft to `{docs_dir}/standards/backend_correctness_standards.md`.\n",
|
|
713
|
+
"learn-documentation-instructions.md": "You are a Senior Technical Architect researching a codebase to produce detailed documentation instructions.\n\n## Objective\n\nExplore the codebase to identify implementation documentation patterns — the markdown records that document what was built, why, and when — then draft `documentation_instructions` for the project config.\n\n## Instructions\n\n### Phase 1 — Explore Implementation Record Patterns\n\nFocus on how the project records what was built, why, and when. These records serve as persistent project memory. Code-level documentation (docstrings, inline comments) is handled by correctness standards, not here.\n\n1. **Implementation Record Discovery**: Search for:\n - Ticket-numbered documents (e.g., `BAPI-*.md`, `PROJ-*.md`) in `docs/`, `documentation/`, or similar directories\n - Feature/migration documents describing completed features or refactors\n - Architecture Decision Records (ADRs) in `adr/`, `decisions/`, or similar\n - Changelogs (`CHANGELOG.md`, release notes)\n\n Count how many records exist and identify the naming convention.\n\n2. **Record Structure Analysis**: Read 3-5 representative implementation records (mix of early and recent). Document:\n - Sections present (Summary, Architecture, Database Changes, API Reference, etc.)\n - Level of detail provided\n - Types of information captured (motivation, design decisions, schema changes, file paths, API contracts)\n - How code examples and diagrams are used\n\n3. **Documentation Location and Organization**: Identify where records are stored, the file naming convention, whether there is a table of contents or index, and whether subdirectories serve different purposes.\n\n4. **Best Practices Research**: Use WebSearch to confirm current best practices for project implementation documentation and engineering decision records.\n\n### Phase 2 — Draft\n\nDraft `documentation_instructions` as clear, actionable instructions for an AI agent writing implementation documentation after completing a feature. Cover:\n- **Purpose**: Documents serve as persistent project memory for future agents and developers.\n- **When to write**: After completing any feature, refactor, migration, or significant bug fix.\n- **File naming convention**: Based on discovered patterns or sensible defaults.\n- **File location**: Where to place implementation records.\n- **Required sections**: Standard structure from analysis or sensible defaults.\n- **Content guidelines**: Level of detail — motivations, design decisions, database changes, file references, API contracts.\n- **Scope boundary**: Implementation records only; code-level docs belong in correctness standards.\n\nWrite the draft to `{docs_dir}/standards/documentation_instructions.md`.\n",
|
|
714
|
+
"learn-e2e-testing.md": "You are a Senior Technical Architect researching a codebase to produce detailed E2E testing instructions.\n\n## Objective\n\nDetect whether an E2E testing framework exists in the codebase, document how to run and write E2E tests, then draft `e2e_testing_instructions` for the project config.\n\n## Instructions\n\n### Phase 1 — Detect E2E Framework\n\nSearch for config files and indicators:\n- **Playwright**: `playwright.config.ts`, `playwright.config.js`, `@playwright/test` in package.json\n- **Cypress**: `cypress.json`, `cypress.config.*`, `cypress/` directory\n- **Selenium/WebDriver**: `selenium` dependencies, WebDriver configs\n- **Puppeteer**: `puppeteer` in package.json\n- **TestCafe**: `.testcaferc.json`\n\nAlso check `package.json` for E2E-related scripts and test directories containing E2E tests.\n\nIf NO E2E testing framework is detected, write \"No E2E testing framework detected in this repository.\" to `{docs_dir}/standards/e2e_testing_instructions.md` and stop.\n\n### Phase 2 — Explore E2E Testing Conventions\n\n1. **Test Execution**: Determine exact commands (all tests, single file, headed/headless), prerequisites (server running, database seeded), and environment requirements.\n\n2. **Test Patterns**: Examine 2-3 representative E2E test files to identify structure (page objects, fixtures, helpers), login/auth flows, test data setup/teardown, async waiting strategies, and selector patterns.\n\n3. **Common Pitfalls**: Identify issues that make tests flaky or slow — hard-coded waits, test isolation, browser state management, network request handling.\n\n4. **Best Practices Research**: Use WebSearch to confirm current best practices for the detected E2E framework.\n\n### Phase 3 — Draft\n\nDraft `e2e_testing_instructions` as clear, actionable instructions for an AI agent writing E2E tests. Cover:\n- How to run tests (exact commands, prerequisites)\n- Test structure and organization\n- Authentication and setup patterns\n- How to wait for async operations (never hard-coded sleeps)\n- Common pitfalls with browser automation\n- Guards against common AI weaknesses: flaky tests, brittle selectors, hard-coded waits\n\nWrite the draft to `{docs_dir}/standards/e2e_testing_instructions.md`.\n",
|
|
715
|
+
"learn-frontend-correctness.md": "You are a Senior Technical Architect researching a codebase to produce detailed correctness standards for frontend code.\n\n## Objective\n\nExplore the codebase to identify correctness standards for frontend code, then draft the corresponding correctness standards document.\n\n## Target Type\n\n- **Type**: `frontend_correctness`\n- **Field name**: `frontend_correctness_standards`\n- **Scope**: JS, TS, JSX, TSX files: React/Vue/Angular/Svelte components, client-side logic, state management.\n\n## Instructions\n\n### Phase 1 — Explore Correctness Patterns\n\nFocus on implementation correctness: how to write code that is correct, idiomatic, and robust within this project's conventions.\n\n1. **File Type Detection**: Use Glob to find files of the relevant type. If very few or no files exist, note this and draft minimal instructions.\n\n2. **Convention Analysis**: Examine 3-5 representative files to identify:\n - Structure patterns (imports, exports, class structure, function ordering)\n - Naming conventions (variables, functions, classes, files)\n - Framework conventions and idioms\n - Best practices followed\n - Issues and inconsistencies\n\n3. **Best Practices Research**: Use WebSearch to confirm current correctness standards for the detected framework/language. Focus on code quality, security, performance, and accessibility.\n\n### Phase 2 — Draft\n\nDraft correctness standards as clear, actionable instructions for an AI code generation agent. Cover:\n- Code structure and organization requirements\n- Naming conventions to follow\n- Framework-specific patterns and idioms\n- Security requirements relevant to this code type\n- Performance considerations\n- Common mistakes to avoid\n- Guards against common AI weaknesses: duplicative code, verbose implementations, security vulnerabilities\n\nWrite the draft to `{docs_dir}/standards/frontend_correctness_standards.md`.\n",
|
|
716
|
+
"learn-review-instructions.md": "You are a Senior Technical Architect researching a codebase to produce detailed code review and self-verification instructions.\n\n## Objective\n\nExplore the codebase to identify self-verification patterns, downstream impact analysis techniques, and local validation tooling, then draft `review_instructions` for the project config.\n\n## Instructions\n\n### Phase 1 — Explore Self-Verification Patterns\n\nFocus on how an AI agent working in a code editor (with access to Grep, Glob, Read, and MCP tools) can verify its own code changes before requesting human review. Do NOT document test runners or CI/CD — focus on static analysis by reading code and searching for patterns.\n\n1. **Code Correctness Patterns**: Examine 3-5 representative modules to identify:\n - Function signature conventions (return types, parameter patterns)\n - Import conventions and layer boundaries (deprecated modules, import restrictions)\n - Return value handling (structured results, tuple unpacking)\n - Auth pattern compliance (required decorators, dependency injections, call order)\n - Naming conventions (files, functions, classes, variables)\n - Error handling patterns (try/except structure, ordering, logging)\n\n2. **Downstream Impact Analysis**: For each technique, demonstrate with a concrete codebase example:\n - Caller discovery (Grep patterns for finding all callers of utility functions)\n - Import graph analysis (finding all files importing from a module)\n - Route registration verification (checking new routes are properly included)\n - Database schema impact (finding queries referencing a given table/column)\n - Model/schema usage (verifying model changes don't break dependents)\n\n3. **Local Validation Tooling**: Discover available MCP tools and validation capabilities:\n - Database MCP tools (schema verification, query validation)\n - Project API MCP tools (config verification, health checks)\n - Hooks and guards (pre-commit hooks, pre-tool hooks)\n - Safety model (read-only vs. mutating operations)\n\n4. **Correctness Standards Integration**: Check `{docs_dir}/standards/` for any existing correctness standards files. Extract key verification checkpoints that can be statically verified.\n\n### Phase 2 — Draft\n\nDraft `review_instructions` with these required sections:\n1. **Self-Verification Checklist** — Concise, scannable checklist with concrete actions and tools.\n2. **Local Code Verification** — Detailed static analysis instructions (function calls, imports, auth, error handling, naming).\n3. **Downstream Effect Analysis** — Finding callers, checking signature compatibility, import tracking, schema impact, route registration.\n4. **Validation Using Local Tooling** — Database validation, project API validation, hooks and guards.\n5. **Correctness Standards Reference** — Distilled checkpoints from loaded standards, or placeholder paths.\n6. **Common AI Agent Mistakes** — Verification-framed guards against duplication, unnecessary abstraction, data leaks, edge cases.\n\nWrite the draft to `{docs_dir}/standards/review_instructions.md`.\n",
|
|
717
|
+
"learn-style-correctness.md": "You are a Senior Technical Architect researching a codebase to produce detailed correctness standards for style files.\n\n## Objective\n\nExplore the codebase to identify correctness standards for style files, then draft the corresponding correctness standards document.\n\n## Target Type\n\n- **Type**: `style_correctness`\n- **Field name**: `style_correctness_standards`\n- **Scope**: Style files: CSS, SCSS, SASS, LESS, Styled Components, Tailwind configs.\n\n## Instructions\n\n### Phase 1 — Explore Correctness Patterns\n\nFocus on implementation correctness: how to write code that is correct, idiomatic, and robust within this project's conventions.\n\n1. **File Type Detection**: Use Glob to find files of the relevant type. If very few or no files exist, note this and draft minimal instructions.\n\n2. **Convention Analysis**: Examine 3-5 representative files to identify:\n - Structure patterns (imports, exports, class structure, function ordering)\n - Naming conventions (variables, functions, classes, files)\n - Framework conventions and idioms\n - Best practices followed\n - Issues and inconsistencies\n\n3. **Best Practices Research**: Use WebSearch to confirm current correctness standards for the detected framework/language. Focus on code quality, security, performance, and accessibility.\n\n### Phase 2 — Draft\n\nDraft correctness standards as clear, actionable instructions for an AI code generation agent. Cover:\n- Code structure and organization requirements\n- Naming conventions to follow\n- Framework-specific patterns and idioms\n- Security requirements relevant to this code type\n- Performance considerations\n- Common mistakes to avoid\n- Guards against common AI weaknesses: duplicative code, verbose implementations, security vulnerabilities\n\nWrite the draft to `{docs_dir}/standards/style_correctness_standards.md`.\n",
|
|
718
|
+
"learn-template-correctness.md": "You are a Senior Technical Architect researching a codebase to produce detailed correctness standards for template files.\n\n## Objective\n\nExplore the codebase to identify correctness standards for template files, then draft the corresponding correctness standards document.\n\n## Target Type\n\n- **Type**: `template_correctness`\n- **Field name**: `template_correctness_standards`\n- **Scope**: Template files: HTML, Jinja2, Handlebars, EJS, ERB, Blade, Pug, Twig.\n\n## Instructions\n\n### Phase 1 — Explore Correctness Patterns\n\nFocus on implementation correctness: how to write code that is correct, idiomatic, and robust within this project's conventions.\n\n1. **File Type Detection**: Use Glob to find files of the relevant type. If very few or no files exist, note this and draft minimal instructions.\n\n2. **Convention Analysis**: Examine 3-5 representative files to identify:\n - Structure patterns (imports, exports, class structure, function ordering)\n - Naming conventions (variables, functions, classes, files)\n - Framework conventions and idioms\n - Best practices followed\n - Issues and inconsistencies\n\n3. **Best Practices Research**: Use WebSearch to confirm current correctness standards for the detected framework/language. Focus on code quality, security, performance, and accessibility.\n\n### Phase 2 — Draft\n\nDraft correctness standards as clear, actionable instructions for an AI code generation agent. Cover:\n- Code structure and organization requirements\n- Naming conventions to follow\n- Framework-specific patterns and idioms\n- Security requirements relevant to this code type\n- Performance considerations\n- Common mistakes to avoid\n- Guards against common AI weaknesses: duplicative code, verbose implementations, security vulnerabilities\n\nWrite the draft to `{docs_dir}/standards/template_correctness_standards.md`.\n",
|
|
719
|
+
"learn-unit-testing.md": "You are a Senior Technical Architect researching a codebase to produce detailed unit testing instructions.\n\n## Objective\n\nExplore the codebase to identify the test runner, assertion library, mocking framework, and testing patterns, then draft `unit_testing_instructions` for the project config.\n\n## Instructions\n\n### Phase 1 — Explore Testing Infrastructure\n\n1. **Test Runner and Framework Detection**: Search for test runner configs (`pytest.ini`, `pyproject.toml [tool.pytest]`, `jest.config.*`, etc.), test directories (`tests/`, `__tests__/`), and package.json test scripts.\n\n2. **Testing Patterns**: Examine 3-5 representative test files to identify:\n - Assertion library and style (`assert`, `expect`, custom matchers)\n - Mocking framework (`unittest.mock`, `jest.mock`, `sinon`, etc.)\n - Fixture patterns (setup/teardown)\n - Test organization (by module, feature, layer)\n - Exemplary tests vs. weak tests\n\n3. **How to Run Tests**: Determine exact commands for: full suite, single file, by name pattern, with verbose output.\n\n4. **Mocking vs. Fidelity**: Document how external APIs are mocked, whether integration tests exist alongside unit tests, and patterns for avoiding third-party calls in tests.\n\n5. **Best Practices Research**: Use WebSearch to confirm current best practices for the detected testing framework.\n\n### Phase 2 — Draft\n\nDraft `unit_testing_instructions` as clear, actionable instructions for an AI agent writing unit tests. Cover:\n- How to run tests (exact commands)\n- Which test framework and assertion library to use\n- How to mock external dependencies without calling third parties\n- How to structure test files and test functions\n- What constitutes a thorough test (not just happy path)\n- How to avoid shallow tests that pass but don't verify meaningful behavior\n- Guards against common AI weaknesses: tests that mock the thing being tested, trivially passing assertions, overly complex setup\n\nWrite the draft to `{docs_dir}/standards/unit_testing_instructions.md`.\n",
|
|
720
|
+
"monitor-ci-checks.md": "Monitor CI checks for the most recent commit.\n\n1. Run `git rev-parse HEAD` to get the current commit SHA.\n2. Call the `resolve_ci_checks` tool with the commit SHA as `commit_ref`. This discovers and classifies the CI checks for the repository.\n3. Poll CI status by calling `poll_ci_checks` with the same `commit_ref`. Check the response for `all_complete` and `all_passed`.\n4. If checks are not yet complete, wait 30 seconds and poll again. Repeat until all checks are complete or 10 minutes have elapsed.\n5. If all checks pass, report success.\n6. If any checks fail, report which checks failed and include any available annotations or log details from the poll response. Do NOT attempt to fix failures — just report them clearly.\n\n## Polling Directive\n\nDuring the polling loop, execute `sleep 30` silently. Do NOT output any inline commentary, reasoning, or partial status updates between polls. Only output a status message when:\n- All checks are complete (pass or fail), OR\n- The 10-minute timeout is reached.\n\nThis minimizes context window consumption during long-running CI waits.\n",
|
|
721
|
+
"update-ticket-rewrite.md": "Rewrite the Jira ticket description for {ticket_key} using the generated clarifying questions and critique documents.\n\n1. Fetch the current ticket description using the `get_ticket` tool with ticket_number `{ticket_key}`.\n2. Read the clarifying questions from the local file saved by the previous step (check `{docs_dir}/clarifying-questions/` for `{ticket_key}-clarifying-questions.md`). For each best-guess answer, verify it against the codebase using file search and code grep. Accept verified answers, correct inaccurate ones with evidence, and let ambiguous ones stand.\n3. Read the critique from the local file saved by the previous step (check `{docs_dir}/ticket-critiques/` for `{ticket_key}-ticket-quality-critique.md`). Address all Requested Changes. Apply Points to Consider selectively — accept genuine improvements, skip stylistic preferences.\n4. Write the rewritten ticket in standard markdown format (not Jira wiki markup). Preserve the Summary, Requirements, and Acceptance Criteria structure.\n5. Save the output to `{docs_dir}/tickets/{ticket_key}.md`. Output only the clean rewritten ticket — no meta-commentary.\n"
|
|
722
|
+
};
|