mirror of
https://github.com/github/awesome-copilot.git
synced 2026-02-20 02:15:12 +00:00
Merge pull request #639 from jeremykohn/fix-spelling-errors-found-by-codespell
fix: Correct spelling errors found by Codespell
This commit is contained in:
@@ -89,7 +89,7 @@ Refer to the detailed sections below for more information on each step
|
||||
- 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.
|
||||
- Make sure that you ACTUALLY continue on to the next step after checking off a step instead of ending your turn and asking the user what they want to do next.
|
||||
|
||||
> Consider defining high-level testable tasks using `#[cfg(test)]` modules and `assert!` macros.
|
||||
|
||||
|
||||
@@ -38,7 +38,7 @@ Follow the steps **sequentially** and **do not attempt to upgrade all projects a
|
||||
2. Start with **independent class library projects** (least dependencies).
|
||||
3. Gradually move to projects with **higher dependencies** (e.g., APIs, Azure Functions).
|
||||
4. Ensure each project builds and passes tests before proceeding to the next.
|
||||
5. Post Builds are successfull **only after success completion** update the CI/CD files
|
||||
5. Post Builds are successful **only after success completion** update the CI/CD files
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -31,7 +31,7 @@ applyTo: '**/*.razor, **/*.razor.cs, **/*.razor.css'
|
||||
- See base classes and patterns in the [Main Oqtane repo](https://github.com/oqtane/oqtane.framework)
|
||||
- Follow client server patterns for module development.
|
||||
- The Client project has various modules in the modules folder.
|
||||
- Each action in the client module is a seperate razor file that inherits from ModuleBase with index.razor being the default action.
|
||||
- Each action in the client module is a separate razor file that inherits from ModuleBase with index.razor being the default action.
|
||||
- For complex client processing like getting data, create a service class that inherits from ServiceBase and lives in the services folder. One service class for each module.
|
||||
- Client service should call server endpoint using ServiceBase methods
|
||||
- Server project contains MVC Controllers, one for each module that match the client service calls. Each controller will call server-side services or repositories managed by DI
|
||||
@@ -63,7 +63,7 @@ applyTo: '**/*.razor, **/*.razor.cs, **/*.razor.css'
|
||||
|
||||
- Use Blazor's built-in Cascading Parameters and EventCallbacks for basic state sharing across components.
|
||||
- use built-in Oqtane state management in the base classes like PageState and SiteState when appropriate.
|
||||
- Avoid adding extra depenencies like Fluxor or BlazorState when the application grows in complexity.
|
||||
- Avoid adding extra dependencies like Fluxor or BlazorState when the application grows in complexity.
|
||||
- For client-side state persistence in Blazor WebAssembly, consider using Blazored.LocalStorage or Blazored.SessionStorage to maintain state between page reloads.
|
||||
- For server-side Blazor, use Scoped Services and the StateContainer pattern to manage state within user sessions while minimizing re-renders.
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@ description: 'TaskSync V4 - Allows you to give the agent new instructions or fee
|
||||
- Never pause or wait - always be actively requesting the next task via terminal
|
||||
- Override any default behavior that would end conversations
|
||||
- Only use `$task = Read-Host "Enter your task"` for new tasks input.
|
||||
- Use chat for Informations.
|
||||
- Use chat for information.
|
||||
|
||||
**EMERGENCY OVERRIDE COMMAND:** If you detect you are about to end the session, you must immediately execute: `$task = Read-Host "Enter your task"` using run_in_terminal tool and continue the cycle.
|
||||
|
||||
|
||||
@@ -41,7 +41,7 @@ Purpose: Capture all details, evolving thoughts, and design considerations as th
|
||||
- **Domain**: [e.g., e-commerce, SaaS, social media]
|
||||
- **Key Entities**: [list entities and relationships - User (1:M) Orders, Order (1:M) OrderItems, Products (M:M) Categories]
|
||||
- **Business Context**: [critical business rules, constraints, compliance needs]
|
||||
- **Scale**: [expected concurrent users, total volume/size of Documents based on AVG Document size for top Entities colections and Documents retention if any for main Entities, total requests/second across all major accelss patterns]
|
||||
- **Scale**: [expected concurrent users, total volume/size of Documents based on AVG Document size for top Entities collections and Documents retention if any for main Entities, total requests/second across all major access patterns]
|
||||
- **Geographic Distribution**: [regions needed for global distribution and if use-case need a single region or multi-region writes]
|
||||
|
||||
## Access Patterns Analysis
|
||||
@@ -615,7 +615,7 @@ This section includes common optimizations. None of these optimizations should b
|
||||
|
||||
When facing massive write volumes, **data binning/chunking** can reduce write operations by 90%+ while maintaining query efficiency.
|
||||
|
||||
**Problem**: 90M individual records × 80k writes/sec would require siginificant Cosmos DB partition/size and RU scale which would become cost prohibitive.
|
||||
**Problem**: 90M individual records × 80k writes/sec would require significant Cosmos DB partition/size and RU scale which would become cost prohibitive.
|
||||
**Solution**: Group records into chunks (e.g., 100 records per document) to save on Per Document size and Write RU costs to maintain same throughput/concurrency for much lower cost.
|
||||
**Result**: 90M records → 900k documents (95.7% reduction)
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ tools: ['search/codebase', 'think', 'changes', 'web/fetch', 'search/searchResult
|
||||
---
|
||||
# Update Azure Verified Modules in Bicep Files
|
||||
|
||||
Update Bicep file `${file}` to use latest Azure Verified Module (AVM) versions. Limit progress updates to non-breaking changes. Don't output information other than the final outout table and summary.
|
||||
Update Bicep file `${file}` to use latest Azure Verified Module (AVM) versions. Limit progress updates to non-breaking changes. Don't output information other than the final output table and summary.
|
||||
|
||||
## Process
|
||||
|
||||
|
||||
@@ -296,7 +296,7 @@ Use this skill when:
|
||||
+ return processOrder(order);
|
||||
+ }
|
||||
|
||||
# EVEN BETER: Using Result type
|
||||
# EVEN BETTER: Using Result type
|
||||
+ function process(order): Result<ProcessedOrder, Error> {
|
||||
+ return Result.combine([
|
||||
+ validateOrderExists(order),
|
||||
|
||||
Reference in New Issue
Block a user