@totaland/create-starter-kit 2.0.1 → 2.0.2

package/templates/frontend/.github/prompts/generate-custom-instructions-from-codebase.prompt.md

@@ -1,239 +0,0 @@
----
-description: 'Migration and code evolution instructions generator for GitHub Copilot. Analyzes differences between two project versions (branches, commits, or releases) to create precise instructions allowing Copilot to maintain consistency during technology migrations, major refactoring, or framework version upgrades.'
----
-
-# Migration and Code Evolution Instructions Generator
-
-## Configuration Variables
-
-```
-${MIGRATION_TYPE="Framework Version|Architecture Refactoring|Technology Migration|Dependencies Update|Pattern Changes"}
-<!-- Type of migration or evolution -->
-
-${SOURCE_REFERENCE="branch|commit|tag"}
-<!-- Source reference point (before state) -->
-
-${TARGET_REFERENCE="branch|commit|tag"}  
-<!-- Target reference point (after state) -->
-
-${ANALYSIS_SCOPE="Entire project|Specific folder|Modified files only"}
-<!-- Scope of analysis -->
-
-${CHANGE_FOCUS="Breaking Changes|New Conventions|Obsolete Patterns|API Changes|Configuration"}
-<!-- Main aspect of changes -->
-
-${AUTOMATION_LEVEL="Conservative|Balanced|Aggressive"}
-<!-- Level of automation for Copilot suggestions -->
-
-${GENERATE_EXAMPLES="true|false"}
-<!-- Include transformation examples -->
-
-${VALIDATION_REQUIRED="true|false"}
-<!-- Require validation before application -->
-```
-
-## Generated Prompt
-
-```
-"Analyze code evolution between two project states to generate precise migration instructions for GitHub Copilot. These instructions will guide Copilot to automatically apply the same transformation patterns during future modifications. Follow this methodology:
-
-### Phase 1: Comparative State Analysis
-
-#### Structural Changes Detection
-- Compare folder structure between ${SOURCE_REFERENCE} and ${TARGET_REFERENCE}
-- Identify moved, renamed, or deleted files
-- Analyze changes in configuration files
-- Document new dependencies and removed ones
-
-#### Code Transformation Analysis
-${MIGRATION_TYPE == "Framework Version" ? 
-  "- Identify API changes between framework versions
-   - Analyze new features being used
-   - Document obsolete methods/properties
-   - Note syntax or convention changes" : ""}
-
-${MIGRATION_TYPE == "Architecture Refactoring" ? 
-  "- Analyze architectural pattern changes
-   - Identify new abstractions introduced
-   - Document responsibility reorganization
-   - Note changes in data flows" : ""}
-
-${MIGRATION_TYPE == "Technology Migration" ? 
-  "- Analyze replacement of one technology with another
-   - Identify functional equivalences
-   - Document API and syntax changes
-   - Note new dependencies and configurations" : ""}
-
-#### Transformation Pattern Extraction
-- Identify repetitive transformations applied
-- Analyze conversion rules from old to new format
-- Document exceptions and special cases
-- Create before/after correspondence matrix
-
-### Phase 2: Migration Instructions Generation
-
-Create a `.github/copilot-migration-instructions.md` file with this structure:
-
-\`\`\`markdown
-# GitHub Copilot Migration Instructions
-
-## Migration Context
-- **Type**: ${MIGRATION_TYPE}
-- **From**: ${SOURCE_REFERENCE} 
-- **To**: ${TARGET_REFERENCE}
-- **Date**: [GENERATION_DATE]
-- **Scope**: ${ANALYSIS_SCOPE}
-
-## Automatic Transformation Rules
-
-### 1. Mandatory Transformations
-${AUTOMATION_LEVEL != "Conservative" ? 
-  "[AUTOMATIC_TRANSFORMATION_RULES]
-   - **Old Pattern**: [OLD_CODE]
-   - **New Pattern**: [NEW_CODE]
-   - **Trigger**: When to detect this pattern
-   - **Action**: Transformation to apply automatically" : ""}
-
-### 2. Transformations with Validation
-${VALIDATION_REQUIRED == "true" ? 
-  "[TRANSFORMATIONS_WITH_VALIDATION]
-   - **Detected Pattern**: [DESCRIPTION]
-   - **Suggested Transformation**: [NEW_APPROACH]
-   - **Required Validation**: [VALIDATION_CRITERIA]
-   - **Alternatives**: [ALTERNATIVE_OPTIONS]" : ""}
-
-### 3. API Correspondences
-${CHANGE_FOCUS == "API Changes" || MIGRATION_TYPE == "Framework Version" ? 
-  "[API_CORRESPONDENCE_TABLE]
-   | Old API   | New API   | Notes     | Example        |
-   | --------- | --------- | --------- | -------------- |
-   | [OLD_API] | [NEW_API] | [CHANGES] | [CODE_EXAMPLE] | " : ""} |
-
-### 4. New Patterns to Adopt
-[DETECTED_EMERGING_PATTERNS]
-- **Pattern**: [PATTERN_NAME]
-- **Usage**: [WHEN_TO_USE] 
-- **Implementation**: [HOW_TO_IMPLEMENT]
-- **Benefits**: [ADVANTAGES]
-
-### 5. Obsolete Patterns to Avoid
-[DETECTED_OBSOLETE_PATTERNS]
-- **Obsolete Pattern**: [OLD_PATTERN]
-- **Why Avoid**: [REASONS]
-- **Alternative**: [NEW_PATTERN]
-- **Migration**: [CONVERSION_STEPS]
-
-## File Type Specific Instructions
-
-${GENERATE_EXAMPLES == "true" ? 
-  "### Configuration Files
-   [CONFIG_TRANSFORMATION_EXAMPLES]
-   
-   ### Main Source Files
-   [SOURCE_TRANSFORMATION_EXAMPLES]
-   
-   ### Test Files
-   [TEST_TRANSFORMATION_EXAMPLES]" : ""}
-
-## Validation and Security
-
-### Automatic Control Points
-- Verifications to perform after each transformation
-- Tests to run to validate changes
-- Performance metrics to monitor
-- Compatibility checks to perform
-
-### Manual Escalation
-Situations requiring human intervention:
-- [COMPLEX_CASES_LIST]
-- [ARCHITECTURAL_DECISIONS]
-- [BUSINESS_IMPACTS]
-
-## Migration Monitoring
-
-### Tracking Metrics
-- Percentage of code automatically migrated
-- Number of manual validations required
-- Error rate of automatic transformations
-- Average migration time per file
-
-### Error Reporting
-How to report incorrect transformations to Copilot:
-- Feedback patterns to improve rules
-- Exceptions to document
-- Adjustments to make to instructions
-
-\`\`\`
-
-### Phase 3: Contextual Examples Generation
-
-${GENERATE_EXAMPLES == "true" ? 
-  "#### Transformation Examples
-   For each identified pattern, generate:
-   
-   \`\`\`
-   // BEFORE (${SOURCE_REFERENCE})
-   [OLD_CODE_EXAMPLE]
-   
-   // AFTER (${TARGET_REFERENCE}) 
-   [NEW_CODE_EXAMPLE]
-   
-   // COPILOT INSTRUCTIONS
-   When you see this pattern [TRIGGER], transform it to [NEW_PATTERN] following these steps: [STEPS]
-   \`\`\`" : ""}
-
-### Phase 4: Validation and Optimization
-
-#### Instructions Testing
-- Apply instructions on test code
-- Verify transformation consistency
-- Adjust rules based on results
-- Document exceptions and edge cases
-
-#### Iterative Optimization  
-${AUTOMATION_LEVEL == "Aggressive" ? 
-  "- Refine rules to maximize automation
-   - Reduce false positives in detection
-   - Improve transformation accuracy
-   - Document lessons learned" : ""}
-
-### Final Result
-
-Migration instructions that enable GitHub Copilot to:
-1. **Automatically apply** the same transformations during future modifications
-2. **Maintain consistency** with newly adopted conventions  
-3. **Avoid obsolete patterns** by automatically proposing alternatives
-4. **Accelerate future migrations** by capitalizing on acquired experience
-5. **Reduce errors** by automating repetitive transformations
-
-These instructions transform Copilot into an intelligent migration assistant, capable of reproducing your technology evolution decisions consistently and reliably.
-"
-```
-
-## Typical Use Cases
-
-### Framework Version Migration
-Perfect for documenting the transition from Angular 14 to Angular 17, React Class Components to Hooks, or .NET Framework to .NET Core. Automatically identifies breaking changes and generates corresponding transformation rules.
-
-### Technology Stack Evolution  
-Essential when replacing a technology entirely: jQuery to React, REST to GraphQL, SQL to NoSQL. Creates a comprehensive migration guide with pattern mappings.
-
-### Architecture Refactoring
-Ideal for large refactorings like Monolith to Microservices, MVC to Clean Architecture, or Component to Composable architecture. Preserves architectural knowledge for future similar transformations.
-
-### Design Pattern Modernization
-Useful for adopting new patterns: Repository Pattern, Dependency Injection, Observer to Reactive Programming. Documents the rationale and implementation differences.
-
-## Unique Benefits
-
-### 🧠 **Artificial Intelligence Enhancement**
-Unlike traditional migration documentation, these instructions "train" GitHub Copilot to reproduce your technology evolution decisions automatically during future code modifications.
-
-### 🔄 **Knowledge Capitalization**  
-Transforms specific project experience into reusable rules, avoiding the loss of migration expertise and accelerating future similar transformations.
-
-### 🎯 **Context-Aware Precision**
-Instead of generic advice, generates instructions tailored to your specific codebase, with real before/after examples from your project evolution.
-
-### ⚡ **Automated Consistency**
-Ensures that new code additions automatically follow the new conventions, preventing architectural regression and maintaining code evolution coherence.

