citypaul
- 48 skills
- 0 followers
- 1 week ago last updated
- ▌ Stack Pull Requests · citypaul bundleDecide whether planned vertical implementation work should ship as independent pull requests or as a stack of small ordered pull requests, then plan, build, review, update, and merge the stack safely. Use when one slice is too large for effective review, when later slices should proceed on the same evolving baseline before earlier pull requests merge, when AI-generated code volume needs deliberate review boundaries, when a plan already defines dependent pull request boundaries or non-trunk bases, or when the user mentions stacked PRs, PR stacks, dependent PRs, gh-stack, bottom-up review, or splitting an implementation across branches. Do not use this skill to split epics or invent horizontal backlog stories; use story-splitting first.
- ▌ Ubiquitous Language · citypaul bundleOne ubiquitous language per bounded context, with a repository-declared glossary as the naming authority and explicit decisions for language changes. Covers the five-step language protocol (detect, propose, decide, record, rename), optional glossary-driven lint ratchets, and safe context-wide renames. Use when naming domain concepts, when a term is missing from or fights the glossary, when spotting synonyms or near-duplicates, when bootstrapping a glossary, or when renaming across a bounded context. For DDD building blocks see domain-driven-design; for acceptance-DSL vocabulary use the project's relevant installed skill.
- ▌ Domain Driven Design · citypaul bundleDomain-Driven Design patterns for TypeScript. Use when implementing ubiquitous language, value objects, entities, aggregates, domain events, domain services, or bounded contexts. Only applies to projects that explicitly use DDD. Do NOT use for simple CRUD or projects without domain modeling.
- ▌ Test Design Reviewer · citypaul bundleReview test quality using Dave Farley's eight properties of good tests. Use when assessing a test file or suite for understandability, maintainability, repeatability, atomicity, necessity, granularity, speed, and evidence of test-first development.
- ▌ Hexagonal Architecture · citypaul bundleUse when the user or project explicitly adopts hexagonal (ports and adapters) architecture — a README, CLAUDE.md, or ADR that says so is the opt-in. Once a project has opted in, load this for every code change in it, not only architecture work — a new feature, a transport or SDK swap, a bug fix, or a small business-rule change to a function that still calls an SDK directly; load it alongside tdd, never instead of it, and follow its Before You Write Code section before editing. Implements TypeScript ports, driving/driven adapters, dependency inversion, and domain isolation. Do NOT infer hexagonal architecture from a generic adapter, interface, test seam, or isolation request in a project that has not opted in.
- ▌ Reduce System Complexity · citypaul bundleReduce total mechanism in a selected existing system or behavior path while conserving its agreed observable behavior and non-functional guarantees. Use when the user explicitly wants fewer branches, states, dependencies, layers, flags, retries, jobs, adapters, or operational moving parts and needs evidence that complexity was removed rather than relocated. Supports read-only diagnosis and authorized reduction slices. Not for routine cleanup, architecture-investment discovery, module-contract design, physical tree design, new behavior, functionality cuts, speculative rewrites, or Redux/functional reducer functions.
- ▌ Evaluate Existing Solutions · citypaul bundleResearch and compare established libraries, open-source tools and applications, managed services, and standard, framework, or platform primitives against an explicit bespoke baseline before committing to a material generic mechanism. Use for library/tool recommendations, build-versus-adopt questions, custom-mechanism replacement, consequential unresolved dependencies, or due diligence on a named but newly introduced material dependency. Produces an evidence-backed adopt, adapt, combine, build, defer, or do-nothing proposal. For repository-wide opportunity discovery use improve-codebase-architecture first and evaluate only the selected job. Not for agent-skill discovery, constraints still needing specification, trivial logic/glue, routine use of an adopted tool, or ordinary fixes.
- ▌ Improve Codebase Architecture · citypaul bundleAudit an existing repository or multi-module subsystem for evidence-backed architecture improvements, rank bounded candidates, and present them in a visual HTML report with before-and-after diagrams and a top recommendation. Use when the user asks where architecture investment would pay off across a codebase, wants multiple architecture candidates ranked, or needs systemic coupling, shotgun-change, testability, or AI-navigability problems diagnosed. For one named module's responsibility, deepening, splitting, or contract use codebase-design; for a source-tree or package audit use structure-codebase; for an already-selected path whose success is an evidence-backed net-mechanism-reduction claim use reduce-system-complexity. This is audit-and-selection by default.
- ▌ Production Parity Skill Builder · citypaul bundleCreate an application-specific production parity skill by inspecting an app's docs, source, tests, CI, deployment, infrastructure, config, auth, and environment setup, then asking targeted harness questions only for source-unanswerable decisions. Use when local, CI, PR, preview, staging, or other non-production environments may drift from production behavior; when production-only auth, config, identity-provider groups, feature flags, infrastructure, backing services, or policy differences caused bugs; or when a team wants a reusable skill that detects, documents, tests, and helps fix parity drift for one specific application.
- ▌ Codebase Design · citypaul bundleDesign and evaluate deep modules: cohesive responsibility behind a small, stable caller-facing contract, with information hiding, justified seams, explicit effects, dependency strategy, and behavior-focused tests. Use when designing or changing an in-process module or package contract, consolidating shallow pass-through modules, deciding what to hide, comparing alternative interfaces, or asking whether code should be combined or split for leverage and locality. For physical layout use structure-codebase; for public compatibility use api-design; for a repository-wide scan use improve-codebase-architecture. For an already-selected whole-path requirement to support a calibrated net-mechanism-reduction claim, use reduce-system-complexity.
- ▌ Story Splitting · citypaul bundleTurn broad requirements, large stories, epics, features, initiatives, or backlog items into small end-to-end child stories without turning them into technical component tasks. Use when refining a backlog, decomposing epics, planning an MVP or walking skeleton, looking for vertical slices, reducing story size, applying SPIDR/Hamburger/capability slicing, avoiding scatter-gather/component stories, or deciding the first valuable story before implementation planning.
- ▌ Bff Entry Points · citypaul bundleDesign and protect browser-facing BFF and backend HTTP entry points: an explicit public/protected access classification for every production route, a composition-prepared endpoint registrar that installs session, Origin, Fetch Metadata, CSRF, and content-type policy by construction, provider-free authorization inside the application, protected SSE and WebSocket registration, browser session coordination, and automated enforcement gates. Use when adding or reviewing HTTP endpoints, when a tenant or customer can see another's data through a route or any authorization bug is reported on an endpoint, authentication middleware, session cookies, CSRF or Origin policy, realtime streams, login/logout flows, or auditing which routes are public. For whether to adopt a BFF, granularity, aggregation, and upstream identity mediation use bff-design; for physical BFF route layout use structure-codebase; for REST semantics, pagination, and versioning use api-design; for OAuth/OIDC protocol flows use secure-oauth-oidc; for po
- ▌ Folder Structure · citypaul bundleDeprecated compatibility alias for structure-codebase. Activate only for the exact legacy name folder-structure or an explicit $folder-structure invocation. Contains no independent architecture guidance and must delegate to the canonical sibling skill.
- ▌ Acceptance Review · citypaul bundleWHEN deciding whether a PR, branch, diff, or current implementation satisfies an authoritative issue, specification, or decision contract; NOT for improving the written artifact, reconstructing meetings, general code review, or implementing fixes. Returns a read-only criterion-by-criterion proof and acceptance verdict.
- ▌ Front End Testing · citypaul bundleBehavior-driven UI testing patterns across Vitest Browser Mode, Playwright E2E evidence boundaries, and DOM Testing Library. Use when testing any front-end application, writing UI or end-to-end tests, querying DOM elements, simulating user interactions, or choosing the lightest harness that proves a browser-observable claim. For React-specific patterns, see the react-testing skill.
- ▌ Graph Engineering · citypaul bundleCompose installed agent skills into one orchestrated multi-agent run: an agent graph where each node is a sub-agent that loads exactly one skill, edges carry structured data, and stages fan work out, adversarially verify it, and synthesize one deliverable. Claude Code calls the executable form a dynamic workflow; the pattern is Anthropic's orchestrator-workers. Use when a task needs several skills applied in parallel (multi-lens review, multi-angle audit or research, migration sweeps), when the user says graph engineering, agent graph, fan out sub-agents, or orchestrate skills, or when designing any workflow where sub-agents each own one skill. For PR review specifically use panel-review (an instance of this skill); for a single second opinion on finished work use double-check; do not use for tasks one skill handles in one context.
- ▌ React Performance · citypaul bundleMake React and Next.js performance changes that are measured, evidence-backed, and behaviorally safe. Routes to the right rule catalogue — vercel-react-best-practices for the 72 prioritized React/Next rules, vercel-composition-patterns for component API shape, next-best-practices for App Router semantics, core-web-vitals and performance for field metrics and non-React budgets — then governs how a rule is applied here: baseline first, one hypothesis at a time, behavior tests unchanged and green, and the house functional and typing rules winning where a micro-optimization would trade them away. Use when React or Next.js feels slow — a search box or list that stutters or lags while typing, a page that burns CPU while it sits open, a sluggish dashboard, jank on scroll, a screen that takes too long to appear — when a bundle, waterfall, re-render, or hydration problem is suspected, when reviewing a diff for performance, or when a performance rule appears to conflict with immutability, TDD, or type-safety guidance.
- ▌ Render Code Shape · citypaul bundleRender the shape of code — module boundaries, the types that cross them, signatures, and a cited call graph — for code that already exists or a change about to be built. Every name, type, and path is read from source and cited, or marked NEW; bodies collapse to one line of intent. Use when asking how something composes, tracing what a request actually touches, pseudocoding a change before implementing it, onboarding to an unfamiliar path, or producing the shape a plan and its tests will be checked against. Read-only: the render is the deliverable, never the edit. For judgments about whether the shape is good see codebase-design; for where files should live see structure-codebase; for a rendered picture see diagrams; for fault localization see debugging.
- ▌ Secure OAUTH Oidc · citypaul bundleDesign, implement, audit, test, troubleshoot, or migrate secure OAuth 2.0 and OpenID Connect (OIDC) systems using RFC 9700 / BCP 240. Use for authorization servers and OpenID Providers, OAuth clients and OIDC relying parties, resource servers, native apps, browser-based apps, multi-issuer login, redirect URIs, authorization code and PKCE flows, state and nonce handling, ID Token validation, token storage and replay, refresh-token rotation, sender-constrained tokens (DPoP or mTLS), mix-up and injection attacks, discovery and metadata, reverse proxies, or migration away from implicit and resource-owner-password grants.
- ▌ Technical Writing · citypaul bundleWriting developer-facing prose that can be skimmed first and trusted enough to finish — READMEs, guides, tutorials, reference docs, proposals, PR descriptions, release notes. Load before drafting, rewriting, restructuring, or editing any technical document, including a request to rewrite or improve a README, when a doc reads as a wall of text, when claims need receipts, or when docs must serve AI agents as well as humans. Covers reader-first structure, falsifiable claims, docs-as-behavior verification, and agent-readable reference shape. For deciding where a learning, gotcha, or decision should be recorded see expectations; for diagram choice and syntax see diagrams; for API reference semantics see api-design; for CLI help text see cli-design.
- ▌ Typescript Strict · citypaulTypeScript strict mode patterns including schema-first development, branded types, type vs interface guidance, and tsconfig strict flags. Use when writing TypeScript code, defining types or schemas, or reviewing type safety. For immutability and pure function patterns, see the functional skill.
- ▌ Structure Codebase · citypaul bundleDesign, audit, and evolve physical source and package structures that expose real architectural boundaries while keeping related behavior together. Use when creating or reviewing repository trees, deciding where files or packages belong, reducing flat folders, organizing by feature, route, screen, use case, bounded context, workflow or endpoint, structuring frontend state/data/UI ownership and design systems, making hexagonal inside/outside boundaries visible, locating ports, adapters and composition roots, structuring BFF routes, planning folder migrations, or enforcing package and import direction. For one module's logical responsibility, deepening, splitting, or caller contract use codebase-design; for repository-wide architecture investment discovery use improve-codebase-architecture. A physical flattening alone is not a reduce-system-complexity result.
- ▌ CLI Design · citypaul bundleUnix-composable CLI design patterns. Use when building CLI tools, designing command trees, implementing output layers, or testing CLI behavior. Covers stream separation (stdout/stderr), format flags (--json/--plain), exit codes, TTY detection, composability, and error design. Language-agnostic principles; TypeScript implementation patterns in resources/. For API design (REST, HTTP), see api-design.
- ▌ Functional · citypaul bundleFunctional programming patterns with immutable data. Use when writing logic, data transformations, or encountering mutation bugs — including any feature request that builds, merges, filters, sorts, prices or otherwise reshapes records, lists, carts, orders or invoices, even when it never mentions immutability; load it alongside tdd for such changes, not instead of it. Covers immutability violations catalog, pure functions, composition, early returns, and options objects. Do NOT over-apply heavy FP abstractions (monads, fp-ts) unless the project requires them.
- ▌ Storyboard · citypaulProduce a mock-audit storyboard — a single HTML page embedding related UX surfaces side-by-side, with per-mock audit checklists, a flow diagram, and gap cards for missing mocks. Use when reviewing several mocks together would materially reduce context-switching or expose cross-surface gaps, or when the user asks to see or audit a whole flow in one place.
- ▌ Find Skills · citypaul bundleDiscover and, with authorization, install agent skills from the open skills ecosystem. Use when the user explicitly asks to find or install a skill from the external skills ecosystem, asks whether an installable agent skill exists for a task, or wants to extend agent capabilities through skills.sh or a skill repository. Not for choosing among already-installed local skills or selecting software libraries, developer tools, applications, services, frameworks, or platform primitives; use evaluate-existing-solutions for technology choices.
- ▌ Refactoring · citypaulRefactoring assessment and behavior-preserving patterns for code with a passing baseline and proportionate preservation evidence. Use when the user asks to clean up, tidy, simplify, restructure, deduplicate, collapse, or merge look-alike code in a selected area, or after GREEN establishes the passing baseline for a TDD increment. Mutation testing verifies the accumulated result later at the end-of-phase PR-readiness gate. Covers recoverable-baseline discipline, when refactoring adds value vs when to skip it, and priority classification; commits always require explicit user approval. For any slice in a selected whole-path reduction program—transition or terminal—use reduce-system-complexity as the governing skill; refactoring may be secondary when applicable. For repository-wide architecture discovery use improve-codebase-architecture; for a module contract use codebase-design. Do NOT use for insufficiently evidenced code or adding behavior.
- ▌ CI Debugging · citypaulSystematic CI/CD failure diagnosis using hypothesis-first investigation, local reproduction, and environment delta analysis. Use when a CI pipeline, GitHub Actions workflow, or build job fails; when tests pass locally but fail in CI; when diagnosing flaky tests, timeouts, or red pipelines; or when the user says "CI is failing", "the build is broken", or "works on my machine".
- ▌ Double Check · citypaul bundleGet a rigorous read-only second opinion on finished work through the host's available reviewer capabilities, preferably from a different model provider. Falls back to a fresh same-provider agent only when necessary and labels the reduced independence. Every review includes a mandatory scope-fidelity check against the original requirements — unrequested additions, unrequested removals, and deleted or weakened tests. Use when asked to double-check, verify, cross-check, or get a second opinion, and before shipping high-stakes or complex work.
- ▌ Expectations · citypaulDecide where a learning, gotcha, or decision should live so it is not lost, and capture it there while context is fresh. Use when the user says they just discovered, learned, or found out something non-obvious, asks where a fact should be recorded, written down, or go, wants a setup gotcha, workaround, or decision kept for the next person or the next agent session, or asks whether something belongs in CLAUDE.md, a README, an ADR, tests, a glossary, or a reusable skill. Routes each fact to its durable owner and decides whether it is reusable or project-local. For the prose of the document itself see technical-writing; for recording a domain term see ubiquitous-language.
- ▌ Panel Review · citypaul bundleComposable multi-agent code review of any change boundary — the working tree mid-development, a branch diff, a stacked layer, or a pull request: one orchestrator fans out sub-agents, each loading exactly one installed skill as a review lens (hexagonal-architecture, domain-driven-design, structure-codebase, typescript-strict, ...), then adversarially verifies findings and synthesizes one ranked report. Invoked as /panel-review with an optional target (defaults to the current branch's work, committed or not) and lens names — sensible defaults plus project-trait auto-detection, add or remove lenses freely. Also owns the PR-readiness evidence gate (change-path classification, mutation-evidence freshness) for when a boundary is heading to a PR. Use when reviewing in-progress work, a branch, a diff, or a PR, before merging, or when the user asks to review through named skills. Built on graph-engineering (the generic machinery); for a cross-provider second opinion on finished work use double-check; for Anthropic's f
- ▌ Finding Seams · citypaul bundleUse when existing code has untestable dependencies that prevent writing tests -- direct construction of collaborators, static or global function calls, tight coupling to external systems, or singleton access patterns. Specifically for identifying substitution points (seams) that make legacy or tightly-coupled code testable without editing at the call site. Do NOT use for greenfield TDD (see tdd), general test writing patterns (see testing), or refactoring already-tested code (see refactoring).
- ▌ Observability · citypaul bundleObservability as an engineering discipline — wide events / canonical log lines, OpenTelemetry instrumentation (traces, metrics, context propagation, sampling, Collector), SLIs/SLOs/error budgets, symptom-based alerting with burn rates, telemetry hygiene, and testing instrumentation as behavior. Use when calls between services cannot be correlated, another team cannot line their side of a call up with ours or find the request it came from, a request or trace id has to cross a service hop, a failure cannot be debugged from the logs, or when instrumenting a service, designing SLOs or alerts, choosing what to log/trace/measure, investigating production unknowns, or reviewing telemetry cost and cardinality. For log transport and shape (stdout, JSON, levels, timestamps) see twelve-factor; for CI failure diagnosis see ci-debugging; for where instrumentation lives in ports-and-adapters codebases see hexagonal-architecture; for environment drift see production-parity-skill-builder; for HTTP error response shape see ap
- ▌ React Testing · citypaul bundleReact component testing patterns including components, hooks, context, and forms. Covers Vitest Browser Mode with vitest-browser-react and @testing-library/react. Use when testing React applications. For general UI testing patterns, see the front-end-testing skill.
- ▌ Specification · citypaul bundleTurn fuzzy intent into shared understanding and acceptance criteria — specification as a conversation, run one question at a time, before any story is split or planned. Use when an idea, feature request, or problem statement has no agreed rules or examples yet ("let's spec this out", "what should this actually do?", "we need acceptance criteria"). Produces an example map and acceptance criteria written back into the team's own story artifact, plus candidate glossary terms and parked questions. The agent-facilitated round is a draft for review by the accountable owner and, when risk or shared ownership warrants it, the relevant human perspectives. For decision trees with no artifact, use grill-me where installed or this skill's one-question protocol; for tightening an existing artifact, see find-gaps; for slicing agreed work, see story-splitting.
- ▌ Twelve Factor · citypaul bundleTwelve-Factor App patterns for software-as-a-service and long-running process applications. Use when configuring deploy-time environment, backing services, process startup/shutdown, or operational parity. Apply individual principles to frontends, serverless functions, and CLIs only where their runtime and platform make them relevant.
- ▌ Event Sourcing · citypaul bundleEvent sourcing patterns for functional TypeScript — persist state as an append-only log of past events and rebuild it by folding them. Use when implementing a Decider write model, an event store, projections and read models, event versioning, or snapshots. Builds on the Decider from domain-driven-design and the ports/adapters from hexagonal-architecture. Do NOT reach for it on CRUD, or when an audit log or the outbox pattern already suffices.
- ▌ Tdd · citypaul bundleRED-GREEN-REFACTOR for production behavior changes, followed by mutation testing or alternate evidence once at the end-of-phase PR-readiness gate. Use before implementing new features, bug fixes, or any changed observable behavior, and as the governing workflow for mixed implementation work. Load it for any request to add, implement, or fix production code, including a bug report that calls the fix a one-liner or a quick change in a named file — a small fix still starts from a failing behavior test, not from an edit. This is the workflow, not the whole toolkit — load it alongside, not instead of, functional for logic or data-shaping changes (pricing, tiering, filtering, merging, sorting, totals), refactoring when a change also tidies already-tested code, front-end-testing (react-testing for React components) when the behaviour under test lives in a browser — a form, a button, a spinner, a page — and any architecture skill the repository declares (hexagonal-architecture, domain-driven-design). Do not use for p
- ▌ Wtf · citypaul bundleRe-explain the immediately previous LLM response when it did not land, using plain, precise UK English.
- ▌ Xstate · citypaul bundleModel front-end and workflow logic as XState v5 statecharts and actors — when finite states earn their place (and when @xstate/store or a discriminated union is honest), event-first machine design, guards/actions/delays, invoke vs spawn, app-level actor systems, persistence, @xstate/react integration, behavior-driven machine testing including model-based path generation via xstate/graph, and a Mermaid stateDiagram-v2 render regenerated whenever a machine is designed or changed. Fires on ordinary React code that is already a hand-rolled statechart, not only on files that import xstate — a submitting or isLoading useState, a then/catch chain that sets state in sequence, a double-submit guard such as an early return while submitting, an error cleared just before a retry, a useEffect needing an ignore flag in its cleanup, a timer something must clear, or a drag or gesture handler binding document listeners it must unbind. Two tests decide ownership, never how the value renders: an external answer changed it, or t
- ▌ Testing · citypaulTesting patterns for behavior-driven tests. Use when writing tests, creating test factories, structuring test files, or deciding what to test. Do NOT use for UI-specific testing (see front-end-testing or react-testing skills).
- ▌ Diagrams · citypaul bundleCreate or audit maintainable diagrams when relationships, sequence, state, hierarchy, or quantitative comparisons are materially clearer visually than in prose. Selects a format the destination actually renders, preserves source authority, validates output, and includes an accessible text explanation.
- ▌ Planning · citypaulPlanning work as vertical slices or an explicitly selected mechanism-reduction program in small, known-good increments, with independent pull requests or an optional stacked-PR topology across one or more ordered slices. Use when starting significant work, turning already-split stories into implementation plans, planning PRs, or sequencing complex tasks. For a mechanism-reduction program, use reduce-system-complexity first to define the conserved contract, terminal mechanism-removal state, and behavior/mechanism gates; planning then sequences it. If the input is a broad story, epic, feature idea, or backlog item that still needs product slicing, use story-splitting first; if a slice needs review layers or later slices should start on an evolving baseline before lower PRs merge, also use stack-pull-requests.
- ▌ Teach Me · citypaul bundleStructured learning and tutoring for any topic. Use when the user wants to learn a concept, be quizzed, create a learning plan, generate a structured course, or produce reviewable HTML lessons. Invoked via /teach-me [topic].
- ▌ Debugging · citypaul bundleWHEN diagnosing a reproducible or observable software failure outside a CI-pipeline-specific workflow; NOT for speculative cleanup, general code review, or speculative behavior changes presented as fixes. Preserves evidence, tests one causal hypothesis at a time, and fixes the owning boundary only when requested; separately authorized reversible incident mitigation may precede diagnosis while severe harm is ongoing.
- ▌ Find Gaps · citypaulAdversarially review an existing written artifact — stories, plans, acceptance criteria, specs, or design mocks — to surface missing states, unhandled edge cases, unstated assumptions, unverifiable criteria, and slices still too broad or horizontal. Works interactively, one question at a time, writing each answer back into the artifact as a new acceptance criterion, plan update, or mock-state spec. Use when an artifact needs tightening before planning or coding ("what's missing?", "poke holes in this", "tighten this up"). Requires an artifact to inspect — for a fuzzy decision tree with no artifact yet, use specification or an installed grill-me skill; for splitting oversized work, see story-splitting.
- ▌ API Design · citypaul bundleStable consumer-facing API and interface design patterns. Use when designing REST endpoints, cross-team boundaries, or any externally consumed or versioned service contract. Covers contract-first development, error semantics (RFC 9457), REST conventions, pagination, idempotency, rate limiting, and backward compatibility. For an in-process feature or module's coherent responsibility and interface depth, use codebase-design. For TypeScript type patterns and trust-boundary validation, see typescript-strict.
- ▌ Bff Design · citypaul bundleDecide whether a system needs a backend-for-frontend, how many, and what each one may own: adoption signals and honest costs, one-experience-one-BFF granularity with frontend-team ownership, the shape-don't-decide rule, upstream aggregation with partial-failure and resilience budgets, identity-keyed BFF caching, mediating user identity toward upstream services (token exchange, confused-deputy prevention), and the alternatives (shared gateway, GraphQL federation, token-mediating backend, direct SPA→API, meta-framework server as BFF). Use when adopting or splitting BFFs, aggregating upstream services, handling upstream failures, forwarding user identity downstream, weighing GraphQL against per-client BFFs, or auditing a BFF that has drifted into a public API or a business-logic layer. For protecting the BFF's own entry points use bff-entry-points; for physical route layout use structure-codebase; for externally consumed API contracts use api-design; for OAuth/OIDC protocol flows use secure-oauth-oidc.