Added github templates for issues and pr

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,138 @@
+name: Bug report
+description: Report a problem with @fortedigital/nextjs-cache-handler
+labels: ["bug"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for taking the time to report a problem. Before filing:
+
+        - **The fastest way to get a bug fixed is to open a pull request that fixes it**, ideally with a regression test (unit and/or e2e). This is a small, maintainer-bandwidth-limited project - a well-described report can sit in the queue for a while, but a PR with a fix and a test gets reviewed and merged much faster. If you're able to, please consider fixing it yourself and opening a PR instead of (or in addition to) this issue. See `CLAUDE.md` / the README for how to run the test suite and the example apps.
+        - If you have a **question** about usage/configuration rather than something that's broken, please use the "Question" issue template instead - it keeps this one focused on actionable bugs.
+        - Please reproduce against the **unmodified `examples/redis-minimal` app** if you can. A lot of back-and-forth on past issues came from bugs that only existed in someone's heavily customized cache-handler config (custom locks, wrappers, serializers, etc.). Isolating whether the bug exists in the plain example saves everyone time - but if you can't spare that, a report without it is still welcome, just fill in as much below as you reasonably can.
+        - This package was forked from [`@neshca/cache-handler`](https://github.com/caching-tools/next-shared-cache) and inherited most of its behavior (TTL/tag model, handler interface, etc.). If what you're seeing matches a documented behavior of that project rather than something specific to this fork, the [neshca docs](https://caching-tools.github.io/next-shared-cache/) may explain it - worth a quick check first.
+
+  - type: checkboxes
+    attributes:
+      label: Preflight checklist
+      options:
+        - label: I searched existing issues and didn't find a duplicate.
+          required: true
+        - label: This is a bug report, not a usage question (usage questions should use the "Question" template).
+          required: true
+
+  - type: input
+    id: package-version
+    attributes:
+      label: "@fortedigital/nextjs-cache-handler version"
+      description: e.g. 3.3.0 (run `npm ls @fortedigital/nextjs-cache-handler` if unsure)
+      placeholder: "3.3.0"
+    validations:
+      required: true
+
+  - type: input
+    id: nextjs-version
+    attributes:
+      label: Next.js version
+      description: e.g. 16.3.0. Note if it's a canary build.
+      placeholder: "16.3.0"
+    validations:
+      required: true
+
+  - type: textarea
+    id: repro-steps
+    attributes:
+      label: Steps to reproduce
+      description: |
+        What you did and what happened. Ideally against `examples/redis-minimal` (`npm run build && npm run start` - caching only activates in a production build), but your own app is fine too if that's easier for you.
+      placeholder: |
+        1. In examples/redis-minimal, visit /some-page
+        2. Wait for revalidate window to pass
+        3. Call revalidateTag("...")
+        4. Observe ...
+    validations:
+      required: true
+
+  - type: textarea
+    id: expected-actual
+    attributes:
+      label: Expected vs. actual behavior
+    validations:
+      required: true
+
+  - type: dropdown
+    id: router
+    attributes:
+      label: Router / caching mode in use
+      description: Optional, but helpful - Next.js 16 has two separate cache configuration surfaces, so this narrows down where the bug likely is.
+      multiple: true
+      options:
+        - App Router (default cacheHandler - ISR / fetch / route handlers)
+        - Pages Router
+        - "Cache Components / \"use cache\" (cacheHandlers, plural)"
+        - PPR (Partial Prerendering)
+        - Not sure
+
+  - type: dropdown
+    id: handlers
+    attributes:
+      label: Which handler(s) from this package are configured?
+      description: Optional.
+      multiple: true
+      options:
+        - redis-strings (node-redis client)
+        - redis-strings via ioredisAdapter
+        - redis-strings via redisClusterAdapter
+        - local-lru
+        - composite
+        - Other / not sure
+
+  - type: input
+    id: env-versions
+    attributes:
+      label: Redis / ioredis / Node.js versions
+      description: "Optional. e.g. \"redis@5.1.1, Redis Server 7.2, Node 22.19.0\""
+
+  - type: dropdown
+    id: topology
+    attributes:
+      label: Deployment topology
+      description: Optional, but useful if this looks like a race condition, hit-rate, or stale-cache issue - those are often topology-dependent.
+      options:
+        - Single instance / single pod
+        - Multiple instances or pods sharing one Redis (e.g. Kubernetes with N replicas)
+        - Serverless (per-invocation instances)
+        - Vercel
+        - Local dev / not deployed
+        - Other (describe in reproduction steps)
+
+  - type: textarea
+    id: cache-handler-config
+    attributes:
+      label: cache-handler.mjs / .ts configuration
+      description: Optional, but if you're using non-default options or any custom wrapper code around the handler (locks, intervals, custom serializers, etc.), pasting it here can save a round trip - a good chunk of past reports turned out to be interactions with surrounding custom code rather than the library itself. Redact secrets.
+      render: typescript
+
+  - type: dropdown
+    id: repro-on-example
+    attributes:
+      label: Does this reproduce on the unmodified examples/redis-minimal app?
+      description: Optional.
+      options:
+        - "Yes - reproduces on examples/redis-minimal as-is"
+        - "No - only reproduces in my own app (explain any relevant differences above)"
+        - "Haven't tried yet"
+
+  - type: textarea
+    id: debug-logs
+    attributes:
+      label: Debug logs
+      description: Optional. Re-run with `NEXT_PRIVATE_DEBUG_CACHE=1` set and paste the relevant `[CacheHandler]` log lines - this is often the first thing that gets asked for, so including it up front can skip a round trip.
+      render: text
+
+  - type: checkboxes
+    id: pr-intent
+    attributes:
+      label: Contribution
+      options:
+        - label: I'm willing to open a pull request with a fix for this.

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -0,0 +1,44 @@
+name: Feature request
+description: Propose a new feature, handler, or capability
+labels: ["enhancement"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        This is a small, maintainer-bandwidth-limited project - new features move fastest when proposed with a concrete approach, and fastest of all when there's a draft PR attached. If you're able to prototype it, consider opening a draft PR alongside (or instead of) this issue so the discussion can happen against real code.
+
+  - type: checkboxes
+    attributes:
+      label: Preflight checklist
+      options:
+        - label: I searched existing issues/PRs and didn't find an existing request or implementation attempt.
+          required: true
+
+  - type: textarea
+    id: problem
+    attributes:
+      label: What problem does this solve?
+      description: What are you trying to do, and what currently stops you? (Not "add X" - the underlying need.)
+    validations:
+      required: true
+
+  - type: textarea
+    id: proposal
+    attributes:
+      label: Proposed solution
+      description: How you'd imagine this working - new handler, new option, config shape, etc.
+    validations:
+      required: true
+
+  - type: textarea
+    id: alternatives
+    attributes:
+      label: Alternatives / workarounds considered
+      description: Optional. Anything you've already tried, or prior art elsewhere (e.g. how another cache-handler package does it).
+
+  - type: checkboxes
+    id: pr-intent
+    attributes:
+      label: Contribution
+      options:
+        - label: I'm willing to implement this and open a PR.

.github/ISSUE_TEMPLATE/question.yml

@@ -0,0 +1,31 @@
+name: Question
+description: Ask about usage, configuration, or how something is supposed to work
+labels: ["question"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Have a "how do I configure X" or "is Y possible" question rather than a broken behavior to report? This is the right place. If it turns out to be a bug, we'll relabel it.
+
+        This package was forked from [`@neshca/cache-handler`](https://github.com/caching-tools/next-shared-cache) and inherited most of its handler interface, tag/TTL model, and general caching approach. If your question is about general concepts (TTL/`estimateExpireAge` behavior, populating the cache on start, tag revalidation semantics, etc.) rather than something specific to this fork, the [neshca docs](https://caching-tools.github.io/next-shared-cache/) may already have your answer - worth a quick check before posting.
+
+  - type: checkboxes
+    attributes:
+      label: Preflight checklist
+      options:
+        - label: I searched existing issues and didn't find an answer.
+          required: true
+
+  - type: textarea
+    id: question
+    attributes:
+      label: Your question
+    validations:
+      required: true
+
+  - type: textarea
+    id: context
+    attributes:
+      label: Relevant context
+      description: Optional - package/Next.js version, handler(s) in use, or a snippet of your cache-handler config, if relevant to the question.
+      render: typescript

.github/pull_request_template.md

@@ -0,0 +1,50 @@
+<!--
+Thanks for contributing! This project has limited maintainer bandwidth, so PRs that are
+self-contained, tested, and clearly described get reviewed and merged much faster than
+ones that require the maintainer to reproduce, test, or scope things down. Please fill
+this in - don't delete sections, but it's fine to write "N/A" where something doesn't apply.
+-->
+
+## What does this PR do, and why?
+
+<!-- Link the issue this addresses, e.g. "Fixes #123" / "Addresses #123". If there's no issue, explain the problem this solves and how you found it (repro steps, prod symptom, etc.). -->
+
+## Type of change
+
+- [ ] Bug fix
+- [ ] New feature / handler
+- [ ] Breaking change (existing Redis data or public API becomes incompatible - e.g. changing a handler's `valueSerializer`/wire format, key layout, or an exported type/interface)
+- [ ] Docs / examples only
+- [ ] Infra / chore (CI, tooling, deps)
+
+If this is a **breaking change**, describe the migration path (key prefix bump, README callout, `docs/migration` entry, etc.):
+
+## How was this verified?
+
+This package's core value is "don't break caching behavior" - a change that passes `tsc`/lint but silently breaks tag revalidation or ISR is worse than no change. Please verify at both levels below rather than relying on unit tests alone.
+
+**Automated tests**
+- [ ] Added/updated unit tests in `packages/nextjs-cache-handler/src/**/*.test.ts` (`npm test` / `npx jest <file>`)
+- [ ] Added/updated Playwright e2e coverage in `examples/redis-minimal/e2e` (`pnpm test:e2e`) - required for anything that changes caching/revalidation behavior observable by a running app
+- [ ] Added/updated the isolated `registerInitialCache` suite (`pnpm test:e2e:isolated`, requires Docker) if this touches build-time cache hydration
+- [ ] N/A - explain why (e.g. docs-only change):
+
+**Manual verification against the example app(s)**
+<!-- Reviewers have repeatedly had to bounce PRs back because they didn't work against examples/redis-minimal when actually run. Please do this before requesting review, not after. -->
+- [ ] Ran `npm run build && npm run start` in `examples/redis-minimal` (or `examples/redis-cache-components` if relevant) and exercised the affected page(s)/route(s) by hand
+- [ ] If behavior is observable in Redis (keys, TTLs, tags), inspected Redis directly (or via `NEXT_PRIVATE_DEBUG_CACHE=1` logs) to confirm the expected state
+- [ ] N/A - explain why:
+
+What did you actually do to verify it, and what did you observe? (commands run, pages visited, before/after logs or Redis state - screenshots welcome). For performance/behavior claims (hit-rate, race conditions, etc.), include concrete before/after numbers or logs, not just theoretical reasoning - several past PRs based purely on code inspection turned out not to fix the reported symptom in practice.
+
+## Compatibility
+
+- [ ] Checked against the Next.js version matrix in `README.md` (does this change apply to 15, 16, or both?)
+- [ ] If this touches `redis-strings`: confirmed it works with the official `redis` (node-redis) client; if `ioredis`-specific, went through `helpers/ioredisAdapter` rather than assuming ioredis methods work directly
+- [ ] `pnpm lint` and `pnpm build` pass locally
+
+## Scope check
+
+- [ ] This PR is limited to the change described above (no unrelated formatting/refactor/example-app noise mixed in)
+- [ ] Updated `README.md` / `docs/migration` if this changes public behavior or requires user action
+- [ ] Marked as **Draft** if this is still work-in-progress and you want early feedback rather than a full review