agents-templated 2.2.1 → 2.2.2

package/templates/.claude/rules/testing.mdc

@@ -0,0 +1,308 @@
+---
+title: "Testing Guidelines & Best Practices"
+description: "Apply when adding tests, verifying coverage, or validating quality before deployment. Always required for business logic and critical flows"
+version: "3.0.0"
+tags: ["testing", "quality", "coverage", "e2e", "a11y"]
+triggers:
+  - "User requests tests for business logic"
+  - "Implementing a new feature"
+  - "Fixing a bug"
+  - "Need to verify API endpoints work"
+  - "Checking application behavior"
+  - "Hardening release artifacts"
+  - "CI/CD validation needed before deployment"
+---
+
+# Testing Guidelines & Best Practices
+
+Comprehensive testing patterns for maintaining quality across any technology stack.
+
+## Core Testing Principles
+
+- **Test Pyramid**: More unit tests (80%), fewer integration tests (15%), minimal E2E tests (5%)
+- **Arrange-Act-Assert**: Structure tests clearly with setup, action, and verification
+- **Descriptive Names**: Test names should describe expected behavior
+- **Independent Tests**: Each test should be able to run in isolation
+- **Fast Feedback**: Unit tests should run quickly (<100ms each)
+- **Deterministic**: Tests should pass/fail consistently, not randomly
+
+## Unit Testing
+
+Unit tests verify individual functions, methods, and components in isolation.
+
+### Unit Test Pattern
+
+Unit Test Structure:
+1. Arrange
+   - Set up test data
+   - Mock dependencies
+   - Configure test environment
+
+2. Act
+   - Call the function/method being tested
+   - Perform the action
+
+3. Assert
+   - Verify the result
+   - Check side effects
+   - Validate behavior
+
+### What to Unit Test
+
+- Business logic functions (validation, calculations, transformations)
+- Utility functions (helpers, formatters, parsers)
+- Service/class methods with clear inputs and outputs
+- Error handling and edge cases
+- Complex conditional logic
+
+### Unit Test Examples (Language-Agnostic)
+
+**Example 1: Validation Function**
+Test: Email validation function
+- Test valid email returns true
+- Test invalid email format returns false
+- Test empty string returns false
+- Test whitespace is trimmed
+- Test case-insensitive comparison
+
+**Example 2: Business Logic**
+Test: Calculate discount price
+- Test standard discount percentage
+- Test no discount
+- Test maximum discount cap
+- Test negative prices handled gracefully
+- Test rounding is correct
+
+**Example 3: Error Handling**
+Test: Parse JSON data
+- Test valid JSON parses successfully
+- Test invalid JSON throws appropriate error
+- Test missing required fields throws error
+- Test extra fields are handled
+- Test error messages are helpful
+
+### Mocking & Test Doubles
+
+Use test doubles (mocks, stubs, fakes) for external dependencies:
+
+Mocking Strategy:
+1. Identify external dependencies
+   - Database calls
+   - API calls
+   - File system access
+   - Time/date functions
+   - Random number generation
+
+2. Replace with appropriate test double
+   - Stub: Return fixed value
+   - Mock: Verify it was called correctly
+   - Fake: Simplified working implementation
+
+3. Verify interactions when appropriate
+   - Was the dependency called?
+   - Was it called with correct arguments?
+   - Was it called the right number of times?
+
+## Integration Testing
+
+Integration tests verify that multiple components work together correctly.
+
+### What to Integration Test
+
+- API endpoints (request  response)
+- Database operations (save, query, delete)
+- Service-to-service interactions
+- Authentication and authorization flows
+- Error scenarios and edge cases
+
+### Integration Test Pattern
+
+Integration Test Structure:
+1. Setup
+   - Create test database/data
+   - Mock external services if needed
+   - Set up test user/session
+
+2. Execute
+   - Make API call or trigger operation
+   - Interact with multiple components
+
+3. Verify
+   - Check response status and data
+   - Verify database changes
+   - Check side effects
+
+### Integration Test Examples
+
+**Example 1: User Creation API**
+Test: POST /api/users with valid data
+- Validate request body
+- Create user in database
+- Return created user with ID
+- User can be retrieved afterward
+- Password is hashed (not plaintext)
+
+**Example 2: Authentication Flow**
+Test: User login
+- Validate credentials
+- Create session/token
+- Return session/token to client
+- Can use session to access protected endpoints
+- Session is invalidated on logout
+
+**Example 3: Error Handling**
+Test: Create user with duplicate email
+- Database rejects duplicate
+- API returns 400 Bad Request
+- Error message is appropriate
+- No partial data is written
+
+## End-to-End Testing
+
+E2E tests verify complete user journeys across the entire application.
+
+### What to E2E Test
+
+- Critical user workflows (login, purchase, form submission)
+- Happy path scenarios
+- Common error scenarios
+- Cross-browser compatibility (if applicable)
+- Accessibility requirements
+
+### E2E Test Examples
+
+**Example 1: User Registration**
+Test: New user can register successfully
+1. Navigate to signup page
+2. Fill in email, password, name
+3. Click submit button
+4. Wait for success message
+5. Redirect to dashboard
+6. User can access protected content
+
+**Example 2: Login with Invalid Credentials**
+Test: Login with wrong password
+1. Navigate to login page
+2. Enter email and wrong password
+3. Click login button
+4. See error message "Invalid credentials"
+5. Still on login page (not redirected)
+6. Can try again
+
+**Example 3: Multi-step Workflow**
+Test: User can complete purchase
+1. Navigate to product page
+2. Add item to cart
+3. Navigate to checkout
+4. Enter shipping information
+5. Enter payment information
+6. Submit order
+7. See confirmation page
+8. Receive confirmation email
+
+## Accessibility Testing
+
+Test that your application meets WCAG 2.1 AA standards.
+
+### Automated Accessibility Testing
+
+Use tools to scan for common accessibility violations:
+- Color contrast issues
+- Missing alt text for images
+- Missing labels for form inputs
+- Heading hierarchy problems
+- Missing ARIA attributes
+
+### Manual Accessibility Testing
+
+- Keyboard navigation: Can user navigate with Tab and Enter?
+- Screen reader: Does content make sense when read aloud?
+- Visual clarity: Can text be read at smaller sizes?
+- Color dependency: Is information conveyed without color alone?
+- Responsiveness: Does layout work on different screen sizes?
+
+## Performance Testing
+
+Test performance requirements and regressions.
+
+### Performance Metrics to Monitor
+
+**Web Applications:**
+- First Contentful Paint (FCP)
+- Largest Contentful Paint (LCP)
+- Cumulative Layout Shift (CLS)
+- Time to Interactive (TTI)
+- Page load time
+
+**API Endpoints:**
+- Response time (p50, p95, p99)
+- Throughput (requests per second)
+- Error rate
+- Database query time
+- Memory usage
+
+### Performance Testing Examples
+
+Test: API response time
+- Create 100 users in database
+- Query all users endpoint
+- Measure response time
+- Assert completes in <500ms
+
+Test: Page load performance
+- Navigate to homepage
+- Measure First Contentful Paint
+- Assert completes in <2 seconds
+
+Test: Database query optimization
+- Insert 10,000 records
+- Run query with filter
+- Verify query uses index
+- Measure execution time
+- Assert completes efficiently
+
+## Hardening Verification Testing
+
+When hardening/obfuscation is enabled (see `.claude/rules/hardening.mdc`), require additional validation on hardened artifacts.
+
+### Required Checks for Hardened Builds
+
+- Run core functional regression tests against hardened output, not only non-hardened builds.
+- Run performance checks and compare against accepted budgets (startup, latency, memory as applicable).
+- Validate crash/debug workflow with restricted symbol/mapping artifact access controls.
+- Confirm release evidence includes hardening profile rationale and rollback trigger/steps.
+
+If these checks are missing for a hardening-required profile, release readiness should be treated as blocked.
+
+## Security Testing
+
+Test security requirements and threat scenarios.
+
+### Security Tests
+
+Test: Input Validation
+- SQL injection payloads in fields
+- XSS payloads in fields
+- Extremely long strings
+- Special characters
+- Wrong data types
+
+Test: Authentication
+- Login with wrong password
+- Access protected endpoint without credentials
+- Use expired token
+- Use modified token
+
+Test: Authorization
+- Access another user's data
+- Perform admin operation as regular user
+- Modify resource of different user
+
+Test: Rate Limiting
+- Exceed rate limit on authentication
+- Verify 429 response
+- Verify retry-after header
+
+## Test Organization
+
+Organize tests logically for easy maintenance:

