diff --git a/.github/instructions/angular.instructions.md b/.github/instructions/angular.instructions.md new file mode 100644 index 0000000..379f725 --- /dev/null +++ b/.github/instructions/angular.instructions.md @@ -0,0 +1,104 @@ +--- +description: 'Angular-specific coding standards and best practices' +applyTo: '**/*.ts, **/*.html, **/*.scss, **/*.css' +--- + +# Angular Development Instructions + +Instructions for generating high-quality Angular applications with TypeScript, using Angular Signals for state management, adhering to Angular best practices as outlined at https://angular.dev. + +## Project Context +- Latest Angular version (use standalone components by default) +- TypeScript for type safety +- Angular CLI for project setup and scaffolding +- Follow Angular Style Guide (https://angular.dev/style-guide) +- Use Angular Material or other modern UI libraries for consistent styling (if specified) + +## Development Standards + +### Architecture +- Use standalone components unless modules are explicitly required +- Organize code by feature modules or domains for scalability +- Implement lazy loading for feature modules to optimize performance +- Use Angular's built-in dependency injection system effectively +- Structure components with a clear separation of concerns (smart vs. presentational components) + +### TypeScript +- Enable strict mode in `tsconfig.json` for type safety +- Define clear interfaces and types for components, services, and models +- Use type guards and union types for robust type checking +- Implement proper error handling with RxJS operators (e.g., `catchError`) +- Use typed forms (e.g., `FormGroup`, `FormControl`) for reactive forms + +### Component Design +- Follow Angular's component lifecycle hooks best practices +- When using Angular >= 19, Use `input()` `output()`, `viewChild()`, `viewChildren()`, `contentChild()` and `viewChildren()` functions instead of decorators; otherwise use decorators +- Leverage Angular's change detection strategy (default or `OnPush` for performance) +- Keep templates clean and logic in component classes or services +- Use Angular directives and pipes for reusable functionality + +### Styling +- Use Angular's component-level CSS encapsulation (default: ViewEncapsulation.Emulated) +- Prefer SCSS for styling with consistent theming +- Implement responsive design using CSS Grid, Flexbox, or Angular CDK Layout utilities +- Follow Angular Material's theming guidelines if used +- Maintain accessibility (a11y) with ARIA attributes and semantic HTML + +### State Management +- Use Angular Signals for reactive state management in components and services +- Leverage `signal()`, `computed()`, and `effect()` for reactive state updates +- Use writable signals for mutable state and computed signals for derived state +- Handle loading and error states with signals and proper UI feedback +- Use Angular's `AsyncPipe` to handle observables in templates when combining signals with RxJS + +### Data Fetching +- Use Angular's `HttpClient` for API calls with proper typing +- Implement RxJS operators for data transformation and error handling +- Use Angular's `inject()` function for dependency injection in standalone components +- Implement caching strategies (e.g., `shareReplay` for observables) +- Store API response data in signals for reactive updates +- Handle API errors with global interceptors for consistent error handling + +### Security +- Sanitize user inputs using Angular's built-in sanitization +- Implement route guards for authentication and authorization +- Use Angular's `HttpInterceptor` for CSRF protection and API authentication headers +- Validate form inputs with Angular's reactive forms and custom validators +- Follow Angular's security best practices (e.g., avoid direct DOM manipulation) + +### Performance +- Enable production builds with `ng build --prod` for optimization +- Use lazy loading for routes to reduce initial bundle size +- Optimize change detection with `OnPush` strategy and signals for fine-grained reactivity +- Use trackBy in `ngFor` loops to improve rendering performance +- Implement server-side rendering (SSR) or static site generation (SSG) with Angular Universal (if specified) + +### Testing +- Write unit tests for components, services, and pipes using Jasmine and Karma +- Use Angular's `TestBed` for component testing with mocked dependencies +- Test signal-based state updates using Angular's testing utilities +- Write end-to-end tests with Cypress or Playwright (if specified) +- Mock HTTP requests using `HttpClientTestingModule` +- Ensure high test coverage for critical functionality + +## Implementation Process +1. Plan project structure and feature modules +2. Define TypeScript interfaces and models +3. Scaffold components, services, and pipes using Angular CLI +4. Implement data services and API integrations with signal-based state +5. Build reusable components with clear inputs and outputs +6. Add reactive forms and validation +7. Apply styling with SCSS and responsive design +8. Implement lazy-loaded routes and guards +9. Add error handling and loading states using signals +10. Write unit and end-to-end tests +11. Optimize performance and bundle size + +## Additional Guidelines +- Follow Angular's naming conventions (e.g., `feature.component.ts`, `feature.service.ts`) +- Use Angular CLI commands for generating boilerplate code +- Document components and services with clear JSDoc comments +- Ensure accessibility compliance (WCAG 2.1) where applicable +- Use Angular's built-in i18n for internationalization (if specified) +- Keep code DRY by creating reusable utilities and shared modules +- Use signals consistently for state management to ensure reactive updates diff --git a/.github/prompts/copilot-instructions-blueprint-generator.prompt.md b/.github/prompts/copilot-instructions-blueprint-generator.prompt.md new file mode 100644 index 0000000..cc91c42 --- /dev/null +++ b/.github/prompts/copilot-instructions-blueprint-generator.prompt.md @@ -0,0 +1,294 @@ +--- +description: 'Technology-agnostic blueprint generator for creating comprehensive copilot-instructions.md files that guide GitHub Copilot to produce code consistent with project standards, architecture patterns, and exact technology versions by analyzing existing codebase patterns and avoiding assumptions.' +mode: 'agent' +--- + +# Copilot Instructions Blueprint Generator + +## Configuration Variables +${PROJECT_TYPE="Auto-detect|.NET|Java|JavaScript|TypeScript|React|Angular|Python|Multiple|Other"} +${ARCHITECTURE_STYLE="Layered|Microservices|Monolithic|Domain-Driven|Event-Driven|Serverless|Mixed"} +${CODE_QUALITY_FOCUS="Maintainability|Performance|Security|Accessibility|Testability|All"} +${DOCUMENTATION_LEVEL="Minimal|Standard|Comprehensive"} +${TESTING_REQUIREMENTS="Unit|Integration|E2E|TDD|BDD|All"} +${VERSIONING="Semantic|CalVer|Custom"} + +## Generated Prompt + +"Generate a comprehensive copilot-instructions.md file that will guide GitHub Copilot to produce code consistent with our project's standards, architecture, and technology versions. The instructions must be strictly based on actual code patterns in our codebase and avoid making any assumptions. Follow this approach: + +### 1. Core Instruction Structure + +```markdown +# GitHub Copilot Instructions + +## Priority Guidelines + +When generating code for this repository: + +1. **Version Compatibility**: Always detect and respect the exact versions of languages, frameworks, and libraries used in this project +2. **Context Files**: Prioritize patterns and standards defined in the .github/copilot directory +3. **Codebase Patterns**: When context files don't provide specific guidance, scan the codebase for established patterns +4. **Architectural Consistency**: Maintain our ${ARCHITECTURE_STYLE} architectural style and established boundaries +5. **Code Quality**: Prioritize ${CODE_QUALITY_FOCUS == "All" ? "maintainability, performance, security, accessibility, and testability" : CODE_QUALITY_FOCUS} in all generated code + +## Technology Version Detection + +Before generating code, scan the codebase to identify: + +1. **Language Versions**: Detect the exact versions of programming languages in use + - Examine project files, configuration files, and package managers + - Look for language-specific version indicators (e.g., in .NET projects) + - Never use language features beyond the detected version + +2. **Framework Versions**: Identify the exact versions of all frameworks + - Check package.json, .csproj, pom.xml, requirements.txt, etc. + - Respect version constraints when generating code + - Never suggest features not available in the detected framework versions + +3. **Library Versions**: Note the exact versions of key libraries and dependencies + - Generate code compatible with these specific versions + - Never use APIs or features not available in the detected versions + +## Context Files + +Prioritize the following files in .github/copilot directory (if they exist): + +- **architecture.md**: System architecture guidelines +- **tech-stack.md**: Technology versions and framework details +- **coding-standards.md**: Code style and formatting standards +- **folder-structure.md**: Project organization guidelines +- **exemplars.md**: Exemplary code patterns to follow + +## Codebase Scanning Instructions + +When context files don't provide specific guidance: + +1. Identify similar files to the one being modified or created +2. Analyze patterns for: + - Naming conventions + - Code organization + - Error handling + - Logging approaches + - Documentation style + - Testing patterns + +3. Follow the most consistent patterns found in the codebase +4. When conflicting patterns exist, prioritize patterns in newer files or files with higher test coverage +5. Never introduce patterns not found in the existing codebase + +## Code Quality Standards + +${CODE_QUALITY_FOCUS.includes("Maintainability") || CODE_QUALITY_FOCUS == "All" ? `### Maintainability +- Write self-documenting code with clear naming +- Follow the naming and organization conventions evident in the codebase +- Follow established patterns for consistency +- Keep functions focused on single responsibilities +- Limit function complexity and length to match existing patterns` : ""} + +${CODE_QUALITY_FOCUS.includes("Performance") || CODE_QUALITY_FOCUS == "All" ? `### Performance +- Follow existing patterns for memory and resource management +- Match existing patterns for handling computationally expensive operations +- Follow established patterns for asynchronous operations +- Apply caching consistently with existing patterns +- Optimize according to patterns evident in the codebase` : ""} + +${CODE_QUALITY_FOCUS.includes("Security") || CODE_QUALITY_FOCUS == "All" ? `### Security +- Follow existing patterns for input validation +- Apply the same sanitization techniques used in the codebase +- Use parameterized queries matching existing patterns +- Follow established authentication and authorization patterns +- Handle sensitive data according to existing patterns` : ""} + +${CODE_QUALITY_FOCUS.includes("Accessibility") || CODE_QUALITY_FOCUS == "All" ? `### Accessibility +- Follow existing accessibility patterns in the codebase +- Match ARIA attribute usage with existing components +- Maintain keyboard navigation support consistent with existing code +- Follow established patterns for color and contrast +- Apply text alternative patterns consistent with the codebase` : ""} + +${CODE_QUALITY_FOCUS.includes("Testability") || CODE_QUALITY_FOCUS == "All" ? `### Testability +- Follow established patterns for testable code +- Match dependency injection approaches used in the codebase +- Apply the same patterns for managing dependencies +- Follow established mocking and test double patterns +- Match the testing style used in existing tests` : ""} + +## Documentation Requirements + +${DOCUMENTATION_LEVEL == "Minimal" ? +`- Match the level and style of comments found in existing code +- Document according to patterns observed in the codebase +- Follow existing patterns for documenting non-obvious behavior +- Use the same format for parameter descriptions as existing code` : ""} + +${DOCUMENTATION_LEVEL == "Standard" ? +`- Follow the exact documentation format found in the codebase +- Match the XML/JSDoc style and completeness of existing comments +- Document parameters, returns, and exceptions in the same style +- Follow existing patterns for usage examples +- Match class-level documentation style and content` : ""} + +${DOCUMENTATION_LEVEL == "Comprehensive" ? +`- Follow the most detailed documentation patterns found in the codebase +- Match the style and completeness of the best-documented code +- Document exactly as the most thoroughly documented files do +- Follow existing patterns for linking documentation +- Match the level of detail in explanations of design decisions` : ""} + +## Testing Approach + +${TESTING_REQUIREMENTS.includes("Unit") || TESTING_REQUIREMENTS == "All" ? +`### Unit Testing +- Match the exact structure and style of existing unit tests +- Follow the same naming conventions for test classes and methods +- Use the same assertion patterns found in existing tests +- Apply the same mocking approach used in the codebase +- Follow existing patterns for test isolation` : ""} + +${TESTING_REQUIREMENTS.includes("Integration") || TESTING_REQUIREMENTS == "All" ? +`### Integration Testing +- Follow the same integration test patterns found in the codebase +- Match existing patterns for test data setup and teardown +- Use the same approach for testing component interactions +- Follow existing patterns for verifying system behavior` : ""} + +${TESTING_REQUIREMENTS.includes("E2E") || TESTING_REQUIREMENTS == "All" ? +`### End-to-End Testing +- Match the existing E2E test structure and patterns +- Follow established patterns for UI testing +- Apply the same approach for verifying user journeys` : ""} + +${TESTING_REQUIREMENTS.includes("TDD") || TESTING_REQUIREMENTS == "All" ? +`### Test-Driven Development +- Follow TDD patterns evident in the codebase +- Match the progression of test cases seen in existing code +- Apply the same refactoring patterns after tests pass` : ""} + +${TESTING_REQUIREMENTS.includes("BDD") || TESTING_REQUIREMENTS == "All" ? +`### Behavior-Driven Development +- Match the existing Given-When-Then structure in tests +- Follow the same patterns for behavior descriptions +- Apply the same level of business focus in test cases` : ""} + +## Technology-Specific Guidelines + +${PROJECT_TYPE == ".NET" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### .NET Guidelines +- Detect and strictly adhere to the specific .NET version in use +- Use only C# language features compatible with the detected version +- Follow LINQ usage patterns exactly as they appear in the codebase +- Match async/await usage patterns from existing code +- Apply the same dependency injection approach used in the codebase +- Use the same collection types and patterns found in existing code` : ""} + +${PROJECT_TYPE == "Java" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### Java Guidelines +- Detect and adhere to the specific Java version in use +- Follow the exact same design patterns found in the codebase +- Match exception handling patterns from existing code +- Use the same collection types and approaches found in the codebase +- Apply the dependency injection patterns evident in existing code` : ""} + +${PROJECT_TYPE == "JavaScript" || PROJECT_TYPE == "TypeScript" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### JavaScript/TypeScript Guidelines +- Detect and adhere to the specific ECMAScript/TypeScript version in use +- Follow the same module import/export patterns found in the codebase +- Match TypeScript type definitions with existing patterns +- Use the same async patterns (promises, async/await) as existing code +- Follow error handling patterns from similar files` : ""} + +${PROJECT_TYPE == "React" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### React Guidelines +- Detect and adhere to the specific React version in use +- Match component structure patterns from existing components +- Follow the same hooks and lifecycle patterns found in the codebase +- Apply the same state management approach used in existing components +- Match prop typing and validation patterns from existing code` : ""} + +${PROJECT_TYPE == "Angular" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### Angular Guidelines +- Detect and adhere to the specific Angular version in use +- Follow the same component and module patterns found in the codebase +- Match decorator usage exactly as seen in existing code +- Apply the same RxJS patterns found in the codebase +- Follow existing patterns for component communication` : ""} + +${PROJECT_TYPE == "Python" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### Python Guidelines +- Detect and adhere to the specific Python version in use +- Follow the same import organization found in existing modules +- Match type hinting approaches if used in the codebase +- Apply the same error handling patterns found in existing code +- Follow the same module organization patterns` : ""} + +## Version Control Guidelines + +${VERSIONING == "Semantic" ? +`- Follow Semantic Versioning patterns as applied in the codebase +- Match existing patterns for documenting breaking changes +- Follow the same approach for deprecation notices` : ""} + +${VERSIONING == "CalVer" ? +`- Follow Calendar Versioning patterns as applied in the codebase +- Match existing patterns for documenting changes +- Follow the same approach for highlighting significant changes` : ""} + +${VERSIONING == "Custom" ? +`- Match the exact versioning pattern observed in the codebase +- Follow the same changelog format used in existing documentation +- Apply the same tagging conventions used in the project` : ""} + +## General Best Practices + +- Follow naming conventions exactly as they appear in existing code +- Match code organization patterns from similar files +- Apply error handling consistent with existing patterns +- Follow the same approach to testing as seen in the codebase +- Match logging patterns from existing code +- Use the same approach to configuration as seen in the codebase + +## Project-Specific Guidance + +- Scan the codebase thoroughly before generating any code +- Respect existing architectural boundaries without exception +- Match the style and patterns of surrounding code +- When in doubt, prioritize consistency with existing code over external best practices +``` + +### 2. Codebase Analysis Instructions + +To create the copilot-instructions.md file, first analyze the codebase to: + +1. **Identify Exact Technology Versions**: + - ${PROJECT_TYPE == "Auto-detect" ? "Detect all programming languages, frameworks, and libraries by scanning file extensions and configuration files" : `Focus on ${PROJECT_TYPE} technologies`} + - Extract precise version information from project files, package.json, .csproj, etc. + - Document version constraints and compatibility requirements + +2. **Understand Architecture**: + - Analyze folder structure and module organization + - Identify clear layer boundaries and component relationships + - Document communication patterns between components + +3. **Document Code Patterns**: + - Catalog naming conventions for different code elements + - Note documentation styles and completeness + - Document error handling patterns + - Map testing approaches and coverage + +4. **Note Quality Standards**: + - Identify performance optimization techniques actually used + - Document security practices implemented in the code + - Note accessibility features present (if applicable) + - Document code quality patterns evident in the codebase + +### 3. Implementation Notes + +The final copilot-instructions.md should: +- Be placed in the .github/copilot directory +- Reference only patterns and standards that exist in the codebase +- Include explicit version compatibility requirements +- Avoid prescribing any practices not evident in the code +- Provide concrete examples from the codebase +- Be comprehensive yet concise enough for Copilot to effectively use + +Important: Only include guidance based on patterns actually observed in the codebase. Explicitly instruct Copilot to prioritize consistency with existing code over external best practices or newer language features. +" + +## Expected Output + +A comprehensive copilot-instructions.md file that will guide GitHub Copilot to produce code that is perfectly compatible with your existing technology versions and follows your established patterns and architecture. \ No newline at end of file diff --git a/.github/prompts/create-agentsmd.prompt.md b/.github/prompts/create-agentsmd.prompt.md new file mode 100644 index 0000000..ad1ec1e --- /dev/null +++ b/.github/prompts/create-agentsmd.prompt.md @@ -0,0 +1,249 @@ +--- +description: "Prompt for generating an AGENTS.md file for a repository" +mode: "agent" +--- + +# Create high‑quality AGENTS.md file + +You are a code agent. Your task is to create a complete, accurate AGENTS.md at the root of this repository that follows the public guidance at https://agents.md/. + +AGENTS.md is an open format designed to provide coding agents with the context and instructions they need to work effectively on a project. + +## What is AGENTS.md? + +AGENTS.md is a Markdown file that serves as a "README for agents" - a dedicated, predictable place to provide context and instructions to help AI coding agents work on your project. It complements README.md by containing detailed technical context that coding agents need but might clutter a human-focused README. + +## Key Principles + +- **Agent-focused**: Contains detailed technical instructions for automated tools +- **Complements README.md**: Doesn't replace human documentation but adds agent-specific context +- **Standardized location**: Placed at repository root (or subproject roots for monorepos) +- **Open format**: Uses standard Markdown with flexible structure +- **Ecosystem compatibility**: Works across 20+ different AI coding tools and agents + +## File Structure and Content Guidelines + +### 1. Required Setup + +- Create the file as `AGENTS.md` in the repository root +- Use standard Markdown formatting +- No required fields - flexible structure based on project needs + +### 2. Essential Sections to Include + +#### Project Overview + +- Brief description of what the project does +- Architecture overview if complex +- Key technologies and frameworks used + +#### Setup Commands + +- Installation instructions +- Environment setup steps +- Dependency management commands +- Database setup if applicable + +#### Development Workflow + +- How to start development server +- Build commands +- Watch/hot-reload setup +- Package manager specifics (npm, pnpm, yarn, etc.) + +#### Testing Instructions + +- How to run tests (unit, integration, e2e) +- Test file locations and naming conventions +- Coverage requirements +- Specific test patterns or frameworks used +- How to run subset of tests or focus on specific areas + +#### Code Style Guidelines + +- Language-specific conventions +- Linting and formatting rules +- File organization patterns +- Naming conventions +- Import/export patterns + +#### Build and Deployment + +- Build commands and outputs +- Environment configurations +- Deployment steps and requirements +- CI/CD pipeline information + +### 3. Optional but Recommended Sections + +#### Security Considerations + +- Security testing requirements +- Secrets management +- Authentication patterns +- Permission models + +#### Monorepo Instructions (if applicable) + +- How to work with multiple packages +- Cross-package dependencies +- Selective building/testing +- Package-specific commands + +#### Pull Request Guidelines + +- Title format requirements +- Required checks before submission +- Review process +- Commit message conventions + +#### Debugging and Troubleshooting + +- Common issues and solutions +- Logging patterns +- Debug configuration +- Performance considerations + +## Example Template + +Use this as a starting template and customize based on the specific project: + +```markdown +# AGENTS.md + +## Project Overview + +[Brief description of the project, its purpose, and key technologies] + +## Setup Commands + +- Install dependencies: `[package manager] install` +- Start development server: `[command]` +- Build for production: `[command]` + +## Development Workflow + +- [Development server startup instructions] +- [Hot reload/watch mode information] +- [Environment variable setup] + +## Testing Instructions + +- Run all tests: `[command]` +- Run unit tests: `[command]` +- Run integration tests: `[command]` +- Test coverage: `[command]` +- [Specific testing patterns or requirements] + +## Code Style + +- [Language and framework conventions] +- [Linting rules and commands] +- [Formatting requirements] +- [File organization patterns] + +## Build and Deployment + +- [Build process details] +- [Output directories] +- [Environment-specific builds] +- [Deployment commands] + +## Pull Request Guidelines + +- Title format: [component] Brief description +- Required checks: `[lint command]`, `[test command]` +- [Review requirements] + +## Additional Notes + +- [Any project-specific context] +- [Common gotchas or troubleshooting tips] +- [Performance considerations] +``` + +## Working Example from agents.md + +Here's a real example from the agents.md website: + +```markdown +# Sample AGENTS.md file + +## Dev environment tips + +- Use `pnpm dlx turbo run where ` to jump to a package instead of scanning with `ls`. +- Run `pnpm install --filter ` to add the package to your workspace so Vite, ESLint, and TypeScript can see it. +- Use `pnpm create vite@latest -- --template react-ts` to spin up a new React + Vite package with TypeScript checks ready. +- Check the name field inside each package's package.json to confirm the right name—skip the top-level one. + +## Testing instructions + +- Find the CI plan in the .github/workflows folder. +- Run `pnpm turbo run test --filter ` to run every check defined for that package. +- From the package root you can just call `pnpm test`. The commit should pass all tests before you merge. +- To focus on one step, add the Vitest pattern: `pnpm vitest run -t ""`. +- Fix any test or type errors until the whole suite is green. +- After moving files or changing imports, run `pnpm lint --filter ` to be sure ESLint and TypeScript rules still pass. +- Add or update tests for the code you change, even if nobody asked. + +## PR instructions + +- Title format: [] +- Always run `pnpm lint` and `pnpm test` before committing. +``` + +## Implementation Steps + +1. **Analyze the project structure** to understand: + + - Programming languages and frameworks used + - Package managers and build tools + - Testing frameworks + - Project architecture (monorepo, single package, etc.) + +2. **Identify key workflows** by examining: + + - package.json scripts + - Makefile or other build files + - CI/CD configuration files + - Documentation files + +3. **Create comprehensive sections** covering: + + - All essential setup and development commands + - Testing strategies and commands + - Code style and conventions + - Build and deployment processes + +4. **Include specific, actionable commands** that agents can execute directly + +5. **Test the instructions** by ensuring all commands work as documented + +6. **Keep it focused** on what agents need to know, not general project information + +## Best Practices + +- **Be specific**: Include exact commands, not vague descriptions +- **Use code blocks**: Wrap commands in backticks for clarity +- **Include context**: Explain why certain steps are needed +- **Stay current**: Update as the project evolves +- **Test commands**: Ensure all listed commands actually work +- **Consider nested files**: For monorepos, create AGENTS.md files in subprojects as needed + +## Monorepo Considerations + +For large monorepos: + +- Place a main AGENTS.md at the repository root +- Create additional AGENTS.md files in subproject directories +- The closest AGENTS.md file takes precedence for any given location +- Include navigation tips between packages/projects + +## Final Notes + +- AGENTS.md works with 20+ AI coding tools including Cursor, Aider, Gemini CLI, and many others +- The format is intentionally flexible - adapt it to your project's needs +- Focus on actionable instructions that help agents understand and work with your codebase +- This is living documentation - update it as your project evolves + +When creating the AGENTS.md file, prioritize clarity, completeness, and actionability. The goal is to give any coding agent enough context to effectively contribute to the project without requiring additional human guidance. diff --git a/.github/prompts/javascript-typescript-jest.prompt.md b/.github/prompts/javascript-typescript-jest.prompt.md new file mode 100644 index 0000000..af7d29e --- /dev/null +++ b/.github/prompts/javascript-typescript-jest.prompt.md @@ -0,0 +1,44 @@ +--- +description: 'Best practices for writing JavaScript/TypeScript tests using Jest, including mocking strategies, test structure, and common patterns.' +mode: 'agent' +--- + +### Test Structure +- Name test files with `.test.ts` or `.test.js` suffix +- Place test files next to the code they test or in a dedicated `__tests__` directory +- Use descriptive test names that explain the expected behavior +- Use nested describe blocks to organize related tests +- Follow the pattern: `describe('Component/Function/Class', () => { it('should do something', () => {}) })` + +### Effective Mocking +- Mock external dependencies (APIs, databases, etc.) to isolate your tests +- Use `jest.mock()` for module-level mocks +- Use `jest.spyOn()` for specific function mocks +- Use `mockImplementation()` or `mockReturnValue()` to define mock behavior +- Reset mocks between tests with `jest.resetAllMocks()` in `afterEach` + +### Testing Async Code +- Always return promises or use async/await syntax in tests +- Use `resolves`/`rejects` matchers for promises +- Set appropriate timeouts for slow tests with `jest.setTimeout()` + +### Snapshot Testing +- Use snapshot tests for UI components or complex objects that change infrequently +- Keep snapshots small and focused +- Review snapshot changes carefully before committing + +### Testing React Components +- Use React Testing Library over Enzyme for testing components +- Test user behavior and component accessibility +- Query elements by accessibility roles, labels, or text content +- Use `userEvent` over `fireEvent` for more realistic user interactions + +## Common Jest Matchers +- Basic: `expect(value).toBe(expected)`, `expect(value).toEqual(expected)` +- Truthiness: `expect(value).toBeTruthy()`, `expect(value).toBeFalsy()` +- Numbers: `expect(value).toBeGreaterThan(3)`, `expect(value).toBeLessThanOrEqual(3)` +- Strings: `expect(value).toMatch(/pattern/)`, `expect(value).toContain('substring')` +- Arrays: `expect(array).toContain(item)`, `expect(array).toHaveLength(3)` +- Objects: `expect(object).toHaveProperty('key', value)` +- Exceptions: `expect(fn).toThrow()`, `expect(fn).toThrow(Error)` +- Mock functions: `expect(mockFn).toHaveBeenCalled()`, `expect(mockFn).toHaveBeenCalledWith(arg1, arg2)` diff --git a/.github/prompts/suggest-awesome-github-copilot-instructions.prompt.md b/.github/prompts/suggest-awesome-github-copilot-instructions.prompt.md new file mode 100644 index 0000000..53ef50d --- /dev/null +++ b/.github/prompts/suggest-awesome-github-copilot-instructions.prompt.md @@ -0,0 +1,88 @@ +--- +mode: 'agent' +description: 'Suggest relevant GitHub Copilot instruction files from the awesome-copilot repository based on current repository context and chat history, avoiding duplicates with existing instructions in this repository.' +tools: ['edit', 'search', 'runCommands', 'runTasks', 'think', 'changes', 'testFailure', 'openSimpleBrowser', 'fetch', 'githubRepo', 'todos', 'search'] +--- +# Suggest Awesome GitHub Copilot Instructions + +Analyze current repository context and suggest relevant copilot-instruction files from the [GitHub awesome-copilot repository](https://github.com/github/awesome-copilot/blob/main/README.instructions.md) that are not already available in this repository. + +## Process + +1. **Fetch Available Instructions**: Extract instruction list and descriptions from [awesome-copilot README.instructions.md](https://github.com/github/awesome-copilot/blob/main/README.instructions.md). Must use `#fetch` tool. +2. **Scan Local Instructions**: Discover existing instruction files in `.github/instructions/` folder +3. **Extract Descriptions**: Read front matter from local instruction files to get descriptions and `applyTo` patterns +4. **Analyze Context**: Review chat history, repository files, and current project needs +5. **Compare Existing**: Check against instructions already available in this repository +6. **Match Relevance**: Compare available instructions against identified patterns and requirements +7. **Present Options**: Display relevant instructions with descriptions, rationale, and availability status +8. **Validate**: Ensure suggested instructions would add value not already covered by existing instructions +9. **Output**: Provide structured table with suggestions, descriptions, and links to both awesome-copilot instructions and similar local instructions + **AWAIT** user request to proceed with installation of specific instructions. DO NOT INSTALL UNLESS DIRECTED TO DO SO. +10. **Download Assets**: For requested instructions, automatically download and install individual instructions to `.github/instructions/` folder. Do NOT adjust content of the files. Use `#todos` tool to track progress. Prioritize use of `#fetch` tool to download assets, but may use `curl` using `#runInTerminal` tool to ensure all content is retrieved. + +## Context Analysis Criteria + +🔍 **Repository Patterns**: +- Programming languages used (.cs, .js, .py, .ts, etc.) +- Framework indicators (ASP.NET, React, Azure, Next.js, etc.) +- Project types (web apps, APIs, libraries, tools) +- Development workflow requirements (testing, CI/CD, deployment) + +🗨️ **Chat History Context**: +- Recent discussions and pain points +- Technology-specific questions +- Coding standards discussions +- Development workflow requirements + +## Output Format + +Display analysis results in structured table comparing awesome-copilot instructions with existing repository instructions: + +| Awesome-Copilot Instruction | Description | Already Installed | Similar Local Instruction | Suggestion Rationale | +|------------------------------|-------------|-------------------|---------------------------|---------------------| +| [blazor.instructions.md](https://github.com/github/awesome-copilot/blob/main/instructions/blazor.instructions.md) | Blazor development guidelines | ❌ No | blazor.instructions.md | Already covered by existing Blazor instructions | +| [reactjs.instructions.md](https://github.com/github/awesome-copilot/blob/main/instructions/reactjs.instructions.md) | ReactJS development standards | ❌ No | None | Would enhance React development with established patterns | +| [java.instructions.md](https://github.com/github/awesome-copilot/blob/main/instructions/java.instructions.md) | Java development best practices | ❌ No | None | Could improve Java code quality and consistency | + +## Local Instructions Discovery Process + +1. List all `*.instructions.md` files in the `instructions/` directory +2. For each discovered file, read front matter to extract `description` and `applyTo` patterns +3. Build comprehensive inventory of existing instructions with their applicable file patterns +4. Use this inventory to avoid suggesting duplicates + +## File Structure Requirements + +Based on GitHub documentation, copilot-instructions files should be: +- **Repository-wide instructions**: `.github/copilot-instructions.md` (applies to entire repository) +- **Path-specific instructions**: `.github/instructions/NAME.instructions.md` (applies to specific file patterns via `applyTo` frontmatter) +- **Community instructions**: `instructions/NAME.instructions.md` (for sharing and distribution) + +## Front Matter Structure + +Instructions files in awesome-copilot use this front matter format: +```markdown +--- +description: 'Brief description of what this instruction provides' +applyTo: '**/*.js,**/*.ts' # Optional: glob patterns for file matching +--- +``` + +## Requirements + +- Use `githubRepo` tool to get content from awesome-copilot repository +- Scan local file system for existing instructions in `instructions/` directory +- Read YAML front matter from local instruction files to extract descriptions and `applyTo` patterns +- Compare against existing instructions in this repository to avoid duplicates +- Focus on gaps in current instruction library coverage +- Validate that suggested instructions align with repository's purpose and standards +- Provide clear rationale for each suggestion +- Include links to both awesome-copilot instructions and similar local instructions +- Consider technology stack compatibility and project-specific needs +- Don't provide any additional information or context beyond the table and the analysis + +## Icons Reference + +- ✅ Already installed in repo +- ❌ Not installed in repo