docs: add issue & PR templates and document agent rules in CLAUDE.md

[martinydeAI]

Link to ticket

Closes #69.

Description

Standardises the agent-driven workflow by introducing GitHub issue and
pull-request templates and recording matching agent rules in CLAUDE.md.

• .github/ISSUE_TEMPLATE/issue.md — short human-facing "Resume"
  section (Description + Tasks checklist) followed by an "AI
  specificities" detail block so other agents picking up the work have
  a structured brief instead of freeform paragraphs.
• .github/PULL_REQUEST_TEMPLATE.md — mirrors that split for PRs:
  human checklist on top, AI brief at the bottom.
• CLAUDE.md gains three rules:
  • require the issue template when creating issues via gh;
  • forbid edits under tests/ without explicit user approval, and
    require a written which-tests / what / why rationale before any
    test edit (the 100% coverage gate makes test churn weighty enough
    that the user, not the agent, should decide whether the production
    code or the test is wrong);
  • require PR descriptions to spell out the blocker and reason when
    a PR carries the do-not-merge label, kept current as blockers
    resolve.
• ADR 002-project-license-mpl-2 → 004-project-license-mpl-2
  renumber follow-up: the license ADR was moved aside in Decide on frontend tooling (CSS framework + asset pipeline) #38 to free
  ADR 002 for the frontend-tooling decision, but the README link
  and the changelog reference still pointed at the old number. Both
  updated, ADR heading + index renumbered to match.

PR-template usage is left implicit in CLAUDE.md because the
itkdev-pull-request skill already preserves repository templates
verbatim — adding a rule here would just duplicate that.

Screenshot of the result

N/A — documentation / repository-config only, no UI affected.

Checklist

• My code is covered by test cases.
• My code passes our test (all our tests).
• My code passes our static analysis suite.
• My code passes our continuous integration process.

If your code does not pass all the requirements on the checklist you have to add a comment explaining why this change
should be exempt from the list.

Additional comments or questions

The "covered by test cases" box is intentionally unchecked: this PR
only touches CLAUDE.md, two GitHub template files, README.md,
CHANGELOG.md, and docs/adr/. There is no PHP/JS to exercise, so
no PHPUnit cases are added. The 100% coverage gate is unaffected
because no src/ files changed.

---

Details - AI specificities

Goal and motivation

• Agent-generated issues and PRs were drifting between freeform
  paragraphs and ad-hoc checklists. The two templates introduce a
  consistent two-part layout (human header + AI brief) so any agent
  continuing the work has structured context.
• CLAUDE.md is the canonical contract for agent behaviour in this
  repo, so the new behavioural rules belong there rather than buried
  inside skill prompts.

Scope

• New files: .github/ISSUE_TEMPLATE/issue.md,
  .github/PULL_REQUEST_TEMPLATE.md.
• Edits to CLAUDE.md (three new rules).
• Edits to CHANGELOG.md (Added + a new Changed section under
  [Unreleased]).
• ADR rename 002-project-license-mpl-2.md →
  004-project-license-mpl-2.md, with README link, ADR heading, and
  index entry updated.

Non-goals

• No new issue-type taxonomy. The existing Bug / Feature / Task split
  in CLAUDE.md stays as is.
• No multi-template PULL_REQUEST_TEMPLATE/ directory — a single
  default template is enough for now.
• No source or test changes (src/, tests/, config/ untouched).
• PR-template usage is not added to CLAUDE.md because the
  itkdev-pull-request skill already enforces it.

Areas needing extra scrutiny

• The template files must keep their headings and HTML comment
  markers intact: the itkdev-pull-request skill copies the template
  verbatim and matches on those markers. Reformatting the headings
  would silently break PR generation.
• The CHANGELOG Changed section is new for this [Unreleased]
  block — previous entries collapsed everything into Added (docs: ADRs drop Follow-up Actions; CHANGELOG consolidates to Added #57).
  We're opting back into a Changed section here because the ADR
  renumber is genuinely a change to existing material, not an
  addition. If the project prefers a single Added list, the
  renumber bullet can be folded back in.

Follow-up work intentionally out of scope

• None. Issue task: add GitHub issue & PR templates and CLAUDE.md rules #69's task list is fully covered by this PR.

Related

• Issue: #69.
• do-not-merge label and the block-on-label workflow were
  introduced in feat: placeholder frontpage (#40) + do-not-merge label workflow #43 (refs Decide on frontend tooling (CSS framework + asset pipeline) #38).
• ADR 002-frontend-tooling (the reason the license ADR had to move
  to 004) landed via Decide on frontend tooling (CSS framework + asset pipeline) #38.
• ADR convention rules already in CLAUDE.md (Set up ADR (Architecture Decision Records) structure #11, task: transform ADR "Follow-up Actions" sections into GitHub issues #44, docs: ADRs drop Follow-up Actions; CHANGELOG consolidates to Added #57) are the
  pattern the new rules follow.

[yepzdk]

Should we align issue templates to the Bug / Feature / Task taxonomy that CLAUDE.md mandates?
This single catch-all issue.md formalizes layout but not the classification the repo actually requires. Splitting it into three templates (or YAML issue forms) aligned to that taxonomy would close the gap between the template and our own rules.

Should we add a checklist item for the test-edit rule?
The new "don't touch tests/ without approval" rule lives only in CLAUDE.md, so it's only enforceable by an agent that reads it. A checklist line in the PR template — e.g. "Test changes were approved / justified" — would surface it at review time where a human actually looks. Worth adding, or do we want to keep the PR checklist as the standard itk-dev one?

Have we considered disabling blank issues via config.yml? There's no .github/ISSUE_TEMPLATE/config.yml, so GitHub still offers the "blank issue" escape hatch — which undermines "require the issue template." Adding config.yml with blank_issues_enabled: false would actually enforce template usage. Does that add value here, or do we want to keep blank issues available?

[martinyde]

Should we align issue templates to the Bug / Feature / Task taxonomy that CLAUDE.md mandates? This single catch-all issue.md formalizes layout but not the classification the repo actually requires. Splitting it into three templates (or YAML issue forms) aligned to that taxonomy would close the gap between the template and our own rules.

Should we add a checklist item for the test-edit rule? The new "don't touch tests/ without approval" rule lives only in CLAUDE.md, so it's only enforceable by an agent that reads it. A checklist line in the PR template — e.g. "Test changes were approved / justified" — would surface it at review time where a human actually looks. Worth adding, or do we want to keep the PR checklist as the standard itk-dev one?

Have we considered disabling blank issues via config.yml? There's no .github/ISSUE_TEMPLATE/config.yml, so GitHub still offers the "blank issue" escape hatch — which undermines "require the issue template." Adding config.yml with blank_issues_enabled: false would actually enforce template usage. Does that add value here, or do we want to keep blank issues available?

Should we align issue templates? :
I did consider this, i just don't see the need yet, maybe i'm missing some benefit, but i thought we could start with this setup and alter if other needs appear.

Should we add a checklist item for the test-edit rule? :
In my workflow the checklists generally seem a bit rudimentary, i rarely set them manually because i rarely see PRs, Issues or ADRs progress over time, and the AI seems to scrape it all into checked/unchecked in one PR. I think the "don't touch tests" rules belong in Claude.md, maybe even as a hook to ensure proper gatekeeping, because it clearly illuminates when something critical is about to be changed. Maybe both approaches are needed.

Have we considered disabling blank issues via config.yml?
That seems like an edge case not worth worrying about.