skills

Render a friendly greeting banner for a named person into a GREETING.txt file. Use when asked to greet someone, write a welcome banner, or produce a personalized hello message saved to a file.

Commit changes the way a sandboxed agent must — write Conventional Commit messages and, because commit signing fails inside the sandbox, hand the real commit off through a generated commit.sh script. Inside a git worktree, commit normally (unsigned) and emit a commit.sh that re-signs the range; in the main checkout, do not commit at all — emit a commit.sh containing the exact git add and git commit invocations for the user to run. Use when committing changes, creating a git commit, staging and committing work, writing or formatting a commit message, splitting changes into separate commits, or when an agent or sandbox cannot sign commits and must hand the commit off to the user. Not for pushing, opening or merging pull requests, rebasing or amending existing history, tagging releases, or non-git version control.

Triage a GitHub code-scanning (CodeQL) finding and produce an immutable Markdown triage report plus an index row, recommending remediation or dismissal, with a permalink pinned to the finding's commit SHA for every code reference so the report stays valid after the code moves. Use when triaging, dismissing, or remediating a code-scanning or CodeQL alert or finding; writing a security finding report; recording why an alert is a false positive or how it was fixed; or maintaining security/code-scanning/index.md and the SECURITY.md triage reference. Takes a finding number or finding URL, fetches details with the gh CLI, assumes the current repository when only a number is given, and refuses findings that do not exist or are already closed. Not for Dependabot or dependency alerts, secret-scanning alerts, runtime incident response, or writing a threat model.

Write the evolve evaluation suite for an agent skill: its triggers (triggers.json — Tier 1 activation tests) and behavioral evals (evals.json — Tier 2 task tests), under evals/<skill>/. Use when asked to generate, write, author, scaffold, or balance an eval suite, evals, or triggers for a skill; to create or edit a triggers.json or evals.json; to add behavioral evals to a SKILL.md; to add or rebalance positive and near-miss negative trigger cases; or to measure or evaluate whether a skill activates and fires on the right prompts and does its job. Follows the evolve evaluations guide and the JSON Schemas it links, fetched at author time so it tracks new assertion types and fields. Prefers deterministic assertions (file_exists, regex, command, tool_call) over the LLM judge. Not for running or sweeping existing suites, writing application unit tests, or comparing model quality.

