@mrciphersmith/keryx 0.3.1 → 0.3.3

package/src/gdskills/bundled/stacks/ci-github-gitlab/governance/scout.json

@@ -0,0 +1,26 @@
+[
+  {
+    "query": "Use when authoring or extending a GitHub Actions workflow (.github/workflows/*.yml) or a GitLab CI pipeline (.gitlab-ci.yml) -- trigger and job design, reusable workflows/templates, caching, least-privilege permissions, and safe handling of untrusted pull-request/merge-request input.",
+    "decision": "create",
+    "topMatch": "ci-github-gitlab/ci-pipeline-code-review (0.57, raw tool decision: use)",
+    "recordedAt": "2026-09-25T15:30:00.000Z",
+    "skillName": "ci-pipeline-implementation",
+    "justification": "keryx skills scout --candidate <own-dir> scored the raw top match as this pack's own ci-pipeline-code-review (overlap 0.57, above the 0.55 'use' threshold) purely on shared CI/permissions/pull-request vocabulary -- but ci-pipeline-code-review is a read-only review skill (no edits, findings + fix direction only) and cannot substitute for authoring/extending a workflow file, which requires actually writing YAML and applying a fix. No skill outside this new pack scored above the fork threshold (nothing in ts-js-node/go/python/docker-k8s-terraform authors GitHub Actions or GitLab CI YAML specifically), so this is a genuine create, not a substitute for an existing implement-category skill."
+  },
+  {
+    "query": "Use when reviewing a GitHub Actions workflow (.github/workflows/*.yml) or GitLab CI pipeline (.gitlab-ci.yml) change for security and structural risk -- pull_request_target combined with untrusted checkout, tag-pinned third-party actions, missing least-privilege permissions, script injection via unsanitized event/variable interpolation, and unprotected access to deploy secrets. Read-only, no edits.",
+    "decision": "create",
+    "topMatch": "ci-github-gitlab/ci-pipeline-implementation (0.37, raw tool decision: fork)",
+    "recordedAt": "2026-09-25T15:30:05.000Z",
+    "skillName": "ci-pipeline-code-review",
+    "justification": "keryx skills scout --candidate <own-dir> scored the raw top match as this pack's own ci-pipeline-implementation (overlap 0.37, above the 0.3 fork threshold) on shared CI/permissions/action vocabulary -- but ci-pipeline-implementation authors and edits workflow files, while this skill is strictly read-only (findings + fix direction, never an edit). The next-nearest matches outside this pack, docker-k8s-terraform's own review skill (0.17) and ts-js-node/nodejs-code-review (0.16), review Dockerfiles/Kubernetes manifests and JS/TS source respectively -- neither carries GitHub Actions/GitLab CI-specific vocabulary (pull_request_target, actions/checkout pinning, GITHUB_TOKEN permissions, protected GitLab variables), so this is a genuine create, not an adaptation of an existing review skill's content."
+  },
+  {
+    "query": "Use when a GitHub Actions workflow run or GitLab CI pipeline is failing at the pipeline-configuration level -- YAML syntax errors, an invalid trigger/job key, a missing or misscoped permissions block breaking a step, a job failing because a protected variable is unavailable on its branch, or a broken needs:/rules:/dependency graph -- with the smallest root-cause fix to the config itself, not the application code it builds.",
+    "decision": "create",
+    "topMatch": "ci-github-gitlab/ci-pipeline-implementation (0.28)",
+    "recordedAt": "2026-09-25T15:30:10.000Z",
+    "skillName": "ci-pipeline-build-fix",
+    "justification": "keryx skills scout --candidate <own-dir> put every match below the 0.3 fork threshold (own-pack implementation/review skills at 0.28/0.24; docker-k8s-terraform-build-fix, python-build-fix, and nodejs-build-fix all around 0.18-0.19 on generic 'root cause'/'build'/'fail' vocabulary only, none of which cover GitHub Actions/GitLab CI syntax errors, needs:/rules: graph breaks, or GitLab protected-variable scoping) -- an unambiguous create, matching the tool's own raw decision."
+  }
+]

package/src/gdskills/bundled/stacks/ci-github-gitlab/pack.json