package/templates/frontend/.github/prompts/java-junit.prompt.md

@@ -1,64 +0,0 @@
----
-mode: 'agent'
-tools: ['changes', 'search/codebase', 'edit/editFiles', 'problems', 'search']
-description: 'Get best practices for JUnit 5 unit testing, including data-driven tests'
----
-
-# JUnit 5+ Best Practices
-
-Your goal is to help me write effective unit tests with JUnit 5, covering both standard and data-driven testing approaches.
-
-## Project Setup
-
-- Use a standard Maven or Gradle project structure.
-- Place test source code in `src/test/java`.
-- Include dependencies for `junit-jupiter-api`, `junit-jupiter-engine`, and `junit-jupiter-params` for parameterized tests.
-- Use build tool commands to run tests: `mvn test` or `gradle test`.
-
-## Test Structure
-
-- Test classes should have a `Test` suffix, e.g., `CalculatorTest` for a `Calculator` class.
-- Use `@Test` for test methods.
-- Follow the Arrange-Act-Assert (AAA) pattern.
-- Name tests using a descriptive convention, like `methodName_should_expectedBehavior_when_scenario`.
-- Use `@BeforeEach` and `@AfterEach` for per-test setup and teardown.
-- Use `@BeforeAll` and `@AfterAll` for per-class setup and teardown (must be static methods).
-- Use `@DisplayName` to provide a human-readable name for test classes and methods.
-
-## Standard Tests
-
-- Keep tests focused on a single behavior.
-- Avoid testing multiple conditions in one test method.
-- Make tests independent and idempotent (can run in any order).
-- Avoid test interdependencies.
-
-## Data-Driven (Parameterized) Tests
-
-- Use `@ParameterizedTest` to mark a method as a parameterized test.
-- Use `@ValueSource` for simple literal values (strings, ints, etc.).
-- Use `@MethodSource` to refer to a factory method that provides test arguments as a `Stream`, `Collection`, etc.
-- Use `@CsvSource` for inline comma-separated values.
-- Use `@CsvFileSource` to use a CSV file from the classpath.
-- Use `@EnumSource` to use enum constants.
-
-## Assertions
-
-- Use the static methods from `org.junit.jupiter.api.Assertions` (e.g., `assertEquals`, `assertTrue`, `assertNotNull`).
-- For more fluent and readable assertions, consider using a library like AssertJ (`assertThat(...).is...`).
-- Use `assertThrows` or `assertDoesNotThrow` to test for exceptions.
-- Group related assertions with `assertAll` to ensure all assertions are checked before the test fails.
-- Use descriptive messages in assertions to provide clarity on failure.
-
-## Mocking and Isolation
-
-- Use a mocking framework like Mockito to create mock objects for dependencies.
-- Use `@Mock` and `@InjectMocks` annotations from Mockito to simplify mock creation and injection.
-- Use interfaces to facilitate mocking.
-
-## Test Organization
-
-- Group tests by feature or component using packages.
-- Use `@Tag` to categorize tests (e.g., `@Tag("fast")`, `@Tag("integration")`).
-- Use `@TestMethodOrder(MethodOrderer.OrderAnnotation.class)` and `@Order` to control test execution order when strictly necessary.
-- Use `@Disabled` to temporarily skip a test method or class, providing a reason.
-- Use `@Nested` to group tests in a nested inner class for better organization and structure.

