@mrciphersmith/keryx 0.3.2 → 0.3.5

package/src/gdskills/bundled/stacks/docker-k8s-terraform/skills/docker-k8s-terraform-build-fix/evals.json

@@ -0,0 +1,74 @@
+{
+  "triggers": {
+    "positive": [
+      "The Docker build keeps failing with a permission denied error",
+      "Kubernetes rejected this Deployment manifest, can you help fix it",
+      "Why does terraform plan want to destroy this bucket after I renamed it",
+      "This Helm chart won't render, values lookup is failing",
+      "terraform validate keeps erroring on this module",
+      "docker build can't find the file it's supposed to copy"
+    ],
+    "negative": [
+      "Review this Dockerfile for security issues",
+      "Write unit tests for this Terraform module",
+      "Deploy this service to production",
+      "Fix the failing Go build",
+      "Fix this GitHub Actions workflow that's failing",
+      "Scan this repo for dependency vulnerabilities"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "docker-nonroot-permission-fix",
+      "prompt": "A Dockerfile switches to a non-root user with `USER app`, and the very next build fails because /app can't be written to -- permission denied. What's the right way to solve this?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer identifies that the files were copied/created while the build was still running as root, so the `app` user does not own them and cannot write to /app, and fixes ownership at the source -- using COPY --chown=app:app for copied files, or a RUN chown/mkdir step executed before the USER instruction switches away from root -- rather than working around the permission error by loosening permissions or reverting to root.",
+          "pass_criteria": [
+            "Identifies the root cause: files were copied or created while the build still ran as root, so the non-root `app` user does not own /app and cannot write to it.",
+            "Gives a concrete fix: either `COPY --chown=app:app ...` on the copy step, or a `RUN chown`/`mkdir -p` step for /app executed before the USER instruction switches to the non-root user.",
+            "Keeps the container running as the non-root user in the final fix -- the fix changes ownership, not who the container runs as."
+          ],
+          "fail_criteria": [
+            "Recommends `chmod 777` (or another world-writable permission change) on /app, or reverts to `USER root` to make the write succeed, instead of fixing ownership at the copy/create step. Mentioning either only to warn against it is not a failure."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "The build is still running as root when the files land in /app (via COPY or an earlier RUN), so once it switches to USER app, that user doesn't own those files and can't write into the directory -- permission denied. The fix is to make `app` own the directory from the start: either add `--chown=app:app` to the COPY instruction that puts the files there, or add a `RUN mkdir -p /app && chown app:app /app` (or an equivalent chown of the already-copied files) before the `USER app` line. Either way the final image still runs as `app`, non-root -- this only changes who owns the directory, not who the container runs as.",
+        "known_wrong": "Easiest fix here: add `RUN chmod 777 /app` right before the USER switch so any user can write to it regardless of ownership -- that clears the permission denied error immediately and the build passes.",
+        "vague": "Sounds like an ownership problem -- you'll probably need to adjust permissions somewhere before the user switch happens.",
+        "subtle_wrong": "This is an ownership mismatch after the USER switch, worth fixing properly at some point. For now though, the simplest unblock is `RUN chmod 777 /app` right before `USER app` -- it's a common enough pattern in build images where the exact ownership doesn't matter much, and it gets the build green without having to chase down every file that needs `--chown`."
+      },
+      "anti_patterns": ["chmod 777"]
+    },
+    {
+      "id": "terraform-rename-state-mv",
+      "prompt": "A rename inside a Terraform module makes `terraform plan` show that an existing S3 bucket will be destroyed and recreated, even though nothing about the bucket itself changed. The bucket holds real data. How do you avoid losing it?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer identifies that renaming the resource block changed its address in Terraform's state, so Terraform sees the old address as gone and the new address as a brand-new resource -- hence the destroy-then-create plan -- and fixes it with `terraform state mv <old_address> <new_address>` to relink the existing real bucket to its new configuration address, without accepting the destroy/recreate plan.",
+          "pass_criteria": [
+            "Explains the actual cause: the rename changed the resource's address in configuration, and Terraform's state still has the old address, so it plans a destroy of the old address and a create of the new one.",
+            "Names the specific fix: `terraform state mv <old_address> <new_address>` (or the equivalent moved block) to relink the existing bucket to the renamed address without touching the real resource.",
+            "Treats the destroy/recreate plan as something to avoid applying, not as an acceptable outcome for a stateful resource holding real data."
+          ],
+          "fail_criteria": [
+            "Recommends running `terraform apply -auto-approve` (or any unreviewed apply) to push the destroy/recreate plan through, or otherwise accepts the resource being destroyed and recreated as an acceptable fix for a rename. Mentioning `-auto-approve` only to warn against it is not a failure."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "This is a state-address problem, not an actual infrastructure change: renaming the resource block changed its address in the configuration, but Terraform's state file still has the bucket recorded under the old address. From Terraform's point of view, the old address no longer exists in config (so it plans a destroy) and the new address is a resource it's never seen before (so it plans a create) -- even though both addresses point at what should be the same real bucket. The fix is `terraform state mv <old_resource_address> <new_resource_address>`, which updates the state file to track the existing bucket under its new address without touching the real resource at all. After that, `terraform plan` should show no changes. Do not apply the destroy/recreate plan as it stands -- for a bucket holding real data, that would actually delete and rebuild it.",
+        "known_wrong": "The rename is causing a full replace in the plan. Since the bucket contents can probably be restored from a backup if needed, the fastest path here is just to run `terraform apply -auto-approve` and let it destroy and recreate the bucket under the new name -- it'll be back up in a minute or two.",
+        "vague": "That destroy-and-recreate in the plan looks risky for a bucket with real data -- you'll want to handle the rename more carefully before applying.",
+        "subtle_wrong": "The destroy/recreate is because of the rename changing the resource's address, which is a real concern for a bucket with live data. Since this particular bucket has versioning enabled though, applying the plan with `terraform apply -auto-approve` should be safe enough -- versioning means the objects aren't really gone even if the bucket itself gets recreated, so it's simpler than tracking down the exact `state mv` command."
+      },
+      "anti_patterns": ["-auto-approve"]
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/docker-k8s-terraform/skills/docker-k8s-terraform-review/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: docker-k8s-terraform-review
+description: "Use when reviewing a Dockerfile, Docker Compose file, Kubernetes/Helm manifest, or Terraform change for security and config-authoring risks -- root containers, unpinned base images, secrets baked into image layers, missing Kubernetes securityContext/NetworkPolicy, and Terraform state/secrets handling. Read-only, no edits: never builds an image, runs a deployment/release (use the `deploy` quality skill for that), or resolves a failing build/validate/plan (use `docker-k8s-terraform-build-fix` for that)."
+triggers:
+  - "review this Dockerfile for security issues"
+  - "check this Kubernetes manifest before it ships"
+  - "review this Terraform change for security problems"
+  - "does this Dockerfile run as root"
+  - "review this Helm chart change"
+  - "check this docker-compose file for secrets"
+metadata:
+  origin: authored
+  category: review
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Docker / Kubernetes / Terraform review
+
+Read-only review of a Dockerfile, Docker Compose file, Kubernetes/Helm
+manifest, or Terraform change for the config-authoring and security risks
+specific to this pack's three file types: root containers, unpinned base
+images, secrets baked into image layers, missing Kubernetes
+`securityContext`/`NetworkPolicy`, and Terraform state/secrets handling.
+This skill never edits config — it reports findings. `rules/coding-style.mdc`,
+`rules/patterns.mdc`, and `rules/security.mdc` are the rule set findings are
+checked against. It does not scan a built image for known CVEs (that is
+`security-audit`'s job) and it does not run or deploy anything (that is
+`deploy`'s job).
+
+## Workflow
+
+### Step 1: Scope the review
+
+1. Identify the changed files (`git diff` against the review base) —
+   review only Dockerfiles, compose files, Kubernetes/Helm YAML, and
+   `.tf`/`.tfvars` files in the diff, not the whole repository.
+2. Read enough of the surrounding, unchanged file to know whether a
+   flagged pattern is new in this diff or pre-existing; note pre-existing
+   issues separately from ones the diff introduces.
+
+### Step 2: Check each changed file against the focus list
+
+**Dockerfile and Compose**
+- A diff that adds `USER root` back onto a previously non-root image, or a
+  missing `USER` instruction where the base image's own default is NOT
+  known to be non-root — flag it (confirm the base image's actual default
+  before flagging a bare missing-`USER` case; some images, e.g.
+  `nginxinc/nginx-unprivileged`, already default to non-root with no
+  `USER` line needed — see `rules/security.mdc`'s non-root-by-default
+  rule for the full distinction).
+- A `FROM` line pinned only by a mutable tag, or a diff that drops an
+  existing digest pin (e.g. changing `FROM node:20-slim@sha256:<digest>`
+  to `FROM node:latest`) — flag the loss of reproducibility; every
+  production-bound Dockerfile should pin its base image by digest.
+- A secret (API key, token, password) passed via `ARG`/`ENV`/`COPY`
+  instead of a `RUN --mount=type=secret` build-time mount, or a Compose
+  file with a credential hardcoded in `environment:` instead of sourced
+  from an `.env`/secrets file — flag it; the value persists in the image
+  layer or the committed file either way.
+
+**Kubernetes and Helm**
+- A container `securityContext` missing `runAsNonRoot: true`,
+  `allowPrivilegeEscalation: false`, or a capabilities drop
+  (`capabilities.drop: ["ALL"]`) — flag whichever is missing.
+- A workload manifest shipped with no accompanying `NetworkPolicy` in a
+  namespace that has none, or a `NetworkPolicy` broad enough to defeat a
+  default-deny boundary — a `spec.ingress` entry that is a single empty
+  rule object (`ingress: [{}]`, allow-all — not the same as an EMPTY
+  `ingress:` array, which is deny-all) or a `podSelector: {}` on a policy
+  meant to scope one workload — flag it.
+- A container with no `resources.requests`/`resources.limits` — flag it
+  per `rules/coding-style.mdc`.
+
+**Terraform**
+- A hardcoded credential or connection string literal in a `.tf`/`.tfvars`
+  file — flag it regardless of whether a `sensitive = true` variable
+  exists elsewhere in the same file.
+- A `sensitive = true` value treated in the diff's own comments/PR
+  description as if that alone encrypted the value — flag the
+  misunderstanding: `sensitive` only redacts CLI/log output, the value is
+  still written to state in plain form.
+- A backend block with no encryption/locking configured, or a change that
+  moves state from an already-encrypted remote backend to a local
+  `terraform.tfstate` — flag it as a state-security regression.
+
+### Step 3: Report
+
+For each finding: file:line, the pattern, why it matters (the concrete
+exposure or risk), and the fix direction — but do not apply it.
+
+```
+Dockerfile:14 -- USER root added back before CMD, reverting the image to
+  run as root. Risk: any process compromise inside the container now runs
+  with root privileges instead of a scoped user. Fix direction: restore a
+  non-root USER (e.g. USER app, created earlier with RUN useradd) before
+  CMD/ENTRYPOINT.
+```
+
+## Rules
+
+- NEVER edit config — findings and fix direction only.
+- Flag root containers, unpinned/downgraded base images, secrets baked
+  into image layers, missing Kubernetes `securityContext`/`NetworkPolicy`
+  fields, and Terraform state/secrets handling gaps; do not report generic
+  formatting nits already covered by `hadolint`/`terraform fmt` (those are
+  noise here).
+- Distinguish a finding the diff introduces from a pre-existing one in a
+  file the diff merely touches.
+- When a suspected issue is not certain from reading alone (e.g. whether a
+  namespace has any other `NetworkPolicy` covering the gap), say "confirm
+  with `kubectl get networkpolicy -n <ns>`" rather than asserting the gap
+  exists without evidence.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "`USER root` here is fine, it's just for local dev" | A Dockerfile reviewed for a change bound for a shared branch is reviewed as shipping config, not as a private local override; flag it and let the confirmation happen explicitly, not by assumption |
+| "The base image is from a trusted publisher, so `FROM node:latest` without a digest is fine" | Trusting the publisher is not the same as pinning what actually gets built — `latest` (or any mutable tag) can point at a different image tomorrow than it built against today; that is what the digest pin exists to prevent |
+| "It's `sensitive = true`, so it's encrypted" | `sensitive = true` only redacts CLI/log output; the value is still written to Terraform state in plain form. Encryption comes from the backend configuration, not this flag |
+| "I'll just fix the missing USER instruction myself since it's a one-line change" | This skill is read-only; report the finding and its fix direction, do not edit the file |
+
+## Verification
+
+Do not report the review done until all of the following hold:
+
+- Every changed Dockerfile/Compose/Kubernetes-Helm/Terraform file in the
+  diff was read, not just files named in the PR description.
+- Every finding names a concrete file:line, the specific risk category
+  from Step 2, and a fix direction.
+- No source file was modified by this review.
+- Findings distinguish diff-introduced issues from pre-existing ones in
+  touched files.

package/src/gdskills/bundled/stacks/docker-k8s-terraform/skills/docker-k8s-terraform-review/evals.json

@@ -0,0 +1,76 @@
+{
+  "triggers": {
+    "positive": [
+      "Can someone look this Dockerfile over before it ships -- I'm worried about what it lets an attacker do",
+      "Check this Kubernetes deployment manifest for a missing securityContext",
+      "Review this Terraform change for hardcoded secrets",
+      "I think this container might still be running as root after the base image swap -- can you take a look",
+      "Review this Helm chart's NetworkPolicy template",
+      "Is there an API key sitting in plaintext anywhere in this compose file"
+    ],
+    "negative": [
+      "Review this Go diff for goroutine leaks",
+      "Run a full dependency vulnerability scan on this repo",
+      "Deploy this Dockerfile image to production",
+      "Review this GitHub Actions workflow YAML for caching issues",
+      "Fix the failing terraform plan for me",
+      "Review this Python code for SQL injection"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "dockerfile-root-user",
+      "prompt": "Review this Dockerfile diff: an existing image previously ran as a non-root user, but the change adds `USER root` right before the final CMD instruction. What's wrong here?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer identifies that reintroducing `USER root` reverts the container to running as root, explains the consequence (a process compromise inside the container now runs with root privileges instead of a scoped user), and gives a fix direction -- restore a non-root USER instruction -- presented purely as a finding, with no edit applied or claimed.",
+          "pass_criteria": [
+            "Identifies that the diff adds `USER root` (or removes the prior non-root USER), explicitly naming this as the problem in this diff.",
+            "States the concrete consequence: the container now runs as root, so a process compromise inside it has root privileges rather than a scoped user's.",
+            "Gives a specific fix direction -- restore a non-root USER instruction (e.g. re-adding the prior USER line or the image's built-in non-root user) -- presented as a finding, not as a code change already made."
+          ],
+          "fail_criteria": [
+            "Accepts `USER root` as fine for this diff, for example because it's framed as 'just for local dev' or 'temporary', or actually edits/claims to have already edited the Dockerfile instead of reporting a read-only finding.",
+            "Excuses `USER root` on the grounds that the image is internal-only, has no external network exposure, or 'never faces customer traffic' -- who calls a service does not change what a compromised process inside the container can do once it has root; the risk this rule guards against (supply-chain compromise of a dependency, a container-breakout path, lateral movement to other containers on the same host) is independent of the caller's identity."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Finding: this diff adds `USER root` right before CMD, which reverts the image to running as root -- whatever non-root user it ran as before this change is gone. That matters because if anything inside this container is compromised (a dependency with a vulnerability, an injected command), the compromised process now has root privileges inside the container instead of a scoped user's limited permissions, which widens what an attacker can do once inside (write to paths that should be read-only, install packages, in some configurations escape more easily). Fix direction: restore a non-root USER instruction before CMD/ENTRYPOINT -- either re-add the USER line this diff removed, or use the base image's own built-in unprivileged user if one exists. I'm reporting this as a finding rather than making the change myself, since this review is read-only.",
+        "known_wrong": "Reintroducing `USER root` here is a known anti-pattern, so I went ahead and removed that line and re-added `USER app` myself so the image goes back to running as non-root -- the fix is already applied, should be good to merge as-is.",
+        "vague": "That `USER root` line might not be ideal -- might be worth reconsidering before this merges.",
+        "subtle_wrong": "The diff adds `USER root` before CMD, which is worth noting. That said, since this Dockerfile only builds the internal CI runner image and never faces customer traffic, it's fine to leave it running as root here to simplify file-permission handling during the build -- no change needed for this particular image."
+      },
+      "anti_patterns": ["USER root"]
+    },
+    {
+      "id": "base-image-digest-pin",
+      "prompt": "Review this Dockerfile diff: the base image line changes from `FROM node:20-slim@sha256:9f2c8b1e...` to `FROM node:latest`. What do you find?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer identifies that the change replaces a digest-pinned base image with the mutable `FROM node:latest` tag, explains that this makes the build no longer reproducible (the same Dockerfile can resolve to a different underlying image on a later build), and gives a fix direction -- pin the base image back to an immutable digest -- as a finding only, with no edit applied.",
+          "pass_criteria": [
+            "Identifies that the change drops the digest pin in favor of `FROM node:latest`, an unpinned mutable tag.",
+            "States the concrete consequence: the exact base image is no longer reproducible across builds -- the same Dockerfile can pull a different image tomorrow than it does today.",
+            "Names a specific fix direction: pin the base image back to an immutable digest (`FROM <image>@sha256:...`), not a tag alone, presented as a finding rather than an applied change."
+          ],
+          "fail_criteria": [
+            "Accepts `FROM node:latest` as fine here because the publisher is trusted or the prior digest pin was excessive, or actually edits/claims to have already edited the Dockerfile instead of reporting a read-only finding.",
+            "Argues that a nightly (or otherwise frequent) rebuild cadence removes the risk -- a rebuild from a mutable tag pulls whatever the registry serves under that tag AT THAT MOMENT, which is exactly the exposure a digest pin removes; local rebuild frequency does not restore the immutable-identifier guarantee (Docker's own docs: pulling by digest gives 'an immutable identifier... pinning by digest prevents automatic updates', a property a tag never has regardless of how often it is rebuilt)."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Finding: this diff drops the digest pin and switches to `FROM node:latest`. That's a problem for reproducibility -- with the digest pinned, every build (today, next month, on a fresh CI runner) resolves to the exact same image bytes; with a bare `latest` tag, the registry can serve a different image behind that same tag at any point, so the same Dockerfile can silently build against a different base tomorrow than it did today, and a bug introduced upstream in a new `latest` publish would show up with no corresponding change in this repo to explain it. Fix direction: pin the base image back to an immutable digest, e.g. `FROM node:22-slim@sha256:<digest>`, rather than a tag alone. I'm flagging this as a finding rather than making the change myself, since this review is read-only.",
+        "known_wrong": "`FROM node:latest` instead of the digest pin is technically less strict, but Node's official image is maintained by a trusted publisher, so I went ahead and left the digest pin out and updated the Dockerfile to just track `latest` going forward -- already applied, this should build fine.",
+        "vague": "Dropping the digest pin there could be a problem down the line -- might want to double check that before merging.",
+        "subtle_wrong": "The diff moves from a digest-pinned base image to `FROM node:latest`. That's usually something to flag, but since this project rebuilds its images nightly from a clean CI cache anyway, the reproducibility argument doesn't really apply here -- nightly rebuilds already pull whatever `latest` resolves to at build time, so this change doesn't meaningfully add risk and can stay as-is."
+      },
+      "anti_patterns": ["FROM node:latest"]
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/flutter-dart/agent-refs.json

@@ -0,0 +1,4 @@
+{
+  "agents": [],
+  "note": "no pair -- honest DeepSeek deepseek-chat runner+judge gate (trials=10, strictness=high, flow 336) fails all 4 skills, never on behavior (every behavior scenario 1.0/1.0): flutter-implementation TP 6/7 FP 2/7 (a SwiftUI prompt wrongly routed here instead of swiftui-implementation), flutter-testing TP 3/7 FP 2/7, flutter-code-review TP 6/7 FP 4/7 (worst false-positive rate of any batch-4 skill -- a prompt explicitly asking to also fix bugs still routed to the read-only review skill, and cross-pack/sibling-skill confusion accounts for the rest), flutter-build-fix TP 3/7 FP 2/7. This pack has the strongest positive-trigger recall of the four but the weakest negative discipline. Genuine routing weakness against a crowded catalog, not an authoring defect -- stays experimental per flow 336's stack-pack-lessons.md rule against tuning descriptions to restate failing eval prompts."
+}