package/templates/.claude/rules/workflows.mdc

@@ -0,0 +1,61 @@
+---
+title: "Development Workflow Guidelines"
+description: "Apply when optimizing development process, running pre-commit checks, or keeping project healthy"
+alwaysApply: false
+version: "1.0.0"
+tags: ["workflow", "quality", "validation", "commit"]
+globs:
+  - "**/*"
+triggers:
+  - "User asks about workflow or pre-commit steps"
+  - "Need to keep project validated"
+  - "Running quality gates before merge"
+  - "Post-hardening verification needed"
+---
+
+# Development Workflow Guidelines
+
+Technology-agnostic suggestions for keeping the project healthy and maintaining quality before commits.
+
+## When This Rule Applies
+
+Use this guidance when the user asks about workflow, pre-commit checks, or keeping the project validated. Do not force these steps on every change—treat them as recommended practices.
+
+## Project Health (agents-templated)
+
+If this project was scaffolded with agents-templated:
+
+- **Periodically**: Run `agents-templated validate` to ensure required docs and rules are present; run `agents-templated doctor` for environment and configuration recommendations.
+- **After pulling template updates**: Run `agents-templated update --check-only` to see available updates, then `agents-templated update` if you want to apply them (with backup).
+
+These commands help keep agent rules, documentation, and security patterns in sync.
+
+## Pre-Commit Quality Gates
+
+Before committing, consider running (in order):
+
+1. **Lint** – Your stack's linter (e.g. ESLint, Pylint, golangci-lint) to catch style and simple issues.
+2. **Type check** – If applicable (TypeScript, mypy, etc.) to catch type errors.
+3. **Tests** – At least the fast test suite (e.g. unit tests) so regressions are caught early.
+4. **Project validation** – For agents-templated projects, `agents-templated validate` can confirm setup is intact.
+
+For high-risk or distributed-client releases, add hardening-specific checks before merge/release:
+
+5. **Hardening profile selection** – Document threat model and selected profile from `.claude/rules/hardening.mdc`.
+6. **Post-hardening verification** – Run functional regression and performance checks on hardened artifacts.
+7. **Artifact controls** – Verify restricted handling for symbol/mapping/debug artifacts and confirm rollback path.
+
+Do not commit with failing lint or tests unless the user explicitly requests a WIP commit (e.g. with `--no-verify` or a clear "work in progress" message).
+
+## Commit Messages
+
+- Prefer clear, descriptive messages (e.g. conventional commits: `feat:`, `fix:`, `docs:`).
+- Reference issues or tickets when relevant (e.g. "Closes #123").
+- Keep the body focused on what changed and why, not how.
+
+## Summary
+
+- Use **agents-templated validate** and **doctor** to maintain project setup and get recommendations.
+- Run **lint**, **type check**, and **tests** before committing when possible.
+- For hardening-required releases, include profile rationale, post-hardening verification evidence, and rollback readiness.
+- Write clear commit messages and reference issues where applicable.

