added claude commands associated with project maintenance

.claude/commands/new-issues.md

@@ -0,0 +1,113 @@
+# New Issues: Feature Gap Analysis and Issue Creation
+
+Audit the README feature matrix, identify gaps and opportunities, and file
+GitHub issues for the best candidates. The prompt is: $ARGUMENTS
+
+---
+
+## Step 1 -- Read the feature matrix
+
+1. Read `README.md` and extract every function listed in the feature matrix tables.
+2. For each function, record:
+   - Category (Surface, Hydrology, Focal, etc.)
+   - Backend support (which of the four columns are native, fallback, or missing)
+3. Read the source files referenced in the matrix to confirm what actually exists
+   (the README can drift from reality).
+
+## Step 2 -- Identify backend gaps
+
+1. List every function where one or more backends show 🔄 (fallback) or blank
+   (unsupported).
+2. Prioritize gaps where:
+   - The function already has 3 of 4 backends (low effort to complete the set)
+   - The missing backend is CuPy or Dask+CuPy (GPU support matters for large rasters)
+   - The function is commonly used by GIS analysts (slope, aspect, flow direction, etc.)
+3. Draft 1-3 maintenance issues for the highest-value backend completions.
+
+## Step 3 -- Identify missing features
+
+Think about what GIS analysts and Python spatial data scientists actually need
+that the library does not yet provide. Consider:
+
+- **Surface analysis gaps:** contour line extraction, profile/cross-section tools,
+  terrain shadow analysis, sky-view factor, landform classification
+  (Weiss 2001, Jasiewicz & Stepinski 2013)
+- **Hydrology gaps:** HAND (Height Above Nearest Drainage) generation (not just
+  flood-depth-from-HAND), depression filling / breach, channel width estimation,
+  compound topographic index (CTI / wetness index)
+- **Focal / neighborhood gaps:** directional filters, morphological operators
+  (erode, dilate, open, close), texture metrics (entropy, GLCM), circular
+  or annular kernels
+- **Multispectral gaps:** water indices (NDWI, MNDWI), built-up indices (NDBI),
+  snow index (NDSI), tasseled cap, PCA, band math DSL
+- **Interpolation gaps:** natural neighbor, RBF (radial basis function),
+  trend surface
+- **Zonal gaps:** zonal geometry (area, perimeter, centroid), majority/minority
+  filter, zonal histogram
+- **Network / connectivity:** cost-path corridor, least-cost corridor,
+  visibility network (intervisibility between multiple points)
+- **Time series:** temporal compositing (median, max-NDVI), change detection,
+  phenology metrics
+- **I/O and interop:** raster clipping to polygon, raster merge/mosaic,
+  coordinate reprojection helpers
+
+Do NOT suggest features that duplicate what GDAL/rasterio already do well
+unless there is a clear benefit to having a pure-Python/Numba version (e.g.
+GPU support, Dask integration, no C dependency).
+
+Select the 3-5 most impactful feature suggestions. Rank by:
+1. How often GIS analysts need the operation (daily-use beats niche)
+2. How well it fits the library's existing architecture
+3. Whether it fills a gap no other GDAL-free Python library covers
+
+## Step 4 -- Draft the issues
+
+For each candidate (both maintenance and new-feature), draft a GitHub issue
+following the `.github/ISSUE_TEMPLATE/feature-proposal.md` template:
+
+- **Title:** short, imperative (e.g. "Add NDWI water index to multispectral module")
+- **Labels:** `enhancement` plus any topical labels that fit
+- **Body sections:**
+  - Reason or Problem
+  - Proposal (Design, Usage, Value)
+  - Stakeholders and Impacts
+  - Drawbacks
+  - Alternatives
+  - Unresolved Questions
+
+Keep each issue body concise. Cite specific algorithms or papers where
+relevant. Include a short code snippet showing the proposed API.
+
+## Step 5 -- Humanize and create
+
+1. Collect all drafted issue bodies into a batch.
+2. **Run each issue body through the `/humanizer` skill** to strip AI writing
+   patterns before creating the issue.
+3. Create each issue with `gh issue create`, passing the humanized title,
+   body, and labels.
+4. Record the issue numbers and URLs.
+
+## Step 6 -- Summary
+
+Print a table of all created issues:
+
+```
+| # | Title | Labels | URL |
+|---|-------|--------|-----|
+```
+
+Then briefly explain the rationale: why these issues were chosen, what
+analyst workflows they unblock, and any issues you considered but dropped
+(with a one-line reason for each).
+
+---
+
+## General rules
+
+- Do not create duplicate issues. Before filing, search existing issues with
+  `gh issue list --limit 100 --state all` and skip anything already covered.
+- Run `/humanizer` on every issue title and body before creating it.
+- If $ARGUMENTS contains specific focus areas (e.g. "hydrology only"),
+  restrict the analysis to those categories.
+- If $ARGUMENTS is empty, run the full analysis across all categories.
+- Prefer fewer, higher-quality issues over a long wishlist.

