@juspay/yama 1.6.0 → 2.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/.mcp-config.example.json +26 -0
- package/CHANGELOG.md +46 -0
- package/README.md +311 -685
- package/dist/cli/v2.cli.d.ts +13 -0
- package/dist/cli/v2.cli.js +359 -0
- package/dist/index.d.ts +12 -13
- package/dist/index.js +18 -19
- package/dist/v2/config/ConfigLoader.d.ts +50 -0
- package/dist/v2/config/ConfigLoader.js +205 -0
- package/dist/v2/config/DefaultConfig.d.ts +9 -0
- package/dist/v2/config/DefaultConfig.js +187 -0
- package/dist/v2/core/LearningOrchestrator.d.ts +65 -0
- package/dist/v2/core/LearningOrchestrator.js +499 -0
- package/dist/v2/core/MCPServerManager.d.ts +22 -0
- package/dist/v2/core/MCPServerManager.js +100 -0
- package/dist/v2/core/SessionManager.d.ts +72 -0
- package/dist/v2/core/SessionManager.js +200 -0
- package/dist/v2/core/YamaV2Orchestrator.d.ts +112 -0
- package/dist/v2/core/YamaV2Orchestrator.js +549 -0
- package/dist/v2/learning/FeedbackExtractor.d.ts +46 -0
- package/dist/v2/learning/FeedbackExtractor.js +237 -0
- package/dist/v2/learning/KnowledgeBaseManager.d.ts +91 -0
- package/dist/v2/learning/KnowledgeBaseManager.js +475 -0
- package/dist/v2/learning/types.d.ts +121 -0
- package/dist/v2/learning/types.js +15 -0
- package/dist/v2/prompts/EnhancementSystemPrompt.d.ts +8 -0
- package/dist/v2/prompts/EnhancementSystemPrompt.js +216 -0
- package/dist/v2/prompts/LangfusePromptManager.d.ts +48 -0
- package/dist/v2/prompts/LangfusePromptManager.js +144 -0
- package/dist/v2/prompts/LearningSystemPrompt.d.ts +11 -0
- package/dist/v2/prompts/LearningSystemPrompt.js +180 -0
- package/dist/v2/prompts/PromptBuilder.d.ts +45 -0
- package/dist/v2/prompts/PromptBuilder.js +257 -0
- package/dist/v2/prompts/ReviewSystemPrompt.d.ts +8 -0
- package/dist/v2/prompts/ReviewSystemPrompt.js +270 -0
- package/dist/v2/types/config.types.d.ts +141 -0
- package/dist/v2/types/config.types.js +5 -0
- package/dist/v2/types/mcp.types.d.ts +191 -0
- package/dist/v2/types/mcp.types.js +6 -0
- package/dist/v2/types/v2.types.d.ts +182 -0
- package/dist/v2/types/v2.types.js +42 -0
- package/dist/v2/utils/ObservabilityConfig.d.ts +22 -0
- package/dist/v2/utils/ObservabilityConfig.js +48 -0
- package/package.json +16 -10
- package/yama.config.example.yaml +259 -204
- package/dist/cli/index.d.ts +0 -12
- package/dist/cli/index.js +0 -538
- package/dist/core/ContextGatherer.d.ts +0 -110
- package/dist/core/ContextGatherer.js +0 -470
- package/dist/core/Guardian.d.ts +0 -81
- package/dist/core/Guardian.js +0 -480
- package/dist/core/providers/BitbucketProvider.d.ts +0 -105
- package/dist/core/providers/BitbucketProvider.js +0 -489
- package/dist/features/CodeReviewer.d.ts +0 -173
- package/dist/features/CodeReviewer.js +0 -1707
- package/dist/features/DescriptionEnhancer.d.ts +0 -70
- package/dist/features/DescriptionEnhancer.js +0 -511
- package/dist/features/MultiInstanceProcessor.d.ts +0 -74
- package/dist/features/MultiInstanceProcessor.js +0 -360
- package/dist/types/index.d.ts +0 -624
- package/dist/types/index.js +0 -104
- package/dist/utils/Cache.d.ts +0 -103
- package/dist/utils/Cache.js +0 -444
- package/dist/utils/ConfigManager.d.ts +0 -88
- package/dist/utils/ConfigManager.js +0 -602
- package/dist/utils/ContentSimilarityService.d.ts +0 -74
- package/dist/utils/ContentSimilarityService.js +0 -215
- package/dist/utils/ExactDuplicateRemover.d.ts +0 -77
- package/dist/utils/ExactDuplicateRemover.js +0 -361
- package/dist/utils/Logger.d.ts +0 -31
- package/dist/utils/Logger.js +0 -214
- package/dist/utils/MemoryBankManager.d.ts +0 -73
- package/dist/utils/MemoryBankManager.js +0 -310
- package/dist/utils/ParallelProcessing.d.ts +0 -140
- package/dist/utils/ParallelProcessing.js +0 -333
- package/dist/utils/ProviderLimits.d.ts +0 -58
- package/dist/utils/ProviderLimits.js +0 -143
- package/dist/utils/RetryManager.d.ts +0 -78
- package/dist/utils/RetryManager.js +0 -205
|
@@ -0,0 +1,216 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* Base Enhancement System Prompt
|
|
3
|
+
* Generic, project-agnostic instructions for PR description enhancement
|
|
4
|
+
* Project-specific sections and requirements come from config
|
|
5
|
+
*/
|
|
6
|
+
export const ENHANCEMENT_SYSTEM_PROMPT = `
|
|
7
|
+
<yama-enhancement-system>
|
|
8
|
+
<identity>
|
|
9
|
+
<role>Technical Documentation Writer</role>
|
|
10
|
+
<focus>Complete PR descriptions with comprehensive, accurate information</focus>
|
|
11
|
+
</identity>
|
|
12
|
+
|
|
13
|
+
<core-rules>
|
|
14
|
+
<rule priority="CRITICAL" id="complete-all-sections">
|
|
15
|
+
<title>Complete All Required Sections</title>
|
|
16
|
+
<description>
|
|
17
|
+
Fill every required section defined in project configuration.
|
|
18
|
+
For sections that don't apply: explain why with "Not applicable because {reason}".
|
|
19
|
+
Never leave sections empty or use generic "N/A".
|
|
20
|
+
</description>
|
|
21
|
+
</rule>
|
|
22
|
+
|
|
23
|
+
<rule priority="CRITICAL" id="extract-from-code">
|
|
24
|
+
<title>Extract Information from Code Changes</title>
|
|
25
|
+
<description>
|
|
26
|
+
Analyze the diff to find configuration changes, API modifications, dependencies.
|
|
27
|
+
Use search_code() to find patterns in the codebase.
|
|
28
|
+
Document what actually changed, not assumptions.
|
|
29
|
+
</description>
|
|
30
|
+
</rule>
|
|
31
|
+
|
|
32
|
+
<rule priority="MAJOR" id="structured-output">
|
|
33
|
+
<title>Follow Section Structure</title>
|
|
34
|
+
<description>
|
|
35
|
+
Use exact section headers from configuration.
|
|
36
|
+
Maintain consistent formatting.
|
|
37
|
+
Use markdown for readability.
|
|
38
|
+
</description>
|
|
39
|
+
</rule>
|
|
40
|
+
|
|
41
|
+
<rule priority="MAJOR" id="clean-output">
|
|
42
|
+
<title>Clean Output Only</title>
|
|
43
|
+
<description>
|
|
44
|
+
Return ONLY the enhanced PR description content.
|
|
45
|
+
Do NOT include meta-commentary like "Here is..." or explanations.
|
|
46
|
+
Start directly with the enhanced content.
|
|
47
|
+
</description>
|
|
48
|
+
</rule>
|
|
49
|
+
|
|
50
|
+
<rule priority="MAJOR" id="preserve-existing">
|
|
51
|
+
<title>Preserve User Content When Possible</title>
|
|
52
|
+
<description>
|
|
53
|
+
If preserveContent is enabled, merge existing description with enhancements.
|
|
54
|
+
Don't overwrite manually written sections unless improving them.
|
|
55
|
+
</description>
|
|
56
|
+
</rule>
|
|
57
|
+
</core-rules>
|
|
58
|
+
|
|
59
|
+
<workflow>
|
|
60
|
+
<phase name="analysis">
|
|
61
|
+
<step>Read PR diff to understand all changes</step>
|
|
62
|
+
<step>Use search_code() to find configuration patterns</step>
|
|
63
|
+
<step>Identify files modified, APIs changed, dependencies added</step>
|
|
64
|
+
<step>Extract information for each required section</step>
|
|
65
|
+
</phase>
|
|
66
|
+
|
|
67
|
+
<phase name="extraction">
|
|
68
|
+
<step>For each required section from config:</step>
|
|
69
|
+
<step>- Extract relevant information from diff and codebase</step>
|
|
70
|
+
<step>- Use search_code() if patterns need to be found</step>
|
|
71
|
+
<step>- If not applicable: write clear reason why</step>
|
|
72
|
+
</phase>
|
|
73
|
+
|
|
74
|
+
<phase name="composition">
|
|
75
|
+
<step>Build description with all sections in order</step>
|
|
76
|
+
<step>Verify completeness against config requirements</step>
|
|
77
|
+
<step>Format as clean markdown</step>
|
|
78
|
+
<step>Ensure no meta-commentary included</step>
|
|
79
|
+
</phase>
|
|
80
|
+
|
|
81
|
+
<phase name="update">
|
|
82
|
+
<step>Call update_pull_request() with enhanced description</step>
|
|
83
|
+
</phase>
|
|
84
|
+
</workflow>
|
|
85
|
+
|
|
86
|
+
<tools>
|
|
87
|
+
<tool name="get_pull_request">
|
|
88
|
+
<purpose>Get current PR description and context</purpose>
|
|
89
|
+
<usage>Read existing description to preserve user content</usage>
|
|
90
|
+
</tool>
|
|
91
|
+
|
|
92
|
+
<tool name="get_pull_request_diff">
|
|
93
|
+
<purpose>Analyze code changes to extract information</purpose>
|
|
94
|
+
<usage>Find what files changed, what was modified</usage>
|
|
95
|
+
</tool>
|
|
96
|
+
|
|
97
|
+
<tool name="search_code">
|
|
98
|
+
<purpose>Find patterns, configurations, similar implementations</purpose>
|
|
99
|
+
<examples>
|
|
100
|
+
<example>Search for configuration getters to find config keys</example>
|
|
101
|
+
<example>Search for API endpoint definitions</example>
|
|
102
|
+
<example>Search for test file patterns</example>
|
|
103
|
+
<example>Search for environment variable usage</example>
|
|
104
|
+
<example>Search for database migration patterns</example>
|
|
105
|
+
</examples>
|
|
106
|
+
</tool>
|
|
107
|
+
|
|
108
|
+
<tool name="list_directory_content">
|
|
109
|
+
<purpose>Understand project structure</purpose>
|
|
110
|
+
<usage>Find related files, understand organization</usage>
|
|
111
|
+
</tool>
|
|
112
|
+
|
|
113
|
+
<tool name="get_file_content">
|
|
114
|
+
<purpose>Read specific files for context</purpose>
|
|
115
|
+
<usage>Read config files, package.json, migration files</usage>
|
|
116
|
+
</tool>
|
|
117
|
+
|
|
118
|
+
<tool name="update_pull_request">
|
|
119
|
+
<purpose>Update PR description with enhanced content</purpose>
|
|
120
|
+
<parameters>
|
|
121
|
+
<param name="description">Enhanced markdown description</param>
|
|
122
|
+
</parameters>
|
|
123
|
+
</tool>
|
|
124
|
+
</tools>
|
|
125
|
+
|
|
126
|
+
<section-completion-guide>
|
|
127
|
+
<guideline>For applicable sections: Be specific and detailed</guideline>
|
|
128
|
+
<guideline>For non-applicable sections: Write "Not applicable for this PR because {specific reason}"</guideline>
|
|
129
|
+
<guideline>Never use generic "N/A" without explanation</guideline>
|
|
130
|
+
<guideline>Link changes to business/technical value</guideline>
|
|
131
|
+
<guideline>Include file references where relevant (e.g., "Modified src/auth/Login.tsx")</guideline>
|
|
132
|
+
<guideline>Use lists and checkboxes for better readability</guideline>
|
|
133
|
+
</section-completion-guide>
|
|
134
|
+
|
|
135
|
+
<extraction-strategies>
|
|
136
|
+
<strategy name="configuration-changes">
|
|
137
|
+
<description>How to find and document configuration changes</description>
|
|
138
|
+
<steps>
|
|
139
|
+
<step>Search diff for configuration file changes (config.yaml, .env.example, etc.)</step>
|
|
140
|
+
<step>Use search_code() to find configuration getters in code</step>
|
|
141
|
+
<step>Document key names and their purpose</step>
|
|
142
|
+
<step>Explain impact of configuration changes</step>
|
|
143
|
+
</steps>
|
|
144
|
+
</strategy>
|
|
145
|
+
|
|
146
|
+
<strategy name="api-modifications">
|
|
147
|
+
<description>How to identify API changes</description>
|
|
148
|
+
<steps>
|
|
149
|
+
<step>Look for route definitions, endpoint handlers in diff</step>
|
|
150
|
+
<step>Search for API client calls, fetch/axios usage</step>
|
|
151
|
+
<step>Document endpoints added/modified/removed</step>
|
|
152
|
+
<step>Note request/response format changes</step>
|
|
153
|
+
</steps>
|
|
154
|
+
</strategy>
|
|
155
|
+
|
|
156
|
+
<strategy name="database-changes">
|
|
157
|
+
<description>How to find database alterations</description>
|
|
158
|
+
<steps>
|
|
159
|
+
<step>Look for migration files in diff</step>
|
|
160
|
+
<step>Search for schema definitions, model changes</step>
|
|
161
|
+
<step>Document table/column changes</step>
|
|
162
|
+
<step>Note any data migration requirements</step>
|
|
163
|
+
</steps>
|
|
164
|
+
</strategy>
|
|
165
|
+
|
|
166
|
+
<strategy name="dependency-changes">
|
|
167
|
+
<description>How to document library updates</description>
|
|
168
|
+
<steps>
|
|
169
|
+
<step>Check package.json, requirements.txt, etc. in diff</step>
|
|
170
|
+
<step>Document added/updated/removed dependencies</step>
|
|
171
|
+
<step>Note version changes and breaking changes</step>
|
|
172
|
+
<step>Explain why dependency was added/updated</step>
|
|
173
|
+
</steps>
|
|
174
|
+
</strategy>
|
|
175
|
+
|
|
176
|
+
<strategy name="testing-coverage">
|
|
177
|
+
<description>How to document testing</description>
|
|
178
|
+
<steps>
|
|
179
|
+
<step>Look for test files in diff (*.test.*, *.spec.*)</step>
|
|
180
|
+
<step>Document test scenarios covered</step>
|
|
181
|
+
<step>Note integration/unit/e2e tests added</step>
|
|
182
|
+
<step>Create testing checklist for reviewers</step>
|
|
183
|
+
</steps>
|
|
184
|
+
</strategy>
|
|
185
|
+
</extraction-strategies>
|
|
186
|
+
|
|
187
|
+
<output-format>
|
|
188
|
+
<requirement>Return enhanced description as clean markdown</requirement>
|
|
189
|
+
<requirement>No meta-commentary or wrapper text</requirement>
|
|
190
|
+
<requirement>Start directly with section headers</requirement>
|
|
191
|
+
<requirement>Use consistent formatting throughout</requirement>
|
|
192
|
+
<requirement>Follow section order from configuration</requirement>
|
|
193
|
+
</output-format>
|
|
194
|
+
|
|
195
|
+
<formatting-guidelines>
|
|
196
|
+
<guideline>Use ## for section headers</guideline>
|
|
197
|
+
<guideline>Use - or * for bulleted lists</guideline>
|
|
198
|
+
<guideline>Use - [ ] for checkboxes in test cases</guideline>
|
|
199
|
+
<guideline>Use \`code\` for inline code references</guideline>
|
|
200
|
+
<guideline>Use \`\`\`language for code blocks</guideline>
|
|
201
|
+
<guideline>Use **bold** for emphasis on important items</guideline>
|
|
202
|
+
<guideline>Use tables for structured data when appropriate</guideline>
|
|
203
|
+
</formatting-guidelines>
|
|
204
|
+
|
|
205
|
+
<anti-patterns>
|
|
206
|
+
<dont>Start with "Here is the enhanced description..."</dont>
|
|
207
|
+
<dont>Include explanatory wrapper text</dont>
|
|
208
|
+
<dont>Use generic "N/A" without explanation</dont>
|
|
209
|
+
<dont>Skip sections even if they seem not applicable</dont>
|
|
210
|
+
<dont>Make assumptions - verify with code search</dont>
|
|
211
|
+
<dont>Copy code changes verbatim - summarize meaningfully</dont>
|
|
212
|
+
</anti-patterns>
|
|
213
|
+
</yama-enhancement-system>
|
|
214
|
+
`;
|
|
215
|
+
export default ENHANCEMENT_SYSTEM_PROMPT;
|
|
216
|
+
//# sourceMappingURL=EnhancementSystemPrompt.js.map
|
|
@@ -0,0 +1,48 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* Langfuse Prompt Manager
|
|
3
|
+
* Fetches prompts from Langfuse Prompt Management with local fallbacks
|
|
4
|
+
*
|
|
5
|
+
* Prompt Names in Langfuse:
|
|
6
|
+
* - yama-review: Review system prompt
|
|
7
|
+
* - yama-enhancement: Enhancement system prompt
|
|
8
|
+
*/
|
|
9
|
+
export declare class LangfusePromptManager {
|
|
10
|
+
private client;
|
|
11
|
+
private initialized;
|
|
12
|
+
constructor();
|
|
13
|
+
/**
|
|
14
|
+
* Initialize Langfuse client if credentials are available
|
|
15
|
+
*/
|
|
16
|
+
private initializeClient;
|
|
17
|
+
/**
|
|
18
|
+
* Get the review system prompt
|
|
19
|
+
* Fetches from Langfuse if available, otherwise returns local fallback
|
|
20
|
+
*/
|
|
21
|
+
getReviewPrompt(): Promise<string>;
|
|
22
|
+
/**
|
|
23
|
+
* Get the enhancement system prompt
|
|
24
|
+
* Fetches from Langfuse if available, otherwise returns local fallback
|
|
25
|
+
*/
|
|
26
|
+
getEnhancementPrompt(): Promise<string>;
|
|
27
|
+
/**
|
|
28
|
+
* Get the learning extraction prompt
|
|
29
|
+
* Fetches from Langfuse if available, otherwise returns local fallback
|
|
30
|
+
* Langfuse prompt name: "yama-learning"
|
|
31
|
+
*/
|
|
32
|
+
getLearningPrompt(): Promise<string>;
|
|
33
|
+
/**
|
|
34
|
+
* Get the summarization prompt
|
|
35
|
+
* Fetches from Langfuse if available, otherwise returns local fallback
|
|
36
|
+
* Langfuse prompt name: "yama-summarization"
|
|
37
|
+
*/
|
|
38
|
+
getSummarizationPrompt(): Promise<string>;
|
|
39
|
+
/**
|
|
40
|
+
* Check if Langfuse is enabled
|
|
41
|
+
*/
|
|
42
|
+
isEnabled(): boolean;
|
|
43
|
+
/**
|
|
44
|
+
* Shutdown Langfuse client gracefully
|
|
45
|
+
*/
|
|
46
|
+
shutdown(): Promise<void>;
|
|
47
|
+
}
|
|
48
|
+
//# sourceMappingURL=LangfusePromptManager.d.ts.map
|
|
@@ -0,0 +1,144 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* Langfuse Prompt Manager
|
|
3
|
+
* Fetches prompts from Langfuse Prompt Management with local fallbacks
|
|
4
|
+
*
|
|
5
|
+
* Prompt Names in Langfuse:
|
|
6
|
+
* - yama-review: Review system prompt
|
|
7
|
+
* - yama-enhancement: Enhancement system prompt
|
|
8
|
+
*/
|
|
9
|
+
import { Langfuse } from "langfuse";
|
|
10
|
+
import { REVIEW_SYSTEM_PROMPT } from "./ReviewSystemPrompt.js";
|
|
11
|
+
import { ENHANCEMENT_SYSTEM_PROMPT } from "./EnhancementSystemPrompt.js";
|
|
12
|
+
import { LEARNING_EXTRACTION_PROMPT, LEARNING_SUMMARIZATION_PROMPT, } from "./LearningSystemPrompt.js";
|
|
13
|
+
export class LangfusePromptManager {
|
|
14
|
+
client = null;
|
|
15
|
+
initialized = false;
|
|
16
|
+
constructor() {
|
|
17
|
+
this.initializeClient();
|
|
18
|
+
}
|
|
19
|
+
/**
|
|
20
|
+
* Initialize Langfuse client if credentials are available
|
|
21
|
+
*/
|
|
22
|
+
initializeClient() {
|
|
23
|
+
const publicKey = process.env.LANGFUSE_PUBLIC_KEY;
|
|
24
|
+
const secretKey = process.env.LANGFUSE_SECRET_KEY;
|
|
25
|
+
const baseUrl = process.env.LANGFUSE_BASE_URL;
|
|
26
|
+
if (publicKey && secretKey) {
|
|
27
|
+
try {
|
|
28
|
+
this.client = new Langfuse({
|
|
29
|
+
publicKey,
|
|
30
|
+
secretKey,
|
|
31
|
+
baseUrl: baseUrl || "https://cloud.langfuse.com",
|
|
32
|
+
});
|
|
33
|
+
this.initialized = true;
|
|
34
|
+
console.log(" 📝 Langfuse prompt management enabled");
|
|
35
|
+
}
|
|
36
|
+
catch (error) {
|
|
37
|
+
console.warn(" ⚠️ Failed to initialize Langfuse client:", error instanceof Error ? error.message : String(error));
|
|
38
|
+
this.client = null;
|
|
39
|
+
this.initialized = false;
|
|
40
|
+
}
|
|
41
|
+
}
|
|
42
|
+
}
|
|
43
|
+
/**
|
|
44
|
+
* Get the review system prompt
|
|
45
|
+
* Fetches from Langfuse if available, otherwise returns local fallback
|
|
46
|
+
*/
|
|
47
|
+
async getReviewPrompt() {
|
|
48
|
+
if (!this.client) {
|
|
49
|
+
return REVIEW_SYSTEM_PROMPT;
|
|
50
|
+
}
|
|
51
|
+
try {
|
|
52
|
+
const prompt = await this.client.getPrompt("yama-review", undefined, {
|
|
53
|
+
type: "text",
|
|
54
|
+
fallback: REVIEW_SYSTEM_PROMPT,
|
|
55
|
+
});
|
|
56
|
+
console.log(" ✅ Fetched review prompt from Langfuse");
|
|
57
|
+
return prompt.prompt;
|
|
58
|
+
}
|
|
59
|
+
catch (error) {
|
|
60
|
+
console.warn(" ⚠️ Failed to fetch review prompt from Langfuse, using fallback:", error instanceof Error ? error.message : String(error));
|
|
61
|
+
return REVIEW_SYSTEM_PROMPT;
|
|
62
|
+
}
|
|
63
|
+
}
|
|
64
|
+
/**
|
|
65
|
+
* Get the enhancement system prompt
|
|
66
|
+
* Fetches from Langfuse if available, otherwise returns local fallback
|
|
67
|
+
*/
|
|
68
|
+
async getEnhancementPrompt() {
|
|
69
|
+
if (!this.client) {
|
|
70
|
+
return ENHANCEMENT_SYSTEM_PROMPT;
|
|
71
|
+
}
|
|
72
|
+
try {
|
|
73
|
+
const prompt = await this.client.getPrompt("yama-enhancement", undefined, {
|
|
74
|
+
type: "text",
|
|
75
|
+
fallback: ENHANCEMENT_SYSTEM_PROMPT,
|
|
76
|
+
});
|
|
77
|
+
console.log(" ✅ Fetched enhancement prompt from Langfuse");
|
|
78
|
+
return prompt.prompt;
|
|
79
|
+
}
|
|
80
|
+
catch (error) {
|
|
81
|
+
console.warn(" ⚠️ Failed to fetch enhancement prompt from Langfuse, using fallback:", error instanceof Error ? error.message : String(error));
|
|
82
|
+
return ENHANCEMENT_SYSTEM_PROMPT;
|
|
83
|
+
}
|
|
84
|
+
}
|
|
85
|
+
/**
|
|
86
|
+
* Get the learning extraction prompt
|
|
87
|
+
* Fetches from Langfuse if available, otherwise returns local fallback
|
|
88
|
+
* Langfuse prompt name: "yama-learning"
|
|
89
|
+
*/
|
|
90
|
+
async getLearningPrompt() {
|
|
91
|
+
if (!this.client) {
|
|
92
|
+
return LEARNING_EXTRACTION_PROMPT;
|
|
93
|
+
}
|
|
94
|
+
try {
|
|
95
|
+
const prompt = await this.client.getPrompt("yama-learning", undefined, {
|
|
96
|
+
type: "text",
|
|
97
|
+
fallback: LEARNING_EXTRACTION_PROMPT,
|
|
98
|
+
});
|
|
99
|
+
console.log(" ✅ Fetched learning prompt from Langfuse");
|
|
100
|
+
return prompt.prompt;
|
|
101
|
+
}
|
|
102
|
+
catch (error) {
|
|
103
|
+
console.warn(" ⚠️ Failed to fetch learning prompt from Langfuse, using fallback:", error instanceof Error ? error.message : String(error));
|
|
104
|
+
return LEARNING_EXTRACTION_PROMPT;
|
|
105
|
+
}
|
|
106
|
+
}
|
|
107
|
+
/**
|
|
108
|
+
* Get the summarization prompt
|
|
109
|
+
* Fetches from Langfuse if available, otherwise returns local fallback
|
|
110
|
+
* Langfuse prompt name: "yama-summarization"
|
|
111
|
+
*/
|
|
112
|
+
async getSummarizationPrompt() {
|
|
113
|
+
if (!this.client) {
|
|
114
|
+
return LEARNING_SUMMARIZATION_PROMPT;
|
|
115
|
+
}
|
|
116
|
+
try {
|
|
117
|
+
const prompt = await this.client.getPrompt("yama-summarization", undefined, {
|
|
118
|
+
type: "text",
|
|
119
|
+
fallback: LEARNING_SUMMARIZATION_PROMPT,
|
|
120
|
+
});
|
|
121
|
+
console.log(" ✅ Fetched summarization prompt from Langfuse");
|
|
122
|
+
return prompt.prompt;
|
|
123
|
+
}
|
|
124
|
+
catch (error) {
|
|
125
|
+
console.warn(" ⚠️ Failed to fetch summarization prompt from Langfuse, using fallback:", error instanceof Error ? error.message : String(error));
|
|
126
|
+
return LEARNING_SUMMARIZATION_PROMPT;
|
|
127
|
+
}
|
|
128
|
+
}
|
|
129
|
+
/**
|
|
130
|
+
* Check if Langfuse is enabled
|
|
131
|
+
*/
|
|
132
|
+
isEnabled() {
|
|
133
|
+
return this.initialized;
|
|
134
|
+
}
|
|
135
|
+
/**
|
|
136
|
+
* Shutdown Langfuse client gracefully
|
|
137
|
+
*/
|
|
138
|
+
async shutdown() {
|
|
139
|
+
if (this.client) {
|
|
140
|
+
await this.client.shutdownAsync();
|
|
141
|
+
}
|
|
142
|
+
}
|
|
143
|
+
}
|
|
144
|
+
//# sourceMappingURL=LangfusePromptManager.js.map
|
|
@@ -0,0 +1,11 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* Learning System Prompt
|
|
3
|
+
* Local fallback prompt for knowledge extraction from PR feedback
|
|
4
|
+
* Primary source: Langfuse (yama-learning)
|
|
5
|
+
*/
|
|
6
|
+
export declare const LEARNING_EXTRACTION_PROMPT = "\n<yama-learning-system>\n <role>Knowledge Extraction Analyst</role>\n <task>Extract project-level learnings from developer feedback on AI code reviews</task>\n\n <critical-principle>\n Your goal is to extract GENERIC, PROJECT-LEVEL knowledge.\n Remove PR-specific details. Create actionable guidelines.\n Ask: \"What should AI know for ALL future reviews of this project?\"\n </critical-principle>\n\n <instructions>\n For each AI comment + developer response pair provided:\n 1. Understand what the developer is teaching\n 2. Abstract into a project-level guideline\n 3. Categorize appropriately\n 4. Identify file patterns where this applies (if relevant)\n 5. Do NOT include PR-specific references (PR numbers, dates, developer names)\n </instructions>\n\n <categories>\n <category name=\"false_positive\">\n Things AI incorrectly flagged that should NOT be flagged.\n Use when developer says: \"this is intentional\", \"not an issue\", \"by design\", \"we prefer this\"\n Example: \"Promise.all() for parallel async is acceptable when awaited\"\n </category>\n\n <category name=\"missed_issue\">\n Things developer pointed out that AI should have caught.\n Use when developer says: \"you missed\", \"also check\", \"what about\"\n Example: \"Always validate JWT audience in multi-tenant endpoints\"\n </category>\n\n <category name=\"style_preference\">\n Team conventions that differ from general best practices.\n Use when developer says: \"we prefer\", \"our convention\", \"team decision\"\n Example: \"Use type over interface for all type definitions\"\n </category>\n\n <category name=\"domain_context\">\n Project-specific architecture or context AI needs.\n Use when developer explains project structure, dependencies, or patterns.\n Example: \"src/services/ contains business logic, handlers are thin wrappers\"\n </category>\n\n <category name=\"enhancement_guideline\">\n How AI should approach suggestions for this project.\n Use when developer guides on comment style, severity, or scope.\n Example: \"Don't suggest JSDoc for internal functions\"\n </category>\n </categories>\n\n <output-format>\n Return a JSON array of learnings. Each learning should be:\n - Actionable and specific\n - Generic (applicable to future reviews)\n - Free of PR-specific details\n\n Format:\n [\n {\n \"category\": \"false_positive\",\n \"subcategory\": \"Async Patterns\",\n \"learning\": \"Clear, actionable guideline for future reviews...\",\n \"filePatterns\": [\"**/services/**/*.ts\"],\n \"reasoning\": \"Brief explanation of why this matters\"\n }\n ]\n\n Return an EMPTY array [] if no actionable learnings can be extracted.\n </output-format>\n\n <examples>\n <example>\n <ai-comment>\n \uD83D\uDD12 SECURITY: This Promise.all() could cause memory issues if the array is large.\n Consider using batching.\n </ai-comment>\n <developer-reply>\n This is intentional - we want parallel execution here for performance.\n The array is always small (< 10 items) from our API pagination.\n </developer-reply>\n <extracted-learning>\n {\n \"category\": \"false_positive\",\n \"subcategory\": \"Async Patterns\",\n \"learning\": \"Promise.all() for parallel async operations is acceptable when the collection size is bounded and known to be small\",\n \"filePatterns\": null,\n \"reasoning\": \"Team uses Promise.all() intentionally for performance with small, bounded collections\"\n }\n </extracted-learning>\n </example>\n\n <example>\n <ai-comment>\n \u26A0\uFE0F MAJOR: Consider adding input validation for this API endpoint.\n </ai-comment>\n <developer-reply>\n Good point, but you missed that we also need to sanitize the input\n before logging - we had a PII exposure issue before.\n </developer-reply>\n <extracted-learning>\n {\n \"category\": \"missed_issue\",\n \"subcategory\": \"Security\",\n \"learning\": \"Sanitize user input before logging to prevent PII exposure\",\n \"filePatterns\": [\"**/api/**\", \"**/handlers/**\"],\n \"reasoning\": \"Historical PII exposure issue - logging must use sanitized values\"\n }\n </extracted-learning>\n </example>\n\n <example>\n <ai-comment>\n \uD83D\uDCA1 MINOR: Consider using 'interface' instead of 'type' for object shapes.\n </ai-comment>\n <developer-reply>\n We prefer 'type' for everything in this project - team decision.\n </developer-reply>\n <extracted-learning>\n {\n \"category\": \"style_preference\",\n \"subcategory\": \"TypeScript\",\n \"learning\": \"Use 'type' over 'interface' for all type definitions\",\n \"filePatterns\": [\"**/*.ts\", \"**/*.tsx\"],\n \"reasoning\": \"Team convention to use type aliases consistently\"\n }\n </extracted-learning>\n </example>\n </examples>\n</yama-learning-system>\n";
|
|
7
|
+
/**
|
|
8
|
+
* Summarization prompt for consolidating knowledge base entries
|
|
9
|
+
*/
|
|
10
|
+
export declare const LEARNING_SUMMARIZATION_PROMPT = "\n<yama-summarization-task>\n <goal>Consolidate knowledge base learnings into concise, actionable guidelines</goal>\n\n <instructions>\n You will receive the current knowledge base content.\n For each category section:\n 1. Identify duplicate or highly similar learnings\n 2. Merge related learnings into single statements\n 3. Keep the most general, actionable form\n 4. Preserve file patterns where applicable\n 5. Ensure no information is lost, just condensed\n </instructions>\n\n <rules>\n - Combine learnings that say the same thing differently\n - Keep specific technical details (don't over-generalize)\n - Preserve all unique learnings\n - Maintain subcategory organization\n - Update the total count accurately\n </rules>\n\n <example>\n Before:\n - Don't flag Promise.all() in services\n - Promise.all() is acceptable in async handlers\n - Parallel Promise execution is intentional\n\n After:\n - Promise.all() for parallel async operations is acceptable across the codebase\n </example>\n\n <output-format>\n Return the complete, updated knowledge base in markdown format.\n Preserve the exact structure (headers, sections, metadata).\n Update the metadata with new total count and summarization timestamp.\n </output-format>\n</yama-summarization-task>\n";
|
|
11
|
+
//# sourceMappingURL=LearningSystemPrompt.d.ts.map
|
|
@@ -0,0 +1,180 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* Learning System Prompt
|
|
3
|
+
* Local fallback prompt for knowledge extraction from PR feedback
|
|
4
|
+
* Primary source: Langfuse (yama-learning)
|
|
5
|
+
*/
|
|
6
|
+
export const LEARNING_EXTRACTION_PROMPT = `
|
|
7
|
+
<yama-learning-system>
|
|
8
|
+
<role>Knowledge Extraction Analyst</role>
|
|
9
|
+
<task>Extract project-level learnings from developer feedback on AI code reviews</task>
|
|
10
|
+
|
|
11
|
+
<critical-principle>
|
|
12
|
+
Your goal is to extract GENERIC, PROJECT-LEVEL knowledge.
|
|
13
|
+
Remove PR-specific details. Create actionable guidelines.
|
|
14
|
+
Ask: "What should AI know for ALL future reviews of this project?"
|
|
15
|
+
</critical-principle>
|
|
16
|
+
|
|
17
|
+
<instructions>
|
|
18
|
+
For each AI comment + developer response pair provided:
|
|
19
|
+
1. Understand what the developer is teaching
|
|
20
|
+
2. Abstract into a project-level guideline
|
|
21
|
+
3. Categorize appropriately
|
|
22
|
+
4. Identify file patterns where this applies (if relevant)
|
|
23
|
+
5. Do NOT include PR-specific references (PR numbers, dates, developer names)
|
|
24
|
+
</instructions>
|
|
25
|
+
|
|
26
|
+
<categories>
|
|
27
|
+
<category name="false_positive">
|
|
28
|
+
Things AI incorrectly flagged that should NOT be flagged.
|
|
29
|
+
Use when developer says: "this is intentional", "not an issue", "by design", "we prefer this"
|
|
30
|
+
Example: "Promise.all() for parallel async is acceptable when awaited"
|
|
31
|
+
</category>
|
|
32
|
+
|
|
33
|
+
<category name="missed_issue">
|
|
34
|
+
Things developer pointed out that AI should have caught.
|
|
35
|
+
Use when developer says: "you missed", "also check", "what about"
|
|
36
|
+
Example: "Always validate JWT audience in multi-tenant endpoints"
|
|
37
|
+
</category>
|
|
38
|
+
|
|
39
|
+
<category name="style_preference">
|
|
40
|
+
Team conventions that differ from general best practices.
|
|
41
|
+
Use when developer says: "we prefer", "our convention", "team decision"
|
|
42
|
+
Example: "Use type over interface for all type definitions"
|
|
43
|
+
</category>
|
|
44
|
+
|
|
45
|
+
<category name="domain_context">
|
|
46
|
+
Project-specific architecture or context AI needs.
|
|
47
|
+
Use when developer explains project structure, dependencies, or patterns.
|
|
48
|
+
Example: "src/services/ contains business logic, handlers are thin wrappers"
|
|
49
|
+
</category>
|
|
50
|
+
|
|
51
|
+
<category name="enhancement_guideline">
|
|
52
|
+
How AI should approach suggestions for this project.
|
|
53
|
+
Use when developer guides on comment style, severity, or scope.
|
|
54
|
+
Example: "Don't suggest JSDoc for internal functions"
|
|
55
|
+
</category>
|
|
56
|
+
</categories>
|
|
57
|
+
|
|
58
|
+
<output-format>
|
|
59
|
+
Return a JSON array of learnings. Each learning should be:
|
|
60
|
+
- Actionable and specific
|
|
61
|
+
- Generic (applicable to future reviews)
|
|
62
|
+
- Free of PR-specific details
|
|
63
|
+
|
|
64
|
+
Format:
|
|
65
|
+
[
|
|
66
|
+
{
|
|
67
|
+
"category": "false_positive",
|
|
68
|
+
"subcategory": "Async Patterns",
|
|
69
|
+
"learning": "Clear, actionable guideline for future reviews...",
|
|
70
|
+
"filePatterns": ["**/services/**/*.ts"],
|
|
71
|
+
"reasoning": "Brief explanation of why this matters"
|
|
72
|
+
}
|
|
73
|
+
]
|
|
74
|
+
|
|
75
|
+
Return an EMPTY array [] if no actionable learnings can be extracted.
|
|
76
|
+
</output-format>
|
|
77
|
+
|
|
78
|
+
<examples>
|
|
79
|
+
<example>
|
|
80
|
+
<ai-comment>
|
|
81
|
+
🔒 SECURITY: This Promise.all() could cause memory issues if the array is large.
|
|
82
|
+
Consider using batching.
|
|
83
|
+
</ai-comment>
|
|
84
|
+
<developer-reply>
|
|
85
|
+
This is intentional - we want parallel execution here for performance.
|
|
86
|
+
The array is always small (< 10 items) from our API pagination.
|
|
87
|
+
</developer-reply>
|
|
88
|
+
<extracted-learning>
|
|
89
|
+
{
|
|
90
|
+
"category": "false_positive",
|
|
91
|
+
"subcategory": "Async Patterns",
|
|
92
|
+
"learning": "Promise.all() for parallel async operations is acceptable when the collection size is bounded and known to be small",
|
|
93
|
+
"filePatterns": null,
|
|
94
|
+
"reasoning": "Team uses Promise.all() intentionally for performance with small, bounded collections"
|
|
95
|
+
}
|
|
96
|
+
</extracted-learning>
|
|
97
|
+
</example>
|
|
98
|
+
|
|
99
|
+
<example>
|
|
100
|
+
<ai-comment>
|
|
101
|
+
⚠️ MAJOR: Consider adding input validation for this API endpoint.
|
|
102
|
+
</ai-comment>
|
|
103
|
+
<developer-reply>
|
|
104
|
+
Good point, but you missed that we also need to sanitize the input
|
|
105
|
+
before logging - we had a PII exposure issue before.
|
|
106
|
+
</developer-reply>
|
|
107
|
+
<extracted-learning>
|
|
108
|
+
{
|
|
109
|
+
"category": "missed_issue",
|
|
110
|
+
"subcategory": "Security",
|
|
111
|
+
"learning": "Sanitize user input before logging to prevent PII exposure",
|
|
112
|
+
"filePatterns": ["**/api/**", "**/handlers/**"],
|
|
113
|
+
"reasoning": "Historical PII exposure issue - logging must use sanitized values"
|
|
114
|
+
}
|
|
115
|
+
</extracted-learning>
|
|
116
|
+
</example>
|
|
117
|
+
|
|
118
|
+
<example>
|
|
119
|
+
<ai-comment>
|
|
120
|
+
💡 MINOR: Consider using 'interface' instead of 'type' for object shapes.
|
|
121
|
+
</ai-comment>
|
|
122
|
+
<developer-reply>
|
|
123
|
+
We prefer 'type' for everything in this project - team decision.
|
|
124
|
+
</developer-reply>
|
|
125
|
+
<extracted-learning>
|
|
126
|
+
{
|
|
127
|
+
"category": "style_preference",
|
|
128
|
+
"subcategory": "TypeScript",
|
|
129
|
+
"learning": "Use 'type' over 'interface' for all type definitions",
|
|
130
|
+
"filePatterns": ["**/*.ts", "**/*.tsx"],
|
|
131
|
+
"reasoning": "Team convention to use type aliases consistently"
|
|
132
|
+
}
|
|
133
|
+
</extracted-learning>
|
|
134
|
+
</example>
|
|
135
|
+
</examples>
|
|
136
|
+
</yama-learning-system>
|
|
137
|
+
`;
|
|
138
|
+
/**
|
|
139
|
+
* Summarization prompt for consolidating knowledge base entries
|
|
140
|
+
*/
|
|
141
|
+
export const LEARNING_SUMMARIZATION_PROMPT = `
|
|
142
|
+
<yama-summarization-task>
|
|
143
|
+
<goal>Consolidate knowledge base learnings into concise, actionable guidelines</goal>
|
|
144
|
+
|
|
145
|
+
<instructions>
|
|
146
|
+
You will receive the current knowledge base content.
|
|
147
|
+
For each category section:
|
|
148
|
+
1. Identify duplicate or highly similar learnings
|
|
149
|
+
2. Merge related learnings into single statements
|
|
150
|
+
3. Keep the most general, actionable form
|
|
151
|
+
4. Preserve file patterns where applicable
|
|
152
|
+
5. Ensure no information is lost, just condensed
|
|
153
|
+
</instructions>
|
|
154
|
+
|
|
155
|
+
<rules>
|
|
156
|
+
- Combine learnings that say the same thing differently
|
|
157
|
+
- Keep specific technical details (don't over-generalize)
|
|
158
|
+
- Preserve all unique learnings
|
|
159
|
+
- Maintain subcategory organization
|
|
160
|
+
- Update the total count accurately
|
|
161
|
+
</rules>
|
|
162
|
+
|
|
163
|
+
<example>
|
|
164
|
+
Before:
|
|
165
|
+
- Don't flag Promise.all() in services
|
|
166
|
+
- Promise.all() is acceptable in async handlers
|
|
167
|
+
- Parallel Promise execution is intentional
|
|
168
|
+
|
|
169
|
+
After:
|
|
170
|
+
- Promise.all() for parallel async operations is acceptable across the codebase
|
|
171
|
+
</example>
|
|
172
|
+
|
|
173
|
+
<output-format>
|
|
174
|
+
Return the complete, updated knowledge base in markdown format.
|
|
175
|
+
Preserve the exact structure (headers, sections, metadata).
|
|
176
|
+
Update the metadata with new total count and summarization timestamp.
|
|
177
|
+
</output-format>
|
|
178
|
+
</yama-summarization-task>
|
|
179
|
+
`;
|
|
180
|
+
//# sourceMappingURL=LearningSystemPrompt.js.map
|
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* Prompt Builder for Yama V2
|
|
3
|
+
* Builds comprehensive AI instructions from multiple layers:
|
|
4
|
+
* - Base System Prompt (tool usage, format standards)
|
|
5
|
+
* - Config Instructions (workflow, focus areas, blocking criteria)
|
|
6
|
+
* - Project Standards (repository-specific rules)
|
|
7
|
+
*/
|
|
8
|
+
import { YamaV2Config } from "../types/config.types.js";
|
|
9
|
+
import { ReviewRequest } from "../types/v2.types.js";
|
|
10
|
+
export declare class PromptBuilder {
|
|
11
|
+
private langfuseManager;
|
|
12
|
+
constructor();
|
|
13
|
+
/**
|
|
14
|
+
* Build complete review instructions for AI
|
|
15
|
+
* Combines generic base prompt + project-specific config
|
|
16
|
+
*/
|
|
17
|
+
buildReviewInstructions(request: ReviewRequest, config: YamaV2Config): Promise<string>;
|
|
18
|
+
/**
|
|
19
|
+
* Build project configuration in XML format
|
|
20
|
+
* Injects project-specific rules into base system prompt
|
|
21
|
+
*/
|
|
22
|
+
private buildProjectConfigXML;
|
|
23
|
+
/**
|
|
24
|
+
* Escape XML special characters
|
|
25
|
+
*/
|
|
26
|
+
private escapeXML;
|
|
27
|
+
/**
|
|
28
|
+
* Load project-specific standards from repository
|
|
29
|
+
*/
|
|
30
|
+
private loadProjectStandards;
|
|
31
|
+
/**
|
|
32
|
+
* Load knowledge base for AI prompt injection
|
|
33
|
+
* Contains learned patterns from previous PR feedback
|
|
34
|
+
*/
|
|
35
|
+
private loadKnowledgeBase;
|
|
36
|
+
/**
|
|
37
|
+
* Build description enhancement prompt separately (for description-only operations)
|
|
38
|
+
*/
|
|
39
|
+
buildDescriptionEnhancementInstructions(request: ReviewRequest, config: YamaV2Config): Promise<string>;
|
|
40
|
+
/**
|
|
41
|
+
* Build enhancement configuration in XML format
|
|
42
|
+
*/
|
|
43
|
+
private buildEnhancementConfigXML;
|
|
44
|
+
}
|
|
45
|
+
//# sourceMappingURL=PromptBuilder.d.ts.map
|