@bridge_gpt/mcp-server 0.1.1 → 0.1.3
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/README.md +37 -1
- package/build/commands.generated.js +20 -0
- package/build/index.js +193 -2
- package/build/pipeline-utils.js +93 -0
- package/build/pipelines.generated.js +14 -286
- package/package.json +3 -2
- package/pipelines/check-ci-ticket.json +35 -0
- package/pipelines/implement-ticket.json +51 -0
- package/pipelines/learn-repository.json +216 -0
- package/pipelines/pr-ticket.json +30 -0
- package/pipelines/review-ticket.json +68 -0
|
@@ -38,127 +38,9 @@ export const PIPELINES = {
|
|
|
38
38
|
}
|
|
39
39
|
]
|
|
40
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
41
|
"implement-ticket": {
|
|
160
42
|
"name": "implement-ticket",
|
|
161
|
-
"description": "
|
|
43
|
+
"description": "Generate plan, execute implementation, commit, open PR, and monitor CI.",
|
|
162
44
|
"variables": [
|
|
163
45
|
"ticket_key",
|
|
164
46
|
"docs_dir"
|
|
@@ -170,44 +52,6 @@ export const PIPELINES = {
|
|
|
170
52
|
"params": {},
|
|
171
53
|
"description": "Verify Bridge API connectivity"
|
|
172
54
|
},
|
|
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
55
|
{
|
|
212
56
|
"type": "mcp_call",
|
|
213
57
|
"tool": "request_plan_generation",
|
|
@@ -516,117 +360,9 @@ export const PIPELINES = {
|
|
|
516
360
|
}
|
|
517
361
|
]
|
|
518
362
|
},
|
|
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
363
|
"review-ticket": {
|
|
628
364
|
"name": "review-ticket",
|
|
629
|
-
"description": "Review a ticket with two rounds of analysis (initial + second opinion)
|
|
365
|
+
"description": "Review a ticket with two rounds of analysis (initial + second opinion) and evaluate suggestions for accuracy and value.",
|
|
630
366
|
"variables": [
|
|
631
367
|
"ticket_key",
|
|
632
368
|
"docs_dir"
|
|
@@ -690,33 +426,25 @@ export const PIPELINES = {
|
|
|
690
426
|
},
|
|
691
427
|
{
|
|
692
428
|
"type": "agent_task",
|
|
693
|
-
"instruction_file": "
|
|
694
|
-
"description": "
|
|
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"
|
|
429
|
+
"instruction_file": "evaluate-ticket-review.md",
|
|
430
|
+
"description": "Evaluate review suggestions against the codebase for groundedness and value"
|
|
704
431
|
}
|
|
705
432
|
]
|
|
706
433
|
}
|
|
707
434
|
};
|
|
708
435
|
export const INSTRUCTIONS = {
|
|
709
436
|
"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",
|
|
437
|
+
"evaluate-ticket-review.md": "Evaluate the clarifying questions and ticket critiques generated for {ticket_key}, assessing their accuracy and value against the actual codebase.\n\n1. Fetch the current ticket description using the `get_ticket` tool with ticket_number `{ticket_key}`.\n2. Gather all clarifying questions and critiques from the preceding pipeline steps. Both initial and second-opinion rounds may be present — use the MCP call results from the conversation context, since the files on disk at `{docs_dir}/clarifying-questions/{ticket_key}-clarifying-questions.md` and `{docs_dir}/ticket-critiques/{ticket_key}-ticket-quality-critique.md` only reflect the most recent round.\n3. For each clarifying question and its best-guess answer, verify groundedness against the codebase using file search and code grep:\n - If the question/answer accurately reflects the codebase, confirm it as grounded with evidence.\n - If the question/answer misunderstands the codebase (wrong assumptions about architecture, incorrect file references, etc.), call it out with evidence of what the code actually does.\n - If the question raises a genuine gap that cannot be resolved from the codebase alone, note it as a legitimate open question.\n4. For each critique point (Requested Changes and Points to Consider), assess:\n - Does it identify a genuine gap or design issue in the ticket? Confirm with codebase evidence.\n - Is it based on an inaccurate understanding of the existing code? Flag with corrections.\n - Is it a stylistic preference rather than a substantive improvement? Note as low-priority.\n5. Produce a structured evaluation with three sections:\n - **Confirmed Improvements**: Suggestions that are grounded and would genuinely improve the ticket by closing significant gaps or correcting design issues.\n - **Needs Scrutiny**: Suggestions based on inaccurate codebase assumptions, with evidence of the actual code behavior.\n - **Open Questions**: Legitimate ambiguities that require human input to resolve.\n6. Save the evaluation to `{docs_dir}/explorations/{ticket_key}-review-evaluation.md`. Output only the structured evaluation — no meta-commentary.\n",
|
|
710
438
|
"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": "
|
|
712
|
-
"learn-backend-correctness.md": "
|
|
713
|
-
"learn-documentation-instructions.md": "
|
|
714
|
-
"learn-e2e-testing.md": "
|
|
715
|
-
"learn-frontend-correctness.md": "
|
|
716
|
-
"learn-review-instructions.md": "
|
|
717
|
-
"learn-style-correctness.md": "
|
|
718
|
-
"learn-template-correctness.md": "
|
|
719
|
-
"learn-unit-testing.md": "
|
|
439
|
+
"learn-architecture.md": "## 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**: Search `api/routes/` and `api/library/` for separation of concerns, layer boundaries, function-vs-class decisions. Read files matching `*_lib.py`, `*_utils.py`, `*_helpers.py` to document module naming suffix conventions.\n2. **Design patterns**: Search for factory functions, strategy patterns, middleware chains, registry patterns, and dependency injection in `api/` and `src/python/`. Cite concrete usage with file path and function name.\n3. **Dependency management**: Read `requirements.in`, `requirements-dev.in`, and `package.json` files to document how dependencies are declared and organized.\n4. **Error handling architecture**: Search for `log_exception_to_sentry` and `HTTPException` usage patterns across `api/routes/` to document the system-wide error propagation strategy.\n5. **Configuration management**: Search for `os.environ` and `get_config_field` usage to document the two-tier system (env vars vs. database config).\n6. **Tech stack detection**: Read `requirements.in`, `package.json`, and `main.py` to identify primary languages, frameworks, and key libraries.\n7. **Security architecture**: Read `api/routes/setup/auth.py` and search for `require_api_key`, `require_api_session`, and `verify_repo_access` to document authentication and authorization design.\n8. **Agent prompting conventions**: Read files in `src/python/llms/agents/` to document prompt construction, section headers, dynamic content delimiters, and 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",
|
|
440
|
+
"learn-backend-correctness.md": "## 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 matching `**/*.py` in `api/` and `src/python/`. If very few or no files exist, note this and draft minimal instructions.\n\n2. **Convention Analysis**: Read 3-5 representative files in `api/routes/` and `api/library/` 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 read files to document:\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\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",
|
|
441
|
+
"learn-documentation-instructions.md": "## 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 matching `BAPI-*.md` or `PROJ-*.md` in `docs/` and subdirectories\n - Feature/migration documents in `docs/`, `documentation/`, or similar directories\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**: Read the directory structure of `docs/` to 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\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",
|
|
442
|
+
"learn-e2e-testing.md": "## 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**: Search for `playwright.config.ts`, `playwright.config.js`, `@playwright/test` in `package.json`\n- **Cypress**: Search for `cypress.json`, `cypress.config.*`, `cypress/` directory\n- **Selenium/WebDriver**: Search for `selenium` in `requirements.in` or `package.json`\n- **Puppeteer**: Search for `puppeteer` in `package.json`\n- **TestCafe**: Search for `.testcaferc.json`\n\nAlso read `package.json` for E2E-related scripts and search for 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**: Read the E2E config file and `package.json` scripts to determine exact commands (all tests, single file, headed/headless), prerequisites (server running, database seeded), and environment requirements.\n\n2. **Test Patterns**: Read 2-3 representative E2E test files in `tests/playwright/` to identify structure (page objects, fixtures, helpers), login/auth flows, test data setup/teardown, async waiting strategies, and selector patterns.\n\n3. **Common Pitfalls**: Search for hard-coded waits (`setTimeout`, `page.waitForTimeout`), test isolation issues, and browser state management patterns across E2E test files.\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",
|
|
443
|
+
"learn-frontend-correctness.md": "## 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 matching `**/*.js`, `**/*.ts`, `**/*.jsx`, `**/*.tsx` (excluding `node_modules/` and `build/`). If very few or no files exist, note this and draft minimal instructions.\n\n2. **Convention Analysis**: Read 3-5 representative frontend 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### 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",
|
|
444
|
+
"learn-review-instructions.md": "## 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**: Read 3-5 representative modules in `api/routes/` and `api/library/` 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**: Read files in `{docs_dir}/standards/` matching `*_correctness_standards.md`. 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",
|
|
445
|
+
"learn-style-correctness.md": "## 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 matching `**/*.css`, `**/*.scss`, `**/*.sass`, `**/*.less` (excluding `node_modules/`). If very few or no files exist, note this and draft minimal instructions.\n\n2. **Convention Analysis**: Read 3-5 representative style 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### 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",
|
|
446
|
+
"learn-template-correctness.md": "## 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 matching `**/*.html`, `**/*.jinja2`, `**/*.j2` in `templates/` and similar directories (excluding `node_modules/`). If very few or no files exist, note this and draft minimal instructions.\n\n2. **Convention Analysis**: Read 3-5 representative template 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### 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",
|
|
447
|
+
"learn-unit-testing.md": "## 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]` section, `jest.config.*`) and read `package.json` test scripts. Read the `tests/` directory structure.\n\n2. **Testing Patterns**: Read 3-5 representative test files in `tests/pytest/` 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**: Read `pyproject.toml`, `package.json`, and `Makefile` (if present) to determine exact commands for: full suite, single file, by name pattern, with verbose output.\n\n4. **Mocking vs. Fidelity**: Read test helper files in `tests/pytest/helpers/` to document how external APIs are mocked, whether integration tests exist alongside unit tests, and patterns for avoiding third-party calls in tests.\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
448
|
"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
449
|
"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
450
|
};
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@bridge_gpt/mcp-server",
|
|
3
|
-
"version": "0.1.
|
|
3
|
+
"version": "0.1.3",
|
|
4
4
|
"description": "Bridge API MCP server — exposes Jira endpoints as MCP tools for Claude Code agents",
|
|
5
5
|
"license": "MIT",
|
|
6
6
|
"type": "module",
|
|
@@ -10,11 +10,12 @@
|
|
|
10
10
|
"files": [
|
|
11
11
|
"build/",
|
|
12
12
|
"!build/pipeline-utils.test.js",
|
|
13
|
+
"pipelines/",
|
|
13
14
|
"README.md",
|
|
14
15
|
"LICENSE"
|
|
15
16
|
],
|
|
16
17
|
"scripts": {
|
|
17
|
-
"build": "node scripts/bundle-pipelines.js && tsc",
|
|
18
|
+
"build": "node scripts/bundle-pipelines.js && node scripts/bundle-commands.js && tsc",
|
|
18
19
|
"postbuild": "node scripts/prepend-shebang.cjs",
|
|
19
20
|
"start": "node build/index.js",
|
|
20
21
|
"test": "node --test build/pipeline-utils.test.js",
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "check-ci-ticket",
|
|
3
|
+
"description": "Commit changes, create a pull request, and monitor CI checks.",
|
|
4
|
+
"variables": ["ticket_key"],
|
|
5
|
+
"steps": [
|
|
6
|
+
{
|
|
7
|
+
"type": "mcp_call",
|
|
8
|
+
"tool": "ping",
|
|
9
|
+
"params": {},
|
|
10
|
+
"description": "Verify Bridge API connectivity"
|
|
11
|
+
},
|
|
12
|
+
{
|
|
13
|
+
"type": "agent_task",
|
|
14
|
+
"instruction_file": "commit-and-push.md",
|
|
15
|
+
"description": "Stage, commit, and push changes",
|
|
16
|
+
"requires_approval": true
|
|
17
|
+
},
|
|
18
|
+
{
|
|
19
|
+
"type": "mcp_call",
|
|
20
|
+
"tool": "create_pull_request",
|
|
21
|
+
"params": {
|
|
22
|
+
"head_branch": "feature/{ticket_key}",
|
|
23
|
+
"base_branch": "main",
|
|
24
|
+
"title": "{ticket_key}: Implementation"
|
|
25
|
+
},
|
|
26
|
+
"description": "Create a pull request",
|
|
27
|
+
"requires_approval": true
|
|
28
|
+
},
|
|
29
|
+
{
|
|
30
|
+
"type": "agent_task",
|
|
31
|
+
"instruction_file": "monitor-ci-checks.md",
|
|
32
|
+
"description": "Monitor CI checks and report results"
|
|
33
|
+
}
|
|
34
|
+
]
|
|
35
|
+
}
|
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "implement-ticket",
|
|
3
|
+
"description": "Generate plan, execute implementation, commit, open PR, and monitor CI.",
|
|
4
|
+
"variables": ["ticket_key", "docs_dir"],
|
|
5
|
+
"steps": [
|
|
6
|
+
{
|
|
7
|
+
"type": "mcp_call",
|
|
8
|
+
"tool": "ping",
|
|
9
|
+
"params": {},
|
|
10
|
+
"description": "Verify Bridge API connectivity"
|
|
11
|
+
},
|
|
12
|
+
{
|
|
13
|
+
"type": "mcp_call",
|
|
14
|
+
"tool": "request_plan_generation",
|
|
15
|
+
"params": {
|
|
16
|
+
"ticket_number": "{ticket_key}",
|
|
17
|
+
"wait_for_result": true,
|
|
18
|
+
"save_locally": true,
|
|
19
|
+
"provider": "{provider}"
|
|
20
|
+
},
|
|
21
|
+
"description": "Generate implementation plan"
|
|
22
|
+
},
|
|
23
|
+
{
|
|
24
|
+
"type": "agent_task",
|
|
25
|
+
"instruction_file": "execute-plan.md",
|
|
26
|
+
"description": "Execute the implementation plan"
|
|
27
|
+
},
|
|
28
|
+
{
|
|
29
|
+
"type": "agent_task",
|
|
30
|
+
"instruction_file": "commit-and-push.md",
|
|
31
|
+
"description": "Stage, commit, and push changes",
|
|
32
|
+
"requires_approval": true
|
|
33
|
+
},
|
|
34
|
+
{
|
|
35
|
+
"type": "mcp_call",
|
|
36
|
+
"tool": "create_pull_request",
|
|
37
|
+
"params": {
|
|
38
|
+
"head_branch": "feature/{ticket_key}",
|
|
39
|
+
"base_branch": "main",
|
|
40
|
+
"title": "{ticket_key}: Implementation"
|
|
41
|
+
},
|
|
42
|
+
"description": "Create a pull request",
|
|
43
|
+
"requires_approval": true
|
|
44
|
+
},
|
|
45
|
+
{
|
|
46
|
+
"type": "agent_task",
|
|
47
|
+
"instruction_file": "monitor-ci-checks.md",
|
|
48
|
+
"description": "Monitor CI checks and report results"
|
|
49
|
+
}
|
|
50
|
+
]
|
|
51
|
+
}
|