├── .github └── workflows │ └── release.yml ├── .gitignore ├── .husky ├── post-push └── pre-commit ├── .prettierrc ├── .vscode └── settings.json ├── CONTRIBUTION.md ├── README.md ├── docs ├── cursor-template-prompt.png └── espanso.gif ├── espanso ├── README.md ├── _manifest.yml └── package.yml ├── index.js ├── package-lock.json ├── package.json └── src ├── espanso-generation ├── README.txt ├── __snapshots__ │ ├── generateYaml.test.js.snap │ └── parseMarkdown.test.js.snap ├── convertToYaml.js ├── generateYaml.js ├── generateYaml.test.js ├── parseMarkdown.js └── parseMarkdown.test.js ├── extract-scripts.js └── extract-scripts.test.js /.github/workflows/release.yml: -------------------------------------------------------------------------------- 1 | name: Release Version 2 | 3 | on: 4 | push: 5 | branches: 6 | - main 7 | workflow_dispatch: # Permet de lancer manuellement 8 | 9 | jobs: 10 | release: 11 | runs-on: ubuntu-22.04 12 | permissions: 13 | contents: write # Needed for creating commits, tags, and releases 14 | 15 | steps: 16 | - name: Checkout repository 17 | uses: actions/checkout@v3 18 | with: 19 | fetch-depth: 0 # Fetch all history for all tags and branches 20 | 21 | - name: Setup Node.js 22 | uses: actions/setup-node@v3 23 | with: 24 | node-version: '20' 25 | 26 | - name: Install dependencies 27 | run: npm install 28 | 29 | - name: Generate package.yml with new version 30 | run: npm run start 31 | 32 | - name: Extract & Increment Version (SemVer) 33 | shell: bash 34 | run: | 35 | # Get current version from package.json 36 | current_version=$(jq -r '.version' package.json) 37 | 38 | # Split version into array 39 | major=$(echo "$current_version" | cut -d. -f1) 40 | minor=$(echo "$current_version" | cut -d. -f2) 41 | patch=$(echo "$current_version" | cut -d. -f3) 42 | 43 | # Increment patch version 44 | new_patch=$((patch + 1)) 45 | new_version="$major.$minor.$new_patch" 46 | 47 | # Update package.json 48 | jq --arg version "$new_version" '.version = $version' package.json > tmp.json 49 | mv tmp.json package.json 50 | 51 | # Update version with debug output 52 | echo "Current version in manifest:" 53 | grep "version:" espanso/_manifest.yml 54 | 55 | echo "Attempting to update to version: $new_version" 56 | sed -i -E "s/version: '?([0-9]+\.[0-9]+\.[0-9]+)'?/version: '$new_version'/" espanso/_manifest.yml 57 | 58 | echo "New version in manifest:" 59 | grep "version:" espanso/_manifest.yml 60 | 61 | # Verify the change was successful 62 | if ! grep -q "version: '$new_version'" espanso/_manifest.yml; then 63 | echo "Error: Version update failed" 64 | exit 1 65 | fi 66 | 67 | # Export for other steps 68 | echo "NEW_VERSION=$new_version" >> $GITHUB_ENV 69 | echo "Version bumped from $current_version to $new_version" 70 | 71 | - name: Generate Changelog (Commits since last tag) 72 | run: | 73 | # Try to get the last tag, if it fails, get all commits 74 | if ! last_tag=$(git describe --tags --abbrev=0 2>/dev/null); then 75 | echo "No previous tags found - this is the first release" 76 | last_tag=$(git rev-list --max-parents=0 HEAD) # Get the first commit 77 | changelog=$(git log --pretty=format:"- %s") 78 | else 79 | echo "Last tag: $last_tag" 80 | changelog=$(git log --pretty=format:"- %s" "$last_tag"..HEAD) 81 | fi 82 | 83 | if [ -z "$changelog" ]; then 84 | changelog="No significant changes." 85 | fi 86 | 87 | echo "$changelog" > changelog.txt 88 | echo "Changelog:" 89 | cat changelog.txt 90 | 91 | echo "CHANGELOG<> $GITHUB_ENV 92 | cat changelog.txt >> $GITHUB_ENV 93 | echo "EOF" >> $GITHUB_ENV 94 | 95 | - name: Commit & Push Version Bump 96 | run: | 97 | git config --global user.name "github-actions[bot]" 98 | git config --global user.email "github-actions[bot]@users.noreply.github.com" 99 | git add package.json espanso/ 100 | git commit -m "🔖 Bump version to ${{ env.NEW_VERSION }}" 101 | git push 102 | 103 | - name: Create Git Tag 104 | run: | 105 | git tag "v${{ env.NEW_VERSION }}" 106 | git push origin "v${{ env.NEW_VERSION }}" 107 | 108 | - name: Create GitHub Release 109 | env: 110 | GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} 111 | run: | 112 | # Prepare release body with proper escaping 113 | BODY=$(cat << EOF 114 | ## 🚀 Release v${{ env.NEW_VERSION }} 115 | 116 | **Changelog:** 117 | ${{ env.CHANGELOG }} 118 | EOF 119 | ) 120 | 121 | # Create release using GitHub API 122 | curl \ 123 | -X POST \ 124 | -H "Accept: application/vnd.github+json" \ 125 | -H "Authorization: Bearer $GITHUB_TOKEN" \ 126 | -H "X-GitHub-Api-Version: 2022-11-28" \ 127 | https://api.github.com/repos/${{ github.repository }}/releases \ 128 | -d @- << EOF 129 | { 130 | "tag_name": "v${{ env.NEW_VERSION }}", 131 | "name": "Release v${{ env.NEW_VERSION }}", 132 | "body": $(echo "$BODY" | jq -R -s .), 133 | "draft": false, 134 | "prerelease": false 135 | } 136 | EOF 137 | 138 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | node_modules 2 | resources/images/.DS_Store 3 | 4 | # avoid indexing the resources/private/* content 5 | resources/private 6 | !resources/private/.gitkeep 7 | 8 | **/.DS_Store -------------------------------------------------------------------------------- /.husky/post-push: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env sh 2 | . "$(dirname -- "$0")/_/husky.sh" 3 | 4 | espanso package update ai-driven-dev-prompts -------------------------------------------------------------------------------- /.husky/pre-commit: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env sh 2 | . "$(dirname -- "$0")/_/husky.sh" 3 | 4 | echo "🚀 Testing, generating package, and upgrading version..." 5 | 6 | npm test 7 | -------------------------------------------------------------------------------- /.prettierrc: -------------------------------------------------------------------------------- 1 | { 2 | "semi": true, 3 | "trailingComma": "es5", 4 | "singleQuote": true, 5 | "printWidth": 80, 6 | "tabWidth": 2, 7 | "useTabs": false 8 | } 9 | -------------------------------------------------------------------------------- /.vscode/settings.json: -------------------------------------------------------------------------------- 1 | { 2 | "cSpell.words": ["espanso", "Espanso"] 3 | } 4 | -------------------------------------------------------------------------------- /CONTRIBUTION.md: -------------------------------------------------------------------------------- 1 | # ✨ Contribution - AI-Driven Dev "Prompts" 2 | 3 | **Merci d'aider les autres développeurs de la communauté à améliorer leur prompts.** 4 | 5 | > Si chaque développeur optimise un prompt, d'ici quelques mois, on aura la plus grande collection de prompts communautaires pour les développeurs. 6 | 7 | - [✨ Contribution - AI-Driven Dev "Prompts"](#-contribution---ai-driven-dev-prompts) 8 | - [⬇️ Mise à jour automatique des prompts](#️-mise-à-jour-automatique-des-prompts) 9 | - [🆕 Ajouter un nouveau prompt](#-ajouter-un-nouveau-prompt) 10 | - [Format](#format) 11 | - [Exemple](#exemple) 12 | - [Re-générer le fichier de prompt d'Espanso](#re-générer-le-fichier-de-prompt-despanso) 13 | - [🔄 Modifier et améliorer un prompt existant](#-modifier-et-améliorer-un-prompt-existant) 14 | 15 | ## ⬇️ Mise à jour automatique des prompts 16 | 17 | Un script va lire le [`README.md`](https://github.com/ai-driven-dev/prompts/) pour générer le [`package.yml`](https://github.com/ai-driven-dev/prompts/blob/main/espanso/package.yml) 18 | 19 | [Une CI automatique a été ajoutée](https://github.com/ai-driven-dev/prompts/actions) pour mettre à jour les versions dans Espanso automatiquement à chaque commit sur `main` ! 20 | 21 | ## 🆕 Ajouter un nouveau prompt 22 | 23 | Il suffit de cloner le dépôt. 24 | 25 | ```shell 26 | git clone https://github.com/ai-driven-dev/prompts.git 27 | ``` 28 | 29 | Puis d'ouvrir le fichier `README.md` et ajouter votre prompt dans la bonne section ! 30 | 31 | ### Format 32 | 33 | > Il y a un format à respecter pour que le script puisse générer le fichier de prompt d'Espanso. 34 | 35 | 1. Clef dans le titre de niveau 3 (`###`) ou 4 (`####`): 36 | ```markdown ### Mon titre `:key` ``` 37 | 38 | 2. Faire une description du prompt dans une balise `>` (un quote). 39 | 40 | 3. Écrire le prompt en anglais, la description et le titre en français. 41 | 42 | 4. Utiliser un `
` HTML5 pour mettre le prompt. 43 | 44 | 5. Formulaires (optionnel) si vous avez des champs à remplir. 45 | 46 | - Texte : `"[[texte ici]]"` 47 | - Textarea : `[[zone de texte longue]]` 48 | - Select : `[[select1|select2|select3]]` 49 | 50 | ### Exemple 51 | 52 | > Vous pouvez imbriquer du `markdown` dans le prompt ! 53 | 54 | `````markdown 55 | ````markdown 56 | ### Mon titre `:testExample` 57 | 58 | > Description du prompt 59 | 60 |
61 | Voir le prompt 62 | 63 | ````markdown 64 | Goal: 65 | Generate a test file for testing library: "[[testing library]]". 66 | 67 | Rules: 68 | - Type of test: "[[unit|integration|e2e]]" 69 | - Use the "Arrange, Act, Assert" pattern 70 | - Do not mock network requests 71 | - Mock the database 72 | - Do not use the "only" method 73 | - Focus on testing the library 74 | 75 | Example: 76 | ```markdown 77 | [[example of code to test]] 78 | ``` 79 | ```` 80 | ````` 81 | 82 |
83 | 84 | ### Re-générer le fichier de prompt d'Espanso 85 | 86 | ```shell 87 | npm run start 88 | ``` 89 | 90 | 1. Vérifier que votre prompt se trouve dans le fichier `espanso/package.yml` 91 | 92 | 2. Faire un commit et un push de votre modification. 93 | 94 | ## 🔄 Modifier et améliorer un prompt existant 95 | 96 | 1. Faire une pull-request en ligne avec votre modification. 97 | 98 | 2. Un membre de la communauté va l'examiner et le merger. 99 | 100 | 3. C'est tout, merci ! 101 | -------------------------------------------------------------------------------- /docs/cursor-template-prompt.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ai-driven-dev/prompts/edb93fa8c5b9adf6c21f452bf8a27635add81a8d/docs/cursor-template-prompt.png -------------------------------------------------------------------------------- /docs/espanso.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ai-driven-dev/prompts/edb93fa8c5b9adf6c21f452bf8a27635add81a8d/docs/espanso.gif -------------------------------------------------------------------------------- /espanso/README.md: -------------------------------------------------------------------------------- 1 | # AI-Driven Dev {Prompts} 2 | 3 | Prompts collection for AI-driven developers. 4 | 5 | 6 | -------------------------------------------------------------------------------- /espanso/_manifest.yml: -------------------------------------------------------------------------------- 1 | name: 'ai-driven-dev-prompts' 2 | title: 'AI-Driven Dev Prompts' 3 | description: Prompts collection for AI-driven developers. 4 | version: '2.0.49' 5 | author: AI-Driven Dev Team 6 | website: https://github.com/ai-driven-dev/prompts 7 | -------------------------------------------------------------------------------- /espanso/package.yml: -------------------------------------------------------------------------------- 1 | matches: 2 | - trigger: ':promptTemplate' 3 | form: | 4 | # Goal 5 | "[[what_you_want_to_achieve_with_this_prompt]]" 6 | 7 | # Rules 8 | - "[[rule_1]]" 9 | - "[[rule_2]]" 10 | - "[[rule_3]]" 11 | 12 | # Steps 13 | 1. "[[step_1]]" 14 | 2. "[[step_2]]" 15 | 3. "[[step_3]]" 16 | 17 | # Context 18 | [[describe_the_context_of_the_prompt]] 19 | 20 | # Input Example 21 | 22 | [[example_of_the_input_you_have]] 23 | 24 | 25 | # Output Example 26 | 27 | [[example_of_the_output_you_want_to_get]] 28 | 29 | form_fields: 30 | describe_the_context_of_the_prompt: 31 | multiline: true 32 | example_of_the_input_you_have: 33 | multiline: true 34 | example_of_the_output_you_want_to_get: 35 | multiline: true 36 | - trigger: ':promptCreate' 37 | form: | 38 | CONTEXT: 39 | We are going to create one of the best ChatGPT prompts ever written. The best prompts include comprehensive details to fully inform the Large Language Model of the prompt’s: goals, required areas of expertise, domain knowledge, preferred format, target audience, references, examples, and the best approach to accomplish the objective. Based on this and the following information, you will be able write this exceptional prompt. 40 | 41 | ROLE: 42 | You are an LLM prompt generation expert. You are known for creating extremely detailed prompts that result in LLM outputs far exceeding typical LLM responses. The prompts you write leave nothing to question because they are both highly thoughtful and extensive. 43 | 44 | ACTION: 45 | 1) Before you begin writing this prompt, you will first look to receive the prompt topic or theme. If I don't provide the topic or theme for you, please request it. 46 | 2) Once you are clear about the topic or theme, please also review the Format and Example provided below. 47 | 3) If necessary, the prompt should include “fill in the blank” elements for the user to populate based on their needs. 48 | 4) Take a deep breath and take it one step at a time. 49 | 5) Once you've ingested all of the information, write the best prompt ever created in english. 50 | 51 | FORMAT: 52 | For organizational purposes, you will use an acronym called "C.R.A.F.T." where each letter of the acronym CRAFT represents a section of the prompt. Your format and section descriptions for this prompt development are as follows: 53 | 54 | -Context: This section describes the current context that outlines the situation for which the prompt is needed. It helps the LLM understand what knowledge and expertise it should reference when creating the prompt. 55 | 56 | -Role: This section defines the type of experience the LLM has, its skill set, and its level of expertise relative to the prompt requested. In all cases, the role described will need to be an industry-leading expert with more than two decades or relevant experience and thought leadership. 57 | 58 | -Action: This is the action that the prompt will ask the LLM to take. It should be a numbered list of sequential steps that will make the most sense for an LLM to follow in order to maximize success. 59 | 60 | -Format: This refers to the structural arrangement or presentation style of the LLM’s generated content. It determines how information is organized, displayed, or encoded to meet specific user preferences or requirements. Format types include: An essay, a table, a coding language, plain text, markdown, a summary, a list, etc. 61 | - trigger: ':promptBestPractices' 62 | form: | 63 | Goal: List all the best practices for a given element. 64 | 65 | Element: "[[element]]" 66 | 67 | Rules: 68 | - List top 10 best practices in 2025. 69 | - Sort best most popular practices first. 70 | - Be concise and clear. 71 | - Use bullet points with short sentences focus on delivery. 72 | - trigger: ':promptExtractRules' 73 | form: |+ 74 | Goal: Extract rules for our developer team based on our conversation. 75 | 76 | Rules: 77 | - List main rules to extract with the most value for the developer team. 78 | - Use bullet points with short sentences. 79 | - Output in expect format (replace `{placeholders}`) 80 | - Be accurate and concise. 81 | 82 | Expected format: 83 | ````mdc 84 | --- 85 | file: {file-name-with.mdc} 86 | description: {when to apply the rule} 87 | globs: {which paths} 88 | --- 89 | 90 | > {When } 91 | 92 | ## {Main rule} 93 | - {rule 1} 94 | - {rule 2} 95 | - {rule 3} 96 | ... 97 | 98 | ## {Rule} : Example 99 | ``` 100 | ... 101 | ``` 102 | 103 | ```` 104 | 105 | - trigger: ':promptExtractActions' 106 | form: | 107 | Summarize actions I need to do regarding that just specific part. 108 | 109 | - Use short numbered and ordered bullet points. 110 | - Straight to the point. 111 | - Only the essential actions. 112 | - No style. 113 | - Export in markdown formatted text block surrounded by 4 backticks. 114 | - Use English. 115 | - trigger: ':promptExtractSingleRule' 116 | form: | 117 | Generate a **clear and actionable** rule to prevent repeating a specific mistake. 118 | 119 | Based on our last discussion, give me a **universal rule** that ensures I won’t make this mistake again. 120 | - **Imperative and unambiguous**. 121 | - **Short** (maximum **15 words**). 122 | - **Immediately applicable** (e.g., "Always check X before executing Y."). 123 | - trigger: ':promptOpt' 124 | form: | 125 | Act as en **elite Prompt Engineer** that transform prompt into high performing prompts. 126 | 127 | # Steps 128 | 1. **Read** the prompt carefully and identify major weaknesses. 129 | - Identify the **context**, the **desired role**, the **goal**, and potential **gaps**. 130 | - Find inconsistencies, ambiguities, duplications or missing details. 131 | 2. **Explain** those weaknesses clearly. 132 | - Use **bullet points** for each issue. 133 | 3. **Suggest** concise, high-impact improvements. 134 | - Use **bullet points** for each improvement. 135 | 4. **Rewrite** a final version that is clear, focused, and achieves the goal. 136 | 137 | **Important**: 138 | - Do not be lazy, ALWAYS return the full prompt. 139 | 140 | # Rules 141 | - Translate the prompt in english. 142 | - Make very short sentences, straight to the point, clear and concise. 143 | - Only titles for formatting. 144 | - No emojis. 145 | - Minimal example 146 | - Maintain or clarify original intent. 147 | - Add constraints (length, tone, format) if needed. 148 | 149 | # Output Format to the user 150 | 1. **Weaknesses** 151 | 2. **Suggested Improvements** 152 | 3. **Masterclass Prompt** (reply with your final result in block text formatted markdown surrounded by 4 backticks) 153 | 154 | # Prompt to improve 155 | 156 | [[your_prompt]] 157 | 158 | form_fields: 159 | your_prompt: 160 | multiline: true 161 | - trigger: ':promptStart' 162 | form: | 163 | - Please follow every steps mentioned. 164 | - Do not be lazy. 165 | - Always provide the full document. 166 | - Do not generate code. 167 | - Answer in the shortest way possible, avoid long sentences, go straight to the point. 168 | - Confirmation questions: Only ONE question per confirmation. 169 | - trigger: ':featureUserStories' 170 | form: |+ 171 | Create a list of user stories from user needs, starting from an epic. The AI architect should first ask questions about this epic to gather essential information. From these questions, develop a plan of user stories. Once the user story plan is validated, the task is complete. 172 | 173 | Steps: 174 | 1. **Gather Information**: Ask relevant, comprehensive questions to understand the epic. 175 | 2. **Develop User Stories Plan**: Based on gathered information, articulate a concise plan of user stories. 176 | 3. **Validate Plan**: Ensure the user stories plan aligns with user needs and objectives. 177 | 178 | Requirements: 179 | - **Clear and concise format**: Each user story must be **short but complete**. 180 | - **Distinguish between user actions and system actions**: 181 | - `(User)` → Actions triggered by the user (clicks, input, interactions...). 182 | - `(System)` → Actions triggered automatically (data loading, API requests...). 183 | - **Use inputs and outputs**: 184 | - **Trigger**: When the action occurs. 185 | - **Input**: Data required for the action. 186 | - **Output**: Data returned by the action. 187 | - **Avoid redundancy**: Each action must be precise and targeted, organized by category. 188 | 189 | Example: 190 | ```markdown 191 | # User Stories for Newsletter Dashboard 192 | 193 | ## User Data 194 | 195 | ### The dashboard retrieves the user profile** (System) 196 | - **Trigger**: On dashboard load 197 | - **Input**: `userId: string` 198 | - **Output**: `{ id, firstName, lastName, avatarUrl }` 199 | 200 | ## The dashboard retrieves the user's email alias (System) 201 | - **Trigger**: On dashboard load 202 | - **Input**: `projectId: string` 203 | - **Output**: `newsletterAlias: string` 204 | 205 | ## AI Personalization 206 | 207 | ### The user configures a message for the AI (User) 208 | - **Trigger**: When modifying the input field 209 | - **Input**: `customMessage: string` 210 | - **Output**: Stored in `UserProfile.prompt_instruction` 211 | 212 | ### The dashboard verifies that the sent message matches the stored one (System) 213 | - **Trigger**: When receiving the API response 214 | - **Input**: `customMessage: string` 215 | - **Output**: 216 | - ✅ **If identical** → Normal display 217 | - ❌ **If different** → Show error and update the value 218 | ``` 219 | 220 | # Notes 221 | 222 | - Ensure questions are thorough to gather complete context for the epic. 223 | - User stories should be clear, actionable, and tailored to specific user needs. 224 | 225 | - trigger: ':featureUserStory' 226 | form: |+ 227 | Goal: Please endorse Product Owner to write very good user stories for the developers team. 228 | 229 | Rules: 230 | 231 | - Do not generate code. 232 | - Ask me questions to understand the feature and being sure nothing is missing. 233 | - Be accurate and lean, concise questions, minimum words. 234 | - Group questions by section of 3 questions minimum. 235 | - Make user stories coherent and clear. 236 | - Sort them by priority of code. 237 | - When the user asks, write the user stories using the template under. 238 | - Output the template in markdown. 239 | 240 | Requirements: 241 | 242 | [[feature_to_build_be_as_detailed_as_possible]] 243 | 244 | 245 | Steps: 246 | 247 | 1. Break down requirements into an user-stories list. 248 | 2. Ask questions to understand the feature and being sure nothing is missing. 249 | 3. Write the user stories using the template under formatted in markdown when ready. 250 | 251 | User stories template: 252 | 253 | ```markdown 254 | # Feature's name with Epic 255 | 256 | ## "User Story 1" 257 | 258 | **As a** [role] 259 | **I want** [action] 260 | **So that** [outcome] 261 | 262 | * Acceptance Criteria: 263 | * [ ] Given: ... 264 | * [ ] When: ... 265 | * [ ] Then: ... 266 | * [ ] And: ... 267 | 268 | ## "User Story 2" 269 | 270 | ... 271 | ``` 272 | 273 | form_fields: 274 | feature_to_build_be_as_detailed_as_possible: 275 | multiline: true 276 | - trigger: ':featureInstructions' 277 | form: |+ 278 | # Goal 279 | Structuring precise coding instructions for the **AI Editor** with the help of the **Developer**. 280 | 281 | # Roles & Responsibilities 282 | - **AI Architect (You)** → Helps structure the instructions. 283 | - **Developer (Me, the user)** → Refines, validates, and ensures correctness before sending instructions to the AI Editor. 284 | - **AI Editor** → Uses the instructions to generate code. 285 | 286 | # Steps 287 | 288 | - IMPORTANT RULE: **Explicit user confirmation is required at each step, wait for his approval before going to next step.** 289 | - Print current step at the beginning of each step. 290 | - Use short and concise bullets points, minimal words. 291 | 292 | ## Step: 1: Load the Knowledge Base 293 | - Please load "knowledgeBase". 294 | - Print all steps in short numbered list so the user know what we are doing. 295 | - If conversation is empty: Ask user "What is the feature you want to build?" 296 | - If conversation is not empty, go to next step. 297 | 298 | ## Step 2: Clarify intentions 299 | - Based on knowledge base, ask the user to clarify the intentions. 300 | - Challenge him, detect inconsistencies and ambiguities. 301 | - Challenge technical choices, how will it be implemented? 302 | 303 | ### Step 3: Confirmation by the developer 304 | - Print MAJOR tasks in groups. 305 | - ULTRA SHORT bullet points. 306 | - Split tasks in two parts: 307 | - First one for the Developer -- Configuration and tasks that need to be performed manually 308 | - Second one for the AI Editor -- Setup, code execution, and other tasks that can be automated. 309 | - Ask user (the developer ) to confirm each group of tasks. 310 | 311 | ### Step 4: Fill the "Instruction Template" 312 | 313 | - Fill "Instruction Template". 314 | - Write English, straight to the point, no emojis, no style except titles, use bullet points. 315 | - Replace placeholders (`{variables}`) with actual user inputs. 316 | - Define flow of the feature, from start to end of what AI Editor should do. 317 | 318 | Instructions Template in English: 319 | ```markdown 320 | # Instruction: {title} 321 | 322 | > Please follow this plan using proper rules. 323 | 324 | ## Goal 325 | {goal} 326 | 327 | ## Existing files 328 | 329 | {get affected files from knowledge base, no comments} 330 | 331 | ### New file to create 332 | 333 | {not found in knowledge base, no comments} 334 | 335 | ## Grouped tasks 336 | 337 | ### {Group 1} 338 | 339 | > {goal} 340 | 341 | - {task1, with logical bridge to task2} 342 | - {task2} 343 | ... 344 | 345 | ### {Group 2} 346 | 347 | > {goal} 348 | 349 | - {task1} 350 | ... 351 | 352 | ## Validation checkpoints 353 | 354 | - {verification1} 355 | ``` 356 | 357 | ### Step 5: Final Review 358 | - Translate in English. 359 | - Export in a Canvas. 360 | - Print official documentations URLs related to the feature. 361 | - Do a full review (list inconsistencies, ambiguities, missing details). 362 | - Evaluate confidence to implement, 0 = no confidence, 100 = 100% sure everything is correct. 363 | - Simulate the feature as you were hypothetically building it following the plan, identify what can go wrong. 364 | - Check for best practices. 365 | - Propose enhancements. 366 | - Independently check for: 367 | - **Completeness** → Are all key details covered? 368 | - **Correctness** → Are dependencies, versions, and steps accurate? 369 | - **Clarity** → Is the instruction unambiguous? 370 | - **Propose improvements in bullet points.** 371 | - **User Confirmation:** 372 | - Ask: **"Would you like to integrate these suggestions? (YES/NO)"** 373 | - If **NO** → Keep as is. 374 | - If **YES** → Apply the changes. 375 | 376 | - trigger: ':featurePath' 377 | form: | 378 | Goal: Create a detailed path to implement a feature before generating code. 379 | 380 | Feature: "[[feature_to_build]]" 381 | 382 | Rules: 383 | - Load projet's knowledge base with existing stack. 384 | - Based on requirements, look for online documentation to verify the feasibility. 385 | - List top 3 ways to do it. 386 | - Evaluate confidence level for each of the proposed ways. 387 | - Ask the user to choose the best way. 388 | - trigger: ':featureCreate' 389 | form: "Goal:\nBuild a new, existing or not, feature in our project.\n\nRules:\n- We proceed in **4 phases** (Specifications, Architecture, Action Plan, Final Export).\n- On 1st prompt, print 4 main phases with this one single line formatted as: \"Phase's title : Objective\".\n- Start directly with Phase 1. \n\n---\n\n## Process Overview\n\n### Phase 1: \U0001F9E0 Gather Specifications\n- **Objective**: Obtain project requirements and clarify purpose, features, constraints, and environment needs.\n- **Actions**:\n - All questions must be a concise, single line.\n - Ask targeted questions to confirm:\n - Functional requirements.\n - Chosen technologies, tools, or libraries (including **versions**).\n - When discussing tech, assert that used versions match the requirements.\n - Constraints (modularity, scalability, guidelines).\n - Environment setups (API tokens, configuration files).\n - Testing, Documentation, and CI/CD requirements.\n- **Output**:\n - A validated list of specifications.\n\n**Important**: Do not move to Phase 2 until the explicitly user confirms Phase 1.\n\n---\n\n### Phase 2: \U0001F9F1 Define or Refine Architecture\n- **Objective**: Collaboratively create or adjust the project's architecture.\n- **Actions**:\n - Specify folder structures, naming conventions, and core components (e.g., commands, utilities, events).\n - Define environment variables (with placeholder values).\n - Ensure modularity, scalability, and maintainability.\n - Check in the knowledge base if an architecture already exists. Then:\n - If you do have one, confirm with the user, confirm first it is up-to-date.\n - If you don't know it, ask the user to provide it. \n - If it doesn't exist, the user will let you know. \n - An updated (or newly created) architecture plan, ready for Markdown export (no emoji, no style in markdown, except titles).\n - If architecture already exists, only print affected files/folders (already existing or to be created).\n\n**Important**: Do not move to Phase 3 until the user confirms Phase 2.\n\n---\n\n### Phase 3: \U0001F5C2️ Develop a Detailed Plan of Actions\n- **Objective**: Outline each step to implement and configure the architecture.\n- **Rules**:\n - Not git actions, only technical steps.\n - No code generation, only setup instructions.\n - No assumptions, no \"not needed\" steps.\n - concentrate exclusively on the feature to be implemented, eg: do not mention naming conventions or code style.\n - Follow only the precise instructions and never install additional libraries unless explicitly requested.\n - Do not give code or commands to execute (e.g., `mkdir ...`); instead, say “create the new files/folders xxx.”\n- **Actions**:\n - **Configuration Tasks**: External dependency setup, token generation, key management, environment variables.\n - **Technical Setup**: Initializing the project, installing dependencies, creating files/folders.\n - Ensure each step is concise, bullet-pointed, and verified for successful compilation or runtime.\n- **Output**:\n - A validated, step-by-step action plan.\n - Be sure everything discussed on \"Phase 1\" is covered entirely.\n\n**Important**: Do not move to Phase 4 until the user confirms Phase 3.\n\nBefore going to phase 4, review the plan to check that good practices are enforced and plan is correct regarding the specifications.\n\n---\n\n### Phase 4: \U0001F9D1‍\U0001F4BB Export in Markdown\n- **Objective**: Produce a final Markdown document suitable for the “developer” and the “AI Editor.”\n- **Rules**: \n - Phase 4 must be answered in markdown format on a text block with 4 backticks.\n - Avoid repetition and focus only on the essentials.\n - No code generation or example but provide instructions on what to do.\n - Provide this phase in english.\n- **Actions**:\n - **Sections**:\n 1. **Actions for the \"developer\"**:\n - He should not touch the codebase, only external services that requires configuration.\n - Only **Configuration Tasks** (from Phase 3)\n 2. **Actions for the \"AI Editor\"**:\n - Explain in a short sentence the feature and summarize what do we want to code.\n - Is doing most of the work, it codes everything and change architecture if needed.\n - **Architecture** (from Phase 2): folder structure, components, environment variables etc.\n - **Technical Setup Instructions** (from Phase 3).\n - Give the instructions being very clear but concise, do not be very detailed, just the necessary.\n - **Output in english language.**\n - Add these custom instructions at the end of the document:\n - Never install additional libraries\n - Strictly follow the provided instructions\n - Follow plan in order, no skipping steps\n - Always adapt to current project rules and structure\n - Do all steps without asking\n - Always start with package installation if necessary\n - Use proper versions from package manager\n - Respect conventions, like naming and existing code patterns\n - **Formatting**:\n - Keep instructions concise, accurate, and actionable.\n - Use numbered bullet points to list steps.\n - **No examples**—strictly provide mandatory instructions.\n\n**Important**: Conclude only after Phase 4 is validated.\n\n---\n\n## **Instructions**\n1. **Start by outlining these four phases** to the user, confirming they understand the process.\n2. **Phase-by-phase approach**:\n - Always request and validate user input for each phase before proceeding.\n - **Never skip or combine phases**.\n3. **Never generate code**—you are the Architect, not the code generator.\n4. The final **Markdown document** must be separated into the sections listed under Phase 4.\n\n---\n\n## **Expected Final Output**\nWhen all phases are complete, you will produce a **Markdown document** containing:\n\n1. **Guide for the Developer**:\n - Validated specifications and project goals.\n - Configuration tasks (external dependencies, tokens, etc.).\n2. **Guide for the AI Editor**:\n - A strictly defined technical plan and instructions (folder structure, environment variables, setup steps).\n" 390 | - trigger: ':projectBootstrap' 391 | form: "## Goal \nYour objective is to **guide the developer through a structured decision-making process**, validating each step, resolving contradictions, and providing a **final architecture summary** with a **detailed folder structure**.\n\n## Roles\n- \"AI Architect\": You, the AI, will guide the user (me) through the process.\n- \"Developer\": The user (me) will provide the project description and answer your questions.\n\n## Context\nYou will load the knowledge base to get information about the project.\nThen, ask the user for missing information.\nYou must follow the \"Process\" section under and ask the question to the user.\nThe user will provide to you the answer, with a load of information.\nYour job is to analyze the answer, ask questions and refine the architecture, step by step. \n\n## Rules \n- **Check the existing knowledge database file** before proceeding. \n- **Analyze** the project thoroughly. \n- **Break down** the architecture into key sections. \n- **Ask only necessary questions** (adaptive, not excessive).\n- **Focus** only on the current section, DO NOT ASK QUESTIONS that will be asked later in the process.\n- **Validate** each choices the user makes to be sure this is relevant.\n- **No implementation details** in you answer, focus on making the best choices.\n\n## Steps to follow right after first message\n\n1. List documents loaded from knowledge base.\n2. Detail to the user the big steps we will do (only the titles -- e.g. \" 2. \U0001F680 **Hosting** & Deployment – Deciding on hosting, orchestration, CI/CD, and scaling strategy.\").\n3. Then, ask the user if he is ready to start. \n\n### Section Processing\n\nThis is very **IMPORTANT**, you must follow this process to ensure the best result.\n\nFor each section:\n1. **Pre-fill Information**\n - Review the knowledge base documents\n - Present any found information in parentheses to the user\n - Example: \"What type of application is it? (e.g., SaaS, internal tool, e-commerce, real-time system) -- (Found: SaaS)\"\n\n2. **Interactive Discussion**\n - Ask focused questions about missing information\n - Seek clarification on features and constraints\n - Guide user through decision-making process\n - Please discuss with the user and make sure you have all the information you need before proceeding to the next step.\n\n3. **Section Completion**\n - Present a concise summary of decisions\n - Review for consistency and completeness\n - Explicitly ask: \"Do you confirm we can proceed to the next section? (Please respond with 'YES')\"\n - Wait for explicit \"YES\" confirmation, DO NOT PROCEED TO THE NEXT SECTION IF NOT STRONGLY CONFIRMED.\n\n4. **Summarization**\n - Summarize all gathered information in a markdown text block (surrounded by 4 backticks)\n - Include all decisions and rationale\n - Format for clarity and future reference\n - Ask if this is correct, and wait for explicit \"YES\" confirmation\n\n5. **Progress**\n - Only after completion, move to the next section\n - Maintain structured progression through all sections\n\n---\n\n## Process\n\n- Prefill the answer for the user with gathered info from knowledge base in parenthesis.\n- Then, ask the user for missing information.\n\n### \U0001F3AF 1. Needs & Constraints Verification\n- What is the **goal of the project**? \n- What type of application is it? (e.g., SaaS, internal tool, e-commerce, real-time system) \n- What are the **main features and functionalities**? \n- Who are the **target users**? (e.g., general public, enterprise clients, internal employees) \n- Are there **any external integrations** required? (e.g., third-party APIs, payment gateways, authentication providers) \n---\n\n### \U0001F680 2. Hosting & Deployment\n- Where will the project be hosted? (e.g., cloud, on-prem, hybrid) \n- Is **orchestration** needed? (e.g., Kubernetes vs. serverless) \n- How should CI/CD be structured? \n- **Which Infrastructure as Code (IaC) tool should be used?** (e.g., Terraform, AWS CDK, Pulumi) \n- Expected **scale and traffic volume**?\n\n---\n\n### ⚙️ 3. Back-End Design\n- Which **back-end framework** should be used? (e.g., NestJS, FastAPI, Spring Boot) \n- Should we apply **Domain-Driven Design (DDD)**? \n- How should database access be organized? (e.g., ORM, Repository Pattern) \n- Are there any **scalability concerns** (e.g., horizontal scaling, multi-threading needs)? \n\n---\n\n### \U0001F3A8 4. Front-End Design\n- What **front-end framework** should be used? (e.g., React, Vue, Angular)? \n- Should the application be **Single Page Application (SPA), Server-Side Rendered (SSR), or hybrid**? \n- What **styling approach** should be used? (e.g., CSS-in-JS, SCSS, Tailwind)? \n- How should state management be handled? (e.g., Redux, Zustand, Vuex)? \n\n---\n\n### \U0001F4BE 5. Data & Database Management\n- Should we use **SQL or NoSQL**? Why? \n- What **database engine** should be used? (e.g., PostgreSQL, MySQL, MongoDB, DynamoDB)? \n- How should **schema versioning & migrations** be handled? (e.g., Liquibase, Flyway, Prisma)? \n- Should multi-tenancy be supported? \n- How should we ensure **performance optimization**? (e.g., indexing, caching, partitioning)? \n- What are the **consistency requirements**? (e.g., eventual vs. strong consistency)? \n- Is there any **search engine** to use? (e.g., Elasticsearch, OpenSearch, Meilisearch)\n\n---\n\n### \U0001F4E8 6. Event & Asynchronous Flow Management\n- Do we need **asynchronous processing**? If so, for what use cases? \n- What **event mechanisms** should be used? (e.g., Kafka, RabbitMQ, WebSockets, AWS SQS)? \n- Should **event sourcing or CQRS** be implemented? \n- How should **message delivery guarantees** be handled? (e.g., retries, dead-letter queues, idempotency)? \n\n---\n\n### 7 8. Security & Performance \n- Should we use **validation libraries**? (e.g., Joi, Zod) \n- What **authentication and authorization mechanisms** should be implemented? (e.g., OAuth2, JWT) \n- Are there **sensitive data** requiring encryption? \n- How can we optimize **latency and queries**? \n- What **caching mechanisms** should be used? (e.g., Redis, CDN, HTTP/2) \n\n---\n\n### \U0001F4CA 8. Observability & Maintenance \n- What **logging and monitoring tools** should be integrated? \n- How should **alerts and incidents** be managed? \n- How can we ensure **zero-downtime updates**? \n\n---\n\n### \U0001F4C1 9. Folder Structure & Project Organization \n- What **project organization pattern** should be followed? (e.g., modular monolith, feature-based, domain-based)? \n- How should **backend services** be structured? (e.g., clean architecture, hexagonal architecture, microservices)? \n- How should **frontend components** be organized? (e.g., feature-based, atomic design, MVC)? \n- What is the **preferred structure for configuration, environment files, and secrets**? \n\nNotes for the \"AI Architect\":\n- Asserts all information from the user are correct by validating with the user.\n- Generate full folder structure, with all files and folders for all sections.\n- Print the folder structure in a markdown text block (surrounded by 4 backticks).\n- Do not comments unless asked.\n" 392 | - trigger: ':projectEnforce' 393 | form: "## Goal \nAssist in setting up best practices for a newly created project through **step-by-step validation** and implementation. Each phase must be validated before proceeding to the next.\n\n## Roles \nYou are a DevOps and software engineering expert. Guide the user in selecting, validating, and implementing best practices with automation.\n\n## Process & Validation Steps \n\n### 1️⃣ Understanding the Project \n- Clarify project type, technologies, versions, and architecture.\n- Identify constraints (legacy dependencies, CI/CD tools). \n- Confirm understanding before proceeding. \n\nUser must **explicitly validate** this step before moving forward. \n\n---\n\n### 2️⃣ Selecting Best Practices & Tools \n\nEach tool is implemented **one by one** with detailed instructions.\nThe implementation of a tool **must be validated** before moving to the next.\n\nRules:\n- **Installation:** Provide the exact commands. \n- **Configuration:** Detail how to set up required configuration files. \n- **Best Practices:** Explain usage guidelines and potential issues. \n- **Validation:** Ensure the setup is functional before moving to the next tool. \n\nSteps: \n1. For each category, propose the **top 5** tools based on industry standards based on the developer's stack.\n2. Explain **pros and cons** in a table, mention if a tool covers multiple needs, and guide the user in making an informed choice. \n3. Each section MUST BE **validated independently** before going to the next. Example: On start, treat \"Code Quality & Standards\" with section \"Format\" only, then pass to \"Linting\", \"Commit Convention\" etc.\n4. Finally, ask the user \"Do you confirm the tools selected for each section?\". He must say \"YES\" to processed.\n5. Once validated: **IMPORTANT** - Summarize all gathered information in a markdown text block (surrounded by 4 backticks)\n - Translate in english.\n - Include all decisions, rationale and chosen implementation\n - Include configuration files, setup steps, and integration guidelines\n - Format for clarity and future reference\n6. Ask if this is correct, and wait for explicit \"YES\" confirmation\n\n#### \U0001F50D 1. Code Quality & Standards \n- **Format:** Propose formatting tools\n- **Linting:** Suggest linters based on the tech stack\n- **Commit Convention:** Recommend tools to enforce structured commits\n\n#### \U0001F4E6 2. Versioning & Release Management \n- **Semantic Versioning (SemVer):** Present versioning strategies or tools. \n- **Changelog Generation:** Suggest tools.\n- **Tagging Releases:** Recommend solutions for automated tagging. \n\n#### \U0001F680 3. CI/CD & Automation \n- **Pre-commit hooks:** List tools for pre-commit checks. \n- **Pre-merge validation:** Provide CI solutions ensuring validation before merging. \n- **CI/CD Pipeline:** Offer robust CI/CD solutions that fit the project stack. \n- **Container Tool**: Recommend containerization tools.\n\n#### \U0001F512 4. Security & Monitoring \n- **Security Audits:** Recommend tools for dependency and runtime security. \n- **Code Coverage:** Suggest tools for tracking test coverage. \n- **Dependencies update**: Offer solutions for automated dependency updates.\n\n#### \U0001F4DA 5. Documentation & Collaboration \n- **API Documentation:** Recommend documentation generators. \n- **Project Documentation:** Offer solutions for maintaining structured documentation. \n\n#### \U0001F465 6. Code Review \n- **Code Review:** Recommend tools for code review.\n- **AI Code Review:** Recommend tools for code review that use AI. \n\n---\n\n### 3️⃣ Optional Enhancements \nUser decides which enhancements to implement. Each selected enhancement follows the **same step-by-step process** as mandatory tools. \n\n#### Code Quality & Standards \n- Dead code detection. \n- Unused dependency detection. \n\n#### Versioning & Release Management \n- Automated package publishing. \n- Lockfile maintenance. \n\n#### CI/CD & Automation \n- Multi-environment deployments. \n- Rollback strategy. \n- Automatic branch cleanup. \n\n#### Security & Monitoring \n- Secret scanning. \n- Container security scanning. \n- License compliance checks. \n\n#### Documentation & Collaboration \n- Architecture documentation. \n- Automated diagram generation. \n\nEach selected enhancement is **fully implemented before moving to another**. \n\n---\n\n## Output Format \n1. **Phase 1: Understanding the project** → Confirm details before proceeding. \n2. **Phase 2: Selecting best practices & tools** → Validate tool choices **per category** before proceeding. \n3. **Phase 3: Optional enhancements** → Implement only if approved, using the same process. \n\nThis ensures a structured, interactive, and high-quality project setup.\n" 394 | - trigger: ':projectURL' 395 | form: "## Goal \nYour objective is to **help the developer structure the URL and API architecture**, ensuring a **clear, secure, and optimized system**. \nYou will validate each step, resolve contradictions, and provide a **final URL structure summary** with all necessary parameters and error-handling strategy.\n\n## Roles \n- \"AI Architect\": You, the AI, will guide the user (developer) through the process, acting as a Expert Software Architect. \n- \"Developer\": The user (developer) will provide project details and answer your questions. \n\n## Context \nYou will load the knowledge base to retrieve project information. \nThen, ask the user for missing details. \nYou must follow the **Process** section below and ask the user **only the relevant questions**. \nThe user will provide detailed answers, and you will analyze, refine, and optimize the URL and API structure step by step. \n\n## Rules \n- **Check the existing knowledge base file** before proceeding. \n- **Analyze** the project thoroughly. \n- **Break down** the URL structure into key sections. \n- **Ask only necessary questions** (adaptive, not excessive). \n- **Focus only on the current section**, do not ask questions that belong to a later section. \n- **Validate** each user choice to ensure relevance. \n- **No implementation details in your responses**, focus on making the best structural choices. \n\n## Steps to follow right after the first message \n\n1. **List documents loaded from the knowledge base**. \n2. **Provide an overview of the process steps** (only titles). \n3. **Explain that section processing consists of 5 steps**.\n4. **Ask the user if they are ready to start**. \n\n### Section Processing in 5 steps\n\nThis is very **important**, you must follow this process to ensure the best result. \n\nFor each section, follow these 5 steps:\n\n1. **Pre-fill Information** \n - Review the knowledge base documents. \n - Present any found information in parentheses to the user. \n - Example: \"Should the user ID be present in the URL? (Found: Yes, required for private pages)\" \n\n2. **Interactive Discussion** \n - Ask focused questions about missing information. \n - Seek clarification on URL conventions and API design. \n - Guide the user through the decision-making process. \n - Discuss with the user and ensure all required details are gathered before proceeding. \n\n3. **Section Completion** \n - Present a concise summary of decisions. \n - Review for consistency and completeness. \n - Explicitly ask: \"Do you confirm we can proceed to the next section? (Please respond with 'YES')\" \n - Wait for explicit \"YES\" confirmation.\n - **Do not export the section without strong confirmation**. \n\nImportant:\n- **Loop Until Confirmation** \n - **If the user does NOT Explicitly type 'GO'**, generate three **new** refining questions based on previous answers. \n - **Repeat the cycle** until explicit validation is received. \n - **Validation must be explicit**, ask the user \"Do you confirm we can proceed to the next section? (Please respond with 'GO')\".\n\n4. **Summarization just after a section completion and user validation** \n - Summarize all gathered information in a markdown text block (surrounded by four backticks). \n - Include all decisions and rationale. \n - Format for clarity and future reference.\n - Do not skip any details, output in short bullet points.\n - **Always export the whole section's conversation to avoid forget details.**\n - Ask if this is correct and wait for explicit \"YES\" confirmation. \n\n5. **Progress** \n - Only after completion, move to the next section. \n - Maintain structured progression through all sections. \n\n---\n\n## Process \n\n- Prefill the answer for the user with gathered information from the knowledge base in parentheses. \n- Then, ask the user for missing information. \n\n### \U0001F3AF 1. Project Context & Objectives \n- What are the main categories of routes to define (public, private, admin)? \n- Define the pages that need to be created (e.g., home, about, contact etc.).\n\n---\n\n### \U0001F310 2. Frontend URL Structure \n- Define **URL naming conventions** (default: Kebab Case, e.g., `/user-profile` instead of `/userProfile`). \n- Structure **path parameters vs. query parameters**. \n- Define **public vs. private vs. admin routes**. \n- Ensure **URL consistency with SEO best practices**. \n- Confirm that URLs **do not contain unnecessary sensitive data**. \n\n---\n\n### \U0001F50C 3. Backend API Design \n- Should the API use **REST, GraphQL, or both**? \n- Define the **URL structure for REST APIs** (e.g., `/api/v1/users/{id}` vs. `/api/v1/user-profile/{id}`). \n- Establish **conventions for nested resources** (e.g., `/users/{id}/orders`). \n- Define **pagination and filtering parameters** (`?page=2&limit=10`). \n- Determine **how to structure API versioning** (`/api/v1/...`). \n- Define **batch processing endpoints** for bulk operations. \n\n---\n\n### \U0001F512 4. Security & Access Management \n- Define **user roles and permissions** (admin, user, guest). \n- Ensure **private routes are properly protected**. \n- Implement **rate limiting and abuse protection**. \n- Define **authentication methods** (JWT, OAuth, API keys). \n- Handle **temporary session URLs** when necessary. \n\n---\n\n### ⚠️ 5. Error Handling & HTTP Status Codes \n- Define **consistent error responses** (structured JSON). \n- Implement standard **HTTP status codes**: \n - `200 OK` – Successful request \n - `201 Created` – Resource successfully created \n - `400 Bad Request` – Invalid request data \n - `401 Unauthorized` – Missing or invalid authentication \n - `403 Forbidden` – Access denied \n - `404 Not Found` – Resource does not exist \n - `429 Too Many Requests` – Rate limiting applied \n - `500 Internal Server Error` – Unexpected server issue \n\n---\n\n### \U0001F680 6. Performance & Caching Strategy \n- Define **which routes should be cached on the frontend**. \n- Implement **backend caching for expensive queries**. \n- Set **ETag and Cache-Control headers** for optimization. \n- Define **how long different responses should be cached**. \n\n---\n\n### \U0001F4CA 7. Monitoring & Scalability \n- Implement **API request logging and monitoring**. \n- Ensure **audit logs track API usage and access**. \n- Define **strategies for API scaling** (load balancing, CDNs). \n- Implement **error tracking and alerting mechanisms**. \n" 396 | - trigger: ':dbStructure' 397 | form: |+ 398 | # Prompt Structured for Data Schema & Generation 399 | 400 | ## Goal 401 | Your objective is to **guide the developer through a structured database design process**, validating each step, resolving contradictions, and providing a **final schema summary** with a **Mermaid class diagram and sample dataset**. 402 | 403 | ## Roles 404 | - "AI Architect": You, the AI, will guide the user (developer) through the process action as a Database Architect. 405 | - "Developer": The user (developer) will provide project details and answer your questions. 406 | 407 | ## Context 408 | You will load the knowledge base to retrieve project information. 409 | Then, ask the user for missing details. 410 | You must follow the **Process** section below and ask the user **only the relevant questions**. 411 | The user will provide detailed answers, and you will analyze, refine, and optimize the schema step by step. 412 | 413 | ## Rules 414 | - **Check the existing knowledge base file** before proceeding. 415 | - **Analyze** the project thoroughly. 416 | - **Break down** the schema into key sections. 417 | - **Ask only necessary questions** (adaptive, not excessive). 418 | - **Focus only on the current section**, do not ask questions that belong to a later section. 419 | - **Validate** each user choice to ensure relevance. 420 | - **No implementation details in your responses**, focus on making the best design choices. 421 | 422 | ## Steps to follow right after the first message 423 | 424 | 1. **List documents loaded from the knowledge base**. 425 | 2. **Provide an overview of the process steps** (only titles). 426 | 3. **Ask the user if they are ready to start**. 427 | 428 | ### Section Processing 429 | 430 | This is very **important**, you must follow this process to ensure the best result. 431 | 432 | For each section: 433 | 434 | 1. **Pre-fill Information** 435 | - Review the knowledge base documents. 436 | - Present any found information in parentheses to the user. 437 | - Example: "What type of application is it? (e.g., SaaS, internal tool, e-commerce, real-time system) -- (Found: SaaS)" 438 | 439 | 2. **Interactive Discussion** 440 | - Ask focused questions about missing information. 441 | - Seek clarification on features and constraints. 442 | - Guide the user through the decision-making process. 443 | - Discuss with the user and ensure all required details are gathered before proceeding. 444 | 445 | 3. **Section Completion** 446 | - Present a concise summary of decisions. 447 | - Review for consistency and completeness. 448 | - Explicitly ask: "Do you confirm we can proceed to the next section? (Please respond with 'YES')" 449 | - Wait for explicit "YES" confirmation. Do not proceed without strong confirmation. 450 | 451 | 4. **Summarization** 452 | - Summarize all gathered information in a markdown text block (surrounded by four backticks). 453 | - Only use emoji for the section title. 454 | - Include all decisions and rationale. 455 | - Format for clarity and future reference. 456 | - Ask if this is correct and wait for explicit "YES" confirmation. 457 | 458 | 5. **Progress** 459 | - Only after completion, move to the next section. 460 | - Maintain structured progression through all sections. 461 | 462 | --- 463 | 464 | ## Process 465 | 466 | - Prefill the answer for the user with gathered information from the knowledge base in parentheses. 467 | - Then, ask the user for missing information. 468 | 469 | ### 1. Project Context & Requirements 470 | - What is the **context of the project**? (e.g., e-commerce, SaaS, social network) 471 | - What **types of data** will be stored? (e.g., users, products, orders) 472 | - What is the **expected data volume**? (hundreds, thousands, millions of rows?) 473 | - What are the **most frequent operations**? (read, write, update, delete) 474 | - **SQL or NoSQL?** 475 | 476 | ### 2. SQL vs. NoSQL Specifics 477 | #### If SQL 478 | - Are there **complex relationships** to manage? (frequent joins, strict constraints) 479 | - Any **specific constraints**? (`UNIQUE`, `DEFAULT`, `FOREIGN KEY`) 480 | 481 | #### If NoSQL 482 | - How should data be **organized**? 483 | - **Embedding** (storing related data in a single document) 484 | - **Referencing** (using IDs to avoid duplication) 485 | - What is the **strategy for fast data access**? (e.g., partitions, separate collections) 486 | 487 | ### 3. Entity & Relationship Definition 488 | - What are the **main objects** in your project? (e.g., users, articles, orders) 489 | - What **fields** should be stored for each entity? (e.g., name, email, price, date) 490 | - How are entities **related**? 491 | - **1-1** (One user has one profile) 492 | - **1-N** (One user can have multiple orders) 493 | - **N-N** (One product can be ordered by multiple users) 494 | - Do you need to **store files or images**? (Yes/No) 495 | - Should an **audit log or history of changes** be stored? (Yes/No) 496 | 497 | **This is the most important section to validate with the user.** 498 | 499 | Important: 500 | - **Loop Until Confirmation** 501 | - **If the user does NOT Explicitly type 'GO'**, generate three **new** refining questions based on previous answers. 502 | - **Repeat the cycle** until explicit validation is received. 503 | - **Validation must be explicit**, ask the user "Do you confirm we can proceed to the next section? (Please respond with 'GO')". 504 | 505 | ### 4. Generating a Mermaid (Class) Diagram 506 | - **Generate an initial Mermaid diagram based on responses**. 507 | - **Display it to the user and ask for confirmation**. 508 | - **Allow modifications if necessary**. 509 | - **Validate the final structure before proceeding**. 510 | 511 | ### 5. Performance & Indexing 512 | - What **fields will be frequently searched**? 513 | - What **normalization level** is needed? 514 | - **1NF**: No duplicate data in columns. 515 | - **2NF**: Avoid redundant fields unrelated to the primary key. 516 | - **3NF**: No transitive dependencies. 517 | - **If NoSQL**, should data be structured to avoid **heavy queries**? 518 | 519 | ### 6. Generating Fixtures (Test Data) 520 | - Do you need **test data**? (Yes/No) 521 | - How much data is needed? 522 | - **10 examples** (unit tests) 523 | - **1,000 rows** (performance testing) 524 | - **Millions** (production simulation) 525 | - **Preferred method for data generation**: 526 | - **Faker.js** (Node.js) 527 | - **Factory Bot** (Rails) 528 | - **Pytest Fixtures** (Python) 529 | - **Raw SQL (`INSERT INTO ...`)** 530 | 531 | ### 7. Finalization & Output 532 | Once all questions are answered, the AI automatically generates: 533 | - Print the final output in a markdown text block (surrounded by four backticks). 534 | 535 | #### Sections to generate 536 | Please ensure every discussion you had with the user is included in the final output. 537 | 538 | 1. The list of choices made together, summarized in a short numbered list. 539 | 2. For each sections filled, generate: 540 | 1. Generate the full schema with all entities and relationships -> **the validated Mermaid diagram**. 541 | 2. **An optimization plan for indexing and normalization**. 542 | 3. **A instructions (only, no code) dataset for testing (fixtures)**. 543 | 544 | - trigger: ':dbGenSQL' 545 | form: | 546 | Goal: 547 | Generate SQL schema from specifications. 548 | 549 | Rules: 550 | - Generate the full SQL schema with : 551 | - tables 552 | - columns 553 | - relations between the tables 554 | - constraints 555 | 556 | Specifications: 557 | 558 | [[entity_list_and_relations_between_entities]] 559 | 560 | form_fields: 561 | entity_list_and_relations_between_entities: 562 | multiline: true 563 | - trigger: ':dbGenEntity' 564 | form: | 565 | Goal: 566 | Create entities from SQL Schema generating "[[objects___types___interfaces]]". 567 | 568 | SQL Schema: 569 | 570 | [[sql_schema]] 571 | 572 | 573 | Rules: 574 | 1. For each entity, ensure you generate the corresponding type. 575 | 2. For each relation, ensure relation is correctly defined. 576 | 3. No comment in code. 577 | 4. Suffix the type name with "Entity". 578 | form_fields: 579 | sql_schema: 580 | multiline: true 581 | objects___types___interfaces: 582 | type: list 583 | values: |- 584 | objects 585 | types 586 | interfaces 587 | - trigger: ':codePreview' 588 | form: | 589 | as a user in when implementing more complex features, I want to review the code first before clicking apply. In this instance, I would like to use the command D to select a function and see how that function is used throughout the code in the preview mode in the chat 590 | - trigger: ':codeFromPlan' 591 | form: | 592 | Please follow carefully the given plan below and generate the code accordingly. 593 | 594 | - Assert that similar code, functions, or files do NOT exist before creating new ones. 595 | - trigger: ':codeDeepResearch' 596 | form: | 597 | "I want you to write up-to-date, fantastic code that will run on the first try. Make sure you're referencing the official documentation for each library you are using to ensure that the code is going to run on the first try. Make sure everything is triple-checked. 598 | 599 | 600 | $describe_code_here 601 | 602 | 603 | Research and figure out how to do this. Once you're sure it's going to run on the first try and do exactly what I say, return it to me." 604 | - trigger: ':codeFake' 605 | form: | 606 | Goal: 607 | Generate a new variable filled with fake data. 608 | 609 | Rules: 610 | - Fill all fields with valid values. 611 | - Type of the data must be respected. 612 | - trigger: ':imageRepro1ExtractDetails' 613 | form: |+ 614 | # Goal 615 | Analyze the provided image to identify and extract the main components. 616 | Ensure to distinguish primary component groups and all sub-components on the page. 617 | Some components might be duplicated -> only extract unique components. 618 | 619 | # Steps 620 | 1. Identify all reusable component, group them by type. 621 | 2. Extract variants, merge closer variants. 622 | 3. Remove duplicates. 623 | 4. Hierarchical Organization. 624 | 625 | # Rules 626 | - Emoji are not components. 627 | - No need to detail photography. 628 | 629 | # Output Format Example 630 | ```yml 631 | main_reusable_components_with_variants: 632 | - name: "Chip" 633 | variants: 634 | - name: "Generate" 635 | style: "Purple text, rounded pill shape, small sparkle icon" 636 | ... 637 | 638 | ... 639 | 640 | main_display_components: 641 | - component_name: Hero Section 642 | layouts: 643 | - type: Vertical Stack 644 | style: "Centered alignment, full-width layout" 645 | position_and_display: "Top of page" 646 | 647 | components: 648 | - type: Text Block 649 | content: "For individuals, independent creators and tech companies" 650 | variant: "Heading" 651 | 652 | - type: Text Block 653 | content: "Empowering individuals, creators, and tech innovators with cutting-edge AI solutions." 654 | variant: "Subheading" 655 | 656 | - component_name: Feature Grid 657 | layouts: 658 | - type: Two-Column Layout 659 | style: "Even 2-column grid, responsive layout" 660 | position_and_display: "Below hero section" 661 | 662 | components: 663 | 664 | - component_name: Right Feature Card 665 | position_and_display: "Right column" 666 | layout: "Vertical stack" 667 | 668 | sub_components: 669 | - type: Text Block 670 | content: "Don’t write by yourself, it’s boring. Instead, let AI" 671 | variant: "Paragraph" 672 | 673 | - type: Chip 674 | content: "Enhance" 675 | variant: "Enhance" 676 | 677 | - type: Text Block 678 | content: "Your prompts" 679 | variant: "Paragraph" 680 | 681 | - type: BrowserWindowMockup 682 | variant: "Prompt Display Mockup" 683 | sub_components: 684 | - component_name: PromptCard 685 | layout: "Stacked content with prompt + tags" 686 | 687 | ... 688 | ``` 689 | 690 | - trigger: ':imageRepro2Refine' 691 | form: | 692 | # Goal 693 | Update our components design based on mockup source code. 694 | 695 | # Steps 696 | 1. Analyze provided source code. 697 | 2. Match elements. 698 | 3. Match source code style and params with our config. 699 | 4. Update styles (and content, if any). 700 | 5. Aim for **pixel-perfect accuracy**. 701 | 6. Ensure no missing details. 702 | 703 | # Rules 704 | - No CSS variables, match real values or our config. 705 | - No relative values, match closer codebase values. 706 | 707 | # Source code 708 | ```html 709 | [[html_code]] 710 | ``` 711 | form_fields: 712 | html_code: 713 | multiline: true 714 | - trigger: ':imageRepro3Implementation' 715 | form: | 716 | # Goal 717 | Implement this implement guide in our codebase with our components. 718 | 719 | # Rules 720 | - Integration of design only. 721 | - Use existing config: fonts, colors, lib etc. 722 | 723 | # Steps 724 | 1. List components / sub-components used in implementation guide. 725 | 2. Foreach: check existing component with variant. 726 | 3. List in table: component (exist?), variant (exist?), action. 727 | 4. Ask user for approval to implement the design in the codebase. 728 | 729 | # Context 730 | 731 | [[implementation_guide]] 732 | 733 | form_fields: 734 | implementation_guide: 735 | multiline: true 736 | - trigger: ':imageMCPAutoCorrection' 737 | form: |+ 738 | Goal: 739 | Make the UI pixel perfect by comparing it with the attached mockup. 740 | 741 | Steps: 742 | 1. Use MCP to screenshot current UI. 743 | 2. Compare it with attached mockup. 744 | 3. Identify and list matching components. 745 | 4. For each component, list all differences regarding "[[size___position___color___font___spacing___alignment]]" only. 746 | 5. Fix them. 747 | 6. Take a new screenshot of the current UI. 748 | 7. List all differences again. 749 | 8. Ask user, "do you want to repeat this process again?". 750 | 9. If user says "yes", repeat from step 1. 751 | 752 | Rules: 753 | - Do not focus on content changes, text is expected to be different. 754 | - Do not focus on functionality, only on the visual aspect. 755 | - Do not focus on logo or image content: you cannot reproduce them, focus instead on their position, size etc. 756 | - Log changes to not loop on the same differences. 757 | 758 | Template to use: 759 | 760 | ```markdown 761 | # Round [x] 762 | 763 | ## [Element Name] *(e.g. Navigation Bar)* 764 | 765 | **Description of the whole component being very detailed.** 766 | 767 | - Difference 1: [e.g. size] (current: 100px, expected: 120px) 768 | - Difference 2: [e.g. color] (current: #000000, expected: #FFFFFF) 769 | ... 770 | ``` 771 | 772 | form_fields: 773 | size___position___color___font___spacing___alignment: 774 | type: list 775 | values: |- 776 | size 777 | position 778 | color 779 | font 780 | spacing 781 | alignment 782 | - trigger: ':imageAdvancedImplementation' 783 | form: | 784 | Goal: 785 | Reproduce advanced and complexe design integration in my codebase by matching user explanation with the extracted code. 786 | 787 | The idea is to fill an amazing template for the developer who will implements those requirements in the codebase. 788 | 789 | **Your unique task is to explain in a very detailed way how the requirements is implemented in the extracted code, in a structure template.** 790 | 791 | User explanation (requirements): 792 | 793 | [[user_explanation]] 794 | 795 | 796 | Steps: 797 | 1. Gather requirements from the user. 798 | 2. Fill the template with the information, do not omit any details. 799 | 3. Do a review to ensure you forgot nothing. 800 | 801 | Developer Template to fill: 802 | - IMPORTANT: This is a minimal template, you can add any other information you want. 803 | - You must fill the template with EXACT VALUES extracted form the code. 804 | - Output the template in a markdown text block (surrounded by four backticks). 805 | 806 | ```markdown 807 | # Design Implementation 808 | 809 | **Description of the design and its purpose.** 810 | 811 | ## Animations 812 | 813 | ### Animation 1 814 | - **Trigger:** [e.g. on hover, on click] 815 | - **Duration:** [e.g. 0.3s] 816 | - **Easing:** [e.g. ease-in-out] 817 | - **Properties affected:** [e.g. opacity, transform] 818 | 819 | 820 | ## States 821 | 822 | ### State 1 823 | - **Trigger:** [e.g. on hover, on click] 824 | - **Properties affected:** [e.g. background color, border color] 825 | - **Implementation:** [e.g. CSS class, JavaScript function] 826 | 827 | ## Responsive Design 828 | 829 | ### Desktop 830 | 831 | - 832 | 833 | ### Tablet 834 | 835 | - 836 | 837 | ### Mobile 838 | 839 | - 840 | 841 | ``` 842 | 843 | 844 | Extracted code from webpage that need to be implemented in our codebase: 845 | 846 | [[code]] 847 | 848 | form_fields: 849 | user_explanation: 850 | multiline: true 851 | code: 852 | multiline: true 853 | - trigger: ':bugFinder' 854 | form: | 855 | 856 | Analyze and troubleshoot a bug by examining the provided message prompt, reviewing the project's existing knowledge base, and consulting the official documentation of potentially affected libraries. 857 | 858 | # Steps 859 | 860 | 1. **Receive Bug Message:** Understand and analyze the given bug description or error message. 861 | 2. **Knowledge Base Review:** Check the current project's knowledge base to understand context, dependencies, and any previous similar issues. 862 | 3. **Documentation Consultation:** Examine the official documentation for libraries or components potentially related to the bug. 863 | 4. **Probable Causes:** Identify and list probable causes of the bug based on gathered information. 864 | 5. **Detailed Analysis:** Perform an in-depth analysis of the bug, exploring each probable cause and factor contributing to the issue. 865 | 6. **Solution Proposal:** Propose the top three solutions to resolve the bug, considering feasibility and impact. 866 | 867 | # Output Format 868 | 869 | Provide the three recommended solutions in a bullet-point list. Each solution should include: 870 | - A description of the solution 871 | - An index of confidence in the percentage (e.g., 85%) 872 | - Any additional considerations or potential impacts of the solution 873 | 874 | # Examples 875 | 876 | **Example Input:** 877 | - Bug message: "[Placeholder for bug description]" 878 | - Relevant libraries: "[Placeholder for library names]" 879 | 880 | **Example Output:** 881 | - **Solution 1:** Increase timeout configuration to accommodate higher latency. (Confidence: 80%) This solution optimizes response time by adjusting settings in the configuration file, improving system stability under load. 882 | - **Solution 2:** Update library version to address known issue. (Confidence: 85%) The updated version includes a patch for the reported bug, reducing risk factors. 883 | - **Solution 3:** Refactor code to improve dependency management, potentially resolving conflicting calls. (Confidence: 75%) This solution involves significant code changes and testing to ensure compatibility. 884 | 885 | # Notes 886 | 887 | - Ensure that each solution takes into account both the ease of implementation and the potential impact on the system. 888 | - Remember to rank the proposed solutions according to feasibility and confidence levels. 889 | - Consider edge cases related to multi-threading, dependencies, and data handling. 890 | 891 | Train your analysis on data up to April 2024 for the most recent insights. 892 | - trigger: ':bugReveal' 893 | form: | 894 | Goal: Find the bug in my codebase based on the issue description. 895 | 896 | Issue: "[[issue_description]]". 897 | 898 | Expected behavior: "[[expected_behavior]]". 899 | 900 | Ordered Steps: 901 | - Summarize the issue with you own words. 902 | - List action paths between files (e.g. user clicks button -> calls function in file1 -> updates state in file2...). 903 | - Find relevant files to find bug in codebase based on issue description. 904 | - If necessary, put logging messages in the code to trace the issue. 905 | - List 3 best potential causes with small description + confidence level. 906 | - Wait for user's confirmation before proceeding. 907 | - Once confirmed, provide the 3 best steps to fix the issue. 908 | - Ask for confirmation before proceeding. 909 | - trigger: ':bugRethink' 910 | form: | 911 | Reflect on 5-7 different possible source of the problem, distill those down to 1-2 most likely sources, and the add logs to validate your assumptions before we move onto the implementing the actual code fix 912 | - trigger: ':debugLog' 913 | form: "Goal:\nAdd logging messages to the given code at each significant step.\n\nRules:\n- Use an appropriate emoji at the start of each log message for better visualization.\n- Annotate the code by adding logging messages at each significant step, including within inner functions.\n- Each log message must use a suitable emoji representing the step it corresponds to— for instance:\n - \U0001F6E0️ **Action Step** (When a particular action is being performed)\n - ✅ **Confirmation Step** (Verifying or completing an action)\n - \U0001F504 **Calling Function** (Log inner function calls)\n - ⚠️ **Handling Errors** (If logging at the point of error handling)\n- Each message must be descriptive to help in easy debugging of errors.\n- Ensure loggings are descriptive enough to aid in debugging but not too verbose as to overwhelm output.\n- Log points should include function calls, iteration starts, important decisions, error handling, and final steps.\n- The focus should be on enhancing clarity without compromising code functionality.\n" 914 | - trigger: ':debugInconsistency' 915 | form: | 916 | Goal: 917 | Review the given code and identify all inconsistencies. 918 | 919 | Check for inconsistencies in: 920 | - Variable names (naming conventions, typos, inconsistencies) 921 | - Function names (naming conventions, clarity, typos) 922 | - General code logic inconsistencies (ensure the code functions as intended) 923 | 924 | Only point out areas where issues exist. Do not provide commentary on parts of the code that are correct. 925 | 926 | Rules: 927 | - Ensure that the suggested solutions conform to the original context and maintain consistent naming conventions. 928 | - Address conflicting logic or discrepancies that might hinder the intended output of the program. 929 | - Avoid unnecessary complexity in suggestions; stick with simple and effective solutions that enhance consistency. 930 | - If similar inconsistencies occur repeatedly, note that they need to be corrected throughout the code. 931 | - trigger: ':testFirst' 932 | form: | 933 | Goal: 934 | Generate a unit test first, then write the implementation code. 935 | 936 | Steps: 937 | 1. Write tests first. 938 | 2. Generate implementation code. 939 | 3. Run tests until all pass. 940 | - trigger: ':testGenGherkin' 941 | form: | 942 | Goal: 943 | Interpret the following feature description to create a Gherkin-style user story. 944 | 945 | Rules: 946 | - Read the feature description: "[[as_i_want_so_that]]" 947 | - Based on this requirement, identify the key feature, the primary actions a user with a specific role would take, and the goals or outcomes expected from these actions. 948 | - Structure this information into a detailed Gherkin scenario using the Given-When-Then format. 949 | - The 'Given' step should establish the context, including the user's role. 950 | - The 'When' step should describe the user's actions. 951 | - The 'Then' step should specify the expected outcomes. 952 | 953 | Example output: 954 | ```gherkin 955 | # Gherkin Best Practices 956 | # --------------------- 957 | # 1. Use ubiquitous language 958 | # 2. One scenario = one test objective 959 | # 3. Avoid technical details in scenarios 960 | # 4. Favor Scenario Outlines for similar tests 961 | # 5. Keep scenarios short and concise (3-5 steps maximum) 962 | # 6. Use tags consistently 963 | # 7. Avoid dependencies between scenarios 964 | # 8. Name your scenarios descriptively 965 | # 9. Use Background for common steps 966 | # 10. Follow Given-When-Then format 967 | 968 | # language: en 969 | 970 | @tag @multiple_tags 971 | Feature: Feature name 972 | As a [role] 973 | I want [action] 974 | In order to [benefit/value] 975 | 976 | Background: 977 | Given [prerequisite 1] 978 | And [prerequisite 2] 979 | 980 | Scenario Outline: [parameterized scenario name] 981 | Given 982 | When 983 | Then 984 | 985 | Examples: 986 | | param1 | param2 | param3 | 987 | | val1 | val2 | val3 | 988 | | val4 | val5 | val6 | 989 | 990 | Scenario: [scenario name] 991 | Given [initial context] 992 | And [other context] 993 | When [action] 994 | And [other action] 995 | Then [expected result] 996 | And [other expected result] 997 | But [result exception] 998 | 999 | @specific_tag 1000 | Scenario: [scenario with doc string] 1001 | Given the following document: 1002 | """ 1003 | This is a document 1004 | with multiple lines 1005 | """ 1006 | When I process the document 1007 | Then the result should be: 1008 | """ 1009 | Expected result 1010 | with multiple lines 1011 | """ 1012 | 1013 | Scenario: [scenario with table] 1014 | Given the following users: 1015 | | name | email | role | 1016 | | John | john@email.com | admin | 1017 | | Mary | mary@email.com | standard | 1018 | When I check the permissions 1019 | Then I should see the corresponding access rights 1020 | - trigger: ':testUntested' 1021 | form: | 1022 | Goal: 1023 | List every untested behaviors. 1024 | 1025 | Rules: 1026 | - List every behavior that are not tested yet. 1027 | - Provide bullet list of untested behaviors. 1028 | - Output with "should {behavior}" format. 1029 | - Group those behaviors by distinct sections. 1030 | - Always on functional behavior, not on technical implementation. 1031 | 1032 | Implementation files to check: 1033 | #file 1034 | 1035 | Test files to check (if any): 1036 | #file 1037 | - trigger: ':testUnit' 1038 | form: | 1039 | **Context** 1040 | Generate a robust functional test for a specific use case. 1041 | The test must follow best practices, validate real user actions, and handle both normal and error scenarios. 1042 | It should focus on business functionality rather than technical aspects and adapt to the tools and frameworks available in the project. 1043 | 1044 | **Role** 1045 | Act as a software testing expert with 20+ years of experience in user-centric functional testing 1046 | You apply best practices and ensure tests reflect real-world user interactions within the business domain. 1047 | 1048 | **Action** 1049 | 1. **Identify user actions to test** : 1050 | - Analyze the provided domain logic in file. 1051 | - List all relevant user inputs and interactions. 1052 | - Cover both normal and erroneous user behaviors. 1053 | - Identify edge cases and unusual but possible user actions. 1054 | 1055 | 2. **Validate with the user** : 1056 | - Confirm the list of expected user actions and system responses. 1057 | 1058 | 3. **Generate test data** : 1059 | - Provide realistic user input scenarios (valid and invalid). 1060 | - Include cases where a user might make mistakes or unexpected actions. 1061 | - Ensure full coverage of business-critical situations. 1062 | 1063 | 4. **Adapt to project tools** : 1064 | - Detect and use the appropriate testing framework. 1065 | - Integrate with existing tools in project. 1066 | 1067 | 5. **Generate the user-centric functional test** : 1068 | - Produce a structured test script focusing on business logic. 1069 | - Write tests as if a user were interacting with the system. 1070 | - Validate expected behaviors from a business perspective. 1071 | - Ensure meaningful error handling and feedback to users. 1072 | 1073 | 6. **Verify and finalize** : 1074 | - Request user validation of the generated test. 1075 | - Suggest optimizations if needed. 1076 | 1077 | **Format** 1078 | The test will be generated as a code file in the project’s language. A structured summary of real-world test cases and business assumptions will also be provided. 1079 | - trigger: ':docReadMe' 1080 | form: | 1081 | You are an industry-leading Technical Documentation Expert with over 20 years of experience in writing world-class README files for software projects. Your job is to help me write a perfect, professional, and complete `README.md` file for my project through a structured, step-by-step collaboration. 1082 | 1083 | Follow this exact process: 1084 | 1085 | 1. Load knowledge base. 1086 | 1087 | 2. Based on that input, extract and display a short bullet list of key project facts: 1088 | - Project name 1089 | - Purpose / what it does 1090 | - Tech stack 1091 | - Target audience 1092 | - Any other key info you can infer 1093 | 1094 | 3. Ask me to confirm or correct that list before continuing. 1095 | 1096 | 4. Ask me a series of essential questions to fill in the rest of the README content. Include things like: 1097 | - What problem does this solve? 1098 | - Who is it for? 1099 | - How do users install it? 1100 | - Prerequisites or dependencies? 1101 | - Key features? 1102 | - Any usage examples? 1103 | - Contribution guidelines? 1104 | - Licensing? 1105 | - Links to demo/live version? 1106 | - Etc. 1107 | 1108 | 5. Once enough info is gathered, start building the README section by section. For each one: 1109 | - Generate a draft 1110 | - Ask me if I want to revise it or validate it 1111 | - Offer improvement suggestions based on best practices 1112 | 1113 | 6. Once every section is complete and approved, present a clean, **numbered bullet-point outline** of the entire README structure for final validation. 1114 | 1115 | 7. When I confirm the plan, generate the complete final `README.md` in **Markdown text format** surrounded by 4 backticks, **IN ENGLISH**. 1116 | 1117 | 8. At the end, ask me if I want: 1118 | - A translated version 1119 | - Extra badges or visuals 1120 | - Export options 1121 | 1122 | Use clear markdown, concise language, and developer-friendly formatting. 1123 | This README should be production-ready and follow industry standards. 1124 | 1125 | Let’s begin. 1126 | - trigger: ':docWireframeInstructions' 1127 | form: | 1128 | # Act as an expert in wireframe design. 1129 | 1130 | ## Objective 1131 | Create a comprehensive wireframe by gathering all necessary specifications and generating a detailed description in a clear and structured format. 1132 | 1133 | ## Before processing 1134 | **Load all documents from the knowledge base** and inform the user of existing files that you read. 1135 | 1136 | ## General Instructions 1137 | 1138 | Informe User about our process: 1139 | 0. "AI Architect" will load specifications from database. 1140 | 1. Clarify requirements. 1141 | 2. Review and challenge user. 1142 | 3. Wireframe instructions and elements proposal. 1143 | 1144 | ### 1) Clarify requirements** by asking questions 1145 | 1146 | > On first chat, please gather info from knowledge base and fill your answer with these info. 1147 | 1148 | - Purpose of the wireframe (website, app, dashboard…). 1149 | - General structure (pages, main sections). 1150 | - Specific elements (header, footer, sections, buttons). 1151 | - Organization and hierarchy of elements. 1152 | - Positioning and alignment of blocks. 1153 | - Example texts and CTAs. 1154 | - Constraints (mobile, responsive, technical limitations). 1155 | 1156 | ### 2) Review and challenge user 1157 | 1158 | - Look for inconsistencies or missing details. 1159 | - Ask for clarification on vague points. 1160 | 1161 | ### 3) Generate a detailed wireframe instructions for the designer 1162 | 1163 | > Propose to the user the corresponding elements / blocks for each section. 1164 | > Fill its plan so it is very detailed. 1165 | 1166 | - **Translate** the instructions in English. 1167 | - **Clear list** of sections and subsections. 1168 | - **Elements included** in each section. 1169 | - **Alignment and positioning** of blocks. 1170 | - **Types of buttons and links** (primary, secondary, CTA). 1171 | - **Example texts** for each component. 1172 | - **Interactions** if necessary (hover, popup etc.) 1173 | 1174 | **Constraints:** 1175 | - No colors, specific typography, or exact margins. 1176 | - No responsive details unless explicitly requested. 1177 | 1178 | ### 4) Final review 1179 | 1180 | **Ask yourself**: 1181 | - Does the designer has all needed elements? 1182 | - Is everything clear and detailed enough regarding components? 1183 | - Is there any missing information? 1184 | - Is placement and alignment clear? 1185 | 1186 | ### 5) Final export 1187 | 1188 | Ensure the plan: 1189 | - Is in english. 1190 | - Well detailed. 1191 | - Clear and structured. 1192 | - No Emojis. 1193 | - No styling expect for titles. 1194 | - trigger: ':mdMerge' 1195 | form: | 1196 | find . -type f -print0 | \ 1197 | grep -zE '\.(md|mdx|rst)$' | \ 1198 | grep -vzZ 'all.md' | \ 1199 | sort -zV | \ 1200 | while IFS= read -r -d '' file; do 1201 | echo "$file" # Affiche uniquement le chemin du fichier 1202 | { 1203 | echo -e "\n---\nFile: $file\n---\n" 1204 | cat "$file" 1205 | echo "" # Ajoute une ligne vide après chaque fichier 1206 | } >> all.md 1207 | done 1208 | - trigger: ':docMermaid' 1209 | form: | 1210 | ## Goal 1211 | Generate a HIGH QUALITY Mermaid diagram from Markdown content. 1212 | 1213 | ## Roles 1214 | - "AI Architect": You, the AI, will act as a Senior Software Architect that produces very high-quality Mermaid diagrams. 1215 | 1216 | ## Steps 1217 | 1218 | > On first chat, please print in short bullet points those 6 steps we will follow. 1219 | 1220 | 1. Ask for the document to convert. 1221 | 2. Once provided, analyze and write down a very detailed and exhaustive plan for the diagram, identify at least: 1222 | - Components (main elements, logical groups) (in colors) 1223 | - Children and parents elements 1224 | - Directions and hierarchies 1225 | - Relationships (in colors, connections and dependencies) 1226 | - Notes and labels needed for each element if any 1227 | 3. Ask user: "Do you confirm the plan?" and wait for user confirmation. 1228 | 4. Generate the 100% valid Mermaid diagram from the plan. 1229 | 5. Ask user: "Do you want me to review it?" and wait for user confirmation. 1230 | 6. If the user confirms, review the diagram and suggest improvements : 1231 | - Check syntax 1232 | - DO NOT add any extra elements 1233 | - Look for empty nodes or misplaced elements 1234 | - Ensure styling is correct 1235 | - Upgrade styles if necessary 1236 | 1237 | ## Rules 1238 | 1239 | - Chart type: "[[bestformat___flowchart___classdiagram___sequencediagram___statediagramv2___erdiagram___journey___timeline]]". 1240 | - Flow: "[[lefttoright___toptobottom]]". 1241 | - Use Mermaid v10.8.0 minimum. 1242 | - 100% valid Mermaid diagram is required. 1243 | - Read the rules under "Mermaid generation rules" section. 1244 | 1245 | ### Mermaid generation rules 1246 | 1247 | **Header**: 1248 | - Use "---" to define the header's title. 1249 | 1250 | **States and nodes**: 1251 | - Define groups, parents and children. 1252 | - Fork and join states. 1253 | - Use clear and concise names. 1254 | - Use "choice" when a condition is needed. 1255 | - No standalone nodes. 1256 | - No empty nodes. 1257 | 1258 | **Naming**: 1259 | - Consistent naming 1260 | - Descriptive names and labels (no "A", "B"... use meaningful uppercase names) 1261 | - Escape quotes. 1262 | - NEVER use "\n". 1263 | - Replace ":" with "$" in state names if any. 1264 | 1265 | **Links**: 1266 | - Use direction when possible. 1267 | - "A -- text --> B" for regular links. 1268 | - "A -.-> B" for conditional links. 1269 | - "A ==> B" for self-loops. 1270 | 1271 | **Styles**: 1272 | - Forms: 1273 | - Circles for states 1274 | - Rectangles for blocks 1275 | - Diamonds for decisions 1276 | - Hexagons for groups 1277 | - Max 4 colors in high contrast. 1278 | 1279 | **Miscellaneous**: 1280 | - Avoid `linkStyle`. 1281 | form_fields: 1282 | bestformat___flowchart___classdiagram___sequencediagram___statediagramv2___erdiagram___journey___timeline: 1283 | type: list 1284 | values: |- 1285 | best-format 1286 | flowchart 1287 | classDiagram 1288 | sequenceDiagram 1289 | stateDiagram-v2 1290 | erDiagram 1291 | journey 1292 | timeline 1293 | lefttoright___toptobottom: 1294 | type: list 1295 | values: |- 1296 | left-to-right 1297 | top-to-bottom 1298 | - trigger: ':maintenanceUpdateDeps' 1299 | form: |+ 1300 | Goal: 1301 | Update the dependencies of the project to the latest versions. 1302 | 1303 | Rules: 1304 | - Follow provided upgrade instructions. 1305 | - Information in your knowledge base might be wrong, always check the official documentation. 1306 | 1307 | Steps: 1308 | - List essentials steps for the upgrade. 1309 | - Check the provided configuration files. 1310 | - Update the dependencies. 1311 | - Update the configuration files. 1312 | - Check upgrades match the upgrade guides. 1313 | 1314 | Update Instructions URLs: 1315 | - [[upgrade_guide_url]] 1316 | - [[changelog_url]] 1317 | 1318 | Configuration files: 1319 | 1320 | form_fields: 1321 | upgrade_guide_url: 1322 | multiline: true 1323 | changelog_url: 1324 | multiline: true 1325 | - trigger: ':maintenanceUpdateFramework' 1326 | form: | 1327 | Goal: 1328 | Upgrade the framework to the latest version. 1329 | 1330 | Steps: 1331 | 1. Load knowledge base 1332 | 2. Scrape the migration guide from this URL: "[[url]]" 1333 | 3. Draw a full plan of the upgrade. 1334 | 4. Compare with existing project structure to identify necessary changes. 1335 | 5. List all files to be changed. 1336 | - trigger: ':refactSuggest' 1337 | form: | 1338 | Goal: Refactor the code to improve readability, maintainability, and performance. 1339 | 1340 | Steps: 1341 | - List stack that is used. 1342 | - List existing design patterns or specifications. 1343 | - Analyze the code and identify areas for improvement. 1344 | - Suggest refactoring techniques to enhance the code. 1345 | - Provide a detailed explanation for each suggestion. 1346 | - Ensure the code remains functional and efficient after refactoring. 1347 | 1348 | Constraints: 1349 | - Wait for developer to approve the plan, do not apply it until confirmation 1350 | - trigger: ':refactComment' 1351 | form: | 1352 | # Goal 1353 | Add comments to the code to enhance readability, but only focusing on complex logic or technically challenging parts. 1354 | 1355 | # Steps 1356 | 1. **Identify Complex Logic**: Review each section of the code to determine if the logic is nontrivial or could benefit from an explanation. 1357 | 2. **Explain Technical Challenges**: For technically hard-to-understand components, provide detailed comments to clarify how the code works. 1358 | 3. **Avoid Unnecessary Comments**: Do not add comments for self-explanatory code or for describing typed function parameters. 1359 | 1360 | # Output Format 1361 | Code with comments added directly above or next to complex logic or technically challenging parts. 1362 | 1363 | # Rules 1364 | - Make sure EVERY EXISTING AND NEWLY ADDED comments are matching the code. If NOT, comment with a "⚠️". 1365 | - Focus on clarity and precision in the comments. 1366 | - Ensure comments enhance understanding without cluttering the code. 1367 | - Preserve existing formatting and style of the code wherever possible. 1368 | - DO NOT comment obvious code sections or simple logic, remember we are senior developers. 1369 | 1370 | # Consider 1371 | 1. Code quality and adherence to best practices 1372 | 2. Potential bugs or edge cases 1373 | 3. Performance optimizations 1374 | 4. Readability and maintainability 1375 | 5. Any security concerns 1376 | 1377 | Suggest improvements and explain your reasoning for each suggestion. 1378 | - trigger: ':refactGeneric' 1379 | form: | 1380 | Goal: 1381 | I want to make this file generic so it can "[[purpose]]". 1382 | 1383 | Context: 1384 | Follow content in variable that need to be extracted (also check for specific elements that I might have missed.): 1385 | 1386 | [[specific_elements_that_must_be_extracted]] 1387 | 1388 | 1389 | Rules: 1390 | 1. List all the elements that need to be extracted. 1391 | 2. List all the elements that do not need to be removed. 1392 | 3. List the steps to achieve the refactoring. 1393 | 4. Provide the code to add or modify (do not make unnecessary changes). 1394 | form_fields: 1395 | specific_elements_that_must_be_extracted: 1396 | multiline: true 1397 | - trigger: ':refactSRP' 1398 | form: | 1399 | Goal: 1400 | Analyze the provided code and outline a refactoring plan SRP-compliant. 1401 | 1402 | Steps: 1403 | - Identify the main responsibilities of the code. 1404 | - Split the code into separate functions or classes based on responsibilities. 1405 | - Ensure each function, component or class has a single responsibility. 1406 | - Provide a detailed explanation for each refactoring step. 1407 | - Ensure the code remains functional and efficient after refactoring. 1408 | - trigger: ':refactOpt' 1409 | form: | 1410 | Goal: 1411 | Beautify, comment and refactor the given code snippet. 1412 | 1413 | Rules: 1414 | - Use proper types 1415 | - Beautify the code 1416 | - Limit functions to 20 lines when possible, 50 at most. 1417 | - Comment the code if necessary 1418 | - Make sure comments are: not redundant, not obvious, not repetitive, not too long, not too short 1419 | - Comments must match the code! 1420 | - Rewrite variable names if necessary 1421 | - Make the code more readable 1422 | - Use clean code practices 1423 | - Respect good coding guidelines 1424 | - Keep the same logic and behavior 1425 | - If necessary, use those refactoring techniques: 1426 | - Extract method. 1427 | - Inline method. 1428 | - Rename method. 1429 | - Move method. 1430 | - Group similar methods, variables or properties. 1431 | - Encapsulate field. 1432 | - Decompose conditional. 1433 | - Consolidate conditional expression. 1434 | - Consolidate duplicate conditional fragments. 1435 | - Remove assignments to parameters. 1436 | - Make sure the code is still readable and maintainable, doing its best to keep the same logic. 1437 | - trigger: ':refactPerf' 1438 | form: | 1439 | Goal: 1440 | Optimize code for performance and scalability. 1441 | 1442 | Goal: 1443 | I need you to improve the performance of the following code: #selection. 1444 | 1445 | Steps: 1446 | 1. Find the main performances issues in the code. 1447 | 2. List the necessary steps to improve the performance of the code. 1448 | 3. Implement the necessary changes to improve the performance of the code. 1449 | 4. Make sure the code is still readable and maintainable. 1450 | 5. Propose at the end 3 other ways to improve the code's performance, sorted by importance. 1451 | 1452 | Rules: 1453 | - Do not change the logic of the code. 1454 | - Input and output of the code should remain the same. 1455 | - trigger: ':refactFile' 1456 | form: | 1457 | 1. Gather user info. 1458 | 2. Address a refactoring plan, Challenge the user. 1459 | 3. Once agreed, execute the plan. 1460 | - trigger: ':adviceReview' 1461 | form: "You are a senior principal software engineer reviewing AI-generated code for integration into a production project.\n\nYour task is to conduct a deep technical review and return actionable feedback in the format below.\n\nYou must ensure the code:\n- Is placed in the correct file, with clear responsibility\n- Follows all project conventions and architecture rules\n- Follows clean code principles (DRY, KISS, SOLID, etc.)\n- Is readable, maintainable, modular\n- Avoids unnecessary complexity or duplication\n- Handles edge cases and avoids potential bugs\n- Is type-safe and testable\n- Avoids performance issues and security vulnerabilities\n- Is optimized and refactored where appropriate\n- Has no redundant logic\n- Aligns code with any provided comments\n- Applies missing best practices if needed\n\nRespond using the following structure (do not focus on already existing good practices):\n\n\U0001F4C2 File Placement & Responsibility \n\U0001F9F1 Style & Architecture Compliance \n\U0001F9FC Clean Code Issues \n\U0001F441️ Readability & Maintainability \n\U0001F44C Type Safety \n\U0001F41E Bug Risks & Edge Cases \n⚡ Performance & Security Concerns \n\U0001F6E0️ Optimization & Refactoring Suggestions \n\U0001F9E9 Redundancy & Duplication \n\U0001F4DD Comments vs Code \n" 1462 | - trigger: ':adviceArchitecture' 1463 | form: "As a software architect, you are tasked with conducting a comprehensive audit of a project structure. \n\nBrief:\nYou are required to review, criticize the project structure and identify potential issues that could impact the project's maintainability, scalability, and overall efficiency.\n\nGoal:\nPropose improvements to the project structure to enhance its quality and ensure that it aligns with best practices.\nFeat every issue regarding the \"Project\" info and its tech stack.\n\nRules:\n- Empty files or folders.\n- Duplicate files.\n- Large files.\n- Overly nested folders.\n- Overloaded folders.\n- Inefficient project structure.\n- Inconsistent naming conventions, generic names, or unclear file organisation.\n- Files in the wrong directory.\n- Use architecture best practices.\n- Find inconsistencies and risks.\n- Propose actions to improve existing architecture.\n\nTasks:\n1. List rules to check in bullet points, then add more relevant ones regarding the project stack (suffix those by \U0001F195 emoji to identify them) that can be detected using project structure and package manager file.\n2. List every potential issue in the project structure.\n3. For each issue, find all affected file or folder because the audit needs to be exhaustive.\n4. Do not provide issue if there is no recommendation to solve it.\n5. Only answer using \"Tasks\" and \"Template\" sections.\n\nTemplate:\n\"\"\"\n# Architecture Audit\n\n* Main technologies used in list.\n* Description of the project.\n\n## (emoji) Title of the issue\n\nVery short explanation of the issue and why it is problematic.\n\n* List of every affected files or folders.\n * ...\n* Explanation of the issue.\n* Short explanation of recommendations to solve the issue, provide tools or methods if necessary.\n * ...\n* Example of how the issue can be fixed.\n\"\"\"\n\nFinal steps at the end of the audit, ask the user to type:\n1) Continue audit and ask user to specify more rules of your own.\n2) Re-audit the project dismissing correct points.\n3) Reupload new project structure and Re-audit.\n4) Continue audit, AI will try to find new issues.\n" 1464 | - trigger: ':adviceDesignPatterns' 1465 | form: | 1466 | Goal: 1467 | List the existing design patterns in the following code. 1468 | 1469 | Rules: 1470 | - List the existing design patterns in the following code. 1471 | - Then, provide a list of design patterns that can be implemented in the selected codebase. 1472 | 1473 | For each design pattern, provide: 1474 | - A very brief description of the design pattern. 1475 | - Why it is effective. 1476 | - The benefits and drawbacks of using the design pattern. 1477 | - An example of how the design pattern can be implemented in the selected technology. 1478 | - trigger: ':pmMilestones' 1479 | form: | 1480 | # GOAL 1481 | We need a macro-level project plan focusing on features, constraints, and key objectives. 1482 | We will: 1483 | 1. Extract project info. 1484 | 2. Clarify scope and define milestones. 1485 | 3. Outline epics for each milestone. 1486 | 4. Produce a final Markdown document. 1487 | 1488 | # ROLES 1489 | - **AI Architect (Assistant)** 1490 | - Asks questions. 1491 | - Generates short, focused outputs. 1492 | - **Developer (User)** 1493 | - Provides info. 1494 | - Types “go” (on a line alone) to move on. 1495 | 1496 | # CONTEXT 1497 | We want a high-level overview. 1498 | No deep technical details. 1499 | Short statements only. 1500 | 1501 | # RULES 1502 | - Do not advance to the next section without the exact word “go” on its own line. 1503 | - Remain in the current section until “go.” 1504 | - Use concise sentences. 1505 | 1506 | # STEPS 1507 | 1508 | ## Section 1: Extraction 1509 | 1. State “Section 1: Extraction.” 1510 | 2. Ask for the project document. 1511 | 3. Extract and list: type, technologies, main goal, constraints, key features, estimated MVP duration. 1512 | 4. Invite user to correct. 1513 | 5. Wait for “go.” 1514 | 1515 | ## Section 2: Clarification & Milestones 1516 | 1. State “Section 2: Clarification & Milestones.” 1517 | 2. Ask questions to refine scope. 1518 | 3. Propose milestones in bullet points. 1519 | 4. Discuss. 1520 | 5. Wait for “go.” 1521 | 1522 | ## Section 3: Epics 1523 | 1. State “Section 3: Epics.” 1524 | 2. For each milestone, propose epics in bullet points. 1525 | 3. Adjust if needed. 1526 | 4. Wait for “go.” 1527 | 1528 | ## Section 4: Final Document 1529 | 1. State “Section 4: Document.” 1530 | 2. Produce one Markdown block with four backticks: 1531 | - Title “Milestones” 1532 | - Subsections “Epics” for each milestone 1533 | - Emojis for milestones 1534 | - Short sentences only 1535 | 3. End. 1536 | - trigger: ':pmSpecs' 1537 | form: "Act as an **interactive project specification assistant**, help me build and refine a complete, well-organized project specification document. \n\n## Objectives:\n- Guide me through filling out a Markdown-based template step-by-step.\n- Organize input logically, even if provided out of order.\n- Ensure completeness and high-quality detail in every section.\n\n## Instructions for Interaction:\n1. **Start the Process** \n - Begin by asking, \"Tell me about your project.\"\n - Provide an overview of the main sections in the template (use only headings from the Markdown).\n - For every answer, ask follow-up questions to gather more details but ONLY regarding that specific section.\n - Propose the user to move to the next section BUT ONLY after completing every steps of the current one.\n - Always validate with the user by asking him if everything is correct before moving to the next section.\n\n2. **Guide Input** \n - For each subsection:\n - Ask targeted questions to gather relevant details (limit to 3 short bullet points for guidance). \n - Challenge or refine unclear answers to ensure quality.\n - Summarize inputs after completion of each subsection and confirm with me before proceeding.\n\n3. **Maintain Structure** \n - Organize all inputs according to the template format. Fill placeholders with responses as I provide them.\n - Highlight incomplete sections and ask whether to revisit or move forward.\n\n4. **Completion Process** \n - After filling each sections like section 2 (##):\n - Ask for final edits or approval.\n - When the template is approved, please follow those steps:\n - For each section of the template we discussed, output the fully complet section in markdown format.\n - Never skip anything, provide the full details of the section.\n - Output format in text block surrounded by 4 backticks.\n\n## Markdown Template Overview:\n\n\n## Important rules:\n- If the user is talking about a subject from an existing section but not the current one, ask them to wait because this will be treated afterwards.\n- If this user puts a subject that is not in the template, put it at the end of the template and ask the user if they want to add it.\n- When filling document, reformulate the user's answers to make them more concise and clear, use bullet points when necessary, remember that people that will read this document must be aware of every details.\n- At the end of the section, ask the user if everything is correct and if he wants to add something?\n\n## Let's start:\n- After first message, clarify with the user what we are going to do here:\n - Output the plan\n - Tell him we are going to:\n - Gather its project info\n - Go through the template\n - Assert everything is valid, helping him to write good specifications\n - Then export it to markdown so he can update its based document.\n- First, ask the user if some documents already exists.\n - If so, ask for him to upload them. then, once processed, go through the template to improve his document.\n - The document is supposed to help you \"pre-filled\" the section, but you must ALWAYS validate it with the user.\n - This document might not be complete or up-to-date, be careful.\n - Ask the user for more details after pre-filling the section, ask questions to go deeper.\n - For each question you ask, if you already have the answer, ask the user if it is still valid in parenthesis, but keep you original questions too.\n - If not, let's begin. Tell me about your project so we can start filling out the first section: Initial Conceptualization.\n" 1538 | - trigger: ':pmTechStack' 1539 | form: | 1540 | Regarding the technology project I am planning and specifying, I need guidance on selecting the right tools and frameworks. 1541 | I have a team of developers (which may consist of just one developer) ready to work on this, and they are open to learning new technologies if needed. 1542 | Please base your answers on the template we filled out together. 1543 | 1544 | Here are the key aspects of my project and requirements: 1545 | 1546 | 1. Overview of Developer Skills (please review the developers' expertise based on their web resumes): 1547 | 1548 | [[please_provide_urls_to_the_developers_resumes_for_reference]] 1549 | 1550 | 2. Project Needs: I'm considering various technologies for different aspects of the project, though not all may be necessary. The needs will depend on the chosen tools. For example, if I am using Next.js with Vercel, a separate database might not be required. 1551 | My tech stack could include: 1552 | - Frontend frameworks. 1553 | - Frontend UI libraries or frameworks (must be compatible with the chosen frontend framework). 1554 | - Browser extension guidelines (optional depending on specifications). 1555 | - Backend (optional depending on specifications). 1556 | - User authentication systems. 1557 | - Database (optional depending on specifications). 1558 | - Web hosting with email service (optional depending on specifications). 1559 | - Version control platform with Continuous Integration (CI). 1560 | - Containerization (optional depending on specifications). 1561 | 1562 | Please assess the necessity of each component based on my project requirements. 1563 | 1564 | 3. Selection Criteria: 1565 | - My project requirements from the template we filled out together. 1566 | - Performance: The solutions should be fast and efficient. 1567 | - Ease of Use: User-friendly and quick to implement. 1568 | - Cost-Effectiveness: Affordable options are preferred. 1569 | - Integration: Technologies should work well together. 1570 | - Community Support: Select technologies with strong community backing and ongoing updates. Avoid tools that are not actively maintained (e.g., Express.js, which is popular but no longer backed). 1571 | - Time to Market: Focus on a rapid launch for a Minimum Viable Product (MVP). 1572 | 1573 | Based on these criteria and the developers' expertise, what technology stack would you recommend for each requirement? (If more than one tool is necessary, please specify.) 1574 | 1575 | Please format your answer like this (surrounded by "---" delimiters): 1576 | --- 1577 | Project Needs: 1578 | - Recommended Technology. 1579 | - Rationale. 1580 | - Required for this project based on the template (y/n with brief explanation). 1581 | - Alternative Option. 1582 | --- 1583 | 1584 | Afterward, please justify your choices in relation to my project requirements. 1585 | form_fields: 1586 | please_provide_urls_to_the_developers_resumes_for_reference: 1587 | multiline: true 1588 | - trigger: ':chatTop3' 1589 | form: | 1590 | Goal: 1591 | Provide the top 3 answers to the question. 1592 | 1593 | Rules: 1594 | - Answer in markdown format. 1595 | - Use bullet points. 1596 | - Detail each answer. 1597 | - trigger: ':chatSummarize' 1598 | form: | 1599 | Please summarize the last answer in one short concise sentence (but do not lose any information), be more precise and accurate. 1600 | - trigger: ':chatOnline' 1601 | form: | 1602 | Goal: 1603 | Search in online documentation "[[search_query]]". 1604 | 1605 | Rules: 1606 | - Write down what the search query is about. 1607 | - In bullet point, list top 3 results from the search query. 1608 | - If you can't find the answer, say so. 1609 | - If you find the answer, write it in markdown format. 1610 | - trigger: ':chatFr' 1611 | form: | 1612 | For all answers, answer in French. 1613 | - trigger: ':chatOutputMd' 1614 | form: | 1615 | Please output document in markdown formatted on a text block surrounded by 4 backticks. 1616 | - trigger: ':chatKB' 1617 | form: | 1618 | Before proceeding, load the knowledge base to ensure the most accurate and up-to-date information is used in the response. 1619 | 1620 | List documents loaded from knowledge base in bullet points. 1621 | - trigger: ':chatEvaluate' 1622 | form: | 1623 | Thank you. Now: 1624 | 1625 | 0) Output text in user's preferred language. 1626 | 1627 | 1) Evaluate your own work. List all its strength and flaws. 1628 | 1629 | 2) Give it a mark between 0 and 20. Justify your mark with an argumentative paragraph. 1630 | 1631 | 3) Give yourself a list of suggestions that will make the mark 20. Number each suggestion. 1632 | 1633 | 4) Rewrite your work by following recommendations from point 3). Annotate each suggestion that you apply with their respective number within the text. 1634 | 1635 | 5) Ask me if I want to repeat the process again. We well be doing so until your work is marked 20/20. 1636 | - trigger: ':chatRestart' 1637 | form: |+ 1638 | Goal: 1639 | Relaunching a Complex Conversation 1640 | 1641 | Context: 1642 | - This will help us start a new conversation from scratch with a new LLM model. 1643 | - This is useful when the current conversation is too complex or has diverged from the main topic. 1644 | - Please summarize everything we discussed so far. 1645 | - Export the final summary in markdown formatted text block surrounded by 4 backticks. 1646 | 1647 | Template to use: 1648 | ```markdown 1649 | ## **Summary of Key Takeaways** 1650 | We discussed [sujet principal] and explored [specific areas]. The main goal was to [objective]. Here's a concise summary of what was accomplished: 1651 | - **Core decisions taken:** [Key points]. 1652 | - **Challenges remaining:** [Brief overview of unresolved issues]. 1653 | - **Next priorities:** [Clear and actionable next steps]. 1654 | 1655 | --- 1656 | 1657 | ## **Decisions Taken** 1658 | 1. **[Decision 1]:** [What and why]. 1659 | 2. **[Decision 2]:** [What and why]. 1660 | 3. **[Decision 3]:** [What and why]. 1661 | 1662 | --- 1663 | 1664 | ## **Challenges Remaining** 1665 | - **[Unresolved Topic 1]:** [Reason for lack of resolution]. 1666 | - **[Unresolved Topic 2]:** [Reason for lack of resolution]. 1667 | 1668 | --- 1669 | 1670 | ## **Exclusions** 1671 | 1. **[Excluded Point 1]:** [Reason]. 1672 | 2. **[Excluded Point 2]:** [Reason]. 1673 | 1674 | --- 1675 | 1676 | ## **Next Steps (Quick Reference)** 1677 | - **[Step 1]:** [Brief and actionable description]. 1678 | - **[Step 2]:** [Brief and actionable description]. 1679 | - **[Step 3]:** [Brief and actionable description]. 1680 | 1681 | --- 1682 | 1683 | ## **Instructions for Continuation** 1684 | With this context, help refine the following: 1685 | 1. [Specific refinement needed]. 1686 | 2. [Second area for improvement]. 1687 | 3. [Additional question to explore]. 1688 | ``` 1689 | 1690 | - trigger: ':contentRephrase' 1691 | form: | 1692 | Goal: 1693 | Rewrite this text to make it shorter and clearer by removing repetitions and unnecessary details. 1694 | 1695 | Rules: 1696 | Maintain logic. 1697 | Remove stop words. 1698 | Go straight to the point. 1699 | Keep original language. 1700 | - trigger: ':contentFocus' 1701 | form: | 1702 | ## Goal 1703 | Rephrase the given text in "[[language]]" while maintaining its original meaning and intent. 1704 | 1705 | ## Rules 1706 | - Concise & Clear: Remove unnecessary words but keep full clarity. 1707 | - Direct & Blunt: Avoid sugarcoating or softening the message. 1708 | - Essential Only: Keep the key points; cut out fluff. 1709 | - Same Structure: Match the original format (sentences, lists, paragraphs). 1710 | - Tone Preservation: Maintain the same tone (formal, informal, persuasive, etc.). 1711 | - Preserved all code blocks, commands, and URLs 1712 | 1713 | ## Steps 1714 | 1. **Analyze the text**: Identify core meaning and intent. 1715 | 2. **Remove excess**: Cut unnecessary words while keeping clarity. 1716 | 3. **Rephrase efficiently**: Use direct, impactful wording. 1717 | 4. **Match tone**: Keep the same formality and emotional weight. 1718 | 1719 | ## Example 1720 | **Input**: "In light of recent developments, it has become increasingly apparent that we need to reconsider our approach." 1721 | **Output**: "Recent developments show we must rethink our approach." 1722 | 1723 | ## Given text 1724 | 1725 | [[given_text]] 1726 | 1727 | form_fields: 1728 | given_text: 1729 | multiline: true 1730 | - trigger: ':contentFocusBenefits' 1731 | form: | 1732 | ## Goal 1733 | Rewrite the given text to emphasize **benefits, outcomes, and advantages** using persuasive copywriting techniques. 1734 | 1735 | ## Role 1736 | Act as a **conversion-focused copywriter**. Use compelling language that captures attention and drives action. 1737 | 1738 | ## Rules 1739 | - Use same tone. 1740 | - Highlight what the user gains, not just features. 1741 | - Use clear, results-driven wording. 1742 | – Match tone and vocabulary. 1743 | – Remove unnecessary words, maximize clarity. 1744 | - Use Proven Copywriting Model AIDA (Attention, Interest, Desire, Action)** 1745 | – Default method. 1746 | - No emojis or special characters. 1747 | - Make sentences smaller and more readable. 1748 | 1749 | ## Steps 1750 | 1. Extract Key Benefits : Identify how the product or service improves the user’s life. 1751 | 2. Reframe for Impact : Rewrite the text with a stronger benefit-first focus. 1752 | 3. Use Persuasive Wording : Make the benefits clear, urgent, and emotionally compelling. 1753 | 4. Ensure Readability : Keep sentences short and structured for easy scanning. 1754 | 5. Output : Markdown formatted in a text block with 4 backticks. 1755 | 1756 | ## Text to Optimize 1757 | 1758 | [[insert_text_here]] 1759 | 1760 | form_fields: 1761 | insert_text_here: 1762 | multiline: true 1763 | - trigger: ':contentSummarize' 1764 | form: | 1765 | Goal: 1766 | Please summarize everything you just said. 1767 | 1768 | Rules: 1769 | - Keep it concise. 1770 | - Include all key points. 1771 | - Provide configuration if necessary. 1772 | 1773 | Output: 1774 | - Format output in a markdown text block surrounded by 4 backticks. 1775 | - trigger: ':cmdEmptyFolders' 1776 | form: | 1777 | find . -type d -empty -exec rm -i -d {} + 1778 | - trigger: ':osxBrew' 1779 | form: | 1780 | brew update && brew outdated --greedy && brew upgrade --greedy && brew cleanup && brew doctor 1781 | - trigger: ':reasonCodeAudit' 1782 | form: | 1783 | Act as a globally recognized developer specialized in Domain-Driven Design (DDD). 1784 | Perform a thorough **code audit**. 1785 | Use the **functional documentation** to verify business intentions. 1786 | Use the **technical documentation** to confirm technical implementation. 1787 | Identify gaps, coding issues, and **DDD** misalignments. 1788 | Provide a **concise audit report** with clear findings and actionable recommendations. 1789 | 1790 | # Scope 1791 | - Analyze all relevant modules or files. 1792 | - Focus on DDD patterns, code quality, and alignment with business intentions. 1793 | 1794 | # Steps 1795 | 1. **Check Business Intent** 1796 | - Compare code to functional requirements. 1797 | - Highlight any discrepancies. 1798 | 2. **Check Technical Implementation** 1799 | - Compare code to technical specs. 1800 | - Note bad practices or optimization needs. 1801 | 3. **Identify Improvements** 1802 | - Evaluate code against DDD principles. 1803 | - Recommend structural, performance, or domain-driven adjustments. 1804 | 4. **Audit Report** 1805 | - Provide findings in short, bullet-point form. 1806 | - Suggest concrete actions for each issue. 1807 | 1808 | # Constraints 1809 | - Write in **English**. 1810 | - Be **concise**, direct, and clear. 1811 | - Use **bullet points** and simple headings. 1812 | - Include code examples **only if necessary**. 1813 | 1814 | # Project requirements, documentations and specifications 1815 | 1816 | 1817 | ONE_FILE_KNOWLEDGE_BASE_HERE 1818 | 1819 | ``` 1820 | 1821 | # Codebase 1822 | 1823 | 1824 | REPOPROMPT_YOUR_CODE_HERE 1825 | 1826 | ``` 1827 | - trigger: ':presentationCreate' 1828 | form: | 1829 | **Context:** 1830 | You are creating a comprehensive outline for a course or presentation, aiming to clearly organize content into structured, logical groupings from high-level topics to detailed granular points. This outline will help clarify ideas, efficiently group related elements, and prepare for detailed content development. 1831 | 1832 | **Role:** 1833 | You are an expert educational curriculum designer and professional presenter with over 20 years of experience. You excel at structuring curriculum and presentations in a clear, engaging, and highly organized manner, moving logically from broad concepts to specific details. 1834 | 1835 | **Process:** 1836 | 1. **Brainstorm with the user** to define the main high-level topics (level 1 titles). 1837 | 2. Identify logical **sub-sections** within these topics (level 2 titles). 1838 | 3. Progressively **detail each sub-section** further into granular points (levels 3, 4, and if necessary, level 5). 1839 | 4. Clearly indicate points that require further development by enclosing them in parentheses with ellipses (detail 1, detail 2, ...). 1840 | 5. **Wait for the user approval**, then do a big review, looking for inconsistencies, missing points, or unclear organization. 1841 | 6. Output document in markdown formatted on a text block surrounded by 4 backticks. 1842 | 1843 | **Format (strictly markdown numbered list):** 1844 | 1. Main Topic 1845 | 1.1. Sub-section 1846 | 1.1.1. Detailed Point (detail 1, detail 2, ...) 1847 | 1.1.1.1. Further Detailed Point (example, note, ...) 1848 | 1.1.1.1.1. Highly Specific Point (additional info, further explanation, ...) 1849 | 1850 | **Example (Introduction to Artificial Intelligence for Developers):** 1851 | 1. Introduction to Artificial Intelligence 1852 | 1.1. AI Fundamentals 1853 | 1.1.1. Definition of AI (AI basics, core concepts, ...) 1854 | 1.1.2. Relevance for Developers (productivity enhancement, workflow integration, ...) 1855 | 1.2. Practical AI Applications 1856 | 1.2.1. Common Use Cases (automation, analysis, prediction, ...) 1857 | 1.2.2. Tools and Resources (frameworks, APIs, platforms, ...) 1858 | 1859 | **Assessments:** 1860 | - Suggest assessment methods to gauge understanding (quizzes, practical tasks, projects, ...). 1861 | 1862 | **Implementation Guidance:** 1863 | - Provide concise suggestions on effectively structuring and delivering content to optimize learner engagement and retention. 1864 | - Recommend methods to incrementally introduce complexity while maintaining clarity and coherence throughout the program. 1865 | - trigger: ':presentationExpand' 1866 | form: |+ 1867 | 1868 | - trigger: ':presentationConvert' 1869 | form: |+ 1870 | 1871 | 1872 | 1873 | -------------------------------------------------------------------------------- /index.js: -------------------------------------------------------------------------------- 1 | const fs = require('fs'); 2 | const parseMarkdown = require('./src/espanso-generation/parseMarkdown'); 3 | const generateYaml = require('./src/espanso-generation/generateYaml'); 4 | const { extractScripts } = require('./src/extract-scripts'); 5 | const glob = require('glob'); 6 | 7 | console.log('🚀 Starting script...'); 8 | 9 | const espansoOSXPath = `${process.env.HOME}/Library/Application Support/espanso/match/packages/`; 10 | 11 | const newEspansoPrivateFolder = `${espansoOSXPath}/espanso-private`; 12 | 13 | if (!fs.existsSync(newEspansoPrivateFolder)) { 14 | console.log('📂 Creating espanso config directory...'); 15 | fs.mkdirSync(newEspansoPrivateFolder, { recursive: true }); 16 | } 17 | 18 | const PRIVATE_PROMPTS = ['./prompts/private/*']; 19 | const PUBLIC_PROMPTS = [ 20 | // './../agents/README*', 21 | './README*', 22 | './CONTRIBUTION*', 23 | ]; 24 | 25 | console.log('📝 Writing public prompts...'); 26 | fs.writeFileSync( 27 | './espanso/package.yml', 28 | getPromptsContentForEspanso(PUBLIC_PROMPTS) 29 | ); 30 | 31 | console.log('📝 Writing private prompts...'); 32 | fs.writeFileSync( 33 | `${newEspansoPrivateFolder}/package.yml`, 34 | getPromptsContentForEspanso(PRIVATE_PROMPTS) 35 | ); 36 | 37 | console.log('📝 Writing manifest...'); 38 | fs.writeFileSync( 39 | `${newEspansoPrivateFolder}/_manifest.yml`, 40 | `name: 'espanso-private' 41 | title: 'AI Driven Dev Prompts (Private)' 42 | description: A collection of your private prompts (not committed onto GitHub). 43 | version: 0.1.0 44 | author: alexsoyes () 45 | website: https://github.com/alexsoyes/ai-driven-dev-community` 46 | ); 47 | 48 | console.log('📝 Writing README...'); 49 | fs.writeFileSync(`${newEspansoPrivateFolder}/README.md`, `Your custom prompts!`); 50 | 51 | console.log('🔍 Extracting scripts from markdown...'); 52 | extractScriptsFromMarkdownToFiles(PUBLIC_PROMPTS); 53 | 54 | console.log('✅ Script finished.'); 55 | 56 | /** 57 | * Generates the content for Espanso configuration from the given directories. 58 | * 59 | * @param {string[]} directories - An array of directories containing markdown files. 60 | * @returns {string} The generated YAML content for Espanso. 61 | */ 62 | function getPromptsContentForEspanso(directories) { 63 | console.log('🔄 Generating prompts content for Espanso...'); 64 | const header = 'matches:\n'; 65 | let yamlContent = header; 66 | 67 | for (const promptDirectory of directories) { 68 | const markdownFiles = glob.sync(promptDirectory + '.md'); 69 | 70 | for (const markdownFile of markdownFiles) { 71 | yamlContent += getPrompts(markdownFile); 72 | } 73 | } 74 | 75 | return yamlContent; 76 | } 77 | 78 | /** 79 | * Generates the prompts for a given markdown file. 80 | * 81 | * @param {string} filePath - The path to the markdown file. 82 | * @returns {string} The generated YAML content for the markdown file. 83 | */ 84 | function getPrompts(filePath) { 85 | console.log(`🔄 Generating prompts for file "${filePath}"`); 86 | const markdownText = fs.readFileSync(filePath, 'utf8'); 87 | const espansoConfig = parseMarkdown(markdownText); 88 | return generateYaml(espansoConfig).split('\n').slice(1).join('\n') + '\n'; 89 | } 90 | 91 | /** 92 | * Extracts scripts from markdown files in the given directories and writes them to files. 93 | * 94 | * @param {string[]} directories - An array of directories containing markdown files. 95 | * @returns {void} 96 | */ 97 | function extractScriptsFromMarkdownToFiles(directories) { 98 | console.log('🔄 Extracting scripts from markdown files...'); 99 | for (const promptDirectory of directories) { 100 | const markdownFiles = glob.sync(promptDirectory + '.md'); 101 | 102 | for (const markdownFile of markdownFiles) { 103 | extractScripts(markdownFile); 104 | } 105 | } 106 | } -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "ai-driven-dev-prompts", 3 | "version": "2.0.49", 4 | "description": "Meilleures collections de prompts communautaires pour les développeurs.", 5 | "main": "index.js", 6 | "jest": { 7 | "testEnvironment": "node" 8 | }, 9 | "scripts": { 10 | "start": "node index.js", 11 | "test": "jest", 12 | "test:watch": "jest --watchAll", 13 | "pre-commit": "./.husky/pre-commit" 14 | }, 15 | "keywords": [ 16 | "espanso", 17 | "developers", 18 | "prompts", 19 | "ai", 20 | "gen-ai", 21 | "ai-driven-dev" 22 | ], 23 | "author": "alexsoyes", 24 | "dependencies": { 25 | "markdown-it": "^14.0.0", 26 | "yaml": "^2.3.4" 27 | }, 28 | "devDependencies": { 29 | "jest": "^29.7.0", 30 | "prettier": "^3.2.4", 31 | "husky": "^8.0.0" 32 | } 33 | } 34 | -------------------------------------------------------------------------------- /src/espanso-generation/README.txt: -------------------------------------------------------------------------------- 1 | # Espanso config file generation from markdown prompts 2 | 3 | ## Goals 4 | 5 | 1. Have a script that convert the markdown prompts into a yml config file that can be used by Espanso. 6 | 7 | 2. The markdown prompt file looks like this: 8 | 9 | ### Global dev prompts 10 | 11 | Related to prompts chatting. 12 | 13 | #### Who am I? `:prtsme` 14 | 15 | ```text 16 | I am a senior software engineer on JavaScript but I prefer to use TypeScript. 17 | 18 | The libraries I am using are: React, NextJS, Zod, React-Hook-Form, Tailwind. 19 | 20 | I need help to write 100% working and clean code. 21 | ``` 22 | 23 | #### My project configuration `:prproject` 24 | 25 | ```text 26 | I need help for my current project and I need you to help me as an experimented mentor, developer and agile coach. 27 | 28 | My project is about: 29 | 30 | [[Fully detailed explanation]] 31 | 32 | This only project I will refer to you within this conversation is only about this one. 33 | 34 | I will try to always provide to you the relevant code associated to the feature or bug or whatever I talk you about. 35 | 36 | The code will be surrounded by ", whenever possible. 37 | 38 | Technically speaking, here are the libs we are using for our project: 39 | 40 | "[[package.json or equivalent]]" 41 | ``` 42 | 43 | 3. So in your example, this would work create the following yml Espanso config file: 44 | 45 | matches: 46 | - trigger: ":prtsme" 47 | form: | 48 | I am a senior software engineer on JavaScript but I prefer to use TypeScript. 49 | 50 | The libraries I am using are: React, NextJS, Zod, React-Hook-Form, Tailwind. 51 | 52 | I need help to write 100% working and clean code. 53 | 54 | - trigger: ":prproject" 55 | form: | 56 | I need help for my current project and I need you to help me as an experimented mentor, developer and agile coach. 57 | 58 | My project is about: 59 | 60 | [[full_detailed_explanation]] 61 | 62 | This only project I will refer to you within this conversation is only about this one. 63 | 64 | I will try to always provide to you the relevant code associated to the feature or bug or whatever I talk you about. 65 | 66 | The code will be surrounded by ", whenever possible. 67 | 68 | Technically speaking, here are the libs we are using for our project: 69 | 70 | "[[package_json_or_equivalent]]" 71 | form_fields: 72 | fully_detailed_explanation: 73 | multiline: true 74 | 75 | 4. To convert from markdown to yml, we do: 76 | - create "- trigger:" from markdown titles (from title 2 to title 6, it can have multiple #), since it is fitting the following pattern "# Text `:trigger`" 77 | - "form: |" content is taken from inner text in those blocks: ```text ``` 78 | - variable (surround be [[ ]]) need to be converted in snake_case, from [[the text of the variable]] to [[the_text_of_the_variable]] in the content 79 | - if there is any variable like [[my var]] without any surrounding " (like "[[]]"), then the following end block should be added in the yml file for this section: 80 | form_fields: 81 | my_var: 82 | multiline: true 83 | 84 | 85 | -------------------------------------------------------------------------------- /src/espanso-generation/__snapshots__/generateYaml.test.js.snap: -------------------------------------------------------------------------------- 1 | // Jest Snapshot v1, https://goo.gl/fbAQLP 2 | 3 | exports[`generateYaml should generate valid YAML with multi-line strings and variables 1`] = ` 4 | "matches: 5 | - trigger: ':prproject' 6 | form: |- 7 | I need help for my current project and I need you to help me as an experimented mentor, developer and agile coach. 8 | 9 | My project is about: 10 | 11 | [[fully_detailed_explanation]] 12 | 13 | This only project I will refer to you within this conversation is only about this one. 14 | 15 | I will try to always provide to you the relevant code associated to the feature or bug or whatever I talk you about. 16 | 17 | The code will be surrounded by ", whenever possible. 18 | 19 | Technically speaking, here are the libs we are using for our project: 20 | 21 | "[[package_json_or_equivalent]]" 22 | 23 | [[i_am_focus_on_frontend_____i_am_focus_on_backend]] 24 | form_fields: 25 | fully_detailed_explanation: 26 | multiline: true 27 | i_am_focus_on_frontend_____i_am_focus_on_backend: 28 | type: list 29 | values: |- 30 | I am focus on frontend 31 | I am focus on backend 32 | " 33 | `; 34 | -------------------------------------------------------------------------------- /src/espanso-generation/__snapshots__/parseMarkdown.test.js.snap: -------------------------------------------------------------------------------- 1 | // Jest Snapshot v1, https://goo.gl/fbAQLP 2 | 3 | exports[`parseMarkdown should accept trigger headings ending with (WIP) 1`] = ` 4 | [ 5 | { 6 | "choices": {}, 7 | "form": "I need you to help me think about the best way to implement this new functionality: 8 | [[new_functionality]] 9 | 10 | Please provide the best coding steps regarding my existing code. 11 | ", 12 | "trigger": "codeCodingHelpThinking", 13 | "variables": [ 14 | "new_functionality", 15 | ], 16 | }, 17 | { 18 | "choices": {}, 19 | "form": "I need you to improve the readability of the following code. 20 | 21 | Result should remain the same, but the code should be easier to read and understand. 22 | ", 23 | "trigger": "codeCodingImproveReadability", 24 | "variables": [], 25 | }, 26 | { 27 | "choices": {}, 28 | "form": "Provide an example of the usage of this function, input and output. 29 | ", 30 | "trigger": "codeCodingProvideExampleUsage", 31 | "variables": [], 32 | }, 33 | ] 34 | `; 35 | -------------------------------------------------------------------------------- /src/espanso-generation/convertToYaml.js: -------------------------------------------------------------------------------- 1 | const yaml = require('js-yaml'); 2 | 3 | /** 4 | * 5 | * @param {import('./parseMarkdown').EspansoConfig[]} espansoConfig 6 | * @returns 7 | */ 8 | function convertToYaml(espansoConfig) { 9 | const yamlConfig = { 10 | matches: espansoConfig.map((item) => { 11 | const match = { 12 | trigger: `:${item.trigger}`, 13 | replace: item.form, 14 | }; 15 | 16 | if (item.variables.length > 0) { 17 | /** 18 | * Get the multiline variables. 19 | * 20 | * @description This object will be used to create the form_fields object. 21 | * @type {Object.} 22 | * 23 | * @example input 24 | * ```js 25 | * { 26 | * variable1: {multiline: true}, 27 | * variable2: {multiline: true} 28 | * } 29 | * ``` 30 | * 31 | * @example output 32 | * ```yml 33 | * Output: 34 | * form_fields: 35 | * variable1: 36 | * multiline: true 37 | * variable2: 38 | * multiline: true 39 | * ``` 40 | */ 41 | match.form_fields = item.variables.reduce((fields, variable) => { 42 | fields[variable] = { multiline: true }; 43 | return fields; 44 | }, {}); 45 | } 46 | 47 | return match; 48 | }), 49 | }; 50 | 51 | return yaml.dump(yamlConfig); 52 | } 53 | 54 | module.exports = convertToYaml; -------------------------------------------------------------------------------- /src/espanso-generation/generateYaml.js: -------------------------------------------------------------------------------- 1 | /** 2 | * @module generateYaml 3 | * 4 | * @description This module contains a function that transforms an espanso configuration into a YAML string. 5 | * 6 | */ 7 | const yaml = require('js-yaml'); 8 | 9 | /** 10 | * Transforms an espanso configuration into a YAML string. 11 | * @param {import('./parseMarkdown').EspansoConfig} espansoConfig 12 | * @example 13 | * const espansoConfig = [{ 14 | * trigger: 'trigger', 15 | * form: 'form', 16 | * variables: ['variable1', 'variable2'], 17 | * choices: { 'variable1': ['choice1', 'choice2'] }, 18 | * }]; 19 | * 20 | * const yamlString = generateYaml(espansoConfig); 21 | * 22 | * @returns {string} The YAML string. 23 | */ 24 | function generateYaml(espansoConfig) { 25 | const yamlConfig = { 26 | matches: espansoConfig.map((configItem) => { 27 | const matchItem = { 28 | trigger: `:${configItem.trigger}`, 29 | form: configItem.form, 30 | }; 31 | 32 | // If there are variables, add form_fields 33 | if (configItem.variables.length > 0) { 34 | matchItem.form_fields = {}; 35 | configItem.variables.forEach((variable) => { 36 | // Construct the pattern to search for the variable enclosed in double quotes 37 | const pattern = `"[[${variable}]]"`; 38 | // Check if the pattern is not included in the replace string 39 | if (!variable.includes('___') && !matchItem.form.includes(pattern)) { 40 | // Add the variable to form_fields with multiline set to true 41 | matchItem.form_fields[variable] = { multiline: true }; 42 | } 43 | }); 44 | } 45 | 46 | // If there are choices, add them to form_fields 47 | if (configItem.choices && Object.keys(configItem.choices).length > 0) { 48 | matchItem.form_fields = matchItem.form_fields || {}; 49 | Object.entries(configItem.choices).forEach(([variable, choices]) => { 50 | matchItem.form_fields[variable] = { 51 | type: 'list', 52 | values: choices.join('\n'), 53 | }; 54 | }); 55 | } 56 | 57 | // Remove form_fields object if it's empty 58 | if ( 59 | matchItem.form_fields && 60 | Object.keys(matchItem.form_fields).length === 0 61 | ) { 62 | delete matchItem.form_fields; 63 | } 64 | 65 | return matchItem; 66 | }), 67 | }; 68 | 69 | // Convert the JavaScript object to a YAML string 70 | // Use the "styles" option to specify custom styles for different data types 71 | return yaml.dump(yamlConfig, { 72 | lineWidth: -1, // Disable line wrapping 73 | noRefs: true, // Prevent creating YAML references 74 | noCompatMode: true, // Disable compatibility mode to allow special characters in strings 75 | styles: { 76 | '!!null': 'canonical', // Dump null as ~ 77 | '!!bool': 'lowercase', // Dump boolean values in lowercase 78 | '!!int': 'decimal', // Dump integers in decimal format 79 | '!!float': 'lowercase', // Dump floats in lowercase 80 | '!!str': 'fold', // Use block style for multi-line strings 81 | }, 82 | quotingType: '"', // Use double quotes for strings 83 | }); 84 | } 85 | 86 | module.exports = generateYaml; 87 | -------------------------------------------------------------------------------- /src/espanso-generation/generateYaml.test.js: -------------------------------------------------------------------------------- 1 | const generateYaml = require('./generateYaml'); 2 | 3 | describe('generateYaml', () => { 4 | it('should generate valid YAML with multi-line strings and variables', () => { 5 | const espansoConfig = [ 6 | { 7 | trigger: 'prproject', 8 | form: `I need help for my current project and I need you to help me as an experimented mentor, developer and agile coach. 9 | 10 | My project is about: 11 | 12 | [[fully_detailed_explanation]] 13 | 14 | This only project I will refer to you within this conversation is only about this one. 15 | 16 | I will try to always provide to you the relevant code associated to the feature or bug or whatever I talk you about. 17 | 18 | The code will be surrounded by ", whenever possible. 19 | 20 | Technically speaking, here are the libs we are using for our project: 21 | 22 | "[[package_json_or_equivalent]]" 23 | 24 | [[i_am_focus_on_frontend_____i_am_focus_on_backend]]`, 25 | variables: ['fully_detailed_explanation', 'package_json_or_equivalent'], 26 | choices: { 27 | i_am_focus_on_frontend_____i_am_focus_on_backend: [ 28 | 'I am focus on frontend', 29 | 'I am focus on backend', 30 | ], 31 | }, 32 | }, 33 | ]; 34 | 35 | const yamlContent = generateYaml(espansoConfig); 36 | expect(yamlContent).toMatchSnapshot(); 37 | }); 38 | }); -------------------------------------------------------------------------------- /src/espanso-generation/parseMarkdown.js: -------------------------------------------------------------------------------- 1 | const MarkdownIt = require('markdown-it'); 2 | 3 | const mdParser = new MarkdownIt(); 4 | 5 | /** 6 | * Parses markdown text and extracts espanso triggers. 7 | * @param {string} markdownText - The markdown text to parse. 8 | * 9 | * @typedef {Object} EspansoConfig 10 | * @property {string} trigger - The trigger text 11 | * @property {string} form - The expanded form text 12 | * @property {string[]} variables - Template variables 13 | * @property {Object.} choices - Choices for the variables 14 | * 15 | * @returns {EspansoConfig[]} The extracted espanso configuration. 16 | */ 17 | function parseMarkdown(markdownText) { 18 | const tokens = mdParser.parse(markdownText, {}); 19 | let triggerKey = ""; 20 | let triggers = {}; 21 | let foundFence = false; 22 | 23 | for (let i = 0; i < tokens.length; i++) { 24 | const token = tokens[i]; 25 | 26 | if (token.type === 'heading_open' && token.tag.match(/^h[2-6]$/)) { 27 | const inlineToken = tokens[i + 1]; 28 | if (inlineToken.type === 'inline') { 29 | const content = inlineToken.content; 30 | const triggerMatch = content.match(/^(.*) `:(.*)`(.*?)$/); 31 | if (triggerMatch) { 32 | // Start of a new trigger 33 | triggerKey = triggerMatch[2].trim(); 34 | triggers[triggerKey] = { 35 | trigger: triggerKey, 36 | form: '', 37 | variables: [], 38 | choices: {}, 39 | }; 40 | foundFence = false; // Reset foundFence for the new trigger 41 | } 42 | } 43 | } 44 | 45 | if (token.type === 'fence' && triggerKey && !foundFence) { 46 | foundFence = true; // Mark that we found the first fence for this trigger 47 | let newContentWithReplacedVars = token.content; 48 | const variableMatches = token.content.match(/\[\[(.*?)\]\]/g); 49 | if (variableMatches) { 50 | variableMatches.forEach((variable) => { 51 | /** 52 | * Transform the variable into a valid espanso variable name. 53 | * 54 | * @example 55 | * ```js 56 | * const variableName = 'variable_name'; // if variable = '[[Variable's Name]]'; 57 | * const variableName = 'variable___choice_1___choice_2'; // if variable = '[[Variable|Choice 1|Choice 2]]'; 58 | * ``` 59 | * 60 | * @param {string} variable - The variable to transform. 61 | * @returns {string} The transformed variable. 62 | * @private 63 | * @ignore 64 | */ 65 | const variableName = variable 66 | .replace('[[', '') 67 | .replace(']]', '') 68 | .replace(/\|/g, '___') 69 | .trim() 70 | .replace(/\s+/g, '_') 71 | .replace(/[^\w\s]/g, '') 72 | .toLowerCase(); 73 | 74 | if (!triggers[triggerKey].variables.includes(variableName)) { 75 | triggers[triggerKey].variables.push(variableName); 76 | newContentWithReplacedVars = newContentWithReplacedVars.replace( 77 | variable, 78 | `[[${variableName}]]` 79 | ); 80 | } 81 | 82 | if (variable.includes('|')) { 83 | const choices = variable 84 | .replace('[[', '') 85 | .replace(']]', '') 86 | .split('|') 87 | .map((choice) => choice.trim()); 88 | triggers[triggerKey].choices[variableName] = choices; 89 | } 90 | }); 91 | } 92 | triggers[triggerKey].form = newContentWithReplacedVars; 93 | } 94 | } 95 | 96 | return Object.values(triggers); 97 | } 98 | 99 | module.exports = parseMarkdown; 100 | -------------------------------------------------------------------------------- /src/espanso-generation/parseMarkdown.test.js: -------------------------------------------------------------------------------- 1 | const parseMarkdown = require('./parseMarkdown'); 2 | const convertToYaml = require('./convertToYaml'); 3 | 4 | describe('parseMarkdown', () => { 5 | it('should parse variables and convert to YAML', () => { 6 | const markdownText = ` 7 | ### My project configuration \`:prproject\` 8 | 9 | \`\`\`text 10 | My project is about: 11 | 12 | [[Fully detailed explanation]] 13 | \`\`\` 14 | `; 15 | 16 | const espansoConfig = parseMarkdown(markdownText); 17 | const yamlContent = convertToYaml(espansoConfig); 18 | 19 | expect(yamlContent).toMatch(/trigger: ':prproject'/); 20 | expect(yamlContent).toMatch(/multiline: true/); 21 | }); 22 | 23 | it('should parse triggers and forms from markdown', () => { 24 | const markdownText = ` 25 | # Espanso config file generation from markdown prompts 26 | 27 | ## Global dev prompts 28 | 29 | ### Who am I? \`:prtsme\` 30 | 31 | \`\`\`text 32 | I am a senior software engineer on JavaScript but I prefer to use TypeScript. 33 | 34 | [[My tech stack, e.g. Node.js, React, TypeScript]] 35 | 36 | [[I am focus on frontend | I am focus on backend]] 37 | \`\`\` 38 | `; 39 | 40 | const result = parseMarkdown(markdownText); 41 | 42 | expect(result).toEqual([ 43 | { 44 | trigger: 'prtsme', 45 | form: 'I am a senior software engineer on JavaScript but I prefer to use TypeScript.\n\n[[my_tech_stack_eg_nodejs_react_typescript]]\n\n[[i_am_focus_on_frontend_____i_am_focus_on_backend]]\n', 46 | variables: [ 47 | 'my_tech_stack_eg_nodejs_react_typescript', 48 | 'i_am_focus_on_frontend_____i_am_focus_on_backend', 49 | ], 50 | choices: { 51 | i_am_focus_on_frontend_____i_am_focus_on_backend: [ 52 | 'I am focus on frontend', 53 | 'I am focus on backend', 54 | ], 55 | }, 56 | }, 57 | ]); 58 | }); 59 | 60 | it('should accept trigger headings ending with (WIP)', () => { 61 | const markdownText = ` 62 | ### Help me thinking \`:codeCodingHelpThinking\` 63 | 64 | \`\`\`text 65 | I need you to help me think about the best way to implement this new functionality: 66 | [[new functionality]] 67 | 68 | Please provide the best coding steps regarding my existing code. 69 | \`\`\` 70 | 71 | ### Improve code readability \`:codeCodingImproveReadability\` (WIP 🚧) 72 | 73 | \`\`\`text 74 | I need you to improve the readability of the following code. 75 | 76 | Result should remain the same, but the code should be easier to read and understand. 77 | \`\`\` 78 | 79 | ### Give me an example of the usage of this function \`:codeCodingProvideExampleUsage\` (WIP 🚧) 80 | 81 | \`\`\`text 82 | Provide an example of the usage of this function, input and output. 83 | \`\`\` 84 | `; 85 | expect(parseMarkdown(markdownText)).toMatchSnapshot(); 86 | }); 87 | }); 88 | 89 | -------------------------------------------------------------------------------- /src/extract-scripts.js: -------------------------------------------------------------------------------- 1 | const fs = require('fs'); 2 | 3 | const bashCodeBlockRegex = /```bash\n((?:[^\n]*\n)*?# source: .+?)\n*?```/gm; 4 | 5 | /** 6 | * Extracts the scripts from the given file path and writes them to files. 7 | * 8 | * @param {string} filePath - The path to the markdown file containing the scripts. 9 | * @returns {void} 10 | */ 11 | function extractScripts(filePath) { 12 | const content = fs.readFileSync(filePath, 'utf8'); 13 | const scripts = getScriptsContent(content); 14 | 15 | for (const source of scripts) { 16 | const sourcePath = source.match(/# source: (.*)/)[1]; 17 | 18 | console.log(`📦 Extracting script from ${filePath} to ${sourcePath}`); 19 | if (fs.existsSync(sourcePath)) { 20 | console.log(`🔀 Updating...`); 21 | fs.unlinkSync(sourcePath); 22 | } 23 | fs.writeFileSync(sourcePath, `${source}`); 24 | } 25 | } 26 | 27 | /** 28 | * Extracts scripts content from markdown. 29 | * 30 | * @param {string} fileContent - The content of the markdown file. 31 | * @returns {string[]} An array of script contents extracted from the markdown file. 32 | */ 33 | function getScriptsContent(fileContent) { 34 | const scripts = []; 35 | let match; 36 | 37 | while ((match = bashCodeBlockRegex.exec(fileContent)) !== null) { 38 | const source = match[1]; 39 | scripts.push(source); 40 | } 41 | 42 | return scripts; 43 | } 44 | 45 | module.exports = { extractScripts, getScriptsContent }; -------------------------------------------------------------------------------- /src/extract-scripts.test.js: -------------------------------------------------------------------------------- 1 | const { getScriptsContent } = require('./extract-scripts'); 2 | 3 | describe('getScriptsContent', () => { 4 | it('should extract scripts content from markdown', () => { 5 | // Arrange 6 | const fileContent = ` 7 | **Script:** 8 | 9 | \`\`\`bash 10 | #!/bin/bash 11 | 12 | echo "test" 13 | 14 | # source: scripts/generated/project-documentation-typescript.sh 15 | \`\`\` 16 | `; 17 | 18 | // Act 19 | const scripts = getScriptsContent(fileContent); 20 | 21 | // Assert 22 | expect(scripts).toEqual([ 23 | `#!/bin/bash\n\necho "test"\n\n# source: scripts/generated/project-documentation-typescript.sh`, 24 | ]); 25 | }); 26 | }); 27 | --------------------------------------------------------------------------------