Browse reusable Agent Skills, each with a clear purpose and practical guidance.
Write and structure RSpec tests for Discourse core, plugins, themes, or theme components. Use when creating or modifying model specs, controller specs, service specs, job specs, system tests, or integration tests. Covers fabricators, page objects, test structure, and theme test setup.
Uses Chrome DevTools MCP for accessibility (a11y) debugging and auditing based on web.dev guidelines. Use when testing semantic HTML, ARIA labels, focus states, keyboard navigation, tap targets, and color contrast.
Build, run, and operate isolated or ephemeral compute on AWS with the Serverless Framework `sandboxes` feature (AWS Lambda MicroVMs). Use whenever the user wants to execute untrusted or AI-generated code, run per-session, per-agent, or per-tenant isolated workloads, build a code-execution backend, or mentions Firecracker MicroVMs, the `sandboxes` block in serverless.yml, `serverless dev --sandbox`, `invoke --sandbox`, `logs --sandbox`, RunMicrovm, or AWS Lambda MicroVMs. Trigger even when the user names neither "Serverless Framework" nor "sandbox" but describes an isolated AWS execution environment.
Add or update translations for the Apache Airflow UI. Guides through setting up locales, scaffolding translation files, translating with locale-specific guidelines, and validating results. Use when working with i18n tasks in airflow-core/src/airflow/ui/public/i18n/locales/.
Generate verified recipe playbooks from AIPs with PR implementations (post mode), or speculative user stories from AIPs without implementations (pre mode). Use when the user provides an AIP URL or AIP content, optionally with PR URLs and file paths.
Track Airflow Improvement Proposal (AIP) implementation progress by comparing Confluence specs against codebase evidence. Use when asked to assess, report on, or compare AIP status.
Guide for contributing to the Airflow Java SDK (AIP-108). Use this skill whenever a contributor is working in the `java-sdk/` directory or on the Java coordinator in `task-sdk/src/airflow/sdk/coordinators/java/` — whether they want to add a feature, write tests, fix a bug, understand the architecture, or prepare a PR. Trigger on phrases like "Java SDK", "JavaCoordinator", "java-sdk", "annotation processor", "Builder.Task", "BundleBuilder", or anything about running JVM tasks in Airflow.
Guide for implementing a brand-new language SDK for Airflow (AIP-108). Use this skill when a contributor wants to add support for a new programming language — designing the Python coordinator, implementing the wire protocol in the target language, writing the bundle format, and structuring the PR. Trigger on phrases like "new language SDK", "new SDK", "add support for [language]", "implement coordinator for", "SubprocessCoordinator", "BaseCoordinator", "new runtime", "AFBNDL01", "supervisor schema", or anything about bringing a new language into the Airflow executor ecosystem.
Adopt and maintain the apache-magpie framework in a project repo via the snapshot-based adoption mechanism. The only framework skill committed in an adopter's repo; every other skill is a symlink the adopt sub-action wires up. Sub-actions: `/magpie-setup` - first-time adoption (default; main-checkout only) `/magpie-setup upgrade` - refresh the gitignored snapshot per the committed lock (main-checkout only) `/magpie-setup worktree-init` - symlink a worktree's snapshot to the main's `/magpie-setup verify` - health check + drift detection `/magpie-setup skill-sources` - fetch/pin/symlink skills from trusted external sources listed in the adopter trust list (main-checkout only) `/magpie-setup override <skill>` - open or scaffold an agentic override in `.apache-magpie-overrides/` `/magpie-setup unadopt` - reverse the adoption (snapshot, locks, symlinks, hook, doc sections); preserves `.apache-magpie-overrides/` by default (main-checkout only)
Replace the manual commit-by-commit classification step in `breeze release-management prepare-provider-documentation` with AI-driven classification. For each provider with pending changes, analyze every PR (batched into one sub-agent per provider, not one per PR), pay special attention to potentially breaking changes by inspecting the actual diff, scope multi-provider PRs to the current provider's slice, ask the release manager when uncertain, and apply version bumps + changelog entries. Use during the regular provider release cycle as an alternative to the interactive breeze prompts.