Add HikariCP connection pool skill and prompt

promptbook/prompts.json

@@ -879,6 +879,27 @@
       ],
       "formatNotes": "All three. Point the tool at `.github/workflows/`, CODEOWNERS, and any existing `.github/rulesets/` or Terraform, and paste the output of `gh api repos/{owner}/{repo}/rulesets`, `gh api repos/{owner}/{repo}/branches/main/protection`, and `gh pr checks <recent-green-pr>`. Copilot: rulesets path instructions plus those files in agent mode (or save it as `.github/prompts/migrate-branch-protection-to-rulesets.prompt.md`). Claude Code: the github-rulesets-merge-queue-guardrails skill plus the files. Codex: AGENTS.md branch rules section, then the diff. The prompt outputs commands to review; it never applies rules itself.",
       "body": "Task: Move this repository's branch and tag protection into rulesets stored as code, make every required check reliable, and add a merge queue if it is warranted. Finish with ruleset files, workflow fixes, an apply and drift-check process, and a proof plan.\n\nContext placeholders (fill from the repo or ask only if missing):\n- Repository: {{OWNER_REPO}}\n- Plan and owner type: {{PLAN}}  (personal, organization on Team, or Enterprise Cloud; decides whether evaluate mode and org rulesets exist)\n- Default branch and release branches: {{BRANCHES}}  (e.g. main, release/*)\n- Release tag pattern: {{TAG_PATTERN}}  (e.g. v*)\n- Required reviews: {{REVIEWS}}  (e.g. 1 approval, code owners, last-push approval)\n- Checks that must pass: {{CHECKS}}  (e.g. build, test, dependency-scan, CodeQL; or \"discover from a recent PR\")\n- Merge method: {{MERGE_METHOD}}  (merge, squash, or rebase)\n- Merge queue: {{MERGE_QUEUE}}  (yes, no, or \"recommend\")\n- Bypass needs: {{BYPASS}}  (e.g. release app for tags, platform team on PRs only; or none)\n- Apply method: {{APPLY}}  (gh api from a reviewed PR, or Terraform integrations/github)\n\nRequirements:\n\n1. Current state\n   - Export with `gh api repos/{{OWNER_REPO}}/rulesets` (and each `rulesets/{id}`) and `gh api repos/{{OWNER_REPO}}/branches/<branch>/protection`\n   - Table: target | source (classic or ruleset) | rule | setting | gap\n   - Flag: force push or deletion allowed, no PR rule, admins exempt by default, required checks with no app pinned, tags unprotected, bypass actors with `always`\n\n2. Check inventory\n   - From `gh pr checks` on a recent green PR and `.github/workflows/`: check name | workflow file | job id | app | triggers | path or branch filters | matrix\n   - Flag required candidates that are path-filtered, renamed recently, duplicated across workflows, or missing `merge_group`\n\n3. Workflow fixes (separate commit, merged first)\n   - Unfiltered `pull_request` and `merge_group` triggers on required workflows; move path logic into a `changes` job with a SHA-pinned filter action\n   - A final gate job (e.g. `ci-ok`) with `needs:` on all required jobs, `if: always()`, failing when any need failed or was cancelled\n   - Stable, unique job `name:` values; no secrets or deploy steps that run only on `merge_group`\n\n4. Ruleset files\n   - `.github/rulesets/default-branch.json`: conditions with `~DEFAULT_BRANCH` (plus {{BRANCHES}}), `deletion`, `non_fast_forward`, `pull_request` from {{REVIEWS}} with `dismiss_stale_reviews_on_push`, `require_last_push_approval`, `required_review_thread_resolution`, `allowed_merge_methods` [{{MERGE_METHOD}}]; `required_status_checks` with the gate job and `integration_id: 15368` for Actions checks\n   - `.github/rulesets/release-tags.json`: target `tag`, include `refs/tags/{{TAG_PATTERN}}`, `creation`, `update`, `deletion`; bypass only the release actor from {{BYPASS}}\n   - Merge queue (if {{MERGE_QUEUE}}): `merge_queue` with `merge_method`, `grouping_strategy: ALLGREEN`, `max_entries_to_build`, `min_entries_to_merge`, `max_entries_to_merge`, `min_entries_to_merge_wait_minutes`, `check_response_timeout_minutes` from CI duration; set `strict_required_status_checks_policy: false`\n   - `bypass_actors`: only {{BYPASS}}, `pull_request` mode for people and teams; explain any `exempt`\n   - `enforcement: evaluate` first if {{PLAN}} is Enterprise, otherwise a staged rollout note\n   - Terraform equivalent if {{APPLY}} is Terraform\n\n5. Apply and drift\n   - Apply script or workflow: POST on first create, PUT by id after; run from a reviewed merge with a token that has Administration write; never from a PR branch\n   - Scheduled drift workflow on weekdays: fetch live rulesets, normalize (drop `id`, `node_id`, `_links`, `created_at`, `updated_at`, `current_user_can_bypass`, `source`), diff, open or update one issue; no automatic re-apply\n   - CODEOWNERS for `.github/rulesets/` and both workflows\n\n6. Migration\n   - Order: workflow fixes, rulesets active, `gh ruleset check <branch>` verified, then delete classic protection\n   - Note that both systems apply while they overlap\n\n7. Proof\n   - PR with failing test: blocked; PR with no approval: blocked; author pushing after approval: approval required again\n   - Direct push and force push to the default branch: rejected\n   - Non-release actor creating or moving a `{{TAG_PATTERN}}` tag: rejected\n   - With a queue: two PRs merge in order; a failing PR is removed; a docs-only PR still gets a green gate\n\nConstraints:\n- Do not apply rulesets or delete classic protection; output files and the commands to review.\n- Don't invent actor ids, team ids, app ids (other than 15368 for GitHub Actions), or check names; use placeholders and list what must be looked up.\n- Minimal workflow diff; do not change build logic.\n- Never give a human `always` bypass, and never let automation enqueue with `GITHUB_TOKEN`.\n- Optimize for GitHub Copilot, Claude Code, and Codex: give concrete files and a checklist.\n\nOutput format:\n1. Current-state table with gaps\n2. Check inventory table with flags\n3. Patch: workflow fixes, ruleset JSON (or Terraform), apply and drift workflows, CODEOWNERS\n4. Migration steps with the exact `gh` commands to review\n5. Proof plan with expected results\n6. Risks and follow-ups (e.g. checks to rename, bypass to remove, org-level rules to propose)\n\nStart with the export. Fix the checks before you require them, and require them before you queue.\n"