package/templates/frontend/.github/prompts/memory-merger.prompt.md

@@ -1,107 +0,0 @@
----
-description: 'Merges mature lessons from a domain memory file into its instruction file. Syntax: `/memory-merger >domain [scope]` where scope is `global` (default), `user`, `workspace`, or `ws`.'
----
-
-# Memory Merger
-
-You consolidate mature learnings from a domain's memory file into its instruction file, ensuring knowledge preservation with minimal redundancy.
-
-**Use the todo list** to track your progress through the process steps and keep the user informed.
-
-## Scopes
-
-Memory instructions can be stored in two scopes:
-
-- **Global** (`global` or `user`) - Stored in `<global-prompts>` (`vscode-userdata:/User/prompts/`) and apply to all VS Code projects
-- **Workspace** (`workspace` or `ws`) - Stored in `<workspace-instructions>` (`<workspace-root>/.github/instructions/`) and apply only to the current project
-
-Default scope is **global**.
-
-Throughout this prompt, `<global-prompts>` and `<workspace-instructions>` refer to these directories.
-
-## Syntax
-
-```
-/memory-merger >domain-name [scope]
-```
-
-- `>domain-name` - Required. The domain to merge (e.g., `>clojure`, `>git-workflow`, `>prompt-engineering`)
-- `[scope]` - Optional. One of: `global`, `user` (both mean global), `workspace`, or `ws`. Defaults to `global`
-
-**Examples:**
-- `/memory-merger >prompt-engineering` - merges global prompt engineering memories
-- `/memory-merger >clojure workspace` - merges workspace clojure memories
-- `/memory-merger >git-workflow ws` - merges workspace git-workflow memories
-
-## Process
-
-### 1. Parse Input and Read Files
-
-- **Extract** domain and scope from user input
-- **Determine** file paths:
-  - Global: `<global-prompts>/{domain}-memory.instructions.md` → `<global-prompts>/{domain}.instructions.md`
-  - Workspace: `<workspace-instructions>/{domain}-memory.instructions.md` → `<workspace-instructions>/{domain}.instructions.md`
-- The user can have mistyped the domain, if you don't find the memory file, glob the directory and determine if there may be a match there. Ask the user for input if in doubt.
-- **Read** both files (memory file must exist; instruction file may not)
-
-### 2. Analyze and Propose
-
-Review all memory sections and present them for merger consideration:
-
-```
-## Proposed Memories for Merger
-
-### Memory: [Headline]
-**Content:** [Key points]
-**Location:** [Where it fits in instructions]
-
-[More memories]...
-```
-
-Say: "Please review these memories. Approve all with 'go' or specify which to skip."
-
-**STOP and wait for user input.**
-
-### 3. Define Quality Bar
-
-Establish 10/10 criteria for what constitutes awesome merged resulting instructions:
-1. **Zero knowledge loss** - Every detail, example, and nuance preserved
-2. **Minimal redundancy** - Overlapping guidance consolidated
-3. **Maximum scannability** - Clear hierarchy, parallel structure, strategic bold, logical grouping
-
-### 4. Merge and Iterate
-
-Develop the final merged instructions **without updating files yet**:
-
-1. Draft the merged instructions incorporating approved memories
-2. Evaluate against quality bar
-3. Refine structure, wording, organization
-4. Repeat until the merged instructions meet 10/10 criteria
-
-### 5. Update Files
-
-Once the final merged instructions meet 10/10 criteria:
-
-- **Create or update** the instruction file with the final merged content
-  - Include proper frontmatter if creating new file
-  - **Merge `applyTo` patterns** from both memory and instruction files if both exist, ensuring comprehensive coverage without duplication
-- **Remove** merged sections from the memory file
-
-## Example
-
-```
-User: "/memory-merger >clojure"
-
-Agent:
-1. Reads clojure-memory.instructions.md and clojure.instructions.md
-2. Proposes 3 memories for merger
-3. [STOPS]
-
-User: "go"
-
-Agent:
-4. Defines quality bar for 10/10
-5. Merges new instructions candidate, iterates to 10/10
-6. Updates clojure.instructions.md
-7. Cleans clojure-memory.instructions.md
-```

