@totaland/create-starter-kit 2.0.1 → 2.0.2

package/templates/backend/.github/prompts/create-technical-spike.prompt.md

@@ -1,230 +0,0 @@
----
-description: 'Create time-boxed technical spike documents for researching and resolving critical development decisions before implementation.'
-tools: ['runCommands', 'runTasks', 'edit', 'search', 'extensions', 'usages', 'vscodeAPI', 'think', 'problems', 'changes', 'testFailure', 'openSimpleBrowser', 'fetch', 'githubRepo', 'todos', 'Microsoft Docs', 'search']
----
-
-# Create Technical Spike Document
-
-Create time-boxed technical spike documents for researching critical questions that must be answered before development can proceed. Each spike focuses on a specific technical decision with clear deliverables and timelines.
-
-## Document Structure
-
-Create individual files in `${input:FolderPath|docs/spikes}` directory. Name each file using the pattern: `[category]-[short-description]-spike.md` (e.g., `api-copilot-integration-spike.md`, `performance-realtime-audio-spike.md`).
-
-```md
----
-title: "${input:SpikeTitle}"
-category: "${input:Category|Technical}"
-status: "🔴 Not Started"
-priority: "${input:Priority|High}"
-timebox: "${input:Timebox|1 week}"
-created: [YYYY-MM-DD]
-updated: [YYYY-MM-DD]
-owner: "${input:Owner}"
-tags: ["technical-spike", "${input:Category|technical}", "research"]
----
-
-# ${input:SpikeTitle}
-
-## Summary
-
-**Spike Objective:** [Clear, specific question or decision that needs resolution]
-
-**Why This Matters:** [Impact on development/architecture decisions]
-
-**Timebox:** [How much time allocated to this spike]
-
-**Decision Deadline:** [When this must be resolved to avoid blocking development]
-
-## Research Question(s)
-
-**Primary Question:** [Main technical question that needs answering]
-
-**Secondary Questions:**
-
-- [Related question 1]
-- [Related question 2]
-- [Related question 3]
-
-## Investigation Plan
-
-### Research Tasks
-
-- [ ] [Specific research task 1]
-- [ ] [Specific research task 2]
-- [ ] [Specific research task 3]
-- [ ] [Create proof of concept/prototype]
-- [ ] [Document findings and recommendations]
-
-### Success Criteria
-
-**This spike is complete when:**
-
-- [ ] [Specific criteria 1]
-- [ ] [Specific criteria 2]
-- [ ] [Clear recommendation documented]
-- [ ] [Proof of concept completed (if applicable)]
-
-## Technical Context
-
-**Related Components:** [List system components affected by this decision]
-
-**Dependencies:** [What other spikes or decisions depend on resolving this]
-
-**Constraints:** [Known limitations or requirements that affect the solution]
-
-## Research Findings
-
-### Investigation Results
-
-[Document research findings, test results, and evidence gathered]
-
-### Prototype/Testing Notes
-
-[Results from any prototypes, spikes, or technical experiments]
-
-### External Resources
-
-- [Link to relevant documentation]
-- [Link to API references]
-- [Link to community discussions]
-- [Link to examples/tutorials]
-
-## Decision
-
-### Recommendation
-
-[Clear recommendation based on research findings]
-
-### Rationale
-
-[Why this approach was chosen over alternatives]
-
-### Implementation Notes
-
-[Key considerations for implementation]
-
-### Follow-up Actions
-
-- [ ] [Action item 1]
-- [ ] [Action item 2]
-- [ ] [Update architecture documents]
-- [ ] [Create implementation tasks]
-
-## Status History
-
-| Date   | Status         | Notes                      |
-| ------ | -------------- | -------------------------- |
-| [Date] | 🔴 Not Started | Spike created and scoped   |
-| [Date] | 🟡 In Progress | Research commenced         |
-| [Date] | 🟢 Complete    | [Resolution summary]       |
-
----
-
-_Last updated: [Date] by [Name]_
-```
-
-## Categories for Technical Spikes
-
-### API Integration
-
-- Third-party API capabilities and limitations
-- Integration patterns and authentication
-- Rate limits and performance characteristics
-
-### Architecture & Design
-
-- System architecture decisions
-- Design pattern applicability
-- Component interaction models
-
-### Performance & Scalability
-
-- Performance requirements and constraints
-- Scalability bottlenecks and solutions
-- Resource utilization patterns
-
-### Platform & Infrastructure
-
-- Platform capabilities and limitations
-- Infrastructure requirements
-- Deployment and hosting considerations
-
-### Security & Compliance
-
-- Security requirements and implementations
-- Compliance constraints
-- Authentication and authorization approaches
-
-### User Experience
-
-- User interaction patterns
-- Accessibility requirements
-- Interface design decisions
-
-## File Naming Conventions
-
-Use descriptive, kebab-case names that indicate the category and specific unknown:
-
-**API/Integration Examples:**
-
-- `api-copilot-chat-integration-spike.md`
-- `api-azure-speech-realtime-spike.md`
-- `api-vscode-extension-capabilities-spike.md`
-
-**Performance Examples:**
-
-- `performance-audio-processing-latency-spike.md`
-- `performance-extension-host-limitations-spike.md`
-- `performance-webrtc-reliability-spike.md`
-
-**Architecture Examples:**
-
-- `architecture-voice-pipeline-design-spike.md`
-- `architecture-state-management-spike.md`
-- `architecture-error-handling-strategy-spike.md`
-
-## Best Practices for AI Agents
-
-1. **One Question Per Spike:** Each document focuses on a single technical decision or research question
-
-2. **Time-Boxed Research:** Define specific time limits and deliverables for each spike
-
-3. **Evidence-Based Decisions:** Require concrete evidence (tests, prototypes, documentation) before marking as complete
-
-4. **Clear Recommendations:** Document specific recommendations and rationale for implementation
-
-5. **Dependency Tracking:** Identify how spikes relate to each other and impact project decisions
-
-6. **Outcome-Focused:** Every spike must result in an actionable decision or recommendation
-
-## Research Strategy
-
-### Phase 1: Information Gathering
-
-1. **Search existing documentation** using search/fetch tools
-2. **Analyze codebase** for existing patterns and constraints
-3. **Research external resources** (APIs, libraries, examples)
-
-### Phase 2: Validation & Testing
-
-1. **Create focused prototypes** to test specific hypotheses
-2. **Run targeted experiments** to validate assumptions
-3. **Document test results** with supporting evidence
-
-### Phase 3: Decision & Documentation
-
-1. **Synthesize findings** into clear recommendations
-2. **Document implementation guidance** for development team
-3. **Create follow-up tasks** for implementation
-
-## Tools Usage
-
-- **search/searchResults:** Research existing solutions and documentation
-- **fetch/githubRepo:** Analyze external APIs, libraries, and examples
-- **codebase:** Understand existing system constraints and patterns
-- **runTasks:** Execute prototypes and validation tests
-- **editFiles:** Update research progress and findings
-- **vscodeAPI:** Test VS Code extension capabilities and limitations
-
-Focus on time-boxed research that resolves critical technical decisions and unblocks development progress.

