diff --git a/agents/rust-gpt-4.1-beast-mode.agent.md b/agents/rust-gpt-4.1-beast-mode.agent.md index 33ca09e6..ecad4a75 100644 --- a/agents/rust-gpt-4.1-beast-mode.agent.md +++ b/agents/rust-gpt-4.1-beast-mode.agent.md @@ -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. diff --git a/instructions/dotnet-upgrade.instructions.md b/instructions/dotnet-upgrade.instructions.md index e384dc37..7c8b733b 100644 --- a/instructions/dotnet-upgrade.instructions.md +++ b/instructions/dotnet-upgrade.instructions.md @@ -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 --- diff --git a/instructions/oqtane.instructions.md b/instructions/oqtane.instructions.md index ef39ab7e..53ee2b5d 100644 --- a/instructions/oqtane.instructions.md +++ b/instructions/oqtane.instructions.md @@ -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. diff --git a/instructions/tasksync.instructions.md b/instructions/tasksync.instructions.md index a0a09f4e..e9e4af69 100644 --- a/instructions/tasksync.instructions.md +++ b/instructions/tasksync.instructions.md @@ -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. diff --git a/prompts/cosmosdb-datamodeling.prompt.md b/prompts/cosmosdb-datamodeling.prompt.md index 241e606e..0c56405d 100644 --- a/prompts/cosmosdb-datamodeling.prompt.md +++ b/prompts/cosmosdb-datamodeling.prompt.md @@ -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) diff --git a/prompts/update-avm-modules-in-bicep.prompt.md b/prompts/update-avm-modules-in-bicep.prompt.md index 49fcda94..5fd0a20b 100644 --- a/prompts/update-avm-modules-in-bicep.prompt.md +++ b/prompts/update-avm-modules-in-bicep.prompt.md @@ -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 diff --git a/skills/refactor/SKILL.md b/skills/refactor/SKILL.md index a5b3af02..ba8313b0 100644 --- a/skills/refactor/SKILL.md +++ b/skills/refactor/SKILL.md @@ -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 { + return Result.combine([ + validateOrderExists(order),