Convert issue forms to markdown templates

.github/ISSUE_TEMPLATE/01_bug_report.md

@@ -0,0 +1,61 @@
+---
+name: Bug report
+about: liveness_primer crashed, produced a wrong report, or behaved differently than documented.
+title: '[bug] '
+labels: bug
+---
+
+<!--
+Thanks for the report. A bug in liveness_primer is typically reproducible from
+a single command plus the two detector refs, so the details below are what a
+maintainer needs to see it happen. Delete anything that does not apply.
+
+Security issues should go through SECURITY.md, not a public issue:
+https://github.com/mcdigman/liveness_primer/blob/main/SECURITY.md
+-->
+
+## Environment
+
+- **liveness_primer version:** <!-- `liveness-primer --version`, which includes the schema version, e.g. liveness-primer 0.1.0 (schema 2.2.0) -->
+- **Python version:** <!-- `python --version` -->
+- **Operating system:** <!-- macOS 14.5 (arm64) / Ubuntu 24.04 (x86_64) / ubuntu-latest GitHub runner -->
+- **Detector and revisions:** <!-- the `--tool` name, repo, and the versions or full pinned hashes of the two commits that reproduce it, e.g. skylos https://github.com/duriantaco/skylos a27bd86223a948fe292677e71bd84e19c1ab24fa e25b12eba4a2f80ad031b388ec81049d46be8f90 -->
+- **Corpus projects involved:** <!-- the `-k` selections, `--all`, or the `--project` URL. If only some projects fail, say which: -k pluggy (also fails on attrs; passes on click) -->
+
+## Description
+
+<!-- What is wrong. -->
+
+## Reproduction
+
+<!-- If possible, a minimal example and the exact command needed to run it. -->
+
+```console
+$
+```
+
+## Expected behavior
+
+<!-- What you expected, and where that expectation comes from (docs, `--help`, a prior version). -->
+
+## Actual behavior
+
+<!--
+What happened instead. Paste the terminal output or traceback — the whole
+thing, not just the last line. Redact paths or tokens if you need to.
+-->
+
+```console
+```
+
+## Report excerpt
+
+<!--
+If the bug is about report content rather than a crash, attach the JSON report
+(`--json-out report.json`) or paste the relevant entry. Drag-and-drop works for
+files.
+-->
+
+## Anything else
+
+<!-- Additional context, screenshots, link to a failing CI run, etc. -->

.github/ISSUE_TEMPLATE/02_adapter_request.md

@@ -0,0 +1,52 @@
+---
+name: Detector adapter request
+about: Ask for a new detector or linter to be supported by a liveness_primer adapter.
+title: '[adapter] '
+labels: 'adapter, enhancement'
+---
+
+<!--
+An adapter teaches liveness_primer to build one detector at two revisions,
+invoke it, and normalize its output into the shared finding model. The ones
+that work well are deterministic, installable from a git ref, and pointable at
+a directory.
+
+The answers below decide whether an adapter is feasible at all, so a partly
+filled issue is fine — say "not sure" rather than guessing.
+-->
+
+- **Detector name:**
+- **Source repository:** <!-- adapters build from a git ref, so a public repository is required -->
+
+## What does it detect, and why compare revisions of it?
+
+<!--
+What kinds of findings it reports, and what a blast-radius comparison would
+tell you that its own test suite does not.
+-->
+
+## Output format
+
+<!--
+Machine-readable output is much easier to normalize; text output is supported
+but needs a stable, parseable shape. Pick one:
+
+  - JSON (documented and stable)
+  - JSON (present but undocumented)
+  - Text (stable line format)
+  - Text (free-form)
+  - SARIF
+  - Other / not sure
+-->
+
+## Revisions worth comparing first
+
+<!-- Two refs a maintainer can use to smoke-test the adapter, e.g. v2.3.0 vs v2.4.0. -->
+
+## Corpus applicability
+
+<!--
+Does it analyze the same source directories the existing corpus entries
+declare, or does it need different targets (installed packages, tests, a whole
+checkout)? Rough per-project runtime is useful too.
+-->

.github/ISSUE_TEMPLATE/03_corpus_suggestion.md

@@ -0,0 +1,50 @@
+---
+name: Corpus suggestion
+about: Propose a project for the pinned corpus, or a change to an existing entry.
+title: '[corpus] '
+labels: corpus
+---
+
+<!--
+Corpus entries are the targets every comparison runs against, so each one must
+be GitHub-hosted, permissively licensed, moderate in size, and pinned to a full
+commit SHA — both detector revisions have to analyze byte-identical checkouts.
+
+The gate on liveness_primer/data/corpus.yaml runs `corpus validate` and a
+GitHub license check on every PR, so an entry that fails these fields will fail
+CI too.
+-->
+
+## What is this?
+
+<!-- Delete all but one. -->
+
+- Add a new project
+- Re-pin an existing project
+- Additional pin for an existing project
+- Change targets or cost for an existing project
+- Remove a project
+
+## Entry
+
+- **Project name:** <!-- the corpus key: short, lowercase, unique, e.g. pluggy -->
+- **Repository URL:** <!-- must be GitHub-hosted, e.g. https://github.com/pytest-dev/pluggy -->
+- **License (SPDX):** <!-- MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC, or PSF-2.0. Anything outside the allowlist needs human review — explain below. -->
+- **Proposed pin:** <!-- a full 40-character commit SHA, not a tag or branch, e.g. f06ceaafbe5bdbdafad8a0c01a2daabb89386a42 -->
+
+## What does it cover that the current corpus does not?
+
+## Size and maintenance
+
+<!--
+Rough source size, recent commit or release activity, and how long a detector
+takes on it. Very large projects may be too expensive for per-PR tool runs.
+Example: about 3k lines under src/, released last month, ~5s under skylos.
+-->
+
+## Anything else
+
+<!--
+For a re-pin, why now. For an additional pin, why it adds additional value.
+For a removal, what changed. For an unusual license, the reasoning.
+-->