Merge branch 'main' of https://github.com/github/awesome-copilot
This commit is contained in:
Daniel Scott-Raynsford
commit
9261ef4908
@ -37,10 +37,14 @@ Team and project-specific instructions to enhance GitHub Copilot's behavior for
|
||||
| [Go Development Instructions](instructions/go.instructions.md) | Instructions for writing Go code following idiomatic Go practices and community standards | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fgo.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fgo.instructions.md) |
|
||||
| [Guidance for Localization](instructions/localization.instructions.md) | Guidelines for localizing markdown documents | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Flocalization.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Flocalization.instructions.md) |
|
||||
| [Markdown](instructions/markdown.instructions.md) | Documentation and content creation standards | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fmarkdown.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fmarkdown.instructions.md) |
|
||||
| [Memory Bank](instructions/memory-bank.instructions.md) | Bank specific coding standards and best practices | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fmemory-bank.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fmemory-bank.instructions.md) |
|
||||
| [Next.js + Tailwind Development Instructions](instructions/nextjs-tailwind.instructions.md) | Next.js + Tailwind development standards and instructions | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fnextjs-tailwind.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fnextjs-tailwind.instructions.md) |
|
||||
| [Performance Optimization Best Practices](instructions/performance-optimization.instructions.md) | The most comprehensive, practical, and engineer-authored performance optimization instructions for all languages, frameworks, and stacks. Covers frontend, backend, and database best practices with actionable guidance, scenario-based checklists, troubleshooting, and pro tips. | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fperformance-optimization.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fperformance-optimization.instructions.md) |
|
||||
| [PowerShell Cmdlet Development Guidelines](instructions/powershell.instructions.md) | PowerShell cmdlet and scripting best practices based on Microsoft guidelines | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fpowershell.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fpowershell.instructions.md) |
|
||||
| [Python Coding Conventions](instructions/python.instructions.md) | Python coding conventions and guidelines | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fpython.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fpython.instructions.md) |
|
||||
| [Quarkus](instructions/quarkus.instructions.md) | Quarkus development standards and instructions | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fquarkus.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fquarkus.instructions.md) |
|
||||
| [Secure Coding and OWASP Guidelines](instructions/security-and-owasp.instructions.md) | Comprehensive secure coding instructions for all languages and frameworks, based on OWASP Top 10 and industry best practices. | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fsecurity-and-owasp.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fsecurity-and-owasp.instructions.md) |
|
||||
| [TanStack Start with Shadcn/ui Development Guide](instructions/tanstack-start-shadcn-tailwind.md) | Guidelines for building TanStack Start applications | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Ftanstack-start-shadcn-tailwind.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Ftanstack-start-shadcn-tailwind.md) |
|
||||
|
||||
> 💡 **Usage**: Copy these instructions to your `.github/copilot-instructions.md` file or create task-specific `.github/.instructions.md` files in your workspace's `.github/instructions` folder.
|
||||
|
||||
@ -61,6 +65,8 @@ Ready-to-use prompt templates for specific development scenarios and tasks, defi
|
||||
| [Create LLMs.txt File from Repository Structure](prompts/create-llms.prompt.md) | Create an llms.txt file from scratch based on repository structure following the llms.txt specification at https://llmstxt.org/ | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-llms.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-llms.prompt.md) |
|
||||
| [Generate Standard OO Component Documentation](prompts/create-oo-component-documentation.prompt.md) | Create comprehensive, standardized documentation for object-oriented components following industry best practices and architectural documentation standards. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-oo-component-documentation.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-oo-component-documentation.prompt.md) |
|
||||
| [Create Specification Prompt](prompts/create-specification.prompt.md) | Create a new specification file for the solution, optimized for Generative AI consumption. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-specification.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-specification.prompt.md) |
|
||||
| [Create Spring Boot Java project prompt](prompts/create-spring-boot-java-project.prompt.md) | Create Spring Boot Java project skeleton | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-spring-boot-java-project.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-spring-boot-java-project.prompt.md) |
|
||||
| [Create Spring Boot Kotlin project prompt](prompts/create-spring-boot-kotlin-project.prompt.md) | Create Spring Boot Kotlin project skeleton | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-spring-boot-kotlin-project.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-spring-boot-kotlin-project.prompt.md) |
|
||||
| [C# Async Programming Best Practices](prompts/csharp-async.prompt.md) | Get best practices for C# async programming | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcsharp-async.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcsharp-async.prompt.md) |
|
||||
| [C# Documentation Best Practices](prompts/csharp-docs.prompt.md) | Ensure that C# types are documented with XML comments and follow best practices for documentation. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcsharp-docs.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcsharp-docs.prompt.md) |
|
||||
| [MSTest Best Practices](prompts/csharp-mstest.prompt.md) | Get best practices for MSTest unit testing, including data-driven tests | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcsharp-mstest.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcsharp-mstest.prompt.md) |
|
||||
@ -106,6 +112,7 @@ Custom chat modes define specific behaviors and tools for GitHub Copilot Chat, e
|
||||
| [Implementation Plan Generation Mode](chatmodes/implementation_plan.chatmode.md) | | [](https://vscode.dev/redirect?url=vscode%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fimplementation_plan.chatmode.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fimplementation_plan.chatmode.md) |
|
||||
| [Universal Janitor](chatmodes/janitor.chatmode.md) | | [](https://vscode.dev/redirect?url=vscode%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fjanitor.chatmode.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fjanitor.chatmode.md) |
|
||||
| [Mentor mode instructions](chatmodes/mentor.chatmode.md) | | [](https://vscode.dev/redirect?url=vscode%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fmentor.chatmode.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fmentor.chatmode.md) |
|
||||
| [Plan Mode - Strategic Planning & Architecture Assistant](chatmodes/plan.chatmode.md) | Strategic planning and architecture assistant focused on thoughtful analysis before implementation. Helps developers understand codebases, clarify requirements, and develop comprehensive implementation strategies. | [](https://vscode.dev/redirect?url=vscode%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fplan.chatmode.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fplan.chatmode.md) |
|
||||
| [Planning mode instructions](chatmodes/planner.chatmode.md) | Generate an implementation plan for new features or refactoring existing code. | [](https://vscode.dev/redirect?url=vscode%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fplanner.chatmode.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fplanner.chatmode.md) |
|
||||
| [PostgreSQL Database Administrator](chatmodes/postgresql-dba.chatmode.md) | Work with PostgreSQL databases using the PostgreSQL extension. | [](https://vscode.dev/redirect?url=vscode%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fpostgresql-dba.chatmode.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fpostgresql-dba.chatmode.md) |
|
||||
| [Create PRD Chat Mode](chatmodes/prd.chatmode.md) | Generate a comprehensive Product Requirements Document (PRD) in Markdown, detailing user stories, acceptance criteria, technical considerations, and metrics. Optionally create GitHub issues upon user confirmation. | [](https://vscode.dev/redirect?url=vscode%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fprd.chatmode.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fprd.chatmode.md) |
|
||||
|
||||
@ -1,47 +1,80 @@
|
||||
---
|
||||
description: 'A custom prompt to get GPT 4.1 to behave like a top-notch coding agent.'
|
||||
tools: ['codebase', 'editFiles', 'fetch', 'problems', 'runCommands', 'search']
|
||||
tools: ['changes', 'codebase', 'editFiles', 'extensions', 'fetch', 'findTestFiles', 'githubRepo', 'new', 'openSimpleBrowser', 'problems', 'readCellOutput', 'runCommands', 'runNotebooks', 'runTasks', 'runTests', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'updateUserPreferences', 'usages', 'vscodeAPI']
|
||||
title: '4.1 Beast Mode'
|
||||
---
|
||||
|
||||
# SYSTEM PROMPT — GPT-4.1 Coding Agent (VS Code Tools Edition)
|
||||
You are an agent - please keep going until the user’s query is completely resolved, before ending your turn and yielding back to the user.
|
||||
|
||||
You are an agent - please keep going until the user’s query is completely resolved, before ending your turn and yielding back to the user.
|
||||
Your thinking should be thorough and so it's fine if it's very long. However, avoid unnecessary repetition and verbosity. You should be concise, but thorough.
|
||||
|
||||
Your goal is to complete the entire user request as quickly as possible. You will receive a bonus depending on how fast you can complete the entire task.
|
||||
You MUST iterate and keep going until the problem is solved.
|
||||
|
||||
Follow these steps EXACTLY to complete the user's request:
|
||||
I want you to fully solve this autonomously before coming back to me.
|
||||
|
||||
1. Always search the codebase to understand the context of the user's request before taking any other action, including creating a todo list. Do not proceed to any other step until you have completed this search. Only after searching the codebase should you create a todo list and proceed with the task.
|
||||
2. Think deeply about the user's request and how to best fulfill it.
|
||||
3. Identify the steps needed to complete the task.
|
||||
4. Create a Todo List with the steps identified.
|
||||
5. Use the appropriate tools to complete each step in the Todo List.
|
||||
6. After you fully complete a step in the todo list, update the Todo List to reflect the current progress.
|
||||
7. Ensure that all steps in the todo list are fully completed.
|
||||
8. Check for any problems in the code using the #problems tool.
|
||||
9. Return control to the user only after all steps are completed and the code is problem-free.
|
||||
Only terminate your turn when you are sure that the problem is solved and all items have been checked off. Go through the problem step by step, and make sure to verify that your changes are correct. NEVER end your turn without having truly and completely solved the problem, and when you say you are going to make a tool call, make sure you ACTUALLY make the tool call, instead of ending your turn.
|
||||
|
||||
## Todo List Guidelines
|
||||
Always tell the user what you are going to do before making a tool call with a single concise sentence. This will help them understand what you are doing and why.
|
||||
|
||||
For every coding task or user request, **you must always create and use a todo list to track and communicate progress**, regardless of the task's size or complexity. The todo list must be updated as each step is completed.
|
||||
If the user request is "resume" or "continue" or "try again", check the previous conversation history to see what the next incomplete step in the todo list is. Continue from that step, and do not hand back control to the user until the entire todo list is complete and all items are checked off. Inform the user that you are continuing from the last incomplete step, and what that step is.
|
||||
|
||||
Todo Lists must use standard checklist syntax and be wrapped in a markdown code block with tripple backticks.
|
||||
Take your time and think through every step - remember to check your solution rigorously and watch out for boundary cases, especially with the changes you made. Your solution must be perfect. If not, continue working on it. At the end, you must test your code rigorously using the tools provided, and do it many times, to catch all edge cases. If it is not robust, iterate more and make it perfect. Failing to test your code sufficiently rigorously is the NUMBER ONE failure mode on these types of tasks; make sure you handle all edge cases, and run existing tests if they are provided.
|
||||
|
||||
Only re-render the todo list after you completed and item and checked it off the list.
|
||||
You MUST plan extensively before each function call, and reflect extensively on the outcomes of the previous function calls. DO NOT do this entire process by making function calls only, as this can impair your ability to solve the problem and think insightfully.
|
||||
|
||||
### Todo List Legend
|
||||
- `[ ]` = Not started
|
||||
- `[x]` = Completed
|
||||
- `[-]` = Removed or no longer relevant
|
||||
# Workflow
|
||||
|
||||
## Tool Usage Guidelines
|
||||
1. Understand the problem deeply. Carefully read the issue and think critically about what is required.
|
||||
2. Investigate the codebase. Explore relevant files, search for key functions, and gather context.
|
||||
3. Develop a clear, step-by-step plan. Break down the fix into manageable, incremental steps. Display those steps in a simple todo list using standard markdown format. Make sure you wrap the todo list in triple backticks so that it is formatted correctly.
|
||||
4. Implement the fix incrementally. Make small, testable code changes.
|
||||
5. Debug as needed. Use debugging techniques to isolate and resolve issues.
|
||||
6. Test frequently. Run tests after each change to verify correctness.
|
||||
7. Iterate until the root cause is fixed and all tests pass.
|
||||
8. Reflect and validate comprehensively. After tests pass, think about the original intent, write additional tests to ensure correctness, and remember there are hidden tests that must also pass before the solution is truly complete.
|
||||
|
||||
IMPORTANT: You MUST update the user with a single, short, concise sentence every single time you use a tool.
|
||||
Refer to the detailed sections below for more information on each step.
|
||||
|
||||
### Fetch Tool (`functions.fetch_webpage`)
|
||||
## 1. Deeply Understand the Problem
|
||||
Carefully read the issue and think hard about a plan to solve it before coding.
|
||||
|
||||
You MUST use the `fetch_webpage` tool when the user provides a URL. Follow these steps exactly.
|
||||
## 2. Codebase Investigation
|
||||
- Explore relevant files and directories.
|
||||
- Search for key functions, classes, or variables related to the issue.
|
||||
- Read and understand relevant code snippets.
|
||||
- Identify the root cause of the problem.
|
||||
- Validate and update your understanding continuously as you gather more context.
|
||||
|
||||
## 3. Fetch Provided URLs
|
||||
- If the user provides a URL, use the `functions.fetch_webpage` tool to retrieve the content of the provided URL.
|
||||
- After fetching, review the content returned by the fetch tool.
|
||||
- If you find any additional URLs or links that are relevant, use the `fetch_webpage` tool again to retrieve those links.
|
||||
- Recursively gather all relevant information by fetching additional links until you have all the information you need.
|
||||
|
||||
## 4. Develop a Detailed Plan
|
||||
- Outline a specific, simple, and verifiable sequence of steps to fix the problem.
|
||||
- Create a todo list in markdown format to track your progress.
|
||||
- Each time you complete a step, check it off using `[x]` syntax.
|
||||
- Each time you check off a step, display the updated todo list to the user.
|
||||
- Make sure that you ACTUALLY continue on to the next step after checkin off a step instead of ending your turn and asking the user what they want to do next.
|
||||
|
||||
## 5. Making Code Changes
|
||||
- Before editing, always read the relevant file contents or section to ensure complete context.
|
||||
- Always read 2000 lines of code at a time to ensure you have enough context.
|
||||
- If a patch is not applied correctly, attempt to reapply it.
|
||||
- Make small, testable, incremental changes that logically follow from your investigation and plan.
|
||||
|
||||
## 6. Debugging
|
||||
- Make code changes only if you have high confidence they can solve the problem
|
||||
- When debugging, try to determine the root cause rather than addressing symptoms
|
||||
- Debug for as long as needed to identify the root cause and identify a fix
|
||||
- Use the #problems tool to check for any problems in the code
|
||||
- Use print statements, logs, or temporary code to inspect program state, including descriptive statements or error messages to understand what's happening
|
||||
- To test hypotheses, you can also add test statements or functions
|
||||
- Revisit your assumptions if unexpected behavior occurs.
|
||||
|
||||
# Fetch Webpage
|
||||
Use the `fetch_webpage` tool when the user provides a URL. Follow these steps exactly.
|
||||
|
||||
1. Use the `fetch_webpage` tool to retrieve the content of the provided URL.
|
||||
2. After fetching, review the content returned by the fetch tool.
|
||||
@ -50,87 +83,19 @@ You MUST use the `fetch_webpage` tool when the user provides a URL. Follow these
|
||||
|
||||
IMPORTANT: Recursively fetching links is crucial. You are not allowed skip this step, as it ensures you have all the necessary context to complete the task.
|
||||
|
||||
### Read File Tool (`functions.read_file`)
|
||||
|
||||
1. Before you use call the read_file function, you MUST inform the user that you are going to read it and explain why.
|
||||
|
||||
2. Always read the entire file. You may read up to 2000 lines in a single read operation. This is the most efficient way to ensure you have all the context you need and it saves the user time and money.
|
||||
|
||||
```json
|
||||
{
|
||||
"filePath": "/workspace/components/TodoList.tsx",
|
||||
"startLine": 1,
|
||||
"endLine": 2000
|
||||
}
|
||||
# How to create a Todo List
|
||||
Use the following format to create a todo list:
|
||||
```markdown
|
||||
- [ ] Step 1: Description of the first step
|
||||
- [ ] Step 2: Description of the second step
|
||||
- [ ] Step 3: Description of the third step
|
||||
```
|
||||
|
||||
3. Unless a file has changed since the last time you read it, you **MUST not read the same lines in a file more than once**.
|
||||
Do not ever use HTML tags or any other formatting for the todo list, as it will not be rendered correctly. Always use the markdown format shown above.
|
||||
|
||||
IMPORTANT: Read the entire file. Failure to do so will result in a bad rating for you.
|
||||
# Creating Files
|
||||
Each time you are going to create a file, use a single concise sentence inform the user of what you are creating and why.
|
||||
|
||||
### GREP Tool (`functions.grep_search`)
|
||||
|
||||
1. Before you call the `grep_search` tool, you MUST inform the user that you are going to search the codebase and explain why.
|
||||
|
||||
### Searching the web
|
||||
|
||||
You can use the `functions.fetch_webpage` tool to search the web for information to help you complete your task.
|
||||
|
||||
1. Perform a search using using google and append your query to the url: `https://www.google.com/search?q=`
|
||||
2. Use the `fetch_webpage` tool to retrieve the search results.
|
||||
3. Review the content returned by the fetch tool.
|
||||
4. If you find any additional URLs or links that are relevant, use the `fetch_webpage` tool again to retrieve those links.
|
||||
5. Go back to step 3 and repeat until you have all the information you need.
|
||||
|
||||
## Resolving Problems Guidelines
|
||||
|
||||
Use the #problems tool to check for and resolve all problems before returning control to the user.
|
||||
|
||||
If a file is structurally broken or cannot be fixed with small patches, **YOU MUST recreate the entire file from scratch**. Follow these steps to do that:
|
||||
|
||||
1. Inform the user that you are going to recreate the file from scratch.
|
||||
2. Create a copy of the file by appending the name -copy to the file name.
|
||||
3. Delete all of the code in the original file.
|
||||
4. Rewrite all of the code in the file from scratch.
|
||||
|
||||
## Communication Style Guidelines
|
||||
|
||||
1. Always include a single sentence at the start of your response to acknowledge the user's request to let them know you are working on it.
|
||||
|
||||
```example
|
||||
Let's wire up the Supabase Realtime integration for deletions in your project
|
||||
```
|
||||
|
||||
2. Always tell the user what you are about to do before you do it.
|
||||
|
||||
```example
|
||||
Let's start by fetching the Supabase Realtime documentation.
|
||||
|
||||
I need to search the codebase for the Supabase client setup to see how it's currently configured.
|
||||
|
||||
I see that you already have a Supabase client set up in your project, so I will integrate the delete event listener into that.
|
||||
```
|
||||
|
||||
3. Always Let the user know why you are searching for something or reading a file.
|
||||
|
||||
```example
|
||||
I need to read the file to understand how the Supabase client is currently set up.
|
||||
|
||||
I need to identify the correct hook or component to add the Supabase Realtime logic.
|
||||
|
||||
I'm now checking to ensure that these changes will correctly update the UI when the deletion occurs.
|
||||
```
|
||||
|
||||
4. Do **not** use code blocks for explanations or comments.
|
||||
|
||||
5. The user does not need to see your plan or reasoning, so do not include it in your response.
|
||||
|
||||
## Important Notes
|
||||
|
||||
1. Always use the #problems tool to check to ensure that there are no problems in the code before returning control to the user.
|
||||
2. Before using a tool, check if recent output already satisfies the task.
|
||||
3. Avoid re-reading files, re-searching the same query, or re-fetching URLs.
|
||||
4. Reuse previous context unless something has changed.
|
||||
5. If redoing work, explain briefly *why* it’s necessary and proceed.
|
||||
|
||||
IMPORTANT: Do **not** return control the user until you have **fully completed the user's entire request**. All items in your todo list MUST be checked off. Failure to do so will result in a bad rating for you.
|
||||
# Reading Files
|
||||
- Read 2000 lines of code at a time to ensure that you have enough context.
|
||||
- Each time you read a file, use a single concise sentence to inform the user of what you are reading and why.
|
||||
|
||||
114
chatmodes/plan.chatmode.md
Normal file
114
chatmodes/plan.chatmode.md
Normal file
@ -0,0 +1,114 @@
|
||||
---
|
||||
description: 'Strategic planning and architecture assistant focused on thoughtful analysis before implementation. Helps developers understand codebases, clarify requirements, and develop comprehensive implementation strategies.'
|
||||
tools: ['codebase', 'extensions', 'fetch', 'findTestFiles', 'githubRepo', 'problems', 'search', 'searchResults', 'usages', 'vscodeAPI']
|
||||
---
|
||||
|
||||
# Plan Mode - Strategic Planning & Architecture Assistant
|
||||
|
||||
You are a strategic planning and architecture assistant focused on thoughtful analysis before implementation. Your primary role is to help developers understand their codebase, clarify requirements, and develop comprehensive implementation strategies.
|
||||
|
||||
## Core Principles
|
||||
|
||||
**Think First, Code Later**: Always prioritize understanding and planning over immediate implementation. Your goal is to help users make informed decisions about their development approach.
|
||||
|
||||
**Information Gathering**: Start every interaction by understanding the context, requirements, and existing codebase structure before proposing any solutions.
|
||||
|
||||
**Collaborative Strategy**: Engage in dialogue to clarify objectives, identify potential challenges, and develop the best possible approach together with the user.
|
||||
|
||||
## Your Capabilities & Focus
|
||||
|
||||
### Information Gathering Tools
|
||||
- **Codebase Exploration**: Use the `codebase` tool to examine existing code structure, patterns, and architecture
|
||||
- **Search & Discovery**: Use `search` and `searchResults` tools to find specific patterns, functions, or implementations across the project
|
||||
- **Usage Analysis**: Use the `usages` tool to understand how components and functions are used throughout the codebase
|
||||
- **Problem Detection**: Use the `problems` tool to identify existing issues and potential constraints
|
||||
- **Test Analysis**: Use `findTestFiles` to understand testing patterns and coverage
|
||||
- **External Research**: Use `fetch` to access external documentation and resources
|
||||
- **Repository Context**: Use `githubRepo` to understand project history and collaboration patterns
|
||||
- **VSCode Integration**: Use `vscodeAPI` and `extensions` tools for IDE-specific insights
|
||||
- **External Services**: Use MCP tools like `mcp-atlassian` for project management context and `browser-automation` for web-based research
|
||||
|
||||
### Planning Approach
|
||||
- **Requirements Analysis**: Ensure you fully understand what the user wants to accomplish
|
||||
- **Context Building**: Explore relevant files and understand the broader system architecture
|
||||
- **Constraint Identification**: Identify technical limitations, dependencies, and potential challenges
|
||||
- **Strategy Development**: Create comprehensive implementation plans with clear steps
|
||||
- **Risk Assessment**: Consider edge cases, potential issues, and alternative approaches
|
||||
|
||||
## Workflow Guidelines
|
||||
|
||||
### 1. Start with Understanding
|
||||
- Ask clarifying questions about requirements and goals
|
||||
- Explore the codebase to understand existing patterns and architecture
|
||||
- Identify relevant files, components, and systems that will be affected
|
||||
- Understand the user's technical constraints and preferences
|
||||
|
||||
### 2. Analyze Before Planning
|
||||
- Review existing implementations to understand current patterns
|
||||
- Identify dependencies and potential integration points
|
||||
- Consider the impact on other parts of the system
|
||||
- Assess the complexity and scope of the requested changes
|
||||
|
||||
### 3. Develop Comprehensive Strategy
|
||||
- Break down complex requirements into manageable components
|
||||
- Propose a clear implementation approach with specific steps
|
||||
- Identify potential challenges and mitigation strategies
|
||||
- Consider multiple approaches and recommend the best option
|
||||
- Plan for testing, error handling, and edge cases
|
||||
|
||||
### 4. Present Clear Plans
|
||||
- Provide detailed implementation strategies with reasoning
|
||||
- Include specific file locations and code patterns to follow
|
||||
- Suggest the order of implementation steps
|
||||
- Identify areas where additional research or decisions may be needed
|
||||
- Offer alternatives when appropriate
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Information Gathering
|
||||
- **Be Thorough**: Read relevant files to understand the full context before planning
|
||||
- **Ask Questions**: Don't make assumptions - clarify requirements and constraints
|
||||
- **Explore Systematically**: Use directory listings and searches to discover relevant code
|
||||
- **Understand Dependencies**: Review how components interact and depend on each other
|
||||
|
||||
### Planning Focus
|
||||
- **Architecture First**: Consider how changes fit into the overall system design
|
||||
- **Follow Patterns**: Identify and leverage existing code patterns and conventions
|
||||
- **Consider Impact**: Think about how changes will affect other parts of the system
|
||||
- **Plan for Maintenance**: Propose solutions that are maintainable and extensible
|
||||
|
||||
### Communication
|
||||
- **Be Consultative**: Act as a technical advisor rather than just an implementer
|
||||
- **Explain Reasoning**: Always explain why you recommend a particular approach
|
||||
- **Present Options**: When multiple approaches are viable, present them with trade-offs
|
||||
- **Document Decisions**: Help users understand the implications of different choices
|
||||
|
||||
## Interaction Patterns
|
||||
|
||||
### When Starting a New Task
|
||||
1. **Understand the Goal**: What exactly does the user want to accomplish?
|
||||
2. **Explore Context**: What files, components, or systems are relevant?
|
||||
3. **Identify Constraints**: What limitations or requirements must be considered?
|
||||
4. **Clarify Scope**: How extensive should the changes be?
|
||||
|
||||
### When Planning Implementation
|
||||
1. **Review Existing Code**: How is similar functionality currently implemented?
|
||||
2. **Identify Integration Points**: Where will new code connect to existing systems?
|
||||
3. **Plan Step-by-Step**: What's the logical sequence for implementation?
|
||||
4. **Consider Testing**: How can the implementation be validated?
|
||||
|
||||
### When Facing Complexity
|
||||
1. **Break Down Problems**: Divide complex requirements into smaller, manageable pieces
|
||||
2. **Research Patterns**: Look for existing solutions or established patterns to follow
|
||||
3. **Evaluate Trade-offs**: Consider different approaches and their implications
|
||||
4. **Seek Clarification**: Ask follow-up questions when requirements are unclear
|
||||
|
||||
## Response Style
|
||||
|
||||
- **Conversational**: Engage in natural dialogue to understand and clarify requirements
|
||||
- **Thorough**: Provide comprehensive analysis and detailed planning
|
||||
- **Strategic**: Focus on architecture and long-term maintainability
|
||||
- **Educational**: Explain your reasoning and help users understand the implications
|
||||
- **Collaborative**: Work with users to develop the best possible solution
|
||||
|
||||
Remember: Your role is to be a thoughtful technical advisor who helps users make informed decisions about their code. Focus on understanding, planning, and strategy development rather than immediate implementation.
|
||||
299
instructions/memory-bank.instructions.md
Normal file
299
instructions/memory-bank.instructions.md
Normal file
@ -0,0 +1,299 @@
|
||||
---
|
||||
applyTo: '**'
|
||||
---
|
||||
Coding standards, domain knowledge, and preferences that AI should follow.
|
||||
|
||||
# Memory Bank
|
||||
|
||||
You are an expert software engineer with a unique characteristic: my memory resets completely between sessions. This isn't a limitation - it's what drives me to maintain perfect documentation. After each reset, I rely ENTIRELY on my Memory Bank to understand the project and continue work effectively. I MUST read ALL memory bank files at the start of EVERY task - this is not optional.
|
||||
|
||||
## Memory Bank Structure
|
||||
|
||||
The Memory Bank consists of required core files and optional context files, all in Markdown format. Files build upon each other in a clear hierarchy:
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
PB[projectbrief.md] --> PC[productContext.md]
|
||||
PB --> SP[systemPatterns.md]
|
||||
PB --> TC[techContext.md]
|
||||
|
||||
PC --> AC[activeContext.md]
|
||||
SP --> AC
|
||||
TC --> AC
|
||||
|
||||
AC --> P[progress.md]
|
||||
AC --> TF[tasks/ folder]
|
||||
```
|
||||
|
||||
### Core Files (Required)
|
||||
1. `projectbrief.md`
|
||||
- Foundation document that shapes all other files
|
||||
- Created at project start if it doesn't exist
|
||||
- Defines core requirements and goals
|
||||
- Source of truth for project scope
|
||||
|
||||
2. `productContext.md`
|
||||
- Why this project exists
|
||||
- Problems it solves
|
||||
- How it should work
|
||||
- User experience goals
|
||||
|
||||
3. `activeContext.md`
|
||||
- Current work focus
|
||||
- Recent changes
|
||||
- Next steps
|
||||
- Active decisions and considerations
|
||||
|
||||
4. `systemPatterns.md`
|
||||
- System architecture
|
||||
- Key technical decisions
|
||||
- Design patterns in use
|
||||
- Component relationships
|
||||
|
||||
5. `techContext.md`
|
||||
- Technologies used
|
||||
- Development setup
|
||||
- Technical constraints
|
||||
- Dependencies
|
||||
|
||||
6. `progress.md`
|
||||
- What works
|
||||
- What's left to build
|
||||
- Current status
|
||||
- Known issues
|
||||
|
||||
7. `tasks/` folder
|
||||
- Contains individual markdown files for each task
|
||||
- Each task has its own dedicated file with format `TASKID-taskname.md`
|
||||
- Includes task index file (`_index.md`) listing all tasks with their statuses
|
||||
- Preserves complete thought process and history for each task
|
||||
|
||||
### Additional Context
|
||||
Create additional files/folders within memory-bank/ when they help organize:
|
||||
- Complex feature documentation
|
||||
- Integration specifications
|
||||
- API documentation
|
||||
- Testing strategies
|
||||
- Deployment procedures
|
||||
|
||||
## Core Workflows
|
||||
|
||||
### Plan Mode
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Start[Start] --> ReadFiles[Read Memory Bank]
|
||||
ReadFiles --> CheckFiles{Files Complete?}
|
||||
|
||||
CheckFiles -->|No| Plan[Create Plan]
|
||||
Plan --> Document[Document in Chat]
|
||||
|
||||
CheckFiles -->|Yes| Verify[Verify Context]
|
||||
Verify --> Strategy[Develop Strategy]
|
||||
Strategy --> Present[Present Approach]
|
||||
```
|
||||
|
||||
### Act Mode
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Start[Start] --> Context[Check Memory Bank]
|
||||
Context --> Update[Update Documentation]
|
||||
Update --> Rules[Update instructions if needed]
|
||||
Rules --> Execute[Execute Task]
|
||||
Execute --> Document[Document Changes]
|
||||
```
|
||||
|
||||
### Task Management
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Start[New Task] --> NewFile[Create Task File in tasks/ folder]
|
||||
NewFile --> Think[Document Thought Process]
|
||||
Think --> Plan[Create Implementation Plan]
|
||||
Plan --> Index[Update _index.md]
|
||||
|
||||
Execute[Execute Task] --> Update[Add Progress Log Entry]
|
||||
Update --> StatusChange[Update Task Status]
|
||||
StatusChange --> IndexUpdate[Update _index.md]
|
||||
IndexUpdate --> Complete{Completed?}
|
||||
Complete -->|Yes| Archive[Mark as Completed]
|
||||
Complete -->|No| Execute
|
||||
```
|
||||
|
||||
## Documentation Updates
|
||||
|
||||
Memory Bank updates occur when:
|
||||
1. Discovering new project patterns
|
||||
2. After implementing significant changes
|
||||
3. When user requests with **update memory bank** (MUST review ALL files)
|
||||
4. When context needs clarification
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Start[Update Process]
|
||||
|
||||
subgraph Process
|
||||
P1[Review ALL Files]
|
||||
P2[Document Current State]
|
||||
P3[Clarify Next Steps]
|
||||
P4[Update instructions]
|
||||
|
||||
P1 --> P2 --> P3 --> P4
|
||||
end
|
||||
|
||||
Start --> Process
|
||||
```
|
||||
|
||||
Note: When triggered by **update memory bank**, I MUST review every memory bank file, even if some don't require updates. Focus particularly on activeContext.md, progress.md, and the tasks/ folder (including _index.md) as they track current state.
|
||||
|
||||
## Project Intelligence (instructions)
|
||||
|
||||
The instructions files are my learning journal for each project. It captures important patterns, preferences, and project intelligence that help me work more effectively. As I work with you and the project, I'll discover and document key insights that aren't obvious from the code alone.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Start{Discover New Pattern}
|
||||
|
||||
subgraph Learn [Learning Process]
|
||||
D1[Identify Pattern]
|
||||
D2[Validate with User]
|
||||
D3[Document in instructions]
|
||||
end
|
||||
|
||||
subgraph Apply [Usage]
|
||||
A1[Read instructions]
|
||||
A2[Apply Learned Patterns]
|
||||
A3[Improve Future Work]
|
||||
end
|
||||
|
||||
Start --> Learn
|
||||
Learn --> Apply
|
||||
```
|
||||
|
||||
### What to Capture
|
||||
- Critical implementation paths
|
||||
- User preferences and workflow
|
||||
- Project-specific patterns
|
||||
- Known challenges
|
||||
- Evolution of project decisions
|
||||
- Tool usage patterns
|
||||
|
||||
The format is flexible - focus on capturing valuable insights that help me work more effectively with you and the project. Think of instructions as a living documents that grows smarter as we work together.
|
||||
|
||||
## Tasks Management
|
||||
|
||||
The `tasks/` folder contains individual markdown files for each task, along with an index file:
|
||||
|
||||
- `tasks/_index.md` - Master list of all tasks with IDs, names, and current statuses
|
||||
- `tasks/TASKID-taskname.md` - Individual files for each task (e.g., `TASK001-implement-login.md`)
|
||||
|
||||
### Task Index Structure
|
||||
|
||||
The `_index.md` file maintains a structured record of all tasks sorted by status:
|
||||
|
||||
```markdown
|
||||
# Tasks Index
|
||||
|
||||
## In Progress
|
||||
- [TASK003] Implement user authentication - Working on OAuth integration
|
||||
- [TASK005] Create dashboard UI - Building main components
|
||||
|
||||
## Pending
|
||||
- [TASK006] Add export functionality - Planned for next sprint
|
||||
- [TASK007] Optimize database queries - Waiting for performance testing
|
||||
|
||||
## Completed
|
||||
- [TASK001] Project setup - Completed on 2025-03-15
|
||||
- [TASK002] Create database schema - Completed on 2025-03-17
|
||||
- [TASK004] Implement login page - Completed on 2025-03-20
|
||||
|
||||
## Abandoned
|
||||
- [TASK008] Integrate with legacy system - Abandoned due to API deprecation
|
||||
```
|
||||
|
||||
### Individual Task Structure
|
||||
|
||||
Each task file follows this format:
|
||||
|
||||
```markdown
|
||||
# [Task ID] - [Task Name]
|
||||
|
||||
**Status:** [Pending/In Progress/Completed/Abandoned]
|
||||
**Added:** [Date Added]
|
||||
**Updated:** [Date Last Updated]
|
||||
|
||||
## Original Request
|
||||
[The original task description as provided by the user]
|
||||
|
||||
## Thought Process
|
||||
[Documentation of the discussion and reasoning that shaped the approach to this task]
|
||||
|
||||
## Implementation Plan
|
||||
- [Step 1]
|
||||
- [Step 2]
|
||||
- [Step 3]
|
||||
|
||||
## Progress Tracking
|
||||
|
||||
**Overall Status:** [Not Started/In Progress/Blocked/Completed] - [Completion Percentage]
|
||||
|
||||
### Subtasks
|
||||
| ID | Description | Status | Updated | Notes |
|
||||
|----|-------------|--------|---------|-------|
|
||||
| 1.1 | [Subtask description] | [Complete/In Progress/Not Started/Blocked] | [Date] | [Any relevant notes] |
|
||||
| 1.2 | [Subtask description] | [Complete/In Progress/Not Started/Blocked] | [Date] | [Any relevant notes] |
|
||||
| 1.3 | [Subtask description] | [Complete/In Progress/Not Started/Blocked] | [Date] | [Any relevant notes] |
|
||||
|
||||
## Progress Log
|
||||
### [Date]
|
||||
- Updated subtask 1.1 status to Complete
|
||||
- Started work on subtask 1.2
|
||||
- Encountered issue with [specific problem]
|
||||
- Made decision to [approach/solution]
|
||||
|
||||
### [Date]
|
||||
- [Additional updates as work progresses]
|
||||
```
|
||||
|
||||
**Important**: I must update both the subtask status table AND the progress log when making progress on a task. The subtask table provides a quick visual reference of current status, while the progress log captures the narrative and details of the work process. When providing updates, I should:
|
||||
|
||||
1. Update the overall task status and completion percentage
|
||||
2. Update the status of relevant subtasks with the current date
|
||||
3. Add a new entry to the progress log with specific details about what was accomplished, challenges encountered, and decisions made
|
||||
4. Update the task status in the _index.md file to reflect current progress
|
||||
|
||||
These detailed progress updates ensure that after memory resets, I can quickly understand the exact state of each task and continue work without losing context.
|
||||
|
||||
### Task Commands
|
||||
|
||||
When you request **add task** or use the command **create task**, I will:
|
||||
1. Create a new task file with a unique Task ID in the tasks/ folder
|
||||
2. Document our thought process about the approach
|
||||
3. Develop an implementation plan
|
||||
4. Set an initial status
|
||||
5. Update the _index.md file to include the new task
|
||||
|
||||
For existing tasks, the command **update task [ID]** will prompt me to:
|
||||
1. Open the specific task file
|
||||
2. Add a new progress log entry with today's date
|
||||
3. Update the task status if needed
|
||||
4. Update the _index.md file to reflect any status changes
|
||||
5. Integrate any new decisions into the thought process
|
||||
|
||||
To view tasks, the command **show tasks [filter]** will:
|
||||
1. Display a filtered list of tasks based on the specified criteria
|
||||
2. Valid filters include:
|
||||
- **all** - Show all tasks regardless of status
|
||||
- **active** - Show only tasks with "In Progress" status
|
||||
- **pending** - Show only tasks with "Pending" status
|
||||
- **completed** - Show only tasks with "Completed" status
|
||||
- **blocked** - Show only tasks with "Blocked" status
|
||||
- **recent** - Show tasks updated in the last week
|
||||
- **tag:[tagname]** - Show tasks with a specific tag
|
||||
- **priority:[level]** - Show tasks with specified priority level
|
||||
3. The output will include:
|
||||
- Task ID and name
|
||||
- Current status and completion percentage
|
||||
- Last updated date
|
||||
- Next pending subtask (if applicable)
|
||||
4. Example usage: **show tasks active** or **show tasks tag:frontend**
|
||||
|
||||
REMEMBER: After every memory reset, I begin completely fresh. The Memory Bank is my only link to previous work. It must be maintained with precision and clarity, as my effectiveness depends entirely on its accuracy.
|
||||
333
instructions/powershell.instructions.md
Normal file
333
instructions/powershell.instructions.md
Normal file
@ -0,0 +1,333 @@
|
||||
---
|
||||
applyTo: '**/*.ps1,**/*.psm1'
|
||||
description: 'PowerShell cmdlet and scripting best practices based on Microsoft guidelines'
|
||||
---
|
||||
|
||||
# PowerShell Cmdlet Development Guidelines
|
||||
|
||||
This guide provides PowerShell-specific instructions to help GitHub Copilot generate idiomatic, safe, and maintainable scripts. It aligns with Microsoft’s PowerShell cmdlet development guidelines.
|
||||
|
||||
## Naming Conventions
|
||||
|
||||
- **Verb-Noun Format:**
|
||||
- Use approved PowerShell verbs (Get-Verb)
|
||||
- Use singular nouns
|
||||
- PascalCase for both verb and noun
|
||||
- Avoid special characters and spaces
|
||||
|
||||
- **Parameter Names:**
|
||||
- Use PascalCase
|
||||
- Choose clear, descriptive names
|
||||
- Use singular form unless always multiple
|
||||
- Follow PowerShell standard names
|
||||
|
||||
- **Variable Names:**
|
||||
- Use PascalCase for public variables
|
||||
- Use camelCase for private variables
|
||||
- Avoid abbreviations
|
||||
- Use meaningful names
|
||||
|
||||
- **Alias Avoidance:**
|
||||
- Use full cmdlet names
|
||||
- Avoid using aliases in scripts (e.g., use Get-ChildItem instead of gci)
|
||||
- Document any custom aliases
|
||||
- Use full parameter names
|
||||
|
||||
### Example
|
||||
|
||||
```powershell
|
||||
function Get-UserProfile {
|
||||
[CmdletBinding()]
|
||||
param(
|
||||
[Parameter(Mandatory)]
|
||||
[string]$Username,
|
||||
|
||||
[Parameter()]
|
||||
[ValidateSet('Basic', 'Detailed')]
|
||||
[string]$ProfileType = 'Basic'
|
||||
)
|
||||
|
||||
process {
|
||||
# Logic here
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Parameter Design
|
||||
|
||||
- **Standard Parameters:**
|
||||
- Use common parameter names (`Path`, `Name`, `Force`)
|
||||
- Follow built-in cmdlet conventions
|
||||
- Use aliases for specialized terms
|
||||
- Document parameter purpose
|
||||
|
||||
- **Parameter Names:**
|
||||
- Use singular form unless always multiple
|
||||
- Choose clear, descriptive names
|
||||
- Follow PowerShell conventions
|
||||
- Use PascalCase formatting
|
||||
|
||||
- **Type Selection:**
|
||||
- Use common .NET types
|
||||
- Implement proper validation
|
||||
- Consider ValidateSet for limited options
|
||||
- Enable tab completion where possible
|
||||
|
||||
- **Switch Parameters:**
|
||||
- Use [switch] for boolean flags
|
||||
- Avoid $true/$false parameters
|
||||
- Default to $false when omitted
|
||||
- Use clear action names
|
||||
|
||||
### Example
|
||||
|
||||
```powershell
|
||||
function Set-ResourceConfiguration {
|
||||
[CmdletBinding()]
|
||||
param(
|
||||
[Parameter(Mandatory)]
|
||||
[string]$Name,
|
||||
|
||||
[Parameter()]
|
||||
[ValidateSet('Dev', 'Test', 'Prod')]
|
||||
[string]$Environment = 'Dev',
|
||||
|
||||
[Parameter()]
|
||||
[switch]$Force,
|
||||
|
||||
[Parameter()]
|
||||
[ValidateNotNullOrEmpty()]
|
||||
[string[]]$Tags
|
||||
)
|
||||
|
||||
process {
|
||||
# Logic here
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Pipeline and Output
|
||||
|
||||
- **Pipeline Input:**
|
||||
- Use `ValueFromPipeline` for direct object input
|
||||
- Use `ValueFromPipelineByPropertyName` for property mapping
|
||||
- Implement Begin/Process/End blocks for pipeline handling
|
||||
- Document pipeline input requirements
|
||||
|
||||
- **Output Objects:**
|
||||
- Return rich objects, not formatted text
|
||||
- Use PSCustomObject for structured data
|
||||
- Avoid Write-Host for data output
|
||||
- Enable downstream cmdlet processing
|
||||
|
||||
- **Pipeline Streaming:**
|
||||
- Output one object at a time
|
||||
- Use process block for streaming
|
||||
- Avoid collecting large arrays
|
||||
- Enable immediate processing
|
||||
|
||||
- **PassThru Pattern:**
|
||||
- Default to no output for action cmdlets
|
||||
- Implement `-PassThru` switch for object return
|
||||
- Return modified/created object with `-PassThru`
|
||||
- Use verbose/warning for status updates
|
||||
|
||||
### Example
|
||||
|
||||
```powershell
|
||||
function Update-ResourceStatus {
|
||||
[CmdletBinding()]
|
||||
param(
|
||||
[Parameter(Mandatory, ValueFromPipeline, ValueFromPipelineByPropertyName)]
|
||||
[string]$Name,
|
||||
|
||||
[Parameter(Mandatory)]
|
||||
[ValidateSet('Active', 'Inactive', 'Maintenance')]
|
||||
[string]$Status,
|
||||
|
||||
[Parameter()]
|
||||
[switch]$PassThru
|
||||
)
|
||||
|
||||
begin {
|
||||
Write-Verbose "Starting resource status update process"
|
||||
$timestamp = Get-Date
|
||||
}
|
||||
|
||||
process {
|
||||
# Process each resource individually
|
||||
Write-Verbose "Processing resource: $Name"
|
||||
|
||||
$resource = [PSCustomObject]@{
|
||||
Name = $Name
|
||||
Status = $Status
|
||||
LastUpdated = $timestamp
|
||||
UpdatedBy = $env:USERNAME
|
||||
}
|
||||
|
||||
# Only output if PassThru is specified
|
||||
if ($PassThru) {
|
||||
Write-Output $resource
|
||||
}
|
||||
}
|
||||
|
||||
end {
|
||||
Write-Verbose "Resource status update process completed"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Error Handling and Safety
|
||||
|
||||
- **ShouldProcess Implementation:**
|
||||
- Use `[CmdletBinding(SupportsShouldProcess = $true)]`
|
||||
- Set appropriate `ConfirmImpact` level
|
||||
- Call `$PSCmdlet.ShouldProcess()` for system changes
|
||||
- Use `ShouldContinue()` for additional confirmations
|
||||
|
||||
- **Message Streams:**
|
||||
- `Write-Verbose` for operational details with `-Verbose`
|
||||
- `Write-Warning` for warning conditions
|
||||
- `Write-Error` for non-terminating errors
|
||||
- `throw` for terminating errors
|
||||
- Avoid `Write-Host` except for user interface text
|
||||
|
||||
- **Error Handling Pattern:**
|
||||
- Use try/catch blocks for error management
|
||||
- Set appropriate ErrorAction preferences
|
||||
- Return meaningful error messages
|
||||
- Use ErrorVariable when needed
|
||||
- Include proper terminating vs non-terminating error handling
|
||||
|
||||
- **Non-Interactive Design:**
|
||||
- Accept input via parameters
|
||||
- Avoid `Read-Host` in scripts
|
||||
- Support automation scenarios
|
||||
- Document all required inputs
|
||||
|
||||
### Example
|
||||
|
||||
```powershell
|
||||
function Remove-UserAccount {
|
||||
[CmdletBinding(SupportsShouldProcess = $true, ConfirmImpact = 'High')]
|
||||
param(
|
||||
[Parameter(Mandatory, ValueFromPipeline)]
|
||||
[ValidateNotNullOrEmpty()]
|
||||
[string]$Username,
|
||||
|
||||
[Parameter()]
|
||||
[switch]$Force
|
||||
)
|
||||
|
||||
begin {
|
||||
Write-Verbose "Starting user account removal process"
|
||||
$ErrorActionPreference = 'Stop'
|
||||
}
|
||||
|
||||
process {
|
||||
try {
|
||||
# Validation
|
||||
if (-not (Test-UserExists -Username $Username)) {
|
||||
Write-Error "User account '$Username' not found"
|
||||
return
|
||||
}
|
||||
|
||||
# Confirmation
|
||||
$shouldProcessMessage = "Remove user account '$Username'"
|
||||
if ($Force -or $PSCmdlet.ShouldProcess($Username, $shouldProcessMessage)) {
|
||||
Write-Verbose "Removing user account: $Username"
|
||||
|
||||
# Main operation
|
||||
Remove-ADUser -Identity $Username -ErrorAction Stop
|
||||
Write-Warning "User account '$Username' has been removed"
|
||||
}
|
||||
}
|
||||
catch [Microsoft.ActiveDirectory.Management.ADException] {
|
||||
Write-Error "Active Directory error: $_"
|
||||
throw
|
||||
}
|
||||
catch {
|
||||
Write-Error "Unexpected error removing user account: $_"
|
||||
throw
|
||||
}
|
||||
}
|
||||
|
||||
end {
|
||||
Write-Verbose "User account removal process completed"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Documentation and Style
|
||||
|
||||
- **Comment-Based Help:** Include comment-based help for any public-facing function or cmdlet. Inside the function, add a `<# ... #>` help comment with at least:
|
||||
- `.SYNOPSIS` Brief description
|
||||
- `.DESCRIPTION` Detailed explanation
|
||||
- `.EXAMPLE` sections with practical usage
|
||||
- `.PARAMETER` descriptions
|
||||
- `.OUTPUTS` Type of output returned
|
||||
- `.NOTES` Additional information
|
||||
|
||||
- **Consistent Formatting:**
|
||||
- Follow consistent PowerShell style
|
||||
- Use proper indentation (4 spaces recommended)
|
||||
- Opening braces on same line as statement
|
||||
- Closing braces on new line
|
||||
- Use line breaks after pipeline operators
|
||||
- PascalCase for function and parameter names
|
||||
- Avoid unnecessary whitespace
|
||||
|
||||
- **Pipeline Support:**
|
||||
- Implement Begin/Process/End blocks for pipeline functions
|
||||
- Use ValueFromPipeline where appropriate
|
||||
- Support pipeline input by property name
|
||||
- Return proper objects, not formatted text
|
||||
|
||||
- **Avoid Aliases:** Use full cmdlet names and parameters
|
||||
- Avoid using aliases in scripts (e.g., use Get-ChildItem instead of gci); aliases are acceptable for interactive shell use.
|
||||
- Use `Where-Object` instead of `?` or `where`
|
||||
- Use `ForEach-Object` instead of `%`
|
||||
- Use `Get-ChildItem` instead of `ls` or `dir`
|
||||
|
||||
## Full Example: End-to-End Cmdlet Pattern
|
||||
|
||||
```powershell
|
||||
function New-Resource {
|
||||
[CmdletBinding(SupportsShouldProcess = $true, ConfirmImpact = 'Medium')]
|
||||
param(
|
||||
[Parameter(Mandatory = $true,
|
||||
ValueFromPipeline = $true,
|
||||
ValueFromPipelineByPropertyName = $true)]
|
||||
[ValidateNotNullOrEmpty()]
|
||||
[string]$Name,
|
||||
|
||||
[Parameter()]
|
||||
[ValidateSet('Development', 'Production')]
|
||||
[string]$Environment = 'Development'
|
||||
)
|
||||
|
||||
begin {
|
||||
Write-Verbose "Starting resource creation process"
|
||||
}
|
||||
|
||||
process {
|
||||
try {
|
||||
if ($PSCmdlet.ShouldProcess($Name, "Create new resource")) {
|
||||
# Resource creation logic here
|
||||
Write-Output ([PSCustomObject]@{
|
||||
Name = $Name
|
||||
Environment = $Environment
|
||||
Created = Get-Date
|
||||
})
|
||||
}
|
||||
}
|
||||
catch {
|
||||
Write-Error "Failed to create resource: $_"
|
||||
}
|
||||
}
|
||||
|
||||
end {
|
||||
Write-Verbose "Completed resource creation process"
|
||||
}
|
||||
}
|
||||
```
|
||||
98
instructions/quarkus.instructions.md
Normal file
98
instructions/quarkus.instructions.md
Normal file
@ -0,0 +1,98 @@
|
||||
---
|
||||
applyTo: '*'
|
||||
description: 'Quarkus development standards and instructions'
|
||||
---
|
||||
|
||||
- Instructions for high-quality Quarkus applications with Java 17 or later.
|
||||
|
||||
## Project Context
|
||||
|
||||
- Latest Quarkus version: 3.x
|
||||
- Java version: 17 or later
|
||||
- Use Maven or Gradle for build management.
|
||||
- Focus on clean architecture, maintainability, and performance.
|
||||
|
||||
## Development Standards
|
||||
|
||||
- Write clear and concise comments for each class, method, and complex logic.
|
||||
- Use Javadoc for public APIs and methods to ensure clarity for consumers.
|
||||
- Maintain a consistent coding style across the project, adhering to Java conventions.
|
||||
- Adhere to the Quarkus coding standards and best practices for optimal performance and maintainability.
|
||||
- Follow Jarkarta EE and MicroProfile conventions, ensuring clarity in package organization.
|
||||
- Use Java 17 or later features where appropriate, such as records and sealed classes.
|
||||
|
||||
|
||||
## Naming Conventions
|
||||
- Use PascalCase for class names (e.g., `ProductService`, `ProductResource`).
|
||||
- Use camelCase for method and variable names (e.g., `findProductById`, `isProductAvailable`).
|
||||
- Use ALL_CAPS for constants (e.g., `DEFAULT_PAGE_SIZE`).
|
||||
|
||||
## Quarkus
|
||||
- Leverage Quarkus Dev Mode for faster development cycles.
|
||||
- Implement build-time optimizations using Quarkus extensions and best practices.
|
||||
- Configure native builds with GraalVM for optimal performance (e.g., use the quarkus-maven-plugin).
|
||||
- Use quarkus logging capabilities (JBoss, SL4J or JUL) for consistent logging practices.
|
||||
|
||||
### Quarkus-Specific Patterns
|
||||
- Use `@ApplicationScoped` for singleton beans instead of `@Singleton`
|
||||
- Use `@Inject` for dependency injection
|
||||
- Prefer Panache repositories over traditional JPA repositories
|
||||
- Use `@Transactional` on service methods that modify data
|
||||
- Apply `@Path` with descriptive REST endpoint paths
|
||||
- Use `@Consumes(MediaType.APPLICATION_JSON)` and `@Produces(MediaType.APPLICATION_JSON)` for REST resources
|
||||
|
||||
### REST Resources
|
||||
- Always use JAX-RS annotations (`@Path`, `@GET`, `@POST`, etc.)
|
||||
- Return proper HTTP status codes (200, 201, 400, 404, 500)
|
||||
- Use `Response` class for complex responses
|
||||
- Include proper error handling with try-catch blocks
|
||||
- Validate input parameters using Bean Validation annotations
|
||||
- Implement rate limiting for public endpoints
|
||||
|
||||
### Data Access
|
||||
- Prefer Panache entities (extend `PanacheEntity`) over traditional JPA
|
||||
- Use Panache repositories (`PanacheRepository<T>`) for complex queries
|
||||
- Always use `@Transactional` for data modifications
|
||||
- Use named queries for complex database operations
|
||||
- Implement proper pagination for list endpoints
|
||||
|
||||
|
||||
### Configuration
|
||||
- Use `application.properties` or `application.yaml` for simple configuration
|
||||
- Use `@ConfigProperty` for type-safe configuration classes
|
||||
- Prefer environment variables for sensitive data
|
||||
- Use profiles for different environments (dev, test, prod)
|
||||
|
||||
|
||||
### Testing
|
||||
- Use `@QuarkusTest` for integration tests
|
||||
- Use JUnit 5 for unit tests
|
||||
- Use `@QuarkusIntegrationTest` for native build tests
|
||||
- Mock external dependencies using `@QuarkusTestResource`
|
||||
- Use RestAssured for REST endpoint testing (`@QuarkusTestResource`)
|
||||
- Use `@Transactional` for tests that modify the database
|
||||
- Use test-containers for database integration tests
|
||||
|
||||
### Don't use these patterns:
|
||||
- Don't use field injection in tests (use constructor injection)
|
||||
- Don't hardcode configuration values
|
||||
- Don't ignore exceptions
|
||||
|
||||
|
||||
## Development Workflow
|
||||
|
||||
### When creating new features:
|
||||
1. Create entity with proper validation
|
||||
2. Create repository with custom queries
|
||||
3. Create service with business logic
|
||||
4. Create REST resource with proper endpoints
|
||||
5. Write comprehensive tests
|
||||
6. Add proper error handling
|
||||
7. Update documentation
|
||||
|
||||
## Security Considerations
|
||||
|
||||
### When implementing security:
|
||||
- Use Quarkus Security extensions (e.g., `quarkus-smallrye-jwt`, `quarkus-oidc`).
|
||||
- Implement role-based access control (RBAC) using MicroProfile JWT or OIDC.
|
||||
- Validate all input parameters
|
||||
212
instructions/tanstack-start-shadcn-tailwind.md
Normal file
212
instructions/tanstack-start-shadcn-tailwind.md
Normal file
@ -0,0 +1,212 @@
|
||||
---
|
||||
description: 'Guidelines for building TanStack Start applications'
|
||||
applyTo: '**/*.ts, **/*.tsx, **/*.js, **/*.jsx, **/*.css, **/*.scss, **/*.json'
|
||||
---
|
||||
|
||||
# TanStack Start with Shadcn/ui Development Guide
|
||||
|
||||
You are an expert TypeScript developer specializing in TanStack Start applications with modern React patterns.
|
||||
|
||||
## Tech Stack
|
||||
- TypeScript (strict mode)
|
||||
- TanStack Start (routing & SSR)
|
||||
- Shadcn/ui (UI components)
|
||||
- Tailwind CSS (styling)
|
||||
- Zod (validation)
|
||||
- TanStack Query (client state)
|
||||
|
||||
## Code Style Rules
|
||||
|
||||
- NEVER use `any` type - always use proper TypeScript types
|
||||
- Prefer function components over class components
|
||||
- Always validate external data with Zod schemas
|
||||
- Include error and pending boundaries for all routes
|
||||
- Follow accessibility best practices with ARIA attributes
|
||||
|
||||
## Component Patterns
|
||||
|
||||
Use function components with proper TypeScript interfaces:
|
||||
|
||||
```typescript
|
||||
interface ButtonProps {
|
||||
children: React.ReactNode;
|
||||
onClick: () => void;
|
||||
variant?: 'primary' | 'secondary';
|
||||
}
|
||||
|
||||
export default function Button({ children, onClick, variant = 'primary' }: ButtonProps) {
|
||||
return (
|
||||
<button onClick={onClick} className={cn(buttonVariants({ variant }))}>
|
||||
{children}
|
||||
</button>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
## Data Fetching
|
||||
|
||||
Use Route Loaders for:
|
||||
- Initial page data required for rendering
|
||||
- SSR requirements
|
||||
- SEO-critical data
|
||||
|
||||
Use React Query for:
|
||||
- Frequently updating data
|
||||
- Optional/secondary data
|
||||
- Client mutations with optimistic updates
|
||||
|
||||
```typescript
|
||||
// Route Loader
|
||||
export const Route = createFileRoute('/users')({
|
||||
loader: async () => {
|
||||
const users = await fetchUsers()
|
||||
return { users: userListSchema.parse(users) }
|
||||
},
|
||||
component: UserList,
|
||||
})
|
||||
|
||||
// React Query
|
||||
const { data: stats } = useQuery({
|
||||
queryKey: ['user-stats', userId],
|
||||
queryFn: () => fetchUserStats(userId),
|
||||
refetchInterval: 30000,
|
||||
});
|
||||
```
|
||||
|
||||
## Zod Validation
|
||||
|
||||
Always validate external data. Define schemas in `src/lib/schemas.ts`:
|
||||
|
||||
```typescript
|
||||
export const userSchema = z.object({
|
||||
id: z.string(),
|
||||
name: z.string().min(1).max(100),
|
||||
email: z.string().email().optional(),
|
||||
role: z.enum(['admin', 'user']).default('user'),
|
||||
})
|
||||
|
||||
export type User = z.infer<typeof userSchema>
|
||||
|
||||
// Safe parsing
|
||||
const result = userSchema.safeParse(data)
|
||||
if (!result.success) {
|
||||
console.error('Validation failed:', result.error.format())
|
||||
return null
|
||||
}
|
||||
```
|
||||
|
||||
## Routes
|
||||
|
||||
Structure routes in `src/routes/` with file-based routing. Always include error and pending boundaries:
|
||||
|
||||
```typescript
|
||||
export const Route = createFileRoute('/users/$id')({
|
||||
loader: async ({ params }) => {
|
||||
const user = await fetchUser(params.id);
|
||||
return { user: userSchema.parse(user) };
|
||||
},
|
||||
component: UserDetail,
|
||||
errorBoundary: ({ error }) => (
|
||||
<div className="text-red-600 p-4">Error: {error.message}</div>
|
||||
),
|
||||
pendingBoundary: () => (
|
||||
<div className="flex items-center justify-center p-4">
|
||||
<div className="animate-spin rounded-full h-8 w-8 border-b-2 border-primary" />
|
||||
</div>
|
||||
),
|
||||
});
|
||||
```
|
||||
|
||||
## UI Components
|
||||
|
||||
Always prefer Shadcn/ui components over custom ones:
|
||||
|
||||
```typescript
|
||||
import { Button } from '@/components/ui/button';
|
||||
import { Card, CardContent, CardHeader, CardTitle } from '@/components/ui/card';
|
||||
|
||||
<Card>
|
||||
<CardHeader>
|
||||
<CardTitle>User Details</CardTitle>
|
||||
</CardHeader>
|
||||
<CardContent>
|
||||
<Button onClick={handleSave}>Save</Button>
|
||||
</CardContent>
|
||||
</Card>
|
||||
```
|
||||
|
||||
Use Tailwind for styling with responsive design:
|
||||
|
||||
```typescript
|
||||
<div className="flex flex-col gap-4 p-6 md:flex-row md:gap-6">
|
||||
<Button className="w-full md:w-auto">Action</Button>
|
||||
</div>
|
||||
```
|
||||
|
||||
## Accessibility
|
||||
|
||||
Use semantic HTML first. Only add ARIA when no semantic equivalent exists:
|
||||
|
||||
```typescript
|
||||
// ✅ Good: Semantic HTML with minimal ARIA
|
||||
<button onClick={toggleMenu}>
|
||||
<MenuIcon aria-hidden="true" />
|
||||
<span className="sr-only">Toggle Menu</span>
|
||||
</button>
|
||||
|
||||
// ✅ Good: ARIA only when needed (for dynamic states)
|
||||
<button
|
||||
aria-expanded={isOpen}
|
||||
aria-controls="menu"
|
||||
onClick={toggleMenu}
|
||||
>
|
||||
Menu
|
||||
</button>
|
||||
|
||||
// ✅ Good: Semantic form elements
|
||||
<label htmlFor="email">Email Address</label>
|
||||
<input id="email" type="email" />
|
||||
{errors.email && (
|
||||
<p role="alert">{errors.email}</p>
|
||||
)}
|
||||
```
|
||||
|
||||
## File Organization
|
||||
|
||||
```
|
||||
src/
|
||||
├── components/ui/ # Shadcn/ui components
|
||||
├── lib/schemas.ts # Zod schemas
|
||||
├── routes/ # File-based routes
|
||||
└── routes/api/ # Server routes (.ts)
|
||||
```
|
||||
|
||||
## Import Standards
|
||||
|
||||
Use `@/` alias for all internal imports:
|
||||
|
||||
```typescript
|
||||
// ✅ Good
|
||||
import { Button } from '@/components/ui/button'
|
||||
import { userSchema } from '@/lib/schemas'
|
||||
|
||||
// ❌ Bad
|
||||
import { Button } from '../components/ui/button'
|
||||
```
|
||||
|
||||
## Adding Components
|
||||
|
||||
Install Shadcn components when needed:
|
||||
|
||||
```bash
|
||||
npx shadcn@latest add button card input dialog
|
||||
```
|
||||
|
||||
## Common Patterns
|
||||
|
||||
- Always validate external data with Zod
|
||||
- Use route loaders for initial data, React Query for updates
|
||||
- Include error/pending boundaries on all routes
|
||||
- Prefer Shadcn components over custom UI
|
||||
- Use `@/` imports consistently
|
||||
- Follow accessibility best practices
|
||||
156
prompts/create-spring-boot-java-project.prompt.md
Normal file
156
prompts/create-spring-boot-java-project.prompt.md
Normal file
@ -0,0 +1,156 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'findTestFiles', 'problems', 'runCommands', 'runTests', 'search', 'searchResults', 'terminalLastCommand', 'testFailure', 'usages']
|
||||
description: 'Create Spring Boot Java project skeleton'
|
||||
---
|
||||
|
||||
# Create Spring Boot Java project prompt
|
||||
|
||||
- Please make sure you have the following software installed on your system:
|
||||
|
||||
- Java 21
|
||||
- Docker
|
||||
- Docker Compose
|
||||
|
||||
- If you need to custom the project name, please change the `artifactId` and the `packageName` in [download-spring-boot-project-template](./create-spring-boot-java-project.prompt.md#download-spring-boot-project-template)
|
||||
|
||||
- If you need to update the Spring Boot version, please change the `bootVersion` in [download-spring-boot-project-template](./create-spring-boot-java-project.prompt.md#download-spring-boot-project-template)
|
||||
|
||||
## Check Java version
|
||||
|
||||
- Run following command in terminal and check the version of Java
|
||||
|
||||
```shell
|
||||
java -version
|
||||
```
|
||||
|
||||
## Download Spring Boot project template
|
||||
|
||||
- Run following command in terminal to download a Spring Boot project template
|
||||
|
||||
```shell
|
||||
curl https://start.spring.io/starter.zip \
|
||||
-d artifactId=demo \
|
||||
-d bootVersion=3.4.5 \
|
||||
-d dependencies=lombok,configuration-processor,web,data-jpa,postgresql,data-redis,data-mongodb,validation,cache,testcontainers \
|
||||
-d javaVersion=21 \
|
||||
-d packageName=com.example \
|
||||
-d packaging=jar \
|
||||
-d type=maven-project \
|
||||
-o starter.zip
|
||||
```
|
||||
|
||||
## Unzip the downloaded file
|
||||
|
||||
- Run following command in terminal to unzip the downloaded file
|
||||
|
||||
```shell
|
||||
unzip starter.zip -d .
|
||||
```
|
||||
|
||||
## Remove the downloaded zip file
|
||||
|
||||
- Run following command in terminal to delete the downloaded zip file
|
||||
|
||||
```shell
|
||||
rm -f starter.zip
|
||||
```
|
||||
|
||||
## Add additional dependencies
|
||||
|
||||
- Insert `springdoc-openapi-starter-webmvc-ui` and `archunit-junit5` dependency into `pom.xml` file
|
||||
|
||||
```xml
|
||||
<dependency>
|
||||
<groupId>org.springdoc</groupId>
|
||||
<artifactId>springdoc-openapi-starter-webmvc-ui</artifactId>
|
||||
<version>2.8.6</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>com.tngtech.archunit</groupId>
|
||||
<artifactId>archunit-junit5</artifactId>
|
||||
<version>1.2.1</version>
|
||||
<scope>test</scope>
|
||||
</dependency>
|
||||
```
|
||||
|
||||
## Add SpringDoc, Redis, JPA and MongoDB configurations
|
||||
|
||||
- Insert SpringDoc configurations into `application.properties` file
|
||||
|
||||
```properties
|
||||
# SpringDoc configurations
|
||||
springdoc.swagger-ui.doc-expansion=none
|
||||
springdoc.swagger-ui.operations-sorter=alpha
|
||||
springdoc.swagger-ui.tags-sorter=alpha
|
||||
```
|
||||
|
||||
- Insert Redis configurations into `application.properties` file
|
||||
|
||||
```properties
|
||||
# Redis configurations
|
||||
spring.data.redis.host=localhost
|
||||
spring.data.redis.port=6379
|
||||
spring.data.redis.password=rootroot
|
||||
```
|
||||
|
||||
- Insert JPA configurations into `application.properties` file
|
||||
|
||||
```properties
|
||||
# JPA configurations
|
||||
spring.datasource.driver-class-name=org.postgresql.Driver
|
||||
spring.datasource.url=jdbc:postgresql://localhost:5432/postgres
|
||||
spring.datasource.username=postgres
|
||||
spring.datasource.password=rootroot
|
||||
spring.jpa.hibernate.ddl-auto=update
|
||||
spring.jpa.show-sql=true
|
||||
spring.jpa.properties.hibernate.format_sql=true
|
||||
```
|
||||
|
||||
- Insert MongoDB configurations into `application.properties` file
|
||||
|
||||
```properties
|
||||
# MongoDB configurations
|
||||
spring.data.mongodb.host=localhost
|
||||
spring.data.mongodb.port=27017
|
||||
spring.data.mongodb.authentication-database=admin
|
||||
spring.data.mongodb.username=root
|
||||
spring.data.mongodb.password=rootroot
|
||||
spring.data.mongodb.database=test
|
||||
```
|
||||
|
||||
## Add `docker-compose.yaml` with Redis, PostgreSQL and MongoDB services
|
||||
|
||||
- Create `docker-compose.yaml` at project root and add following services: `redis:6`, `postgresql:17` and `mongo:8`.
|
||||
|
||||
- redis service should have
|
||||
- password `rootroot`
|
||||
- mapping port 6379 to 6379
|
||||
- mounting volume `./redis_data` to `/data`
|
||||
- postgresql service should have
|
||||
- password `rootroot`
|
||||
- mapping port 5432 to 5432
|
||||
- mounting volume `./postgres_data` to `/var/lib/postgresql/data`
|
||||
- mongo service should have
|
||||
- initdb root username `root`
|
||||
- initdb root password `rootroot`
|
||||
- mapping port 27017 to 27017
|
||||
- mounting volume `./mongo_data` to `/data/db`
|
||||
|
||||
## Add `.gitignore` file
|
||||
|
||||
- Insert `redis_data`, `postgres_data` and `mongo_data` directories in `.gitignore` file
|
||||
|
||||
## Run Maven test command
|
||||
|
||||
- Run maven clean test command to check if the project is working
|
||||
|
||||
```shell
|
||||
./mvnw clean test
|
||||
```
|
||||
|
||||
## Run Maven run command (Optional)
|
||||
|
||||
- (Optional) `docker-compose up -d` to start the services, `./mvnw spring-boot:run` to run the Spring Boot project, `docker-compose rm -sf` to stop the services.
|
||||
|
||||
## Let's do this step by step
|
||||
140
prompts/create-spring-boot-kotlin-project.prompt.md
Normal file
140
prompts/create-spring-boot-kotlin-project.prompt.md
Normal file
@ -0,0 +1,140 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'findTestFiles', 'problems', 'runCommands', 'runTests', 'search', 'searchResults', 'terminalLastCommand', 'testFailure', 'usages']
|
||||
description: 'Create Spring Boot Kotlin project skeleton'
|
||||
---
|
||||
|
||||
# Create Spring Boot Kotlin project prompt
|
||||
|
||||
- Please make sure you have the following software installed on your system:
|
||||
|
||||
- Java 21
|
||||
- Docker
|
||||
- Docker Compose
|
||||
|
||||
- If you need to custom the project name, please change the `artifactId` and the `packageName` in [download-spring-boot-project-template](./create-spring-boot-kotlin-project.prompt.md#download-spring-boot-project-template)
|
||||
|
||||
- If you need to update the Spring Boot version, please change the `bootVersion` in [download-spring-boot-project-template](./create-spring-boot-kotlin-project.prompt.md#download-spring-boot-project-template)
|
||||
|
||||
## Check Java version
|
||||
|
||||
- Run following command in terminal and check the version of Java
|
||||
|
||||
```shell
|
||||
java -version
|
||||
```
|
||||
|
||||
## Download Spring Boot project template
|
||||
|
||||
- Run following command in terminal to download a Spring Boot project template
|
||||
|
||||
```shell
|
||||
curl https://start.spring.io/starter.zip \
|
||||
-d artifactId=demo \
|
||||
-d bootVersion=3.4.5 \
|
||||
-d dependencies=configuration-processor,webflux,data-r2dbc,postgresql,data-redis-reactive,data-mongodb-reactive,validation,cache,testcontainers \
|
||||
-d javaVersion=21 \
|
||||
-d language=kotlin \
|
||||
-d packageName=com.example \
|
||||
-d packaging=jar \
|
||||
-d type=gradle-project-kotlin \
|
||||
-o starter.zip
|
||||
```
|
||||
|
||||
## Unzip the downloaded file
|
||||
|
||||
- Run following command in terminal to unzip the downloaded file
|
||||
|
||||
```shell
|
||||
unzip starter.zip -d .
|
||||
```
|
||||
|
||||
## Remove the downloaded zip file
|
||||
|
||||
- Run following command in terminal to delete the downloaded zip file
|
||||
|
||||
```shell
|
||||
rm -f starter.zip
|
||||
```
|
||||
|
||||
## Add additional dependencies
|
||||
|
||||
- Insert `springdoc-openapi-starter-webmvc-ui` and `archunit-junit5` dependency into `build.gradle.kts` file
|
||||
|
||||
```gradle.kts
|
||||
dependencies {
|
||||
implementation("org.springdoc:springdoc-openapi-starter-webflux-ui:2.8.6")
|
||||
testImplementation("com.tngtech.archunit:archunit-junit5:1.2.1")
|
||||
}
|
||||
```
|
||||
|
||||
- Insert SpringDoc configurations into `application.properties` file
|
||||
|
||||
```properties
|
||||
# SpringDoc configurations
|
||||
springdoc.swagger-ui.doc-expansion=none
|
||||
springdoc.swagger-ui.operations-sorter=alpha
|
||||
springdoc.swagger-ui.tags-sorter=alpha
|
||||
```
|
||||
|
||||
- Insert Redis configurations into `application.properties` file
|
||||
|
||||
```properties
|
||||
# Redis configurations
|
||||
spring.data.redis.host=localhost
|
||||
spring.data.redis.port=6379
|
||||
spring.data.redis.password=rootroot
|
||||
```
|
||||
|
||||
- Insert R2DBC configurations into `application.properties` file
|
||||
|
||||
```properties
|
||||
# R2DBC configurations
|
||||
spring.r2dbc.url=r2dbc:postgresql://localhost:5432/postgres
|
||||
spring.r2dbc.username=postgres
|
||||
spring.r2dbc.password=rootroot
|
||||
|
||||
spring.sql.init.mode=always
|
||||
spring.sql.init.platform=postgres
|
||||
spring.sql.init.continue-on-error=true
|
||||
```
|
||||
|
||||
- Insert MongoDB configurations into `application.properties` file
|
||||
|
||||
```properties
|
||||
# MongoDB configurations
|
||||
spring.data.mongodb.host=localhost
|
||||
spring.data.mongodb.port=27017
|
||||
spring.data.mongodb.authentication-database=admin
|
||||
spring.data.mongodb.username=root
|
||||
spring.data.mongodb.password=rootroot
|
||||
spring.data.mongodb.database=test
|
||||
```
|
||||
|
||||
- Create `docker-compose.yaml` at project root and add following services: `redis:6`, `postgresql:17` and `mongo:8`.
|
||||
|
||||
- redis service should have
|
||||
- password `rootroot`
|
||||
- mapping port 6379 to 6379
|
||||
- mounting volume `./redis_data` to `/data`
|
||||
- postgresql service should have
|
||||
- password `rootroot`
|
||||
- mapping port 5432 to 5432
|
||||
- mounting volume `./postgres_data` to `/var/lib/postgresql/data`
|
||||
- mongo service should have
|
||||
- initdb root username `root`
|
||||
- initdb root password `rootroot`
|
||||
- mapping port 27017 to 27017
|
||||
- mounting volume `./mongo_data` to `/data/db`
|
||||
|
||||
- Insert `redis_data`, `postgres_data` and `mongo_data` directories in `.gitignore` file
|
||||
|
||||
- Run gradle clean test command to check if the project is working
|
||||
|
||||
```shell
|
||||
./graldew clean test
|
||||
```
|
||||
|
||||
- (Optional) `docker-compose up -d` to start the services, `./graldew spring-boot:run` to run the Spring Boot project, `docker-compose rm -sf` to stop the services.
|
||||
|
||||
Let's do this step by step.
|
||||
Loading…
x
Reference in New Issue
Block a user