package/templates/backend/.github/prompts/csharp-nunit.prompt.md

@@ -1,71 +0,0 @@
----
-tools: ['changes', 'search/codebase', 'edit/editFiles', 'problems', 'search']
-description: 'Get best practices for NUnit unit testing, including data-driven tests'
----
-
-# NUnit Best Practices
-
-Your goal is to help me write effective unit tests with NUnit, covering both standard and data-driven testing approaches.
-
-## Project Setup
-
-- Use a separate test project with naming convention `[ProjectName].Tests`
-- Reference Microsoft.NET.Test.Sdk, NUnit, and NUnit3TestAdapter packages
-- Create test classes that match the classes being tested (e.g., `CalculatorTests` for `Calculator`)
-- Use .NET SDK test commands: `dotnet test` for running tests
-
-## Test Structure
-
-- Apply `[TestFixture]` attribute to test classes
-- Use `[Test]` attribute for test methods
-- Follow the Arrange-Act-Assert (AAA) pattern
-- Name tests using the pattern `MethodName_Scenario_ExpectedBehavior`
-- Use `[SetUp]` and `[TearDown]` for per-test setup and teardown
-- Use `[OneTimeSetUp]` and `[OneTimeTearDown]` for per-class setup and teardown
-- Use `[SetUpFixture]` for assembly-level setup and teardown
-
-## Standard Tests
-
-- Keep tests focused on a single behavior
-- Avoid testing multiple behaviors in one test method
-- Use clear assertions that express intent
-- Include only the assertions needed to verify the test case
-- Make tests independent and idempotent (can run in any order)
-- Avoid test interdependencies
-
-## Data-Driven Tests
-
-- Use `[TestCase]` for inline test data
-- Use `[TestCaseSource]` for programmatically generated test data
-- Use `[Values]` for simple parameter combinations
-- Use `[ValueSource]` for property or method-based data sources
-- Use `[Random]` for random numeric test values
-- Use `[Range]` for sequential numeric test values
-- Use `[Combinatorial]` or `[Pairwise]` for combining multiple parameters
-
-## Assertions
-
-- Use `Assert.That` with constraint model (preferred NUnit style)
-- Use constraints like `Is.EqualTo`, `Is.SameAs`, `Contains.Item`
-- Use `Assert.AreEqual` for simple value equality (classic style)
-- Use `CollectionAssert` for collection comparisons
-- Use `StringAssert` for string-specific assertions
-- Use `Assert.Throws<T>` or `Assert.ThrowsAsync<T>` to test exceptions
-- Use descriptive messages in assertions for clarity on failure
-
-## Mocking and Isolation
-
-- Consider using Moq or NSubstitute alongside NUnit
-- Mock dependencies to isolate units under test
-- Use interfaces to facilitate mocking
-- Consider using a DI container for complex test setups
-
-## Test Organization
-
-- Group tests by feature or component
-- Use categories with `[Category("CategoryName")]`
-- Use `[Order]` to control test execution order when necessary
-- Use `[Author("DeveloperName")]` to indicate ownership
-- Use `[Description]` to provide additional test information
-- Consider `[Explicit]` for tests that shouldn't run automatically
-- Use `[Ignore("Reason")]` to temporarily skip tests

