Set up or align a repository's GitHub collaboration and delivery surface: repo settings, branch/ruleset policy, PR and security templates, Actions hardening, GitHub Environments, release workflows, and deploy workflows. Use when standardizing GitHub setup for repos, CI/CD, publishing versioned packages, or deploying running apps; route app deploy details to deploy references and package publish details to release references.

Update repo documentation and durable agent-facing artifacts such as AGENTS.md, README.md, docs/, specs, plans, decisions, and runbooks. Use when code, skill, or infrastructure changes risk doc drift or when documentation needs cleanup or restructuring. Do not use for code review, runtime verification, or boot/readiness infrastructure setup.

Remove AI-writing tells and rewrite prose to sound natural and human. Triggers: humanise, humanize, de-AI, deAI, sound natural, less robotic, remove AI tells, AI writing, chatbot tone, Wikipedia AI writing signs, voice match, voice calibration. Uses AskUserQuestion for intake; Read/Write for files; WebSearch/WebFetch when the user wants terminology or usage research; Bash when applying edits in a repo. Outputs: interactive Q&A then rewritten text (and optional brief edit log). Do NOT use for: inventing facts, changing the author's stance, weakening safety or compliance language without explicit instruction, or skipping intake when the user's goals and preservation rules are unclear.

Contribute to ai-slop-gate — an open-source CI/CD policy gate that detects AI-generated code slop, security issues, and compliance violations. Use when adding a new LLM provider (Gemini, Groq, Ollama) or static provider, writing analysis rules, extending the policy engine, working with reporters, fixing compliance sidecar logic, or writing tests. Activate when working with ai_slop_gate/ source tree, policy.yml, snapshot, or GitHub Actions workflows.

Adversarial reviewer personality for architecture discussions. Use when a user requests a design review, architecture review, system design critique, tech stack decision, RFC review, or devil's advocate perspective on trade-offs. Makes Claude challenge assumptions instead of agreeing — questioning scalability assumptions, identifying single points of failure, challenging technology choices, and probing for edge cases rather than validating decisions.

Execute a strict Red-Green-Refactor TDD cycle for a single requirement at a time, in any language or framework. Use when the user provides a business rule, acceptance criterion, or feature requirement and wants a failing test written first, followed by minimum implementation, then a clean refactor. Works for unit tests, integration tests, UI component tests, and API tests across stacks including TypeScript, JavaScript, React, .NET (C#/xUnit/NUnit), Python, Java, and others. Triggered by phrases like "write a test first", "TDD", "red-green-refactor", "behavioral test", "test-driven", "failing test first", or "write the test before the code".

Creates Vaadin Browserless server-side unit tests for Vaadin views covering navigation, component interactions, form validation, grid operations, and notifications. Use when the user asks to "write Browserless tests", "write Vaadin UI unit tests", "unit test a Vaadin view without a browser", "create view tests with the official Vaadin testing framework", or mentions Browserless testing, SpringBrowserlessTest, browserless-test-junit6, UI Unit Testing, or server-side Vaadin testing.

Creates versioned Flyway database migration scripts (V*.sql) with sequences, tables, constraints, and foreign keys from the entity model. Use when the user asks to "create a migration", "generate SQL scripts", "set up database tables", "write a Flyway migration", or mentions schema migration, DB migration, database versioning, or SQL migration files.

Implements use cases by creating Vaadin views, forms, and grids for the UI layer and jOOQ queries for the data access layer. Use when the user asks to "implement a use case", "build the UI", "create a Vaadin view", "write the data access layer", or mentions Vaadin implementation, jOOQ queries, Java web app, or database-backed UI.

Health check and readiness endpoints for web services — liveness probes, dependency checks, and graceful startup/shutdown. Use when building any backend service that will be deployed behind a load balancer, in containers, or in any environment that monitors service health.

Vue 3 Composition API patterns that agents commonly get wrong: reactivity pitfalls, composable structure, Pinia setup stores, watch vs computed, storeToRefs, template refs, provide/inject, and accessibility. Use when building or reviewing Vue 3 apps.