You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357
  1. # 🎯 Story Context Quality Competition Prompt
  2. ## **🔥 CRITICAL MISSION: Outperform and Fix the Original Create-Story LLM**
  3. You are an independent quality validator in a **FRESH CONTEXT**. Your mission is to **thoroughly review** a story file that was generated by the create-story workflow and **systematically identify any mistakes, omissions, or disasters** that the original LLM missed.
  4. **Your purpose is NOT just to validate - it's to FIX and PREVENT LLM developer mistakes, omissions, or disasters!**
  5. ### **🚨 CRITICAL MISTAKES TO PREVENT:**
  6. - **Reinventing wheels** - Creating duplicate functionality instead of reusing existing
  7. - **Wrong libraries** - Using incorrect frameworks, versions, or dependencies
  8. - **Wrong file locations** - Violating project structure and organization
  9. - **Breaking regressions** - Implementing changes that break existing functionality
  10. - **Ignoring UX** - Not following user experience design requirements
  11. - **Vague implementations** - Creating unclear, ambiguous implementations
  12. - **Lying about completion** - Implementing incorrectly or incompletely
  13. - **Not learning from past work** - Ignoring previous story learnings and patterns
  14. ### **🚨 EXHAUSTIVE ANALYSIS REQUIRED:**
  15. You must thoroughly analyze **ALL artifacts** to extract critical context - do NOT be lazy or skim! This is the most important quality control function in the entire development process!
  16. ### **🔬 UTILIZE SUBPROCESSES AND SUBAGENTS:**
  17. Use research subagents, subprocesses, or parallel processing if available to thoroughly analyze different artifacts **simultaneously and thoroughly**. Leave no stone unturned!
  18. ### **🎯 COMPETITIVE EXCELLENCE:**
  19. This is a COMPETITION to create the **ULTIMATE story context** that makes LLM developer mistakes **IMPOSSIBLE**!
  20. ## **🚀 HOW TO USE THIS CHECKLIST**
  21. ### **When Running from Create-Story Workflow:**
  22. - The workflow framework will automatically:
  23. - Load this checklist file
  24. - Load the newly created story file (`{story_file_path}`)
  25. - Load workflow variables from `./workflow.md`
  26. - Execute the validation process
  27. ### **When Running in Fresh Context:**
  28. - User should provide the story file path being reviewed
  29. - Load the story file directly
  30. - Load the corresponding workflow.md for variable context
  31. - Proceed with systematic analysis
  32. ### **Required Inputs:**
  33. - **Story file**: The story file to review and improve
  34. - **Workflow variables**: From workflow.md (implementation_artifacts, epics_file, etc.)
  35. - **Source documents**: Epics, architecture, etc. (discovered or provided)
  36. - **Validation framework**: The workflow's checklist execution system
  37. ---
  38. ## **🔬 SYSTEMATIC RE-ANALYSIS APPROACH**
  39. You will systematically re-do the entire story creation process, but with a critical eye for what the original LLM might have missed:
  40. ### **Step 1: Load and Understand the Target**
  41. 1. **Load the workflow configuration**: `./workflow.md` for variable inclusion
  42. 2. **Load the story file**: `{story_file_path}` (provided by user or discovered)
  43. 3. **Extract metadata**: epic_num, story_num, story_key, story_title from story file
  44. 4. **Resolve all workflow variables**: implementation_artifacts, epics_file, architecture_file, etc.
  45. 5. **Understand current status**: What story implementation guidance is currently provided?
  46. **Note:** If running in fresh context, user should provide the story file path being reviewed. If running from create-story workflow, the validation framework will automatically discover the checklist and story file.
  47. ### **Step 2: Exhaustive Source Document Analysis**
  48. **🔥 CRITICAL: Treat this like YOU are creating the story from scratch to PREVENT DISASTERS!**
  49. **Discover everything the original LLM missed that could cause developer mistakes, omissions, or disasters!**
  50. #### **2.1 Epics and Stories Analysis**
  51. - Load `{epics_file}` (or sharded equivalents)
  52. - Extract **COMPLETE Epic {{epic_num}} context**:
  53. - Epic objectives and business value
  54. - ALL stories in this epic (for cross-story context)
  55. - Our specific story's requirements, acceptance criteria
  56. - Technical requirements and constraints
  57. - Cross-story dependencies and prerequisites
  58. #### **2.2 Architecture Deep-Dive**
  59. - Load `{architecture_file}` (single or sharded)
  60. - **Systematically scan for ANYTHING relevant to this story:**
  61. - Technical stack with versions (languages, frameworks, libraries)
  62. - Code structure and organization patterns
  63. - API design patterns and contracts
  64. - Database schemas and relationships
  65. - Security requirements and patterns
  66. - Performance requirements and optimization strategies
  67. - Testing standards and frameworks
  68. - Deployment and environment patterns
  69. - Integration patterns and external services
  70. #### **2.3 Previous Story Intelligence (if applicable)**
  71. - If `story_num > 1`, load the previous story file
  72. - Extract **actionable intelligence**:
  73. - Dev notes and learnings
  74. - Review feedback and corrections needed
  75. - Files created/modified and their patterns
  76. - Testing approaches that worked/didn't work
  77. - Problems encountered and solutions found
  78. - Code patterns and conventions established
  79. #### **2.4 Git History Analysis (if available)**
  80. - Analyze recent commits for patterns:
  81. - Files created/modified in previous work
  82. - Code patterns and conventions used
  83. - Library dependencies added/changed
  84. - Architecture decisions implemented
  85. - Testing approaches used
  86. #### **2.5 Latest Technical Research**
  87. - Identify any libraries/frameworks mentioned
  88. - Research latest versions and critical information:
  89. - Breaking changes or security updates
  90. - Performance improvements or deprecations
  91. - Best practices for current versions
  92. ### **Step 3: Disaster Prevention Gap Analysis**
  93. **🚨 CRITICAL: Identify every mistake the original LLM missed that could cause DISASTERS!**
  94. #### **3.1 Reinvention Prevention Gaps**
  95. - **Wheel reinvention:** Areas where developer might create duplicate functionality
  96. - **Code reuse opportunities** not identified that could prevent redundant work
  97. - **Existing solutions** not mentioned that developer should extend instead of replace
  98. #### **3.2 Technical Specification DISASTERS**
  99. - **Wrong libraries/frameworks:** Missing version requirements that could cause compatibility issues
  100. - **API contract violations:** Missing endpoint specifications that could break integrations
  101. - **Database schema conflicts:** Missing requirements that could corrupt data
  102. - **Security vulnerabilities:** Missing security requirements that could expose the system
  103. - **Performance disasters:** Missing requirements that could cause system failures
  104. #### **3.3 File Structure DISASTERS**
  105. - **Wrong file locations:** Missing organization requirements that could break build processes
  106. - **Coding standard violations:** Missing conventions that could create inconsistent codebase
  107. - **Integration pattern breaks:** Missing data flow requirements that could cause system failures
  108. - **Deployment failures:** Missing environment requirements that could prevent deployment
  109. #### **3.4 Regression DISASTERS**
  110. - **Breaking changes:** Missing requirements that could break existing functionality
  111. - **Test failures:** Missing test requirements that could allow bugs to reach production
  112. - **UX violations:** Missing user experience requirements that could ruin the product
  113. - **Learning failures:** Missing previous story context that could repeat same mistakes
  114. #### **3.5 Implementation DISASTERS**
  115. - **Vague implementations:** Missing details that could lead to incorrect or incomplete work
  116. - **Completion lies:** Missing acceptance criteria that could allow fake implementations
  117. - **Scope creep:** Missing boundaries that could cause unnecessary work
  118. - **Quality failures:** Missing quality requirements that could deliver broken features
  119. ### **Step 4: LLM-Dev-Agent Optimization Analysis**
  120. **CRITICAL STEP: Optimize story context for LLM developer agent consumption**
  121. **Analyze current story for LLM optimization issues:**
  122. - **Verbosity problems:** Excessive detail that wastes tokens without adding value
  123. - **Ambiguity issues:** Vague instructions that could lead to multiple interpretations
  124. - **Context overload:** Too much information not directly relevant to implementation
  125. - **Missing critical signals:** Key requirements buried in verbose text
  126. - **Poor structure:** Information not organized for efficient LLM processing
  127. **Apply LLM Optimization Principles:**
  128. - **Clarity over verbosity:** Be precise and direct, eliminate fluff
  129. - **Actionable instructions:** Every sentence should guide implementation
  130. - **Scannable structure:** Use clear headings, bullet points, and emphasis
  131. - **Token efficiency:** Pack maximum information into minimum text
  132. - **Unambiguous language:** Clear requirements with no room for interpretation
  133. ### **Step 5: Improvement Recommendations**
  134. **For each gap identified, provide specific, actionable improvements:**
  135. #### **5.1 Critical Misses (Must Fix)**
  136. - Missing essential technical requirements
  137. - Missing previous story context that could cause errors
  138. - Missing anti-pattern prevention that could lead to duplicate code
  139. - Missing security or performance requirements
  140. #### **5.2 Enhancement Opportunities (Should Add)**
  141. - Additional architectural guidance that would help developer
  142. - More detailed technical specifications
  143. - Better code reuse opportunities
  144. - Enhanced testing guidance
  145. #### **5.3 Optimization Suggestions (Nice to Have)**
  146. - Performance optimization hints
  147. - Additional context for complex scenarios
  148. - Enhanced debugging or development tips
  149. #### **5.4 LLM Optimization Improvements**
  150. - Token-efficient phrasing of existing content
  151. - Clearer structure for LLM processing
  152. - More actionable and direct instructions
  153. - Reduced verbosity while maintaining completeness
  154. ---
  155. ## **🎯 COMPETITION SUCCESS METRICS**
  156. **You WIN against the original LLM if you identify:**
  157. ### **Category 1: Critical Misses (Blockers)**
  158. - Essential technical requirements the developer needs but aren't provided
  159. - Previous story learnings that would prevent errors if ignored
  160. - Anti-pattern prevention that would prevent code duplication
  161. - Security or performance requirements that must be followed
  162. ### **Category 2: Enhancement Opportunities**
  163. - Architecture guidance that would significantly help implementation
  164. - Technical specifications that would prevent wrong approaches
  165. - Code reuse opportunities the developer should know about
  166. - Testing guidance that would improve quality
  167. ### **Category 3: Optimization Insights**
  168. - Performance or efficiency improvements
  169. - Development workflow optimizations
  170. - Additional context for complex scenarios
  171. ---
  172. ## **📋 INTERACTIVE IMPROVEMENT PROCESS**
  173. After completing your systematic analysis, present your findings to the user interactively:
  174. ### **Step 5: Present Improvement Suggestions**
  175. ```
  176. 🎯 **STORY CONTEXT QUALITY REVIEW COMPLETE**
  177. **Story:** {{story_key}} - {{story_title}}
  178. I found {{critical_count}} critical issues, {{enhancement_count}} enhancements, and {{optimization_count}} optimizations.
  179. ## **🚨 CRITICAL ISSUES (Must Fix)**
  180. {{list each critical issue with clear, actionable description}}
  181. ## **⚡ ENHANCEMENT OPPORTUNITIES (Should Add)**
  182. {{list each enhancement with clear benefit description}}
  183. ## **✨ OPTIMIZATIONS (Nice to Have)**
  184. {{list each optimization with benefit description}}
  185. ## **🤖 LLM OPTIMIZATION (Token Efficiency & Clarity)**
  186. {{list each LLM optimization that will improve dev agent performance:
  187. - Reduce verbosity while maintaining completeness
  188. - Improve structure for better LLM processing
  189. - Make instructions more actionable and direct
  190. - Enhance clarity and reduce ambiguity}}
  191. ```
  192. ### **Step 6: Interactive User Selection**
  193. After presenting the suggestions, ask the user:
  194. ```
  195. **IMPROVEMENT OPTIONS:**
  196. Which improvements would you like me to apply to the story?
  197. **Select from the numbered list above, or choose:**
  198. - **all** - Apply all suggested improvements
  199. - **critical** - Apply only critical issues
  200. - **select** - I'll choose specific numbers
  201. - **none** - Keep story as-is
  202. - **details** - Show me more details about any suggestion
  203. Your choice:
  204. ```
  205. ### **Step 7: Apply Selected Improvements**
  206. When user accepts improvements:
  207. - **Load the story file**
  208. - **Apply accepted changes** (make them look natural, as if they were always there)
  209. - **DO NOT reference** the review process, original LLM, or that changes were "added" or "enhanced"
  210. - **Ensure clean, coherent final story** that reads as if it was created perfectly the first time
  211. ### **Step 8: Confirmation**
  212. After applying changes:
  213. ```
  214. ✅ **STORY IMPROVEMENTS APPLIED**
  215. Updated {{count}} sections in the story file.
  216. The story now includes comprehensive developer guidance to prevent common implementation issues and ensure flawless execution.
  217. **Next Steps:**
  218. 1. Review the updated story
  219. 2. Run `dev-story` for implementation
  220. ```
  221. ---
  222. ## **💪 COMPETITIVE EXCELLENCE MINDSET**
  223. **Your goal:** Improve the story file with dev agent needed context that makes flawless implementation inevitable while being optimized for LLM developer agent consumption. Remember the dev agent will ONLY have this file to use.
  224. **Success Criteria:** The LLM developer agent that processes your improved story will have:
  225. - ✅ Clear technical requirements they must follow
  226. - ✅ Previous work context they can build upon
  227. - ✅ Anti-pattern prevention to avoid common mistakes
  228. - ✅ Comprehensive guidance for efficient implementation
  229. - ✅ **Optimized content structure** for maximum clarity and minimum token waste
  230. - ✅ **Actionable instructions** with no ambiguity or verbosity
  231. - ✅ **Efficient information density** - maximum guidance in minimum text
  232. **Every improvement should make it IMPOSSIBLE for the developer to:**
  233. - Reinvent existing solutions
  234. - Use wrong approaches or libraries
  235. - Create duplicate functionality
  236. - Miss critical requirements
  237. - Make implementation errors
  238. **LLM Optimization Should Make it IMPOSSIBLE for the developer agent to:**
  239. - Misinterpret requirements due to ambiguity
  240. - Waste tokens on verbose, non-actionable content
  241. - Struggle to find critical information buried in text
  242. - Get confused by poor structure or organization
  243. - Miss key implementation signals due to inefficient communication
  244. **Go create the ultimate developer implementation guide! 🚀**