package/templates/backend/.github/prompts/ef-core.prompt.md

@@ -1,76 +0,0 @@
----
-mode: 'agent'
-tools: ['changes', 'search/codebase', 'edit/editFiles', 'problems', 'runCommands']
-description: 'Get best practices for Entity Framework Core'
----
-
-# Entity Framework Core Best Practices
-
-Your goal is to help me follow best practices when working with Entity Framework Core.
-
-## Data Context Design
-
-- Keep DbContext classes focused and cohesive
-- Use constructor injection for configuration options
-- Override OnModelCreating for fluent API configuration
-- Separate entity configurations using IEntityTypeConfiguration
-- Consider using DbContextFactory pattern for console apps or tests
-
-## Entity Design
-
-- Use meaningful primary keys (consider natural vs surrogate keys)
-- Implement proper relationships (one-to-one, one-to-many, many-to-many)
-- Use data annotations or fluent API for constraints and validations
-- Implement appropriate navigational properties
-- Consider using owned entity types for value objects
-
-## Performance
-
-- Use AsNoTracking() for read-only queries
-- Implement pagination for large result sets with Skip() and Take()
-- Use Include() to eager load related entities when needed
-- Consider projection (Select) to retrieve only required fields
-- Use compiled queries for frequently executed queries
-- Avoid N+1 query problems by properly including related data
-
-## Migrations
-
-- Create small, focused migrations
-- Name migrations descriptively
-- Verify migration SQL scripts before applying to production
-- Consider using migration bundles for deployment
-- Add data seeding through migrations when appropriate
-
-## Querying
-
-- Use IQueryable judiciously and understand when queries execute
-- Prefer strongly-typed LINQ queries over raw SQL
-- Use appropriate query operators (Where, OrderBy, GroupBy)
-- Consider database functions for complex operations
-- Implement specifications pattern for reusable queries
-
-## Change Tracking & Saving
-
-- Use appropriate change tracking strategies
-- Batch your SaveChanges() calls
-- Implement concurrency control for multi-user scenarios
-- Consider using transactions for multiple operations
-- Use appropriate DbContext lifetimes (scoped for web apps)
-
-## Security
-
-- Avoid SQL injection by using parameterized queries
-- Implement appropriate data access permissions
-- Be careful with raw SQL queries
-- Consider data encryption for sensitive information
-- Use migrations to manage database user permissions
-
-## Testing
-
-- Use in-memory database provider for unit tests
-- Create separate testing contexts with SQLite for integration tests
-- Mock DbContext and DbSet for pure unit tests
-- Test migrations in isolated environments
-- Consider snapshot testing for model changes
-
-When reviewing my EF Core code, identify issues and suggest improvements that follow these best practices.