+    },
+    {
+      "id": "tune-hikari-connection-pool",
+      "title": "Tune a Spring Boot Service's Database Connection Pool",
+      "whenToUse": "Size and harden a Spring Boot service's HikariCP pool from real numbers: build a connection budget from the database limit and every pool at HPA max, find long transactions and remote calls inside them, set timeouts and lifetimes below the path's idle limits, add database-side statement timeouts, wire pool metrics and alerts, and prove the result with a load test that shows fast failure instead of 30-second waits.",
+      "tools": [
+        "copilot",
+        "claude-code",
+        "codex"
+      ],
+      "tags": [
+        "java",
+        "spring-boot",
+        "hikaricp",
+        "postgresql",
+        "database",
+        "aks",
+        "performance"
+      ],
+      "formatNotes": "All three. Point the tool at `application*.yml`, `@Transactional` classes and repositories, the Deployment and HPA manifests, and paste `SHOW max_connections;`, a `pg_stat_activity` count grouped by `application_name` and `state`, and a screenshot or export of HikariCP metrics if you have them. Copilot: the datasource path instructions plus those files in agent mode (or save it as `.github/prompts/tune-hikari-connection-pool.prompt.md`). Claude Code: the hikari-connection-pool-guardrails skill plus the files. Codex: AGENTS.md database connections section, then the diff. The prompt proposes a config and code diff; it never changes database settings itself.",
+      "body": "Task: Size and harden this Spring Boot service's database connection pool so it fits the database at full scale, fails fast under pressure, and shows its health on a dashboard. Finish with a connection budget, a config and code diff, database-side settings to review, and a load-test plan.\n\nContext placeholders (fill from the repo or ask only if missing):\n- Service and datasources: {{SERVICE}}  (e.g. orders-api, one primary datasource)\n- Database engine and tier: {{DATABASE}}  (e.g. Azure Database for PostgreSQL Flexible Server, 4 vCores)\n- Database max_connections and reserved slots: {{DB_LIMIT}}\n- Other clients of the same database: {{OTHER_CLIENTS}}  (services, jobs, their pool sizes and replica counts)\n- Replicas: {{REPLICAS}}  (HPA min and max, rollout maxSurge)\n- Request timeout at the edge: {{EDGE_TIMEOUT}}  (e.g. ingress 15s, client 10s)\n- Network path: {{PATH}}  (direct, PgBouncer transaction mode, private endpoint, load balancer idle timeout)\n- Credentials: {{CREDENTIALS}}  (password, or passwordless token with lifetime)\n- Threads: {{THREADS}}  (platform threads with Tomcat max, or virtual threads)\n- Symptoms, if any: {{SYMPTOMS}}  (e.g. connection-not-available timeouts, too many clients, p99 spikes)\n\nRequirements:\n\n1. Connection budget\n   - Table: client | pool size | replicas at max | surge | total\n   - usable = {{DB_LIMIT}} minus reserved; show the per-pod maximum for {{SERVICE}} and whether today's config exceeds it\n   - Flag pools copied between services with different replica counts\n\n2. Holding time audit\n   - Find `@Transactional` methods and repositories that call HTTP clients, publish and wait on messages, sleep, stream large results, or loop over remote calls\n   - Check `spring.jpa.open-in-view` and lazy loading in controllers\n   - Table: method | what holds the connection | estimated hold time | fix\n\n3. Pool configuration\n   - `maximum-pool-size` from the budget, fixed pool (`minimum-idle` unset), `pool-name`\n   - `connection-timeout` below {{EDGE_TIMEOUT}}; map `SQLTransientConnectionException` to 503 with Retry-After\n   - `max-lifetime` and `keepalive-time` below every limit in {{PATH}} and {{CREDENTIALS}}, with the reasoning\n   - `leak-detection-threshold` in dev and test profiles only\n   - If {{PATH}} includes PgBouncer transaction mode: `prepareThreshold=0` (unless supported), no session state across transactions\n   - If {{THREADS}} is virtual threads: pool as the concurrency limit, a bulkhead on database-heavy endpoints\n   - JDBC `socketTimeout` and `ApplicationName` in the URL\n\n4. Database-side settings (output only)\n   - Per-role `statement_timeout`, `idle_in_transaction_session_timeout`, and `CONNECTION LIMIT` matching the budget\n   - Note where the managed service sets server parameters instead of SQL\n\n5. Observability\n   - Micrometer HikariCP metrics on the actuator endpoint already in use\n   - Alerts: `hikaricp_connections_timeout_total` increase above zero; `hikaricp_connections_pending` above zero for 5 minutes; usage p95 above a threshold\n   - One dashboard row: active, idle, pending, max, acquire p95, usage p95\n\n6. Shutdown and isolation\n   - `server.shutdown=graceful`, `preStop` delay, termination grace period above drain plus statement timeout\n   - Batch, report, or migration work on its own pool or deployment; migrations run once, not per replica\n\n7. Proof\n   - Load test at expected peak and at 2x: no timeouts at peak; at 2x, requests fail in about the connection timeout with 503, not after 30s\n   - Kill a database connection or restart the proxy: pool recovers without restarting pods\n   - Rolling deploy at HPA max: total connections stay under the budget\n   - Leak test in dev: a deliberate leak produces a leak warning with the stack trace\n\nConstraints:\n- Do not change database server parameters or roles; output the statements to review.\n- Do not raise the pool size to hide slow queries; list the queries instead.\n- Do not invent limits, timeouts, or replica counts; use placeholders and list what must be looked up.\n- Minimal diff; no unrelated refactors.\n- Optimize for GitHub Copilot, Claude Code, and Codex: give concrete files and a checklist.\n\nOutput format:\n1. Connection budget table with the per-pod maximum\n2. Holding time audit table with fixes\n3. Patch: application.yml per profile, exception mapping, code changes for long transactions, manifests\n4. Database-side statements to review\n5. Alerts and dashboard definitions\n6. Proof plan with expected results\n7. Risks and follow-ups (e.g. queries to tune, services to resize, a proxy to consider)\n\nStart with the budget. Shorten how long connections are held before you change how many there are.\n"
     }
   ]
 }