package/templates/frontend/.github/prompts/multi-stage-dockerfile.prompt.md

@@ -1,46 +0,0 @@
----
-tools: ['search/codebase']
-description: 'Create optimized multi-stage Dockerfiles for any language or framework'
----
-
-Your goal is to help me create efficient multi-stage Dockerfiles that follow best practices, resulting in smaller, more secure container images.
-
-## Multi-Stage Structure
-
-- Use a builder stage for compilation, dependency installation, and other build-time operations
-- Use a separate runtime stage that only includes what's needed to run the application
-- Copy only the necessary artifacts from the builder stage to the runtime stage
-- Use meaningful stage names with the `AS` keyword (e.g., `FROM node:18 AS builder`)
-- Place stages in logical order: dependencies → build → test → runtime
-
-## Base Images
-
-- Start with official, minimal base images when possible
-- Specify exact version tags to ensure reproducible builds (e.g., `python:3.11-slim` not just `python`)
-- Consider distroless images for runtime stages where appropriate
-- Use Alpine-based images for smaller footprints when compatible with your application
-- Ensure the runtime image has the minimal necessary dependencies
-
-## Layer Optimization
-
-- Organize commands to maximize layer caching
-- Place commands that change frequently (like code changes) after commands that change less frequently (like dependency installation)
-- Use `.dockerignore` to prevent unnecessary files from being included in the build context
-- Combine related RUN commands with `&&` to reduce layer count
-- Consider using COPY --chown to set permissions in one step
-
-## Security Practices
-
-- Avoid running containers as root - use `USER` instruction to specify a non-root user
-- Remove build tools and unnecessary packages from the final image
-- Scan the final image for vulnerabilities
-- Set restrictive file permissions
-- Use multi-stage builds to avoid including build secrets in the final image
-
-## Performance Considerations
-
-- Use build arguments for configuration that might change between environments
-- Leverage build cache efficiently by ordering layers from least to most frequently changing
-- Consider parallelization in build steps when possible
-- Set appropriate environment variables like NODE_ENV=production to optimize runtime behavior
-- Use appropriate healthchecks for the application type with the HEALTHCHECK instruction