Go documentation conventions — a doc comment on every exported function, struct, type, and package, package comments in a dedicated doc.go for multi-file packages, godoc style (complete sentences beginning with the identifier's name), and LLM-ready CLI reference generation for cobra tools via a docgen helper built on cobra/doc. Use when writing or reviewing doc comments or godoc in Go code, adding a doc.go or writing a package comment for a Go package, documenting an exported Go API, package, function, or struct, deciding where a package comment or doc.go belongs, or generating markdown CLI documentation for a cobra-based Go tool. Not for OpenAPI/REST API specs.

Scaffold a Go project with the canonical layout — cmd/ entrypoints with a thin main, private packages under internal/ (no pkg/), a separate tools module pinning Go developer CLIs (invoked directly via go tool -modfile=tools/go.mod, no GOBIN), Node tools pinned in package.json and run from node_modules/.bin, and a Makefile whose pr target runs the full local gate. Use when creating a new Go project, service, or repository, or restructuring an existing Go repo to the standard layout; pinning Go or Node developer tooling or adding a tools module to an existing repo; creating or adding a Makefile with the standard targets (pr, fmt, vet, test, fuzz, build); or deciding where Go code should live (internal vs pkg).

Release engineering for Go projects — GoReleaser v2 with version ldflags into an internal/version package, SBOMs and multi-arch container images, tag-triggered GitHub Actions releases, CI running build/vet/test -race/govulncheck with SHA-pinned actions, and Dependabot coverage for gomod, tools, npm, and Actions. Use when adding GitHub Actions CI for a Go repository; writing a release workflow that publishes Go binaries, SBOMs, and multi-arch container images; setting up GoReleaser for a Go project; stamping version metadata into a Go binary at build time; or adding Dependabot coverage to a Go repo. Not for scaffolding a new Go project or its Makefile.

Modern Go code style for stdlib-first programs — error wrapping with %w, sentinel errors, structured logging with log/slog, context threading, consumer-defined interfaces, nil-safe constructors, net/http servers with method-pattern routing, flag/env configuration for services, and cobra commands with viper configuration for CLI tools. Use when writing, reviewing, or refactoring any Go code (.go files, packages, services, CLIs): handling or wrapping errors in Go, adding structured logging to a Go program, threading context, shaping interfaces or constructors, adding a net/http handler, endpoint, or route, configuring flags and env vars, or building a Go CLI tool or subcommand with cobra and viper. For Go only — not other languages.

Use when writing, reviewing, or running Go tests in _test.go files — writing tests for a Go package, adding table-driven tests with t.Run subtests, testing a Go HTTP handler with httptest, adding a Go fuzz test or seed corpus, running or choosing go test flags (-race, -fuzz, -fuzztime), or deciding whether to use testify. Covers Go testing conventions: table-driven tests, plain stdlib assertions (no testify or assertion frameworks), hand-written fakes behind small interfaces, t.Helper() helpers, httptest for handlers, and native fuzz targets (testing.F) with seed corpora.

Python documentation conventions — a Google-style docstring on every public module, class, and function, enforced by ruff's pydocstyle (D) rules with the google convention, and LLM-ready markdown CLI reference generation for Click or Typer tools via a reproducible docgen helper. Use when writing or reviewing docstrings, choosing or enforcing a docstring style, configuring ruff's D rules, deciding where module or package docstrings belong, or generating markdown CLI documentation for a Click/Typer-based Python tool.

Scaffold and modernize a Python project with uv. Sets up the src/ layout; a pyproject.toml on uv's native uv_build backend; runtime deps plus a dev dependency group (PEP 735) pinning developer tooling like ruff, ty (or pyright), and pytest; a committed uv.lock and pinned interpreter; a thin __main__ entry point; and a Makefile whose pr target runs the full local gate. Use when: creating a new Python project, package, library, or CLI with uv; creating or configuring a pyproject.toml; choosing a build backend (uv_build) or dependency layout; restructuring an existing repo to the src/ layout; migrating from pip/requirements.txt, poetry, or pipenv onto uv; setting up a dev dependency group or pinning Python dev tools (ruff, ty or pyright, pytest); or adding Makefile targets (pr, fmt, lint, typecheck, test, build) to a Python codebase. Not for writing functions, type hints, tests, or publishing to PyPI — those are separate Python skills.

Release engineering for Python projects on uv — static versioning in pyproject.toml exposed via importlib.metadata, building the sdist and wheel with uv build, publishing to PyPI with uv publish via Trusted Publishing (OIDC, no token), tag-triggered GitHub Actions releases, CI running ruff/ty (or pyright)/pytest with SHA-pinned actions, and Dependabot coverage for uv and Actions. Use when releasing or publishing a Python package to PyPI, running uv build to make a wheel and sdist, running uv publish, configuring Trusted Publishing or a tag-triggered release workflow, writing a GitHub Actions CI workflow that runs ruff format/ruff check/ty (or pyright)/pytest for a uv project, versioning a package, or adding Dependabot coverage for uv and GitHub Actions to a Python repo.

Modern Python house style: ruff is the single formatter and linter (replacing black, isort, flake8, pylint, pyupgrade) with an opinionated lint select set, plus idioms ruff cannot enforce — pathlib over os.path, module-level logging instead of print, specific chained exceptions, dataclasses for data, comprehensions and context managers. Use when formatting, linting, reviewing, or refactoring Python code or improving its idiomatic style; setting up, configuring, or running ruff (in pyproject.toml or replacing black/isort/flake8/pylint), or choosing which ruff lint rules to enable; converting print to logging, fixing exception handling, choosing pathlib vs os.path, or otherwise shaping errors, logging, file I/O, or data structures in Python. Not for type annotations, docstrings, tests, project/uv scaffolding, or non-Python languages.

Python test authoring and review with pytest. Use when writing, adding, generating, or reviewing Python tests or unit tests for a function, module, or class; running pytest or a single test (the -k flag and other invocation flags for a Makefile or CI); parametrizing test cases into the table-driven pattern; setting up pytest fixtures or using the built-in tmp_path, monkeypatch, or capsys; choosing between hand-written fakes and mock objects; asserting a function raises with pytest.raises; or adding property-based or fuzz tests to a Python parser, encoder, or validator with Hypothesis. Covers pytest conventions, fixtures, parametrization, fakes vs mocks, error-path testing, and Hypothesis property testing. Not for non-Python test frameworks (Jest, Go testing), type hints, ruff/linting, or scaffolding a project.

Python static typing and type annotations, checked with a static type checker — ty (Astral) or pyright (Microsoft/Pylance). Use when adding, writing, or reviewing type hints or annotations on Python functions, methods, parameters, or return values; adding return type annotations across a module; fixing or resolving Python type errors; making a function or class generic with a type parameter; modernizing hints to X | None instead of Optional, A | B instead of Union, and built-in list[]/dict[] generics; choosing between Protocol and ABC for an interface or using typing.Self and PEP 695 syntax; or setting up, configuring, or running ty or pyright under [tool.ty] or [tool.pyright] in pyproject.toml, migrating from mypy, and wiring a type-check step into the dev gate or CI. For Python code only — not TypeScript, Go, or other languages, not runtime isinstance checks, formatting, or test-writing.

Wire a repository to the bitwise-media-group/github-workflows reusable workflows — thin caller workflows for CI, CodeQL, release (release-please/GoReleaser), and the signature-preserving fast-forward /merge, merge-notice, and Dependabot auto-merge flows — plus the Makefile consumer contract, @v2 pinning, and FF Merge org setup. Use when setting up CI, CodeQL, releases, or auto-merge for a repo, adding a caller that uses the shared/reusable workflows, scaffolding a repo's .github/ with the org's standard automation, or asked which reusable workflow to call and what to grant it.

Security hardening for GitHub Actions workflows with a least-privilege posture — default-deny permissions ({} then minimal per-job scopes), SHA-pinning every third-party action, avoiding pull_request_target (and the safe trusted-event allowlist pattern when an elevated trigger is unavoidable), preventing expression/script injection via env indirection, explicit secrets (no inherit), and OIDC over long-lived keys. Use when writing or reviewing GitHub Actions workflows for security, locking down permissions or GITHUB_TOKEN, deciding whether pull_request_target is safe, handling untrusted PR input or secrets, or pinning actions.

GitHub Actions workflow authoring conventions for readable, least-privilege workflows — .github/workflows/*.yaml layout, explicit scoped triggers, boolean logic with truthy/falsey expressions (if ${{ inputs.flag }} over == 'true'), concurrency, matrix builds, job outputs, and authoring reusable (workflow_call) and composite actions. Use when writing, reviewing, or refactoring GitHub Actions workflows or composite actions (.github/workflows/*.yaml, action.yml), adding a job, matrix, or if-condition, or deciding how to structure triggers, inputs, and expressions.

Validate GitHub Actions workflow files locally with the actionlint then zizmor loop — actionlint for syntax, expression typing, and shellcheck of run steps; zizmor for security audits (expression injection, pull_request_target risks, unpinned actions, over-broad permissions). Use after editing any .github/workflows/*.yaml or action.yml, before committing workflow changes, when asked to lint, validate, or security-audit GitHub Actions workflows, when a workflow fails in CI, or when setting up actionlint/zizmor for a repository.

Scaffold a new Terraform module with the canonical file layout — terraform.tf, main.tf, variables.tf, outputs.tf, README.md — and house style. Use when creating a new Terraform module, adding a module under a modules/ directory, or restructuring an existing module to the standard layout.

Terraform/HCL style conventions for writing readable, reusable modules — collection types, resource naming, name_prefix, for_each toggles, variable and output grouping, null defaults, and canonical file layout. Use when writing, reviewing, or refactoring Terraform code (.tf files, modules, root configurations), or when deciding how to name resources, structure variables, or shape module outputs.

Format and validate Terraform code with the fmt / init / validate / tflint loop. Use after editing any .tf file, before committing Terraform changes, when asked to lint, format, validate, or check Terraform modules and root configurations, or when setting up tflint for a repository.