@@ -0,0 +1,41 @@
+{
+  "id": "ci-github-gitlab",
+  "family": "tool",
+  "modules": ["ci-github-gitlab-rules", "ci-github-gitlab-skills"],
+  "detectionMarkers": ["github-actions", "gitlab-ci"],
+  "provenance": {
+    "origin": "authored",
+    "sourceRef": "flow 338, Wave 4 batch 6"
+  },
+  "stability": "experimental",
+  "skills": {
+    "implement": ["ci-pipeline-implementation"],
+    "test": [],
+    "review": ["ci-pipeline-code-review"],
+    "build-fix": ["ci-pipeline-build-fix"],
+    "migrate": []
+  },
+  "notes": "No separate `test` skill: a CI workflow file has no independent test suite of its own beyond the platform linter (actionlint / GitLab CI Lint), which `ci-pipeline-implementation`'s own Verify step and `ci-pipeline-build-fix` already cover -- a dedicated `test` skill would duplicate one of those two rather than earn a distinct place. No `migrate` skill: migrating GitHub Actions runtime/syntax versions or GitLab CI schema changes did not reach the bar for a distinct skill in this pass (unlike `ts-js-node`/`react`'s ESM/version-upgrade migrations, there is no single recurring migration shape specific enough to write a focused skill and eval suite around yet) -- left for a future batch if a concrete need shows up.",
+  "agentProfile": {
+    "displayName": "CI (GitHub Actions & GitLab CI)",
+    "auditFocus": [
+      "a pull_request_target job that checks out github.event.pull_request.head.sha/.ref and then runs a build/test/lint step against it (the pwn-request pattern)",
+      "a third-party uses: action pinned to a mutable tag (@v4, @main) instead of a full commit SHA",
+      "a workflow-level permissions: write-all, or no permissions: block at all, on a workflow whose jobs do not all need write access",
+      "${{ github.event.* }} interpolated directly into a run: shell string instead of passed through env: first, or a GitLab CI script: line that unquotes an untrusted variable, feeds it to eval/sh -c, or reaches it through an unvalidated $[[ inputs.* ]] interpolation",
+      "a GitLab CI deploy job consuming a Protected+Masked variable with no rules: restricting it to the protected branch/tag that variable is exposed to",
+      "a cache key that never changes, or a job with no timeout-minutes/timeout on a step that can hang"
+    ],
+    "buildCommands": [
+      "actionlint (GitHub Actions workflow files, when configured)",
+      "the project's own GitLab CI Lint / gitlab-ci-lint run (.gitlab-ci.yml, when configured)",
+      "re-trigger the specific failing run to confirm the named error is resolved"
+    ],
+    "fixGuardrails": [
+      "never grant a broader permissions: scope than the specific failing step needs, and never at the workflow level to fix one job's failure",
+      "never unprotect a GitLab CI/CD variable, or remove a rules:/branch gate protecting it, just to make a job on the wrong branch pass",
+      "never disable or loosen a rules:/if: condition to make a job \"just run\" without understanding why it was scoped that way",
+      "never pin an action to a tag to work around a SHA-pinning lint failure instead of resolving to the correct commit SHA"
+    ]
+  }
+}

package/src/gdskills/bundled/stacks/ci-github-gitlab/rules/patterns.mdc