package/templates/CLAUDE.md

@@ -7,23 +7,23 @@ All policy, routing, and skill governance lives here — edit this file directly
 
 ## Reference Index
 
-### Rule modules (`.github/instructions/rules/`)
-
-| Module | File | Governs |
-|--------|------|---------|
-| Security | `.github/instructions/rules/security.mdc` | Validation, authn/authz, secrets, rate limiting |
-| Testing | `.github/instructions/rules/testing.mdc` | Strategy, coverage mix, test discipline |
-| Core | `.github/instructions/rules/core.mdc` | Type safety, runtime boundaries, error modeling |
-| Database | `.github/instructions/rules/database.mdc` | ORM patterns, migrations, query safety |
-| Frontend | `.github/instructions/rules/frontend.mdc` | Accessibility, responsiveness, client trust boundaries |
-| Style | `.github/instructions/rules/style.mdc` | Naming, modularity, separation of concerns |
-| System Workflow | `.github/instructions/rules/system-workflow.mdc` | Branching, PR structure, review gates |
-| Workflows | `.github/instructions/rules/workflows.mdc` | Automation, CI/CD, deployment gates |
-| Hardening | `.github/instructions/rules/hardening.mdc` | Threat modeling, audit mode, dependency review |
-| Intent Routing | `.github/instructions/rules/intent-routing.mdc` | Deterministic task-to-rule mapping |
-| Planning | `.github/instructions/rules/planning.mdc` | Feature discussion and implementation planning |
-| AI Integration | `.github/instructions/rules/ai-integration.mdc` | LLM safety, cost controls, fallback behavior |
-| Guardrails | `.github/instructions/rules/guardrails.mdc` | Hard stops, scope control, reversibility, minimal footprint |
+### Rule modules (`.claude/rules/`)
+
+| Module | File | Apply when... |
+|--------|------|---------------|
+| Security | `.claude/rules/security.mdc` | Implementing authentication, validating inputs, protecting against injection attacks |
+| Testing | `.claude/rules/testing.mdc` | Adding tests, verifying coverage, validating quality before deployment |
+| Core | `.claude/rules/core.mdc` | Designing architecture, setting up projects, defining type systems |
+| Database | `.claude/rules/database.mdc` | Designing schema, building data access layers, optimizing queries |
+| Frontend | `.claude/rules/frontend.mdc` | Building UI components, designing pages, creating forms, implementing accessibility |
+| Style | `.claude/rules/style.mdc` | Organizing code, naming variables, improving clarity and maintainability |
+| System Workflow | `.claude/rules/system-workflow.mdc` | Planning delivery phases, defining acceptance criteria, establishing rollback |
+| Workflows | `.claude/rules/workflows.mdc` | Optimizing development process, running pre-commit checks, keeping project healthy |
+| Hardening | `.claude/rules/hardening.mdc` | Building distributed apps, protecting IP logic, preparing production releases |
+| Intent Routing | `.claude/rules/intent-routing.mdc` | Determining which rule applies, routing to correct execution pathway |
+| Planning | `.claude/rules/planning.mdc` | Implementing features, designing systems, making architectural decisions |
+| AI Integration | `.claude/rules/ai-integration.mdc` | Integrating LLMs, RAG pipelines, prompt engineering, AI-powered features |
+| Guardrails | `.claude/rules/guardrails.mdc` | Any destructive/irreversible action, scope expansion, dangerous requests |
 
 ### Skill modules (`.github/skills/`)
 