package/templates/frontend/.github/prompts/playwright-automation-fill-in-form.prompt.md

@@ -1,29 +0,0 @@
----
-description: 'Automate filling in a form using Playwright MCP'
-tools: []
-model: 'Claude Sonnet 4'
----
-
-# Automating Filling in a Form with Playwright MCP
-
-Your goal is to automate the process of filling in a form using Playwright MCP.
-
-## Specific Instructions
-
-Navigate to https://forms.microsoft.com/url-of-my-form
-
-### Fill in the form with the following details:
-
-1. Show: playwright live
-
-2. Date: 15 July
-
-3. Time: 1:00 AM
-
-4. Topic: Playwright Live - Latest updates on Playwright MCP + Live Demo
-
-5. Upload image: /Users/myuserName/Downloads/my-image.png
-
-DO NOT SUBMIT THE FORM. 
-
-Ask for a review of the form before submitting it.

package/templates/frontend/.github/prompts/playwright-explore-website.prompt.md

@@ -1,19 +0,0 @@
----
-mode: agent
-description: 'Website exploration for testing using Playwright MCP'
-tools: ['changes', 'search/codebase', 'edit/editFiles', 'fetch', 'findTestFiles', 'problems', 'runCommands', 'runTasks', 'runTests', 'search', 'search/searchResults', 'runCommands/terminalLastCommand', 'runCommands/terminalSelection', 'testFailure', 'playwright']
-model: 'Claude Sonnet 4'
----
-
-# Website Exploration for Testing
-
-Your goal is to explore the website and identify key functionalities.
-
-## Specific Instructions
-
-1. Navigate to the provided URL using the Playwright MCP Server. If no URL is provided, ask the user to provide one.
-2. Identify and interact with 3-5 core features or user flows.
-3. Document the user interactions, relevant UI elements (and their locators), and the expected outcomes.
-4. Close the browser context upon completion.
-5. Provide a concise summary of your findings.
-6. Propose and generate test cases based on the exploration.

package/templates/frontend/.github/prompts/playwright-generate-test.prompt.md

@@ -1,19 +0,0 @@
----
-agent: 'agent'
-description: 'Generate a Playwright test based on a scenario using Playwright MCP'
-tools: ['changes', 'search/codebase', 'edit/editFiles', 'fetch', 'problems', 'runCommands', 'runTasks', 'runTests', 'search', 'search/searchResults', 'runCommands/terminalLastCommand', 'runCommands/terminalSelection', 'testFailure', 'playwright/*']
-model: 'Claude Sonnet 4.5'
----
-
-# Test Generation with Playwright MCP
-
-Your goal is to generate a Playwright test based on the provided scenario after completing all prescribed steps.
-
-## Specific Instructions
-
-- You are given a scenario, and you need to generate a playwright test for it. If the user does not provide a scenario, you will ask them to provide one.
-- DO NOT generate test code prematurely or based solely on the scenario without completing all prescribed steps.
-- DO run steps one by one using the tools provided by the Playwright MCP.
-- Only after all steps are completed, emit a Playwright TypeScript test that uses `@playwright/test` based on message history
-- Save generated test file in the tests directory
-- Execute the test file and iterate until the test passes