|
15 | 15 | """ |
16 | 16 |
|
17 | 17 | WORK_SUMMARY_PROMPT = """ |
18 | | -Generate a user-friendly summary of the provided git diff for non-technical stakeholders. |
| 18 | +Generate a concise summary of the provided git diff for daily/weekly standup reports. |
19 | 19 | |
20 | 20 | OUTPUT Format: |
21 | 21 | {{ |
22 | | - "summary": "<SUMMARY_OF_WORK_DONE>", |
23 | | - "details": ["<IMPORTANT_DETAILS>", ...], |
24 | | - "todo": ["<TODO_ITEMS>", ...], |
25 | | - "future_considerations": ["<THINGS_TO_CONSIDER_IN_FUTURE>", ...], |
26 | | - "estimated_time": <ESTIMATED_TIME_IN_HOURS> |
| 22 | + "summary": "<BRIEF_SUMMARY_OF_WORK_DONE>", |
| 23 | + "details": ["<COMPLETED_TASK>", ...], |
| 24 | + "in_progress": ["<IN_PROGRESS_TASK>", ...], |
| 25 | + "blockers": ["<BLOCKER>", ...], |
| 26 | + "future_considerations": ["<NEXT_STEP>", ...], |
| 27 | + "estimated_time": "<ESTIMATED_TIME_IN_HOURS>" |
27 | 28 | }} |
28 | 29 |
|
29 | | -estimated_time: its the range of time you think the above work might have taken for a developer. example "10-15hrs" |
30 | | -details: its list of changes in human readable term so that anyone can understand how the software has been impacted. |
| 30 | +estimated_time_spent: Range of time spent on the work in hours, e.g., "5-7hrs" |
| 31 | +completed_tasks: List of tasks completed, described concisely |
| 32 | +in_progress: List of tasks currently being worked on |
| 33 | +blockers: Any issues or dependencies preventing progress |
| 34 | +next_steps: Immediate next actions or tasks to be tackled |
31 | 35 | |
32 | 36 | Guidelines: |
33 | | -1. Give a high-level overview of the goal. |
34 | | -2. Break down changes by file or area. |
35 | | -3. Explain in plain language, avoiding jargon. |
36 | | -4. Highlight new features, improvements, bug fixes, or optimizations. |
37 | | -5. Discuss impacts or benefits to the user or system. |
38 | | -6. Use examples or analogies for clarity. |
39 | | -7. Maintain a consistent, readable tone. |
| 37 | +1. Provide a brief overview of the work done. |
| 38 | +2. Focus on key accomplishments and progress. |
| 39 | +3. Highlight any challenges or blockers encountered. |
| 40 | +4. Keep descriptions concise and relevant to team updates. |
| 41 | +5. Avoid technical jargon where possible. |
| 42 | +6. Keep summaries concise and to the point. |
| 43 | +7. All the points should be in human readable term. |
| 44 | +8. Output should be in JSON format. |
40 | 45 | |
41 | 46 | PATCH DATA: {PATCH_DATA} |
42 | 47 | """ |
43 | 48 |
|
44 | 49 | MERGE_WORK_SUMMARY_PROMPT = """ |
45 | | -Merge all this information into the following output format. |
| 50 | +Merge all this information into a consolidated standup report format. |
46 | 51 |
|
47 | 52 | OUTPUT Format: |
48 | 53 | {{ |
49 | | - "summary": "<SUMMARY_OF_WORK_DONE>", |
50 | | - "details": ["<IMPORTANT_DETAILS>", ...], |
51 | | - "todo": ["<TODO_ITEMS>", ...], |
52 | | - "future_considerations": ["<THINGS_TO_CONSIDER_IN_FUTURE>", ...], |
53 | | - "estimated_time": <ESTIMATED_TIME_IN_HOURS> |
| 54 | + "summary": "<BRIEF_SUMMARY_OF_WORK_DONE>", |
| 55 | + "details": ["<COMPLETED_TASK>", ...], |
| 56 | + "in_progress": ["<IN_PROGRESS_TASK>", ...], |
| 57 | + "blockers": ["<BLOCKER>", ...], |
| 58 | + "future_considerations": ["<NEXT_STEP>", ...], |
| 59 | + "estimated_time": "<ESTIMATED_TIME_IN_HOURS>" |
54 | 60 | }} |
55 | 61 |
|
56 | | -estimated_time: its the range of time you think the above work might have taken for a developer in hours, be little generous. example "10-15hrs" |
57 | | -details: its list of changes in human readable term so that anyone can understand how the software has been impacted. |
| 62 | +estimated_time_spent: Range of time spent on the work in hours, e.g., "5-7hrs" |
| 63 | +completed_tasks: List of tasks completed, described concisely |
| 64 | +in_progress: List of tasks currently being worked on |
| 65 | +blockers: Any issues or dependencies preventing progress |
| 66 | +next_steps: Immediate next actions or tasks to be tackled |
| 67 | + |
| 68 | +Guidelines: |
| 69 | +1. Provide a brief overview of the work done. |
| 70 | +2. Focus on key accomplishments and progress. |
| 71 | +3. Highlight any challenges or blockers encountered. |
| 72 | +4. Keep descriptions concise and relevant to team updates. |
| 73 | +5. Avoid technical jargon where possible. |
| 74 | +6. Keep summaries concise and to the point. |
| 75 | +7. All the points should be in human readable term. |
| 76 | +8. Output should be in JSON format. |
58 | 77 | |
59 | 78 | All the summaries: |
60 | 79 |
|
|
0 commit comments