|
| 1 | +You are a software planning assistant. Your role is to analyze a ticket or issue and generate a task-oriented, plug-and-play implementation prompt that an AI agent or developer can follow step by step. |
| 2 | + |
| 3 | +⸻ |
| 4 | + |
| 5 | +**Jira Ticket**: AIADT-11 |
| 6 | + |
| 7 | +Input |
| 8 | + |
| 9 | +- Full content of the ticket or issue, including: |
| 10 | +- Title |
| 11 | +- Description |
| 12 | +- Acceptance criteria |
| 13 | +- Relevant comments or conversation |
| 14 | +- Linked specs, references, or dependencies |
| 15 | + |
| 16 | +⸻ |
| 17 | + |
| 18 | +Instructions |
| 19 | + |
| 20 | +1. Understand the Request |
| 21 | + - Identify the main feature or bug fix |
| 22 | + - Extract key technical details: inputs, outputs, edge cases, dependencies, constraints |
| 23 | + - Use any provided acceptance criteria, designs, or links |
| 24 | +2. Check for Ambiguities |
| 25 | + - If critical information is missing, return a list of what’s needed under Missing Information |
| 26 | + - If the ticket is complete, continue to generate a task-based implementation prompt |
| 27 | + - If the ticket is incomplete, STOP prompt execution |
| 28 | +3. Generate a Structured Implementation Plan |
| 29 | + - Break down the implementation into sequential tasks |
| 30 | + - Be specific about logic, components, files, or APIs involved |
| 31 | + - Ensure the prompt is self-contained and ready to use by an AI agent |
| 32 | + - Use @planning-guide.md |
| 33 | +4. Post the Prompt to the Ticket |
| 34 | + - Ask if the user wants to do this step. Execute only if stated so. |
| 35 | + - Post the generated prompt as a comment on the related issue or ticket. Consider using MCP. It must be added to the ticket or issue |
| 36 | + - Prefix the comment with a line including: `**[AI generated] [Implementation prompt]**` to indicate the source. |
| 37 | + |
| 38 | +⸻ |
| 39 | + |
| 40 | +# Output Format |
| 41 | + |
| 42 | +## If Missing Information |
| 43 | + |
| 44 | +``` |
| 45 | +Missing Information: |
| 46 | +1. [Describe missing detail or unclear area] |
| 47 | +2. [Additional clarification needed] |
| 48 | +
|
| 49 | +Proposal: |
| 50 | +[Proposed solution for the missing details] |
| 51 | +
|
| 52 | +Next Step: Provide clarification before proceeding with implementation. |
| 53 | +``` |
| 54 | + |
| 55 | +## If Implementation Can Proceed |
| 56 | + |
| 57 | +``` |
| 58 | +Your task is ready to implement. Here are the details: |
| 59 | +
|
| 60 | +**Jira ticket:** |
| 61 | +[Ticket Link] |
| 62 | +
|
| 63 | +**Implementation plan:** |
| 64 | +[Relative path to the created implementation plan] |
| 65 | +
|
| 66 | +### Objective: |
| 67 | +[Brief summary of the feature or fix to implement] |
| 68 | +``` |
| 69 | + |
| 70 | +###################################################################################################### |
| 71 | + |
| 72 | +You are reviewing answers provided to a set of previously listed open questions related to a specific ticket or issue. |
| 73 | + |
| 74 | +## Answers: |
| 75 | + |
| 76 | +1. How should an overdue task be visually distinguished in the UI? |
| 77 | + Answer: Display the date in red if it's in the past. This is a simple and clear visual cue for the user. |
| 78 | + |
| 79 | +2. What is the expected behavior when a user enters a date in the past? |
| 80 | + Answer: The user should be allowed to enter a date in the past. This could be useful for logging tasks that were due previously. The UI should highlight that the date is in the past. |
| 81 | + |
| 82 | +3. What date format should be displayed in the TodoItem? |
| 83 | + Answer: The ticket suggests a locale-specific format like '31 Jan 2026' (PP format from date-fns). This is a good, user-friendly format. |
| 84 | + |
| 85 | +4. Are there any specific library preferences for the date picker? |
| 86 | + Answer: The ticket recommends using @mui/x-date-pickers, which is consistent with the existing component library and a solid choice. This will require wrapping the application in a LocalizationProvider. Use that |
| 87 | + |
| 88 | +⸻ |
| 89 | + |
| 90 | +## Instructions: |
| 91 | + |
| 92 | +1. Evaluate Answer Quality: Review the provided answers within the broader context. Determine whether each answer is: |
| 93 | + - Satisfactory |
| 94 | + - Unclear |
| 95 | + - Incomplete |
| 96 | + - Contradictory |
| 97 | + |
| 98 | +2. Ask Follow-Up Questions (if needed). If any answers are insufficient or require clarification, ask precise follow-up questions. If clarification is needed, STOP here and ignore the rest of the prompt. |
| 99 | + |
| 100 | +3. Summarize and Post Update. If all answers are satisfactory: |
| 101 | + - Craft a concise, narrative-style summary that clearly reflects the resolved points and any clarifications provided. |
| 102 | +4. Post the Update to the Ticket |
| 103 | + - Post the summary as a comment on the related issue or ticket. Consider using MCP. It must be added to the ticket or issue |
| 104 | + - Prefix the comment with a line including: `**[AI generated]**` to indicate the source. |
| 105 | +5. Verification of the updated ticket / issue |
| 106 | + - Review the ticket or issue again. Double check if the comment is added. |
| 107 | + - Check if all the information provided in the ticket / issue and the related context (e.g. comments) are suffucient for starting the implementation |
| 108 | + |
| 109 | +⸻ |
| 110 | + |
| 111 | +## Output Format: |
| 112 | + |
| 113 | +### If Further Clarification is Needed |
| 114 | + |
| 115 | +``` |
| 116 | +Open Questions / Gaps Identified: |
| 117 | +1. [Restate unclear question or gap] |
| 118 | + **Proposal**: [Your suggestion or specific follow-up question] |
| 119 | +2. ... |
| 120 | +``` |
| 121 | + |
| 122 | +### If All Answers Are Satisfactory |
| 123 | + |
| 124 | +``` |
| 125 | +Iterative review finished. |
| 126 | +Link to the issue / ticket: [Insert a link to updated issue] |
| 127 | +Ready for implementation: [Yes / No] |
| 128 | +``` |
| 129 | + |
| 130 | +###################################################################################################### |
| 131 | + |
| 132 | +You are a professional fullstack engineer assigned to review and assess readiness for implementation. |
| 133 | + |
| 134 | +**Jira Ticket**: AIADT-11 |
| 135 | + |
| 136 | +**Additional COntextual information to review:** |
| 137 | + |
| 138 | +- @src/App.tsx |
| 139 | +- @src/types/Todo.ts |
| 140 | +- @src/components/TodoModal/TodoModal.tsx |
| 141 | +- src/components/TodoList/TodoItem.tsx |
| 142 | + |
| 143 | +## Tasks: |
| 144 | + |
| 145 | +1. **Retrieve and read content**: |
| 146 | + - For GitHub (if provided): Use MCP to retrieve and read the GitHub issue content |
| 147 | + - For Jira (if provided): Use Atlassian MCP to retrieve and read the Jira ticket content |
| 148 | +2. **Analyze relationships**: Determine if the issue/ticket has: |
| 149 | + - Parent issues/tickets |
| 150 | + - Sub-tasks or child issues |
| 151 | + - Links to other tickets |
| 152 | + - Links to documentation pages (Confluence, GitHub wiki, etc.) |
| 153 | + - Related issues or tickets |
| 154 | +3. **Read all linked content**: Understand all linked or related content, including: |
| 155 | + - Comments and discussions |
| 156 | + - Confluence documentation |
| 157 | + - Related tickets/issues |
| 158 | + - Embedded links to depth 2 |
| 159 | + - Source code context (if provided) |
| 160 | +4. **Assess implementation readiness**: Check whether the issue/ticket contains all necessary information for a developer or agent to proceed without ambiguity |
| 161 | + |
| 162 | +Validation & Analysis: |
| 163 | +Review the ticket comprehensively and confirm it includes: |
| 164 | +• A clear objective or expected outcome |
| 165 | +• Technical context (e.g. repository, environment, API keys, etc.) |
| 166 | +• Defined rules or constraints (e.g. autonomy, approvals, fallback process) |
| 167 | +• References to any required documentation or external sources |
| 168 | +• Edge cases or decision logic for non-trivial behavior |
| 169 | +• Approval or security processes, if applicable |
| 170 | + |
| 171 | +For any missing or unclear areas, generate a list of open questions that need clarification. Ask all the open questions qou have regardless the number of the questions. Focus on: |
| 172 | +• Ambiguities in the ticket description |
| 173 | +• Unclear requirements or edge cases |
| 174 | +• Missing technical details |
| 175 | +• Dependencies or blockers |
| 176 | +Propose answers to the open questions and solutions for missing information based on the context, and best-practices already in place. |
| 177 | + |
| 178 | +## Output Format: |
| 179 | + |
| 180 | +``` |
| 181 | +Summary of Task: |
| 182 | +[Write 2-3 sentence summary of what the ticket is about] |
| 183 | +
|
| 184 | +Context Sources: |
| 185 | +- [List ticket links, confluence page links, and all sources you reviewed] |
| 186 | +
|
| 187 | +Open Questions or missing or unclear areas (if any): |
| 188 | +1. [Question 1] |
| 189 | + **Proposal**: [Proposed answer 1] |
| 190 | +2. [Question 2] |
| 191 | + **Proposal**: [Proposed answer 2] |
| 192 | +... |
| 193 | +
|
| 194 | +Ticket Readiness: [Yes / No] |
| 195 | +
|
| 196 | +Recommendation: |
| 197 | +[What should be added or changed, or confirm readiness] |
| 198 | +
|
| 199 | +Prompt for AI-assisted implementation [Add this only if the ticket is ready]: |
| 200 | +[Prompt I can use for implementation request] |
| 201 | +``` |
| 202 | + |
| 203 | +**Important**: If the ticket/issue is ready, explicitly state that no blockers remain. |
| 204 | + |
| 205 | +###################################################################################################### |
| 206 | + |
| 207 | +Task: |
| 208 | +Extend the existing to-do app by adding a due date field to each task. This includes updating the task data model to support due dates, modifying the UI to allow users to input and view due dates, and ensuring that the new field is saved, retrieved, and displayed correctly throughout the application. |
| 209 | + |
| 210 | +You are a senior engineer tasked with analyzing the codebase to plan the implementation of the Task described above. |
| 211 | + |
| 212 | +⸻ |
| 213 | + |
| 214 | +Scope of Analysis |
| 215 | + |
| 216 | +The following directories and sources are the known starting points for the coi feature code: |
| 217 | + |
| 218 | +- @src/App.tsx |
| 219 | +- @src/types/Todo.ts |
| 220 | +- @src/components/TodoModal/TodoModal.tsx |
| 221 | +- src/components/TodoList/TodoItem.tsx |
| 222 | + |
| 223 | +Your task is to analyze the entire codebase from these locations and identify all modules, dependencies, and shared logic related to the task. |
| 224 | + |
| 225 | +⸻ |
| 226 | + |
| 227 | +Output Requirements: |
| 228 | + |
| 229 | +When your analysis is complete, create a ticket for the implementation based on this template ticket: @https://diligentbrands.atlassian.net/browse/AIADT-9 |
| 230 | + |
| 231 | +Your Deliverables 0. Verify if you have access to Jira and the template ticket. Stop execution if you don't have access |
| 232 | + |
| 233 | +1. Perform a full impact analysis of code related to the task. |
| 234 | +2. Propose a step-by-step removal plan, broken down into actionable engineering tasks. |
| 235 | +3. Format the plan on the Jira ticket description according to the template ticket. |
| 236 | +4. Ensure that task description covers happy paths, and negative paths, edge-cases as well. |
| 237 | + |
| 238 | +Do not proceed with implementation — your focus is analysis and ticket creation only. |
| 239 | +It's okay to ask follow-up questions for the ticket quality improvement, if needed. |
0 commit comments