.claude/commands/release-major.md

@@ -0,0 +1,109 @@
+# Release: Major
+
+Cut a major release (X.Y.Z -> X+1.0.0). Follow every step below in order.
+
+$ARGUMENTS
+
+---
+
+## Step 1 -- Determine the new version
+
+1. Run `git tag --sort=-v:refname | head -5` to find the latest tag.
+2. Parse the current version (format `vX.Y.Z`).
+3. Increment the **major** component and reset minor+patch: `X.Y.Z` -> `(X+1).0.0`.
+4. Store the new version string (without `v` prefix) for later steps.
+
+## Step 2 -- Create a release branch
+
+```bash
+git checkout master && git pull
+git checkout -b release/vX.Y.Z
+```
+
+## Step 3 -- Update CHANGELOG.md
+
+1. Run `git log --pretty=format:"- %s" <latest_tag>..HEAD` to collect
+   changes since the last release.
+2. Add a new section at the top of CHANGELOG.md (below the header line)
+   matching the existing format:
+   ```
+   ### Version X.Y.Z - YYYY-MM-DD
+
+   #### New Features
+   - feature description (#PR)
+
+   #### Bug Fixes & Improvements
+   - fix description (#PR)
+   ```
+3. Use today's date.  Categorize entries under "New Features" and/or
+   "Bug Fixes & Improvements" as appropriate.
+4. Run `/humanizer` on the changelog text before writing it.
+
+## Step 4 -- Commit and push
+
+```bash
+git add CHANGELOG.md
+git commit -m "Update CHANGELOG for vX.Y.Z release"
+git push -u origin release/vX.Y.Z
+```
+
+## Step 5 -- Verify CI
+
+1. Run `gh pr create --title "Release vX.Y.Z" --body "Changelog update for vX.Y.Z major release."` to open a PR against master.
+2. Wait for CI:
+   ```bash
+   gh pr checks <PR_NUMBER> --watch
+   ```
+3. If CI fails, fix the issue, amend or add a commit, push, and re-check.
+
+## Step 6 -- Merge the release branch
+
+```bash
+gh pr merge <PR_NUMBER> --merge --delete-branch
+```
+
+## Step 7 -- Tag the release
+
+```bash
+git checkout master && git pull
+git tag -a vX.Y.Z -m "Version X.Y.Z"
+git push origin vX.Y.Z
+```
+
+Do **not** sign the tag (`-s` flag omitted).
+
+## Step 8 -- Create a GitHub release
+
+```bash
+gh release create vX.Y.Z --title "vX.Y.Z" --notes-file <(changelog_excerpt)
+```
+
+Use the CHANGELOG section for this version as the release notes body.
+Run `/humanizer` on the notes before creating the release.
+
+## Step 9 -- Verify PyPI
+
+1. The `pypi-publish.yml` workflow triggers automatically on tag push.
+2. Watch the workflow:
+   ```bash
+   gh run list --workflow=pypi-publish.yml --limit 1
+   gh run watch <RUN_ID>
+   ```
+3. Confirm the new version appears:
+   ```bash
+   pip index versions xarray-spatial 2>/dev/null || echo "Check https://pypi.org/project/xarray-spatial/"
+   ```
+
+## Step 10 -- Summary
+
+Print the new version, links to the PR, GitHub release, and PyPI page.
+
+---
+
+## General rules
+
+- Run `/humanizer` on all text destined for GitHub: PR title/body, release
+  notes, commit messages, and any comments left on issues or PRs.
+- Any temporary files created during the release (build artifacts, scratch
+  files) must use unique names including the version number to avoid
+  collisions (e.g. `changelog-draft-1.0.0.md`).