@@ -59,40 +59,40 @@ Subagents are bounded agents with limited tool access. They inherit all policy f
 
 ## Always Enforce
 
-1. **Security-first (non-overrideable)** — `.github/instructions/rules/security.mdc`
+1. **Security-first (non-overrideable)** — `.claude/rules/security.mdc`
    - Validate all external inputs at boundaries.
    - Require authentication and role-based authorization for protected operations.
    - Rate-limit public APIs.
    - Never expose secrets, credentials, or PII in logs/errors/responses.
 
-2. **Testing discipline (non-overrideable)** — `.github/instructions/rules/testing.mdc`
+2. **Testing discipline (non-overrideable)** — `.claude/rules/testing.mdc`
    - Coverage mix target: Unit 80% / Integration 15% / E2E 5%.
    - Business logic must have tests; critical flows need integration coverage.
    - Never disable/remove tests to pass builds.
 
-3. **Type safety and runtime boundaries** — `.github/instructions/rules/core.mdc`
+3. **Type safety and runtime boundaries** — `.claude/rules/core.mdc`
    - Strong internal typing, runtime validation at boundaries, explicit error models.
 
-4. **Database integrity** — `.github/instructions/rules/database.mdc`
+4. **Database integrity** — `.claude/rules/database.mdc`
    - Prefer ORM/ODM, justify raw queries, enforce DB constraints, prevent N+1, reversible migrations.
 
-5. **Frontend standards** — `.github/instructions/rules/frontend.mdc`
+5. **Frontend standards** — `.claude/rules/frontend.mdc`
    - WCAG 2.1 AA, responsive defaults, clear loading/error states, no unsafe client trust.
 
-6. **Style and consistency** — `.github/instructions/rules/style.mdc`
+6. **Style and consistency** — `.claude/rules/style.mdc`
    - Consistent naming, small composable modules, explicit contracts, no magic values.
 
-7. **Workflow discipline** — `.github/instructions/rules/system-workflow.mdc`, `.github/instructions/rules/workflows.mdc`
+7. **Workflow discipline** — `.claude/rules/system-workflow.mdc`, `.claude/rules/workflows.mdc`
    - Feature branches only, no direct main edits, deterministic PR structure, review gates.
 
-8. **Hardening mode** — `.github/instructions/rules/hardening.mdc`
+8. **Hardening mode** — `.claude/rules/hardening.mdc`
    - In hardening/audit contexts: assume hostile input, threat-model, validate config safety, strict rate limits, dependency audit.
 
