jwt-toolkit

Scaffold a new top-level Click subcommand for jwt-toolkit (the `jwt-toolkit <verb>` form, like `decode`, `audit`, `verify`). Creates `jwt_toolkit/commands/<name>.py`, registers it in `jwt_toolkit/cli/__init__.py` (import + `add_command` + aligned `CLI_HELP` entry), and writes a matching `tests/test_cmd_<name>.py`. Enforces the project's CLI conventions: `console`-only output, secrets as options not positional args, typed `core/errors` raised and translated, `--json` payloads carrying `JSON_SCHEMA_VERSION`. Use this skill only for **new top-level verbs**. Don't use it for adding flags or behavior to an existing command, for creating subcommands under an existing group, or for refactors — edit the existing file directly.

Cut a new jwt-toolkit release end-to-end — preflight (clean main, CI green, local `make check`, artifact build + twine check), semver guidance derived from the diff since the last tag, version bump in `pyproject.toml`, signed annotated tag, push, GitHub Release that triggers `publish.yml` (PyPI Trusted Publishing with `pypi` environment manual approval), and post-publish verification on PyPI's JSON API and a clean-env `uvx` install. Use only when the user explicitly asks to release, cut, ship, bump version, tag a release, or push to PyPI. Never infer a release from "wrap up" or "we're done".

Domain-aware security review of the current diff for jwt-toolkit. Goes beyond bandit/ruff — catches JWT-specific regressions (alg=none acceptance, algorithm confusion, non-constant-time signature/MAC comparison, JWKS SSRF), secret leakage in errors and output, public-API breaks (`JSON_SCHEMA_VERSION` and `core/errors.py` codes), layering violations (Click/Rich/network in `core/`), wordlist DoS shapes, and runtime dependency drift. Use this skill proactively whenever the user asks "is this safe to merge", "did I introduce a security regression", "review the diff", "check for secret leaks", before opening a PR that touches `jwt_toolkit/` source, or after finishing changes to `core/`, `commands/`, `crypto`, `auditor`, `forge`, `jwks`, error handling, or anything affecting `--json` output. Skip if the diff is pure documentation, `.claude/`, or other meta changes with no source touched.

Create a Conventional Commits-style commit for jwt-toolkit. Inspects the staged/unstaged diff, drafts a `type(scope): subject` message in the repo's voice, gates source-code changes on `make check`, and commits via a HEREDOC so the message format is preserved. Use when the user asks to commit, save, or check in work — never proactively, only on explicit request.

Open a GitHub pull request for jwt-toolkit. Verifies branch naming, runs `make check`, suggests `/security-review` when source/diff warrants it, drafts the PR body against the repo's `.github/PULL_REQUEST_TEMPLATE.md` (Summary, Type, Related issues, Changes, How to test, Checklist), and creates the PR with `gh pr create`. Use only when the user asks to open a PR.

Run the full CI gate (`make check` — lint + typecheck + test + security + audit) and report per-stage pass/fail with triage. Use before declaring non-trivial work done, before pushing, before opening a PR, or whenever the user asks "is this ready?".