@@ -0,0 +1,77 @@
+---
+extends: common
+paths: [".github/workflows/*.yml", ".github/workflows/*.yaml", ".github/actions/**/action.yml", ".github/actions/**/action.yaml", ".gitlab-ci.yml", ".gitlab/**/*.yml", ".gitlab/**/*.yaml"]
+metadata:
+  origin: authored
+---
+
+# CI workflow patterns (GitHub Actions & GitLab CI)
+
+Narrows `core-common-rules`' stack-agnostic design guidance to workflow-YAML
+structure and reuse. Applies only to GitHub Actions workflow files under
+`.github/workflows/`, GitHub composite `action.yml`/`action.yaml` files
+under `.github/actions/`, `.gitlab-ci.yml`, and GitLab CI included config
+under `.gitlab/` — not to Kubernetes manifests,
+Docker Compose files, or any other YAML the `docker-k8s-terraform` pack
+already scopes to.
+
+## Trigger and concurrency shape
+
+- Scope `on:`/`rules:` to the events a workflow actually needs (a specific
+  branch, path filter, or event type) rather than firing on every push —
+  a broad trigger wastes runner minutes and widens the surface a
+  misconfigured job can affect.
+- Add a `concurrency:` group (GitHub Actions) or a `resource_group` (GitLab
+  CI) to any workflow that deploys or mutates shared state, so a second
+  push does not race an in-flight run against the same target — a
+  `resource_group` serializes/queues jobs targeting the same resource,
+  which is the property a deploy job needs. Do not reach for
+  `interruptible: true` here: that flag means the OPPOSITE (this job is
+  SAFE to auto-cancel when a newer pipeline starts), which is right for a
+  build/test job made obsolete by a newer commit, not for a deploy already
+  in flight.
+- Keep `pull_request` as the default trigger for anything that only builds
+  or tests untrusted contributions; reach for `pull_request_target` only
+  when the job genuinely needs base-repo secrets, and see
+  `rules/security.mdc` for what that requires.
+
+## Job structure and reuse
+
+- Give every job an explicit `name:` and a `timeout-minutes` (GitHub
+  Actions) or job-level `timeout` (GitLab CI) — an unbounded job can hang
+  a runner indefinitely on a stuck process or a flaky network call.
+- Factor a step sequence used by more than one workflow into a reusable
+  workflow (`workflow_call`) or composite action (GitHub Actions), or an
+  `include:`/`extends:` template (GitLab CI), instead of copy-pasting the
+  same steps into every workflow file — the copy drifts the moment one
+  copy gets a fix the others do not.
+- Pin a `runs-on`/`image:` to a specific, known runner or image tag rather
+  than a rolling `latest`, so a runner image update cannot silently change
+  build behavior underneath an unrelated change.
+- Use a job-level `needs:` (GitHub Actions) or `needs:`/stage ordering
+  (GitLab CI) to express real dependencies between jobs explicitly, rather
+  than relying on default stage ordering to imply an ordering the config
+  does not actually state.
+
+## Caching and artifacts
+
+- Key a cache (`actions/cache`, GitLab's `cache:key`) off the lockfile or
+  dependency manifest hash, not a static string — a static key serves a
+  stale cache forever and a hash-based key invalidates exactly when the
+  dependency set actually changes.
+- Scope `artifacts:`/`actions/upload-artifact` to the files a later job
+  actually consumes, with an explicit retention/expiry, rather than
+  uploading an entire working directory that balloons storage and
+  transfer time.
+
+## Anti-patterns to flag
+
+- A workflow that duplicates the same 10+ line step sequence across
+  multiple jobs or files instead of a reusable workflow, composite
+  action, or `include:`/`extends:` template.
+- A job with no `timeout-minutes`/`timeout` on a step that can hang (a
+  network call, a wait loop, an interactive prompt the runner cannot
+  answer).
+- A cache key that never changes (a literal string with no hash of the
+  lockfile), which either never invalidates or never actually caches
+  anything useful.

package/src/gdskills/bundled/stacks/ci-github-gitlab/rules/security.mdc

@@ -0,0 +1,144 @@
+---
+extends: common
+paths: [".github/workflows/*.yml", ".github/workflows/*.yaml", ".github/actions/**/action.yml", ".github/actions/**/action.yaml", ".gitlab-ci.yml", ".gitlab/**/*.yml", ".gitlab/**/*.yaml"]
+metadata:
+  origin: authored
+---
+
+# CI workflow security (GitHub Actions & GitLab CI)
+
+Narrows `core-common-rules`' stack-agnostic security rules to the risks
+specific to workflow-YAML configuration. Applies only to GitHub Actions
+workflow files under `.github/workflows/`, GitHub composite `action.yml`/
+`action.yaml` files under `.github/actions/`, `.gitlab-ci.yml`, and GitLab
+CI included config under `.gitlab/`.
+
+## `pull_request_target` and untrusted fork code
+
+- `pull_request_target` runs in the context of the **base** repository —
+  every repo secret the workflow references is available to it (secrets
+  are consumed, not read/write-scoped, so "access" is simply yes/no here),
+  and `GITHUB_TOKEN` gets read/write repository permissions by default
+  (unless a `permissions:` block explicitly narrows it) — even though the
+  triggering pull request can come from an untrusted fork.
+- Never check out and then execute the pull request's own head ref/SHA
+  (`actions/checkout` with `ref: ${{ github.event.pull_request.head.sha }}`)
+  inside a `pull_request_target` job and then run a build/test/lint
+  command against it — that combination (checkout untrusted code + run it
+  with base-repo secrets) is the "pwn request" pattern: it hands an
+  attacker-controlled pull request everything it needs to exfiltrate
+  secrets or push with the workflow's own write access.
+- If a `pull_request_target` job genuinely needs to read fork content
+  (e.g. to comment on a PR), check it out read-only and do not execute
+  anything from it — no `run:`, no build step, no test step against the
+  fork's own code — or route the job through a privilege-separated
+  `workflow_run` split (a build job with no secrets, a separate
+  privileged job that only consumes safe artifacts) instead.
+- When a job only needs to build/test a contribution and does not need
+  base-repo secrets or write access, use `pull_request`, not
+  `pull_request_target` — when a `pull_request` run is triggered from a
+  fork, `GITHUB_TOKEN` (still the base repo's own token, not a separate
+  "fork token") gets read-only permissions, and no other repo secret is
+  passed to the runner at all.
+
+## Pin third-party actions to a commit SHA
+
+- Reference a third-party action by its full-length commit SHA
+  (`uses: actions/checkout@<40-char-sha>`), not a mutable tag like `@v4`
+  or a branch name — a tag can be moved by the action's own maintainer
+  (or, if the account is compromised, by an attacker) to point at a
+  different, malicious commit without the reference in your workflow ever
+  changing.
+- A first-party action from `actions/*` maintained by GitHub itself is
+  lower risk than an arbitrary third-party action, but the SHA-pinning
+  rule still applies to any action outside the repository's own
+  `.github/actions/` — do not special-case a well-known org as exempt.
+- When a comment noting the tag the SHA corresponds to helps readability
+  (`uses: actions/checkout@<sha> # v4.2.0`), that comment is documentation
+  only — it is the SHA, not the comment, that pins the actual code that
+  runs.
+
+## Least-privilege `permissions:`
+
+- Default to `permissions: {}` (or `permissions: read-all` only when read
+  access is genuinely needed everywhere) at the workflow level, then grant
+  the specific scopes a job needs (`contents: write`, `pull-requests:
+  write`, `id-token: write` for OIDC, etc.) at the **job** level, not the
+  workflow level — a workflow-level `permissions: write-all` (or no
+  `permissions:` key at all, which can default to broad access depending
+  on the repository/org setting) hands every job in the file whatever
+  scope the most-privileged job needed, even ones that only read.
+- Grant `id-token: write` only to the job that actually performs OIDC
+  federation (cloud credential exchange); never at the workflow level
+  alongside jobs that do not need it.
+
+## Script injection via untrusted expression expansion
+
+- Never interpolate an untrusted `${{ github.event.* }}` value (a PR
+  title, issue body, commit message, branch name, or any other
+  attacker-influenced field) directly into a `run:` shell string — the
+  expression is substituted into the generated script **before** the
+  shell runs, so a value containing shell metacharacters (`"`, `` ` ``,
+  `$(...)`) can break out of the intended string and execute arbitrary
+  commands on the runner with whatever permissions that job has.
+- Pass the untrusted value through an intermediate `env:` variable first,
+  then reference the environment variable (`"$TITLE"`, quoted) inside the
+  script, instead of interpolating `${{ github.event.pull_request.title
+  }}` directly into the `run:` string — the environment variable is set
+  in memory and never re-enters shell-script generation, which is what
+  actually neutralizes the injection.
+- GitLab CI's own script-injection risk is NOT the same mechanism, and the
+  `env:`-indirection fix above does not carry over: every GitLab CI/CD
+  variable (a predefined one like `CI_MERGE_REQUEST_TITLE`, or one you
+  declare under `variables:`) is already an ordinary shell environment
+  variable by the time `script:` runs — there is no separate "before the
+  shell sees it" substitution step to intercept the way `${{ }}` needs
+  routing through `env:` first. Wrapping an already-a-variable in another
+  `variables:` entry changes nothing about how the shell expands it.
+  The real risks, and their real fixes:
+  - **Unquoted expansion**: `script: - rm -rf $CI_MERGE_REQUEST_TITLE` lets
+    the shell word-split and glob-expand an untrusted value; always quote
+    (`"$CI_MERGE_REQUEST_TITLE"`), and never build a command string by
+    concatenating an untrusted variable into one for `eval`/`sh -c`
+    (`eval "some-command $CI_MERGE_REQUEST_TITLE"` is exploitable however
+    the variable got its value).
+  - **Config-time interpolation via CI/CD inputs** (`$[[ inputs.x ]]`,
+    used in a component/included config's `rules:`/`script:`): this IS
+    substituted into the YAML/expression text before the job is even
+    created, the same class of risk `${{ }}` is in GitHub Actions — do not
+    feed an untrusted pipeline or trigger input value (a `spec:inputs`
+    value the pipeline/component was invoked with, not a predefined
+    variable like an MR title) into an `inputs:`-driven `$[[ ]]`
+    interpolation that reaches a `script:` line or a `rules:if:`
+    expression without validating/escaping it first.
+
+## GitLab CI protected variables and branches
+
+- A CI/CD variable marked "Protected" is only exposed to pipelines running
+  on a protected branch or a protected tag — an unprotected branch's
+  pipeline (including one from a fork merge request, when forks are
+  allowed) never receives it. Do not rely on a protected variable being
+  present in a job whose `rules:`/`only:`/`except:` allow it to run on a
+  non-protected ref; the value will simply be empty there, not an error.
+- Mark any variable carrying a credential, deploy token, or signing
+  secret both "Protected" and "Masked" and restrict the job that consumes
+  it to protected branches/tags via `rules:` — a deploy job reachable from
+  an unprotected branch or an open merge request should not have access
+  to production credentials at all.
+
+## Anti-patterns to flag
+
+- A `pull_request_target` job that checks out `github.event.pull_request.head.sha`
+  (or `.ref`) and then runs a build/test/lint step against that checkout.
+- Any `uses:` line pinned to a tag (`@v4`, `@main`) instead of a full
+  commit SHA for a third-party action.
+- A workflow-level `permissions: write-all`, or no `permissions:` block at
+  all, on a workflow with jobs that do not all need write access.
+- `${{ github.event.* }}` interpolated directly inside a `run:` string
+  instead of passed through `env:` first.
+- A GitLab CI `script:` unquoted use of a variable holding untrusted input
+  (an MR title, a branch name), or that variable concatenated into a
+  string handed to `eval`/`sh -c`.
+- An untrusted value reaching a GitLab CI/CD `inputs:`-driven `$[[ ]]`
+  interpolation in a `script:` line or a `rules:if:` expression with no
+  validation.

package/src/gdskills/bundled/stacks/ci-github-gitlab/skills/ci-pipeline-build-fix/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: ci-pipeline-build-fix
+description: "Use when a GitHub Actions workflow run or GitLab CI pipeline is failing at the pipeline-configuration level -- YAML syntax errors, an invalid trigger/job key, a missing or misscoped permissions block breaking a step, a job failing because a protected variable is unavailable on its branch, or a broken needs:/rules:/dependency graph -- with the smallest root-cause fix to the config itself. Not for a failure in the application code the pipeline runs (a Python, TypeScript, Go, or other language compile/import/test error -- fix the code, or use that language's own build-fix skill), not for a Dockerfile/Kubernetes/Terraform build or validation failure (use docker-k8s-terraform-build-fix), and not for authoring a new workflow/pipeline from scratch (use ci-pipeline-implementation)."
+triggers:
+  - "this GitHub Actions workflow fails to parse, what's wrong with the YAML"
+  - "our deploy step lost access to a GitLab variable it needs"
+  - "this job says permission denied writing to the PR, fix the workflow"
+  - "the pipeline says invalid needs: reference, fix the job graph"
+  - "GitLab CI says this job's rules: never match, why doesn't it run"
+  - "actions/checkout is failing with an unrecognized input, fix the workflow"
+  - "this step references a repo secret that doesn't exist, the job just fails silently"
+metadata:
+  origin: authored
+  category: build-fix
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# CI pipeline build-fix (GitHub Actions & GitLab CI)
+
+Fix a GitHub Actions workflow or GitLab CI pipeline that is failing at the
+**pipeline-configuration level**: YAML syntax, an invalid or misspelled
+trigger/job key, a `permissions:` scope too narrow for what a step needs,
+a job that cannot see a variable because of GitLab's protected-branch
+scoping, or a broken `needs:`/`rules:`/dependency graph. Scoped to the
+workflow file itself — a failure in the application code the pipeline
+builds or tests belongs to that stack's own `build-fix`/`test` skill, not
+here; do not widen a permissions grant or disable a `rules:` gate just to
+make a run go green without understanding why it was scoped that way.
+
+## Workflow
+
+### Step 1: Read the actual failure, not just the job name
+
+1. Get the exact error from the run log or the platform's own linter
+   (GitHub Actions' "Invalid workflow file" annotation, GitLab's CI Lint
+   page/`gitlab-ci-lint` output) — a config-level failure usually names
+   the exact line and key it choked on.
+2. Classify the failure: YAML syntax (indentation, an unquoted string
+   colliding with a reserved word), an unknown/misspelled key, a
+   `permissions:` scope missing what a step needs (e.g. `Resource not
+   accessible by integration` writing a PR comment), a variable that is
+   `Protected` but the job runs on an unprotected branch, or a `needs:`/
+   `rules:`/dependency reference to a job name that does not exist or
+   never runs on this ref.
+
+### Step 2: Fix the smallest root cause
+
+- **YAML syntax**: fix the actual indentation/quoting/key at the named
+  line; do not restructure unrelated parts of the file.
+- **Missing permission**: grant the specific scope the failing step
+  actually needs at the job level (not a blanket `write-all` at the
+  workflow level) — trace the failing API call back to the
+  [documented scope it requires](https://docs.github.com/en/actions/reference/authentication-in-a-workflow)
+  rather than guessing.
+- **Protected variable unavailable**: either move the job's `rules:` so
+  it only runs on the protected branch/tag the variable is scoped to, or
+  — if the job genuinely must run elsewhere — use a separate,
+  non-protected variable there and keep the protected one for the
+  protected-branch job only. Never unprotect the variable just to make an
+  unprotected-branch job pass.
+- **Broken `needs:`/`rules:`/dependency graph**: fix the job-name
+  reference or the ordering itself; confirm the referenced job actually
+  exists and actually runs on the ref this job runs on (a `needs:`
+  reference to a job whose own `rules:`/`if:` skips it on this ref is a
+  common cause of "job never starts").
+
+### Step 3: Verify
+
+- Re-run the platform's own linter (`actionlint`, GitLab's CI Lint page,
+  or a local `gitlab-ci-lint` run) against the fixed file.
+- Confirm the fix does not widen `permissions:` past what the failing
+  step specifically needs, and does not remove a `rules:`/protected-branch
+  gate instead of routing the job to the right ref.
+- Trigger (or describe how to trigger) the same failing run once more to
+  confirm the specific error is gone.
+
+### Step 4: Report
+
+```
+Fixed: .github/workflows/deploy.yml
+  - permissions.pull-requests was missing "write"; the step posting a PR
+    comment needed it. Added at job level only (not workflow level).
+  - actionlint passes; re-run confirms the comment step now succeeds.
+```
+
+## Rules
+
+- Fix the smallest root cause named by the actual linter/run-log error;
+  do not restructure unrelated jobs or steps while fixing one failure.
+- Never grant a broader `permissions:` scope than the specific failing
+  step needs, and never grant it at the workflow level to fix a
+  single job's failure.
+- Never unprotect a GitLab CI/CD variable, or remove a `rules:`/branch
+  gate protecting it, just to make a job on the wrong branch pass —
+  route the job to the right branch/ref, or use a separate variable
+  there.
+- Never disable or loosen a `rules:`/`if:` condition to make a job "just
+  run" without first understanding why it was scoped the way it was.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll set permissions: write-all, it's faster than figuring out which scope this needs" | That fixes this failure by silently widening every other job in the file too; the actual fix (one scope, one job) costs one extra line and leaves the rest of the file at its intended privilege |
+| "This variable is protected and the job can't see it, I'll just uncheck Protected" | That exposes the credential to every unprotected branch's pipeline, including forks if allowed -- move the job to the protected ref instead, or use a separate non-protected variable for the non-protected case |
+| "The rules: condition is why this job won't run, I'll just delete it" | Deleting the gate makes the job run everywhere the rule was written to exclude, which is usually the actual cause of the failure being investigated in the first place, not the fix for it |
+
+## Verification
+
+Do not report the fix done until all of the following hold:
+
+- The platform's own linter (actionlint / GitLab CI Lint) passes against
+  the fixed file.
+- The specific error named in the original failure is resolved, not
+  worked around by widening scope or disabling a gate.
+- No `permissions:` grant was added beyond what the failing step
+  specifically needs.
+- No `rules:`/protected-variable gate was removed or loosened as part of
+  the fix.

package/src/gdskills/bundled/stacks/ci-github-gitlab/skills/ci-pipeline-build-fix/evals.json

@@ -0,0 +1,73 @@
+{
+  "triggers": {
+    "positive": [
+      "This workflow won't even parse -- GitHub says there's a YAML syntax error",
+      "Our deploy job can't read the API_KEY variable even though it's set in GitLab",
+      "The bot says Resource not accessible by integration when posting a PR comment",
+      "GitLab keeps saying this job's rules never match so it just gets skipped",
+      "actions/checkout is erroring out with an unrecognized input on this job",
+      "This job references another job in needs: that GitHub says doesn't exist"
+    ],
+    "negative": [
+      "The build fails because a Python import is missing, fix the code",
+      "Our TypeScript compile step is failing with a type error, fix it",
+      "The Go binary fails go vet, please fix the source",
+      "This Dockerfile fails to build because of a missing apt package",
+      "Write a new workflow that lints our code on every push",
+      "Review this workflow for security issues before we merge it"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "permission-scope-fix",
+      "prompt": "This job fails with 'Resource not accessible by integration' when it tries to comment on the pull request. The workflow currently has no permissions: block. How do I fix it?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer identifies the missing pull-requests: write scope as the root cause of the 'Resource not accessible by integration' failure, fixes it by adding that specific scope (plus contents: read if the job checks out code) scoped no wider than the failing job needs -- at the job level when the workflow has other jobs that should not get it, or at the workflow level only if this is the workflow's only job -- and confirms the fix does not widen access beyond what the failing comment step needs (no workflow-level write-all, no unscoped grant reaching jobs that do not need it).",
+          "pass_criteria": [
+            "Identifies the missing permissions: pull-requests: write scope as the root cause of the 'Resource not accessible by integration' failure.",
+            "Scopes the grant to only what this job needs (pull-requests: write, plus contents: read if the job also checks out code) rather than a broad or unscoped grant -- placing it at the job level is the clearly correct choice when the workflow has other jobs that do not need it, and is an acceptable choice (not a requirement to fail on) when this is the workflow's only job.",
+            "States or confirms that the fix does not widen scope beyond what the failing comment step specifically needs."
+          ],
+          "fail_criteria": [
+            "Recommends permissions: write-all (or another broad, unscoped grant, at either the workflow or job level) as the fix instead of the specific pull-requests: write (+ contents: read if needed) scope. Mentioning write-all only to warn against it is not a failure."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "The root cause is that the workflow has no permissions: block at all, so the default GITHUB_TOKEN scope doesn't include write access to pull requests, and the comment step fails with 'Resource not accessible by integration'. Fix: add `permissions: { contents: read, pull-requests: write }` directly on this job (not at the workflow level, so the rest of the file stays at its current, narrower scope) -- contents: read is included because setting any explicit permissions: block resets every unlisted scope to none, and this job still needs to check out the repo. That grants exactly the access the comment step needs and nothing more. Re-run the job after adding it to confirm the comment now posts successfully.",
+        "known_wrong": "Simplest fix here is to add `permissions: write-all` at the top of the workflow -- that guarantees this job (and anything else added later) has whatever access it needs without having to track down the exact scope each time.",
+        "vague": "You'll need to add the right permissions so the comment step can post.",
+        "subtle_wrong": "Add `permissions: { contents: write, pull-requests: write, issues: write }` at the workflow level -- that covers the comment step and leaves room for other jobs that might need similar write access later, so nobody has to keep revisiting the permissions block every time a new job needs something."
+      },
+      "anti_patterns": ["write-all"]
+    },
+    {
+      "id": "protected-variable-fix",
+      "prompt": "The deploy job can't see DEPLOY_TOKEN even though it's defined in GitLab CI/CD variables and marked Protected. The pipeline runs on a feature branch, which is not a protected branch. How do I fix this?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer identifies that DEPLOY_TOKEN being unavailable is because it is marked Protected and the pipeline is running on an unprotected feature branch, and fixes it by restricting the deploy job's rules: to the protected branch/tag (or by introducing a separate non-protected variable for the feature-branch case) rather than by unprotecting DEPLOY_TOKEN.",
+          "pass_criteria": [
+            "Identifies that DEPLOY_TOKEN is unavailable because it is a Protected variable and the pipeline is running on an unprotected feature branch, not because the variable is misconfigured or missing.",
+            "Recommends restricting the deploy job (via rules:) to run only on the protected branch/tag DEPLOY_TOKEN is exposed to, or introducing a separate non-protected variable for the feature-branch case.",
+            "Does not recommend removing Protected status from DEPLOY_TOKEN as part of the fix."
+          ],
+          "fail_criteria": [
+            "Recommends unprotecting or removing Protected status from DEPLOY_TOKEN so it becomes available on the feature branch. Mentioning that this is what not to do is not a failure."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "DEPLOY_TOKEN is marked Protected in GitLab, which means it's only exposed to pipelines running on a protected branch or tag -- a feature branch pipeline simply never receives it, which is why it reads as empty/missing rather than erroring loudly. Fix: restrict this deploy job's rules: so it only runs on the protected branch (or tag) that DEPLOY_TOKEN is actually scoped to, rather than on every feature branch. If the deploy job genuinely needs to run from feature branches too (e.g. for a staging deploy), use a separate, non-protected variable for that case instead of exposing the production DEPLOY_TOKEN there.",
+        "known_wrong": "Easiest fix is to open the variable settings in GitLab and uncheck 'Protected' on DEPLOY_TOKEN -- then it'll be available to every branch's pipeline, including this feature branch, with no other changes needed.",
+        "vague": "You probably just need to adjust the variable settings so the deploy job can see it.",
+        "subtle_wrong": "Since the feature branch needs the token right now for testing, go ahead and unprotect DEPLOY_TOKEN temporarily -- you can always re-protect it later once the feature branch work is done and merged."
+      }
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/ci-github-gitlab/skills/ci-pipeline-code-review/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: ci-pipeline-code-review
+description: "Use when reviewing a GitHub Actions workflow (.github/workflows/*.yml) or GitLab CI pipeline (.gitlab-ci.yml) change for security and structural risk -- pull_request_target combined with untrusted checkout, tag-pinned third-party actions, missing least-privilege permissions, script injection via unsanitized event/variable interpolation, and unprotected access to deploy secrets. Read-only, no edits."
+triggers:
+  - "review this GitHub Actions workflow diff for security issues"
+  - "check this .gitlab-ci.yml change for exposed secrets"
+  - "does this workflow have a script injection risk?"
+  - "review this pull_request_target job for pwn request risk"
+  - "check whether these third-party actions are pinned safely"
+  - "review this deploy job for least-privilege permissions"
+metadata:
+  origin: authored
+  category: review
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# CI pipeline security review (GitHub Actions & GitLab CI)
+
+Review a GitHub Actions workflow or GitLab CI pipeline change for the
+specific risks `rules/security.mdc` catalogs: `pull_request_target`
+combined with untrusted checkout, mutable-tag action pinning, missing
+least-privilege `permissions:`, script injection via unsanitized
+`${{ github.event.* }}`/CI-variable interpolation, and unprotected access
+to deploy secrets. **This skill is strictly read-only** — it reports
+findings and a fix direction, and never edits, patches, or claims to have
+applied even a partial or proof-of-concept change to the workflow file
+under review; a change belongs to `ci-pipeline-implementation`, not here.
+
+## Workflow
+
+### Step 1: Scope the diff
+
+1. Read the full diff of every changed `.github/workflows/*.yml` or
+   `.gitlab-ci.yml` file, not just the added lines — a security-relevant
+   line (a `permissions:` block, a `uses:` pin) removed or weakened is as
+   much a finding as one added.
+2. Note the trigger(s) each changed/added job runs under
+   (`pull_request`, `pull_request_target`, `push`, `workflow_dispatch`,
+   GitLab's `rules:`/pipeline source) — the trigger determines which
+   findings below even apply.
+
+### Step 2: Check each risk category
+
+- **`pull_request_target` + untrusted checkout.** Does any
+  `pull_request_target`-triggered job check out the contributor's own fork
+  ref or head commit SHA (via the pull request event's own `head` field)
+  and then run a build/test/lint step against that checkout?
+  That combination is the "pwn request" pattern — flag it regardless of
+  how innocuous the executed step looks, since the risk is the
+  combination, not any one line.
+- **Action pinning.** Does every third-party `uses:` line (anything
+  outside the repository's own `.github/actions/`) reference a full
+  commit SHA rather than a tag (`@v4`) or branch name? A tag comment next
+  to a SHA is fine; a bare tag as the actual pin is not.
+- **`permissions:` scope.** Is there a workflow-level `permissions:
+  write-all`, or no `permissions:` key at all on a workflow whose jobs do
+  not all need write access? Is `id-token: write` granted only to the job
+  that actually performs OIDC federation?
+- **Script injection.** For GitHub Actions: does any `run:` step
+  interpolate `${{ github.event.* }}` (a PR title, issue body, branch
+  name, commit message) directly into the shell string, instead of
+  routing it through an intermediate `env:` entry first? For GitLab CI:
+  does a `script:` line use an untrusted variable (an MR title, a branch
+  name) unquoted, or concatenate it into a string handed to `eval`/
+  `sh -c` — routing it through another `variables:` entry does not fix
+  this, since every GitLab CI/CD variable is already a shell environment
+  variable by the time `script:` runs; also check any `$[[ inputs.* ]]`
+  interpolation for untrusted input, since that IS substituted before the
+  job is created.
+- **GitLab protected variables/branches.** Does a deploy job that
+  consumes a credential-bearing variable have `rules:` restricting it to
+  the protected branch/tag that variable is actually exposed to, and is
+  that variable itself marked Protected and Masked?
+
+### Step 3: Report findings
+
+For each finding: name the exact line/job, state which risk category it
+falls under, explain the concrete consequence (not just "this is
+insecure"), and give a fix direction from `rules/security.mdc` — never
+apply the fix yourself.
+
+```
+Findings in .github/workflows/pr-review.yml:
+  - Job "test" (line 12): triggered by pull_request_target, this job
+    checks out the fork's own head SHA and then runs `make test` against
+    it -- pwn-request pattern. Fix direction: switch to `pull_request`, or split
+    into an unprivileged build job + a separate privileged job that only
+    consumes safe artifacts.
+  - Job "test" (line 18): actions/checkout@v4 -- pinned to a mutable tag.
+    Fix direction: pin to actions/checkout's full commit SHA.
+No other findings.
+```
+
+## Rules
+
+- Read-only: report findings and fix direction, never edit the workflow
+  file or claim a fix was applied, even partially or as a proof of
+  concept.
+- Flag `pull_request_target` + untrusted-checkout-and-execute as a
+  finding every time it appears, regardless of how trivial the executed
+  step looks.
+- Flag any third-party action pinned to a tag rather than a full commit
+  SHA.
+- Flag a workflow-level `permissions: write-all` (or no `permissions:` at
+  all) alongside jobs that do not all need write access.
+- Flag `${{ github.event.* }}` interpolated directly into a `run:` string
+  instead of passed through `env:` first (GitHub Actions). Flag a GitLab
+  CI `script:` line that uses an untrusted variable unquoted or
+  concatenates it into `eval`/`sh -c` (routing it through another
+  `variables:` entry does not fix this), or an untrusted pipeline/trigger
+  input reaching a `$[[ inputs.* ]]` interpolation unvalidated.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "This is just a docs/CI change, security review doesn't apply" | A CI workflow change is exactly the surface this skill exists for -- a workflow file itself grants access to secrets and write scope, independent of what other code changed in the same PR |
+| "The tag is from the official actions/ org, it's fine to leave unpinned" | The pinning risk is about the tag being movable, not about who currently controls it -- a first-party org account can still be compromised, and the fix costs nothing |
+| "I noticed the fix while reviewing so I went ahead and applied it" | This skill is read-only; report the finding and fix direction, and let the implementation skill or the author apply it |
+
+## Verification
+
+Do not report the review done until all of the following hold:
+
+- Every changed job's trigger was checked against the
+  `pull_request_target` + untrusted-checkout pattern.
+- Every third-party `uses:` line in the diff was checked for tag vs.
+  commit-SHA pinning.
+- The `permissions:` block (workflow- and job-level) was checked for
+  least privilege.
+- Every `run:` step touching `${{ github.event.* }}` was checked for
+  direct interpolation vs. intermediate `env:` (GitHub Actions), and every
+  GitLab CI `script:` step touching an untrusted variable was checked for
+  unquoted use, `eval`/`sh -c` concatenation, or an unvalidated
+  `$[[ inputs.* ]]` interpolation.
+- No finding was silently skipped because the surrounding change looked
+  unrelated to security.