-9. **Planning discipline** — `.github/instructions/rules/planning.mdc`
+9. **Planning discipline** — `.claude/rules/planning.mdc`
    - Every feature discussion or implementation produces a `.github/prompts/` plan file.
    - Plans are updated as work progresses, not discarded.
 
-10. **Guardrails (non-overrideable)** — `.github/instructions/rules/guardrails.mdc`
+10. **Guardrails (non-overrideable)** — `.claude/rules/guardrails.mdc`
    - Require `CONFIRM-DESTRUCTIVE:<target>` token before any destructive/irreversible action.
    - Work only within the defined task scope; no silent expansion.
    - Classify every action by reversibility before executing.

package/templates/agents/rules/ai-integration.mdc

@@ -1,10 +1,18 @@
 ---
 title: "AI / LLM Integration"
-description: "Safety, cost, and quality rules for integrating large language models into applications"
-version: "1.0.0"
+description: "Apply when integrating LLMs, RAG pipelines, prompt engineering, or building AI-powered features. Covers safety, cost, and quality"
+version: "3.0.0"
 tags: ["ai", "llm", "openai", "anthropic", "rag", "prompt-engineering", "safety"]
 alwaysApply: false
 globs: ["**/*llm*", "**/*openai*", "**/*anthropic*", "**/*langchain*", "**/*rag*", "**/ai/**"]
+triggers:
+  - "Integrating OpenAI or other LLM API"
+  - "Building RAG pipeline or semantic search"
+  - "Implementing prompt template or engineering"
+  - "Adding AI-powered feature to application"
+  - "Evaluating LLM responses or quality"
+  - "Optimizing LLM API costs"
+  - "Implementing AI moderation or safety controls"
 ---
 
 ## Purpose

package/templates/agents/rules/core.mdc

@@ -1,11 +1,18 @@
 ---
 title: "Core Project Guidelines"
-description: "Enterprise-grade architecture and best practices for technology-agnostic development"
+description: "Apply to all architecture, type safety, code organization, and enterprise quality standards. Foundation for every feature"
 alwaysApply: true
 version: "3.0.0"
 tags: ["architecture", "core", "enterprise", "technology-agnostic"]
 globs:
   - "*"
+triggers:
+  - "Designing application architecture"
+  - "Setting up new project or module"
+  - "Defining type systems and validation"
+  - "Organizing code structure"
+  - "Improving code quality standards"
+  - "Making testing or performance decisions"
 ---
 
 ## Developer Identity

package/templates/agents/rules/database.mdc

@@ -1,12 +1,20 @@
 ---
 title: "Database and Data Layer Guidelines"
-description: "Database-agnostic patterns for data access and schema design"
+description: "Apply when designing schema, building data access layers, optimizing queries, or managing database operations"
 alwaysApply: true
 version: "3.0.0"
 tags: ["database", "backend", "data", "orm", "schema"]
 globs:
   - "src/models/**/*"
   - "src/data/**/*"
+triggers:
+  - "Designing database schema"
+  - "Adding database migrations"
+  - "Building data access layer"
+  - "Querying or filtering data"
+  - "Optimizing slow queries"
+  - "Managing relationships between entities"
+  - "Handling data validation in models"
 ---
 
 # Database and Data Layer Guidelines
@@ -302,4 +310,4 @@ Test: Cascade delete
 
 ---
 
-Remember: Good database design prevents bugs, improves performance, and makes your application maintainable.
+Remember: Good database design prevents bugs, improves performance, and makes your application maintainable.

package/templates/agents/rules/frontend.mdc

@@ -1,6 +1,6 @@
 ---
 title: "Frontend Development Guidelines"
-description: "Framework-agnostic frontend development patterns with security and accessibility"
+description: "Apply when building UI components, designing pages, creating forms, or implementing accessibility and responsive interfaces"
 alwaysApply: true
 version: "3.0.0"
 tags: ["frontend", "ui", "ux", "security", "accessibility"]
@@ -8,6 +8,14 @@ globs:
   - "src/**/*"
   - "components/**/*"
   - "public/**/*"
+triggers:
+  - "Building UI components or pages"
+  - "Creating forms and handling user input"
+  - "Designing responsive layouts"
+  - "Implementing accessibility features"
+  - "Styling and theming interfaces"
+  - "Building navigation and routing"
+  - "Implementing client-side state management"
 ---
 
 # Frontend Development Guidelines
