[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AE3BXPXEAZESQY24M54VMP":3,"skill-same:01M6AE3BXPXEAZESQY24M54VMP":74},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":45,"linkOnly":46,"markdownContent":47,"markdownBody":48,"frontMatter":49,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":55,"ownerHtmlUrl":56,"ownerBlogUrl":57,"ownerDescription":58,"updatedAt":59,"install":60,"resources":73},"01M6AE3BXPXEAZESQY24M54VMP","quarkus-native-and-container",null,"Build Quarkus native executables (Mandrel\u002FGraalVM), fix native failures with reflection registration, test the native binary, and produce container images and Kubernetes\u002FOpenShift manifests. Use for native, Docker, Jib or Kubernetes work in a Quarkus project.","github\u002Fawesome-copilot","github","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F9919?v=4","01M6AC83DS133TPXFSP1DHNCC6","GitHub","01M6AD3PBDYPK7NVFJNJ66Y8RS",41046,"MIT","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fquarkus-native-and-container\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44],"native","quarkus native and container","quarkus","container","use","for","manifests","openshift","with","project","registration","reflection","images","docker","fix","work","graalvm","produce","container images","test","kubernetes","2026-11-10 10:12:30",false,"---\nname: quarkus-native-and-container\ndescription: 'Build Quarkus native executables (Mandrel\u002FGraalVM), fix native failures with reflection registration, test the native binary, and produce container images and Kubernetes\u002FOpenShift manifests. Use for native, Docker, Jib or Kubernetes work in a Quarkus project.'\n---\n\n# Quarkus Native and Container\n\nCheck the project's Quarkus version first. For generic (non-Quarkus) GraalVM work, use the optional `java-add-graalvm-native-image-support` skill if installed (otherwise see the GraalVM docs, \u003Chttps:\u002F\u002Fwww.graalvm.org\u002Flatest\u002Freference-manual\u002Fnative-image\u002F>).\n\n## Native build\n\n```bash\n# container build: no local GraalVM needed (Docker\u002FPodman required)\n.\u002Fmvnw package -Dnative -Dquarkus.native.container-build=true\n# local Mandrel\u002FGraalVM (JAVA_HOME \u002F GRAALVM_HOME must point to it)\n.\u002Fmvnw package -Dnative\n# Gradle, Quarkus 3.10+ (add -Dquarkus.native.container-build=true without a local Mandrel)\n.\u002Fgradlew build -Dquarkus.native.enabled=true -Dquarkus.package.jar.enabled=false\n# Gradle, older Quarkus\n.\u002Fgradlew build -Dquarkus.package.type=native\n```\n\n`quarkus.package.type` was deprecated in 3.10 (the 3.10 migration guide replaces it with `quarkus.native.enabled` and `quarkus.package.jar.*`); it is still accepted in 3.40 with a warning. Version gate verified with Gradle: on 3.9.5 `-Dquarkus.native.enabled=true -Dquarkus.package.jar.enabled=false` is ignored (\"Unrecognized configuration key\" warnings) and only a JVM `quarkus-app` is built, while `-Dquarkus.package.type=native` produces the native runner; on 3.10.0, 3.27.6 and 3.40.1 the new keys produce the native runner (3.10.0 also accepts the old key with the deprecation warning). The Maven `native` profile in the generated `pom.xml` already sets `quarkus.native.enabled=true`, `quarkus.package.jar.enabled=false` and `skipITs=false` when `-Dnative` is passed.\n\nLocal build verified on macOS arm64 with the Mandrel tarball for your Quarkus line from \u003Chttps:\u002F\u002Fgithub.com\u002Fgraalvm\u002Fmandrel\u002Freleases> (`mandrel-java25-macos-aarch64-25.0.4.1-Final.tar.gz` for 3.40.1, extracted anywhere, `JAVA_HOME` pointing at its `Contents\u002FHome`; Xcode command line tools are enough): 3.40.1 Maven `package -Dnative` took about 70 s and Gradle `build` with the two flags about 2.5 min; the runner is a Mach-O executable that starts in about 0.04 s, and `.\u002Fmvnw verify -Dnative` ran the `*IT` against it successfully. Quarkus checks the Mandrel\u002FGraalVM version: 3.40 refuses 23.1 (\"Out of date version of GraalVM or Mandrel detected ... Quarkus currently supports 25.0.0\"), so use Mandrel 25 with 3.40 and `mandrel-java21-macos-aarch64-23.1.12.1-Final` with 3.27.6 (Maven `verify -Dnative` and Gradle both verified there).\n\nBinary: `target\u002F*-runner` (Maven) or `build\u002F*-runner` (Gradle). A container build on macOS or Windows produces a Linux ELF that cannot run on the host: run it in a Linux container (for example `docker run -v \"$PWD\u002Ftarget:\u002Fw:ro\" registry.access.redhat.com\u002Fubi9\u002Fubi-minimal \u002Fw\u002F\u003Cname>-runner` with the datasource passed through `QUARKUS_DATASOURCE_*` env vars), and note that `.\u002Fmvnw verify -Dnative` then fails in the `*IT` with `Exit code is: '126'`. Mandrel is Red Hat's GraalVM distribution for Quarkus; the container build pulls a Mandrel builder image matching the project (3.40.1 used `quay.io\u002Fquarkus\u002Fubi9-quarkus-mandrel-builder-image:jdk-25`, Mandrel 25.0.4.1, about 2.5 minutes including the image pull); override it with `quarkus.native.builder-image` if needed. Native builds are slow and memory-hungry (several GB); do them in CI or on demand, not on every test run.\n\n## Common native failures\n\n| Symptom | Fix |\n|---|---|\n| `ClassNotFoundException` \u002F `NoSuchMethodException` at runtime (reflection, JSON serialization of DTOs) | annotate with `@RegisterForReflection` (or `@RegisterForReflection(targets = ...)` on a holder class for third-party types), or put a `reflection-config.json` in `src\u002Fmain\u002Fresources` and set `quarkus.native.additional-build-args=-H:ReflectionConfigurationFiles=reflection-config.json` |\n| Missing resource files | `quarkus.native.resources.includes=templates\u002F**` |\n| Library not supporting native | look for a Quarkus extension, or choose another library |\n| Class initialized at build time breaks | `--initialize-at-run-time=...` through `quarkus.native.additional-build-args` |\n| `OutOfMemoryError` during build | raise container memory or `quarkus.native.native-image-xmx` |\n| Dynamic proxies \u002F serialization | register via annotations or extension |\n\n```java\n@RegisterForReflection(targets = ExternalDto.class)\npublic record ProductDto(String name) {}\n```\n\nPrefer Quarkus extensions (they register reflection automatically) over raw libraries. Verified: a Panache + Quarkus REST app built natively and served JSON with a record DTO; Quarkus REST registers returned types itself, so `@RegisterForReflection` is mainly needed for types reached only reflectively (custom serialization, third-party types). Both rows were reproduced on 3.40.1 (local Mandrel 25): a resource calling `Class.forName(\"org.acme.Hidden\").getDeclaredConstructor().newInstance()` returned HTTP 500 `ClassNotFoundException: org.acme.Hidden` in the native binary, and worked after adding `src\u002Fmain\u002Fresources\u002Freflection-config.json` (`[{ \"name\": \"org.acme.Hidden\", \"allDeclaredConstructors\": true }]`) with the documented `-H:ReflectionConfigurationFiles=reflection-config.json` (the relative file name resolves from `src\u002Fmain\u002Fresources`). For the run-time initialization row, a `static final java.util.Random` in a class forced to build-time init (`--initialize-at-build-time=org.acme.Holder`) failed the build with \"Detected an instance of Random\u002FSplittableRandom class in the image heap ... mark it explicitly for run time initialization with '--initialize-at-run-time=\u003Cculprit>'\"; switching to `--initialize-at-run-time=org.acme.Holder` fixed it, also combined with the reflection flag in one comma-separated `quarkus.native.additional-build-args`. Quarkus's generated native-image feature calls `RuntimeClassInitialization.initializeAtBuildTime(\"\")` and then applies explicit run-time overrides, so classes default to build-time initialization. Your own static initializers (random seeds, clocks, env reads, threads) can therefore cause this failure too, not only libraries.\n\n## Test the native binary\n\n```java\n@QuarkusIntegrationTest\nclass GreetingResourceIT extends GreetingResourceTest {}\n```\n\n```bash\n.\u002Fmvnw verify -Dnative\n```\n\n`@QuarkusIntegrationTest` black-box tests run in the `verify` phase (Failsafe) against the native binary; no CDI injection.\n\n## Container images\n\n```bash\nquarkus extension add container-image-jib      # or container-image-docker\n.\u002Fmvnw package -Dquarkus.container-image.build=true\n.\u002Fmvnw package -Dnative -Dquarkus.native.container-build=true -Dquarkus.container-image.build=true\n```\n\n`container-image-jib` needs no Docker daemon to push: with `DOCKER_HOST` pointing at a non-existent socket, `.\u002Fmvnw package -Dquarkus.container-image.build=true -Dquarkus.container-image.push=true -Dquarkus.container-image.registry=localhost:5055 -Dquarkus.container-image.insecure=true -Dquarkus.container-image.group=acme` pushed `acme\u002Fq340m:1.0.0-SNAPSHOT` to a local `registry:2` (3.40.1, JVM image). Without `push=true` Jib loads the image into a local Docker\u002FPodman and fails with `Cannot get an executable name when no container runtime is available` when none is reachable. A tar-only output was not found or tested; the pushed image was not run.\n\nDockerfiles for manual builds live in `src\u002Fmain\u002Fdocker` (`Dockerfile.jvm`, `Dockerfile.native`, `Dockerfile.native-micro`). Set `quarkus.container-image.registry\u002Fgroup\u002Fname\u002Ftag`, and `-Dquarkus.container-image.push=true` to push. Use pinned base-image tags and run as non-root.\n\n## Kubernetes \u002F OpenShift\n\n```bash\nquarkus extension add kubernetes     # or: quarkus extension add openshift\n.\u002Fmvnw package\n```\n\nManifests are generated in `target\u002Fkubernetes\u002Fkubernetes.yml` (and `.json`) for the `kubernetes` extension, and in `target\u002Fkubernetes\u002Fopenshift.yml` for `openshift`. Customize via properties; the prefix follows the target (`quarkus.kubernetes.*` for Kubernetes, `quarkus.openshift.*` for OpenShift):\n\n```properties\nquarkus.kubernetes.replicas=2\nquarkus.kubernetes.ingress.expose=true\nquarkus.kubernetes.env.secrets=app-secrets\nquarkus.kubernetes.resources.requests.memory=128Mi\n```\n\nThe generated Deployment has no probes by default; with `quarkus-smallrye-health` installed it includes liveness, readiness and startup probes (`\u002Fq\u002Fhealth\u002Flive`, `\u002Fq\u002Fhealth\u002Fready`, `\u002Fq\u002Fhealth\u002Fstarted`), and it sets `envFrom.secretRef` for `env.secrets` (verified on 3.40.1). Deploy with `quarkus.kubernetes.deploy=true` or `kubectl apply -f target\u002Fkubernetes\u002Fkubernetes.yml`. On OpenShift use the same properties under `quarkus.openshift.*`, expose the service with a Route via `quarkus.openshift.route.expose=true` (Kubernetes uses `quarkus.kubernetes.ingress.expose=true` instead), and apply with `oc apply -f target\u002Fkubernetes\u002Fopenshift.yml` (or `quarkus.openshift.deploy=true`). Review generated YAML before applying; keep secrets out of it.\n\nSee also: native executables \u003Chttps:\u002F\u002Fquarkus.io\u002Fguides\u002Fbuilding-native-image>; upgrades via `quarkus update` (\u003Chttps:\u002F\u002Fquarkus.io\u002Fguides\u002Fupdate-quarkus>); GraalVM release notes \u003Chttps:\u002F\u002Fwww.graalvm.org\u002Frelease-notes\u002F>.\n","# Quarkus Native and Container\n\nCheck the project's Quarkus version first. For generic (non-Quarkus) GraalVM work, use the optional `java-add-graalvm-native-image-support` skill if installed (otherwise see the GraalVM docs, \u003Chttps:\u002F\u002Fwww.graalvm.org\u002Flatest\u002Freference-manual\u002Fnative-image\u002F>).\n\n## Native build\n\n```bash\n# container build: no local GraalVM needed (Docker\u002FPodman required)\n.\u002Fmvnw package -Dnative -Dquarkus.native.container-build=true\n# local Mandrel\u002FGraalVM (JAVA_HOME \u002F GRAALVM_HOME must point to it)\n.\u002Fmvnw package -Dnative\n# Gradle, Quarkus 3.10+ (add -Dquarkus.native.container-build=true without a local Mandrel)\n.\u002Fgradlew build -Dquarkus.native.enabled=true -Dquarkus.package.jar.enabled=false\n# Gradle, older Quarkus\n.\u002Fgradlew build -Dquarkus.package.type=native\n```\n\n`quarkus.package.type` was deprecated in 3.10 (the 3.10 migration guide replaces it with `quarkus.native.enabled` and `quarkus.package.jar.*`); it is still accepted in 3.40 with a warning. Version gate verified with Gradle: on 3.9.5 `-Dquarkus.native.enabled=true -Dquarkus.package.jar.enabled=false` is ignored (\"Unrecognized configuration key\" warnings) and only a JVM `quarkus-app` is built, while `-Dquarkus.package.type=native` produces the native runner; on 3.10.0, 3.27.6 and 3.40.1 the new keys produce the native runner (3.10.0 also accepts the old key with the deprecation warning). The Maven `native` profile in the generated `pom.xml` already sets `quarkus.native.enabled=true`, `quarkus.package.jar.enabled=false` and `skipITs=false` when `-Dnative` is passed.\n\nLocal build verified on macOS arm64 with the Mandrel tarball for your Quarkus line from \u003Chttps:\u002F\u002Fgithub.com\u002Fgraalvm\u002Fmandrel\u002Freleases> (`mandrel-java25-macos-aarch64-25.0.4.1-Final.tar.gz` for 3.40.1, extracted anywhere, `JAVA_HOME` pointing at its `Contents\u002FHome`; Xcode command line tools are enough): 3.40.1 Maven `package -Dnative` took about 70 s and Gradle `build` with the two flags about 2.5 min; the runner is a Mach-O executable that starts in about 0.04 s, and `.\u002Fmvnw verify -Dnative` ran the `*IT` against it successfully. Quarkus checks the Mandrel\u002FGraalVM version: 3.40 refuses 23.1 (\"Out of date version of GraalVM or Mandrel detected ... Quarkus currently supports 25.0.0\"), so use Mandrel 25 with 3.40 and `mandrel-java21-macos-aarch64-23.1.12.1-Final` with 3.27.6 (Maven `verify -Dnative` and Gradle both verified there).\n\nBinary: `target\u002F*-runner` (Maven) or `build\u002F*-runner` (Gradle). A container build on macOS or Windows produces a Linux ELF that cannot run on the host: run it in a Linux container (for example `docker run -v \"$PWD\u002Ftarget:\u002Fw:ro\" registry.access.redhat.com\u002Fubi9\u002Fubi-minimal \u002Fw\u002F\u003Cname>-runner` with the datasource passed through `QUARKUS_DATASOURCE_*` env vars), and note that `.\u002Fmvnw verify -Dnative` then fails in the `*IT` with `Exit code is: '126'`. Mandrel is Red Hat's GraalVM distribution for Quarkus; the container build pulls a Mandrel builder image matching the project (3.40.1 used `quay.io\u002Fquarkus\u002Fubi9-quarkus-mandrel-builder-image:jdk-25`, Mandrel 25.0.4.1, about 2.5 minutes including the image pull); override it with `quarkus.native.builder-image` if needed. Native builds are slow and memory-hungry (several GB); do them in CI or on demand, not on every test run.\n\n## Common native failures\n\n| Symptom | Fix |\n|---|---|\n| `ClassNotFoundException` \u002F `NoSuchMethodException` at runtime (reflection, JSON serialization of DTOs) | annotate with `@RegisterForReflection` (or `@RegisterForReflection(targets = ...)` on a holder class for third-party types), or put a `reflection-config.json` in `src\u002Fmain\u002Fresources` and set `quarkus.native.additional-build-args=-H:ReflectionConfigurationFiles=reflection-config.json` |\n| Missing resource files | `quarkus.native.resources.includes=templates\u002F**` |\n| Library not supporting native | look for a Quarkus extension, or choose another library |\n| Class initialized at build time breaks | `--initialize-at-run-time=...` through `quarkus.native.additional-build-args` |\n| `OutOfMemoryError` during build | raise container memory or `quarkus.native.native-image-xmx` |\n| Dynamic proxies \u002F serialization | register via annotations or extension |\n\n```java\n@RegisterForReflection(targets = ExternalDto.class)\npublic record ProductDto(String name) {}\n```\n\nPrefer Quarkus extensions (they register reflection automatically) over raw libraries. Verified: a Panache + Quarkus REST app built natively and served JSON with a record DTO; Quarkus REST registers returned types itself, so `@RegisterForReflection` is mainly needed for types reached only reflectively (custom serialization, third-party types). Both rows were reproduced on 3.40.1 (local Mandrel 25): a resource calling `Class.forName(\"org.acme.Hidden\").getDeclaredConstructor().newInstance()` returned HTTP 500 `ClassNotFoundException: org.acme.Hidden` in the native binary, and worked after adding `src\u002Fmain\u002Fresources\u002Freflection-config.json` (`[{ \"name\": \"org.acme.Hidden\", \"allDeclaredConstructors\": true }]`) with the documented `-H:ReflectionConfigurationFiles=reflection-config.json` (the relative file name resolves from `src\u002Fmain\u002Fresources`). For the run-time initialization row, a `static final java.util.Random` in a class forced to build-time init (`--initialize-at-build-time=org.acme.Holder`) failed the build with \"Detected an instance of Random\u002FSplittableRandom class in the image heap ... mark it explicitly for run time initialization with '--initialize-at-run-time=\u003Cculprit>'\"; switching to `--initialize-at-run-time=org.acme.Holder` fixed it, also combined with the reflection flag in one comma-separated `quarkus.native.additional-build-args`. Quarkus's generated native-image feature calls `RuntimeClassInitialization.initializeAtBuildTime(\"\")` and then applies explicit run-time overrides, so classes default to build-time initialization. Your own static initializers (random seeds, clocks, env reads, threads) can therefore cause this failure too, not only libraries.\n\n## Test the native binary\n\n```java\n@QuarkusIntegrationTest\nclass GreetingResourceIT extends GreetingResourceTest {}\n```\n\n```bash\n.\u002Fmvnw verify -Dnative\n```\n\n`@QuarkusIntegrationTest` black-box tests run in the `verify` phase (Failsafe) against the native binary; no CDI injection.\n\n## Container images\n\n```bash\nquarkus extension add container-image-jib      # or container-image-docker\n.\u002Fmvnw package -Dquarkus.container-image.build=true\n.\u002Fmvnw package -Dnative -Dquarkus.native.container-build=true -Dquarkus.container-image.build=true\n```\n\n`container-image-jib` needs no Docker daemon to push: with `DOCKER_HOST` pointing at a non-existent socket, `.\u002Fmvnw package -Dquarkus.container-image.build=true -Dquarkus.container-image.push=true -Dquarkus.container-image.registry=localhost:5055 -Dquarkus.container-image.insecure=true -Dquarkus.container-image.group=acme` pushed `acme\u002Fq340m:1.0.0-SNAPSHOT` to a local `registry:2` (3.40.1, JVM image). Without `push=true` Jib loads the image into a local Docker\u002FPodman and fails with `Cannot get an executable name when no container runtime is available` when none is reachable. A tar-only output was not found or tested; the pushed image was not run.\n\nDockerfiles for manual builds live in `src\u002Fmain\u002Fdocker` (`Dockerfile.jvm`, `Dockerfile.native`, `Dockerfile.native-micro`). Set `quarkus.container-image.registry\u002Fgroup\u002Fname\u002Ftag`, and `-Dquarkus.container-image.push=true` to push. Use pinned base-image tags and run as non-root.\n\n## Kubernetes \u002F OpenShift\n\n```bash\nquarkus extension add kubernetes     # or: quarkus extension add openshift\n.\u002Fmvnw package\n```\n\nManifests are generated in `target\u002Fkubernetes\u002Fkubernetes.yml` (and `.json`) for the `kubernetes` extension, and in `target\u002Fkubernetes\u002Fopenshift.yml` for `openshift`. Customize via properties; the prefix follows the target (`quarkus.kubernetes.*` for Kubernetes, `quarkus.openshift.*` for OpenShift):\n\n```properties\nquarkus.kubernetes.replicas=2\nquarkus.kubernetes.ingress.expose=true\nquarkus.kubernetes.env.secrets=app-secrets\nquarkus.kubernetes.resources.requests.memory=128Mi\n```\n\nThe generated Deployment has no probes by default; with `quarkus-smallrye-health` installed it includes liveness, readiness and startup probes (`\u002Fq\u002Fhealth\u002Flive`, `\u002Fq\u002Fhealth\u002Fready`, `\u002Fq\u002Fhealth\u002Fstarted`), and it sets `envFrom.secretRef` for `env.secrets` (verified on 3.40.1). Deploy with `quarkus.kubernetes.deploy=true` or `kubectl apply -f target\u002Fkubernetes\u002Fkubernetes.yml`. On OpenShift use the same properties under `quarkus.openshift.*`, expose the service with a Route via `quarkus.openshift.route.expose=true` (Kubernetes uses `quarkus.kubernetes.ingress.expose=true` instead), and apply with `oc apply -f target\u002Fkubernetes\u002Fopenshift.yml` (or `quarkus.openshift.deploy=true`). Review generated YAML before applying; keep secrets out of it.\n\nSee also: native executables \u003Chttps:\u002F\u002Fquarkus.io\u002Fguides\u002Fbuilding-native-image>; upgrades via `quarkus update` (\u003Chttps:\u002F\u002Fquarkus.io\u002Fguides\u002Fupdate-quarkus>); GraalVM release notes \u003Chttps:\u002F\u002Fwww.graalvm.org\u002Frelease-notes\u002F>.\n",{"name":5,"description":7},"main","5269f7ea2d6c3a9bfda5ed878b6726cf509121fd","skills\u002Fquarkus-native-and-container",5340,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot","https:\u002F\u002Fawesome-copilot.github.com\u002F","https:\u002F\u002Fgithub.com\u002Fgithub","https:\u002F\u002Fgithub.com\u002Fabout","How people build software.","2026-11-11 13:41:32",{"source":8,"skillName":5,"commands":61,"prompt":71,"zipAvailable":72},[62,65,68],{"tool":63,"command":64},"npx","npx skills add github\u002Fawesome-copilot --skill quarkus-native-and-container",{"tool":66,"command":67},"bunx","bunx skills add github\u002Fawesome-copilot --skill quarkus-native-and-container",{"tool":69,"command":70},"pnpm","pnpm dlx skills add github\u002Fawesome-copilot --skill quarkus-native-and-container","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fquarkus-native-and-container\u002FSKILL.md",true,[],[75,105,132,162,196,213],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":87,"publishedAt":45},"01M70KXZNX9ES38N2A8M58ZZMZ","supabase-rls-policies","Write, review, and test Supabase Row Level Security (RLS) policies so that one user cannot read or change another user's rows. Use when creating or changing tables, policies, views, or security definer functions in a Supabase project, when reviewing a migration that touches RLS, or when asked to prove user isolation with pgTAP tests that sign in as two users.","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fsupabase-rls-policies\u002FSKILL.md",[81,84],{"categoryNo":82,"categoryName":83,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":85,"categoryName":86,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[88,89,90,91,33,92,93,94,95,96,97,98,99,100,101,102,28,103,104,32],"supabase","rls","supabase rls","supabase rls policies","when","review","change","read","write","security","isolation","tables","as","tests","prove","users","functions",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":112,"publishedAt":45},"01M70KWA5YWXDV6V8DZ19E3T2Y","skill-distribution-audit","Audit a skill collection before release or investigate installer omissions, archived\u002Ftemplate leakage, duplicate identities, and manifest drift. Reconcile the intended public source set, distribution manifest, and actual discovery output for a specified consumer version. Includes a deterministic set-comparison helper.","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fskill-distribution-audit\u002FSKILL.md",[111],{"categoryNo":85,"categoryName":86,"taxonomyType":21,"taxonomyTypeDesc":22},[113,114,115,116,117,118,29,119,120,121,122,123,124,125,126,127,128,129,130,131],"distribution","skill distribution audit","audit","SET","deterministic","installer","discovery","comparison","helper","manifest","version","collection","drift","output","investigate","duplicate","template","release","reconcile",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":136,"sourceHtmlUrl":137,"categories":138,"keywords":144,"publishedAt":45},"01M70KCJPFVW7PPQ49CC5R8JGK","logicapps-custom-code-net10-migration","Migrate Azure Logic Apps Standard local-function custom-code projects from .NET 8 to .NET 10. Use for legacy Logic Apps custom-code workspace upgrades, project\u002Fpackage configuration, custom-worker settings, publication, and integrated VS Code debugging. Not for ordinary .NET applications, standalone Azure Functions, Consumption workflows, or cloud deployment.","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Flogicapps-custom-code-net10-migration\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Flogicapps-custom-code-net10-migration\u002FSKILL.md",[139],{"categoryNo":140,"categoryName":141,"taxonomyType":142,"taxonomyTypeDesc":143},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[145,146,147,148,149,150,29,33,151,152,153,154,155,156,157,28,158,159,160,161],"custom","code","logicapps custom code net10 migration","migration","projects","standalone","deployment","applications","local","azure","worker","upgrades","package","apps","Legacy","debugging","workflows",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":166,"sourceHtmlUrl":167,"categories":168,"keywords":173,"publishedAt":45},"01M6AEBN37RQMXJ3298PEY7PG1","winmd-api-search","Find and explore Windows desktop APIs. Use when building features that need platform capabilities — camera, file access, notifications, UI controls, AI\u002FML, sensors, networking, etc. Discovers the right API for a task and retrieves full type details (methods, properties, events, enumeration values).","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fwinmd-api-search\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fwinmd-api-search\u002FSKILL.md",[169,172],{"categoryNo":170,"categoryName":171,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":140,"categoryName":141,"taxonomyType":142,"taxonomyTypeDesc":143},[174,175,176,177,178,179,180,181,182,183,184,185,186,187,188,92,189,190,191,192,193,29,194,195],"winmd api search","search","api","windows","desktop","file access","enumeration","ui","ml","file","networking","capabilities","notifications","explore","access","features","full","camera","events","platform","methods","controls",{"skillNo":197,"name":198,"nameZh":6,"description":199,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":200,"licenseFileUrl":201,"sourceHtmlUrl":202,"categories":203,"keywords":209,"publishedAt":45},"01M6AE571R3SC1ZGE202B3NB5S","resemble-detect","Deepfake detection and media safety — detect AI-generated audio, images, video, and text, trace synthesis sources, apply watermarks, verify speaker identity, and analyze media intelligence using Resemble AI","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fresemble-detect\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fresemble-detect\u002FSKILL.md",[204,205,208],{"categoryNo":170,"categoryName":171,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":206,"categoryName":207,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":85,"categoryName":86,"taxonomyType":21,"taxonomyTypeDesc":22},[210,116,183,211,212],"resemble detect","https","identity",{"skillNo":214,"name":215,"nameZh":6,"description":216,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":200,"licenseFileUrl":217,"sourceHtmlUrl":218,"categories":219,"keywords":224,"publishedAt":45},"01M6AE30BSK2HCY4TQQ22Z8JRD","quality-playbook","Run a complete quality engineering audit on any codebase. Derives behavioral requirements from the code, generates spec-traced functional tests, runs a three-pass code review with regression tests, executes a multi-model spec audit (Council of Three), and produces a consolidated bug report with TDD-verified patches. Finds the 35% of real defects that structural code review alone cannot catch. Works with any language. Trigger on 'quality playbook', 'spec audit', 'Council of Three', 'fitness-to-purpose', or 'coverage theater'.","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fquality-playbook\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fquality-playbook\u002FSKILL.md",[220,223],{"categoryNo":221,"categoryName":222,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":85,"categoryName":86,"taxonomyType":21,"taxonomyTypeDesc":22},[225,226,227,228,146,93,9,115,229,230,211,231,232,233,234,235,236,237,238,239,240,241,101,242,243,244,245],"playbook","quality playbook","quality","code review","tdd","run","report","spec","bug report","council","engineering","functional","spec audit","bug","verified","multi-model","three","coverage","model","regression","structural"]