.claude/commands/release-minor.md

@@ -0,0 +1,109 @@
+# Release: Minor
+
+Cut a minor release (X.Y.Z -> X.Y+1.0). Follow every step below in order.
+
+$ARGUMENTS
+
+---
+
+## Step 1 -- Determine the new version
+
+1. Run `git tag --sort=-v:refname | head -5` to find the latest tag.
+2. Parse the current version (format `vX.Y.Z`).
+3. Increment the **minor** component and reset patch: `X.Y.Z` -> `X.(Y+1).0`.
+4. Store the new version string (without `v` prefix) for later steps.
+
+## Step 2 -- Create a release branch
+
+```bash
+git checkout master && git pull
+git checkout -b release/vX.Y.Z
+```
+
+## Step 3 -- Update CHANGELOG.md
+
+1. Run `git log --pretty=format:"- %s" <latest_tag>..HEAD` to collect
+   changes since the last release.
+2. Add a new section at the top of CHANGELOG.md (below the header line)
+   matching the existing format:
+   ```
+   ### Version X.Y.Z - YYYY-MM-DD
+
+   #### New Features
+   - feature description (#PR)
+
+   #### Bug Fixes & Improvements
+   - fix description (#PR)
+   ```
+3. Use today's date.  Categorize entries under "New Features" and/or
+   "Bug Fixes & Improvements" as appropriate.
+4. Run `/humanizer` on the changelog text before writing it.
+
+## Step 4 -- Commit and push
+
+```bash
+git add CHANGELOG.md
+git commit -m "Update CHANGELOG for vX.Y.Z release"
+git push -u origin release/vX.Y.Z
+```
+
+## Step 5 -- Verify CI
+
+1. Run `gh pr create --title "Release vX.Y.Z" --body "Changelog update for vX.Y.Z minor release."` to open a PR against master.
+2. Wait for CI:
+   ```bash
+   gh pr checks <PR_NUMBER> --watch
+   ```
+3. If CI fails, fix the issue, amend or add a commit, push, and re-check.
+
+## Step 6 -- Merge the release branch
+
+```bash
+gh pr merge <PR_NUMBER> --merge --delete-branch
+```
+
+## Step 7 -- Tag the release
+
+```bash
+git checkout master && git pull
+git tag -a vX.Y.Z -m "Version X.Y.Z"
+git push origin vX.Y.Z
+```
+
+Do **not** sign the tag (`-s` flag omitted).
+
+## Step 8 -- Create a GitHub release
+
+```bash
+gh release create vX.Y.Z --title "vX.Y.Z" --notes-file <(changelog_excerpt)
+```
+
+Use the CHANGELOG section for this version as the release notes body.
+Run `/humanizer` on the notes before creating the release.
+
+## Step 9 -- Verify PyPI
+
+1. The `pypi-publish.yml` workflow triggers automatically on tag push.
+2. Watch the workflow:
+   ```bash
+   gh run list --workflow=pypi-publish.yml --limit 1
+   gh run watch <RUN_ID>
+   ```
+3. Confirm the new version appears:
+   ```bash
+   pip index versions xarray-spatial 2>/dev/null || echo "Check https://pypi.org/project/xarray-spatial/"
+   ```
+
+## Step 10 -- Summary
+
+Print the new version, links to the PR, GitHub release, and PyPI page.
+
+---
+
+## General rules
+
+- Run `/humanizer` on all text destined for GitHub: PR title/body, release
+  notes, commit messages, and any comments left on issues or PRs.
+- Any temporary files created during the release (build artifacts, scratch
+  files) must use unique names including the version number to avoid
+  collisions (e.g. `changelog-draft-0.9.0.md`).