Repo AI Assistant Instructions.

You are a senior QA automation engineer setting up an AI coding assistant for a test automation repository. Generate a CLAUDE.md (or AGENTS.md) file that gives the AI assistant accurate, opinionated context to work effectively in this repo.

Repository purpose: {{REPO_PURPOSE}}
Automation framework and language: {{FRAMEWORK_STACK}}
Folder structure (brief): {{FOLDER_STRUCTURE}}
Selector strategy: {{SELECTOR_STRATEGY}}
Assertion style and libraries: {{ASSERTION_STYLE}}
Test naming conventions: {{NAMING_CONVENTIONS}}
Test data approach: {{TEST_DATA_APPROACH}}
Areas the AI must NOT change: {{DO_NOT_TOUCH}}
Good examples of existing patterns to follow: {{GOOD_EXAMPLES}}
Anti-patterns the AI should refuse to write: {{ANTI_PATTERNS}}

Generate a CLAUDE.md / AGENTS.md file with the following sections:

## Overview
What this repo does, what application it tests, and the primary automation framework.

## Key commands
The commands needed to install dependencies, run the full suite, run a subset by tag, and lint/type-check.

## Architecture
Brief description of the folder structure, what lives where, and how tests are organised.

## Selector strategy
Precise rules for how to locate elements — e.g., prefer data-testid, then ARIA roles, then visible text; never use CSS class names or XPath. Include an example of correct and incorrect selector usage.

## Assertion style
Which assertion library and style to use. Include a correct and an incorrect example.

## Test naming conventions
Rules for naming test files, describe blocks, and individual test cases.

## Test data
How test data is managed — where it lives, how it is seeded, and the hard rule that real credentials, PII, and production data must never appear in the repo.

## Do not change
Explicit list of files, directories, or patterns the AI must not modify without explicit instruction. Explain why for each.

## Anti-patterns to refuse
Things the AI must refuse to generate even if asked — e.g., hardcoded waits, CSS class selectors, disabling linting rules, committing secrets.

## Code review checklist
A short checklist the AI should run against any test it generates before presenting it.

Keep the file concise — under 400 lines. This file will be read by the AI on every interaction, so precision matters more than length.

You are a senior QA automation engineer setting up GitHub Copilot instructions for a test automation repository. Generate a .github/copilot-instructions.md file.

Repository purpose: {{REPO_PURPOSE}}
Automation framework and language: {{FRAMEWORK_STACK}}
Selector strategy: {{SELECTOR_STRATEGY}}
Test naming conventions: {{NAMING_CONVENTIONS}}
Assertion style: {{ASSERTION_STYLE}}
Test data approach (no real credentials or PII): {{TEST_DATA_APPROACH}}
Patterns to generate by default: {{DEFAULT_PATTERNS}}
Patterns to avoid: {{AVOID_PATTERNS}}

Generate a copilot-instructions.md file with concise, imperative instructions for each area:

## Framework and language
Tell Copilot which framework, language version, and import style to use.

## Selector strategy
Exact priority order for element selectors. Include one correct and one incorrect example.

## Test structure
How test files, describe blocks, and test cases are structured and named.

## Assertions
Which assertion library and style to use; what to assert (specific values, not just element existence).

## Test data
Rules for test data: where it comes from, that only synthetic data is used, and that credentials and PII must never appear in generated code or comments.

## Patterns to always use
Concrete list of patterns Copilot should default to.

## Patterns to never generate
Concrete list of patterns Copilot must avoid, even if prompted — e.g. hardcoded waits, CSS class selectors, disabled lint rules.

Keep the file short and directive. Copilot instructions work best when instructions are specific and unambiguous.

You are a senior QA automation engineer configuring Cursor IDE rules for a test automation repository. Generate a Cursor rules file that steers the AI toward your team's conventions.

Repository purpose: {{REPO_PURPOSE}}
Automation framework and language: {{FRAMEWORK_STACK}}
Project structure (brief): {{PROJECT_STRUCTURE}}
Selector strategy: {{SELECTOR_STRATEGY}}
Test naming conventions: {{NAMING_CONVENTIONS}}
Assertion style: {{ASSERTION_STYLE}}
Test data approach: {{TEST_DATA_APPROACH}}
Patterns to always use: {{DEFAULT_PATTERNS}}
Patterns to never generate: {{AVOID_PATTERNS}}
File globs these rules apply to: {{FILE_GLOBS}} (e.g. **/*.spec.ts)

Generate a Cursor rules file using the standard Cursor rules format. Include one rule block per concern, each with:
- A clear description of the rule
- Whether it always applies or is context-triggered
- Specific, concrete guidance — not abstract advice

Cover the following concerns:
1. Framework and language style — imports, async/await, TypeScript strictness.
2. Selector strategy — priority order, correct and incorrect examples.
3. Test structure — file organisation, describe blocks, test naming pattern.
4. Assertions — library, assertion style, specificity requirement.
5. Test data — synthetic only, where it lives, no credentials or PII in generated code.
6. Anti-patterns — a hard list of things Cursor must never generate (e.g. hardcoded waits, CSS class selectors, disabled lint rules).
7. File boundaries — which files Cursor should not edit unless explicitly instructed.

Keep each rule concise and directive. The goal is consistent suggestions, not a documentation site.

You are a senior QA lead codifying testing standards for an engineering team. Write a testing guidelines document for the repository described below.

Repository purpose: {{REPO_PURPOSE}}
Automation framework and language: {{FRAMEWORK_STACK}}
Test types in scope: {{TEST_TYPES}}
Team audience (who must follow these guidelines): {{AUDIENCE}}
Current pain points or anti-patterns to address: {{PAIN_POINTS}}
Non-negotiable quality gates: {{QUALITY_GATES}}

Write a testing guidelines document with the following sections:

## What we test and what we don't
Clear statement of which test types are in scope (unit, integration, E2E, API, etc.) and why. Explicit statement of what is out of scope and where those gaps are accepted as a risk.

## Test structure and naming
Rules for organising test files, writing describe blocks, naming individual tests, and grouping related tests. Include correct and incorrect examples.

## Selector strategy (for UI tests)
Exact priority order. Correct and incorrect examples. Explanation of why the priority exists (resilience, readability).

## Assertions
What to assert, how to phrase assertions, and which assertion style to use. The rule that assertions must verify specific values, not just presence or truthy state.

## Test data
How test data is created, where it lives, and the hard rules: synthetic data only; no real credentials, customer data, PII, or production system identifiers in test code or fixtures.

## Test independence
Each test must set up its own state and clean up after itself. Tests must not depend on execution order or shared mutable state.

## Quality gates
List the non-negotiable gates (e.g. all tests pass before merge, no new flaky tests, type-check passes, no hardcoded secrets) with the enforcement mechanism for each.

## Code review checklist for tests
A concrete checklist reviewers use when reviewing a test PR.

## Anti-patterns and why they are banned
A table: Anti-pattern | Why it is banned | Correct alternative.

Keep the document opinionated, concise, and example-driven. Annotate assumptions about the stack or team.