@@ -214,4 +222,4 @@ E2E tests:
 
 ---
 
-Remember: Build user interfaces that work for everyone, load quickly, and provide excellent user experience.
+Remember: Build user interfaces that work for everyone, load quickly, and provide excellent user experience.

package/templates/agents/rules/guardrails.mdc

@@ -1,9 +1,17 @@
 ---
 alwaysApply: true
 title: "AI Agent Guardrails"
-description: "Behavioral constraints preventing dangerous, irreversible, or out-of-scope agent actions"
-version: "1.0.0"
+description: "Apply before any irreversible action, scope expansion, dangerous request, or system change. Safety constraints that cannot be weakened"
+version: "3.0.0"
 tags: ["guardrails", "safety", "scope", "reversibility", "agent-behavior"]
+triggers:
+  - "Planning destructive or irreversible action"
+  - "Deleting files, databases, or deployment"
+  - "Modifying security or authentication"
+  - "Making scope expansion decisions"
+  - "Evaluating request safety and reversibility"
+  - "Handling secrets or sensitive data"
+  - "Making agent behavioral decisions"
 ---
 
 ## Purpose

package/templates/agents/rules/hardening.mdc

@@ -1,8 +1,16 @@
 ---
 title: "Application Hardening & Obfuscation"
-description: "Risk-based hardening model including obfuscation, tamper resilience, and verification"
-version: "1.0.0"
+description: "Apply when building distributed apps, protecting IP logic, preparing production releases, or hardening against reverse engineering"
+version: "3.0.0"
 tags: ["hardening", "obfuscation", "anti-tamper", "security"]
+triggers:
+  - "Preparing mobile or desktop app for release"
+  - "Protecting proprietary business logic"
+  - "Hardening against reverse engineering"
+  - "Building distributed client applications"
+  - "Preparing production release with hardening"
+  - "Implementing tamper detection"
+  - "Adding integrity checks to release"
 ---
 
 ## Purpose

package/templates/agents/rules/intent-routing.mdc

@@ -1,8 +1,16 @@
 ---
 title: "Intent Routing & Command Selection"
-description: "Deterministic intent routing from natural language to executable command contracts"
-version: "1.0.0"
+description: "Apply when determining which rule applies, routing to correct execution pathway, or making command selection decisions"
+version: "3.0.0"
 tags: ["routing", "deterministic", "workflow", "commands"]
+triggers:
+  - "User makes natural language request"
+  - "Determining which rule applies"
+  - "Routing to correct execution pathway"
+  - "Selecting command or agent to invoke"
+  - "Handling ambiguous user intent"
+  - "Making safety behavior decisions"
+  - "Validating action scope and appropriateness"
 ---
 
 ## Purpose

package/templates/agents/rules/planning.mdc

@@ -1,9 +1,17 @@
 ---
 title: "Planning Discipline"
-description: "Every feature discussion or implementation must produce a reusable prompt plan file in .github/prompts/"
-version: "1.0.0"
+description: "Apply when implementing features, designing systems, discussing architecture, or making implementation decisions. Produces reusable prompt plan files"
+version: "3.0.0"
 tags: ["planning", "workflow", "documentation", "prompts"]
 alwaysApply: true
+triggers:
+  - "User requests a new feature"
+  - "Planning implementation approach"
+  - "Discussing architectural changes"
+  - "Breaking down user stories"
+  - "Creating acceptance criteria"
+  - "Designing database schema"
+  - "Planning deployment phases"
 ---
 
 ## Purpose

package/templates/agents/rules/security.mdc

@@ -1,8 +1,17 @@
 ---
 title: "Security Rules & Best Practices"
-description: "Framework and language-agnostic security patterns for enterprise applications"
+description: "Apply when implementing authentication, authorization, API validation, secrets management, or protecting against OWASP Top 10 vulnerabilities"
+alwaysApply: true
 version: "3.0.0"
-tags: ["security", "owasp", "authentication", "validation"]
+tags: ["security", "auth", "validation", "secrets", "owasp"]
+triggers:
+  - "User adds login/authentication to project"
+  - "Building API endpoints or handling user input"
+  - "Storing passwords, tokens, or sensitive data"
+  - "Validating form inputs or API requests"
+  - "Protecting against injection, XSS, CSRF"
+  - "Adding authorization/permissions to endpoints"
+  - "Integrating third-party APIs or external services"
 ---
 
 # Security Rules & Best Practices