Ai and devops (#249)

* Devops and AI Related Improvements

Improve factoring of agent instructions for Copilot/Claude

Simplify devcontainer config and add per-file debug launch config

* Add .claude to git tracking for skills and common settings

Update changelog to match Keep A Changelog formatting

* Apply suggestions from code review

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

---------

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Author: medley56

.claude/CLAUDE.md

@@ -0,0 +1 @@
+@.github/instructions/space_packet_parser.instructions.md

.devcontainer/claude-settings.json .claude/settings.json.devcontainer/claude-settings.json renamed to .claude/settings.json

@@ -0,0 +1,99 @@
+Update `docs/source/changelog.md` based on recent git history. Follow these steps exactly.
+
+## Step 1 — Gather context
+
+Run the following commands:
+
+```bash
+git tag --sort=-version:refname | head -1
+```
+
+Save the output as `LATEST_TAG`. Then run:
+
+```bash
+git log <LATEST_TAG>..HEAD --oneline --no-merges
+git log <LATEST_TAG>..HEAD --oneline --merges
+```
+
+Read these files in full:
+
+- `docs/source/changelog.md`
+- `pyproject.toml` (find `version =` under `[project]`)
+- `meta.yaml` (find `version:` field)
+- `CITATION.cff` (find `version:` field)
+
+## Step 2 — Detect release scenario
+
+Compare the version in `pyproject.toml` / `meta.yaml` / `CITATION.cff` against `LATEST_TAG`.
+
+- If the version in the files **differs** from `LATEST_TAG`, use `AskUserQuestion` to confirm:
+  > "Version X.Y.Z appears in pyproject.toml/meta.yaml/CITATION.cff but the latest git tag is LATEST_TAG. Is this a new release that should be added as a versioned section in the changelog?"
+  - If the user confirms → **Scenario A** (new release)
+  - If the user declines → **Scenario B** (update unreleased only)
+- If the version already matches `LATEST_TAG` → **Scenario B** automatically.
+
+## Step 3 — Analyze git log
+
+From the combined output of both `git log` commands:
+
+- Identify meaningful changes. Look for PR numbers via patterns `(#NNN)` or `Merge pull request #NNN`.
+- **Skip**: pure Dependabot dependency bumps (e.g. "Bump X from Y to Z"), CI/workflow-only changes with no user-visible impact.
+- Classify each meaningful change into one of these Keep A Changelog categories:
+  - `Added` — new features or capabilities
+  - `Changed` — changes to existing behavior; prefix `_BREAKING_:` for breaking changes
+  - `Fixed` — bug fixes
+  - `Removed` — removed features or APIs; prefix `_BREAKING_:` for breaking removals
+  - `Deprecated` — features marked for future removal
+  - `Security` — security fixes
+- Format each entry as:
+  ```
+  - Description of the change. [#NNN](https://github.com/lasp/space_packet_parser/issues/NNN)
+  ```
+- Check the existing `## [Unreleased]` section in the changelog — do **not** duplicate entries already present there.
+
+## Step 4 — Edit the changelog
+
+### Scenario A — New release (user confirmed)
+
+Let:
+
+- `NEW_VERSION` = version from `pyproject.toml`
+- `TODAY` = today's date in `YYYY-MM-DD` format
+- `PREV_TAG` = `LATEST_TAG`
+
+1. Rename the `## [Unreleased]` heading to `## [NEW_VERSION] - TODAY`. Populate its body with the categorized entries from Step 3, preserving any entries that were already in `[Unreleased]` before them.
+2. Insert a new empty `## [Unreleased]` section above the renamed section:
+
+   ```markdown
+   ## [Unreleased]
+
+   ## [NEW_VERSION] - TODAY
+   ```
+
+3. Update the footer diff links at the bottom of the file:
+   - Change the `[unreleased]` link to:
+     ```
+     [unreleased]: https://github.com/lasp/space_packet_parser/compare/NEW_VERSION...HEAD
+     ```
+   - Insert a new versioned link immediately after the `[unreleased]` line:
+     ```
+     [NEW_VERSION]: https://github.com/lasp/space_packet_parser/compare/PREV_TAG...NEW_VERSION
+     ```
+
+### Scenario B — Update unreleased only
+
+1. Add the categorized entries from Step 3 under the appropriate `### Category` headings within the existing `## [Unreleased]` section. Create any missing `### Category` headings as needed.
+2. Footer: if `[unreleased]` currently points to a tag other than `LATEST_TAG`, update it to:
+   ```
+   [unreleased]: https://github.com/lasp/space_packet_parser/compare/LATEST_TAG...HEAD
+   ```
+
+## Step 5 — Verify
+
+After editing, confirm:
+
+- `## [Unreleased]` is the first version section in the file.
+- All new entries are under the correct `### Category` heading.
+- The footer `[unreleased]` link ends with `...HEAD`.
+- No duplicate entries exist.
+- Footer versioned links are in descending version order.

.claude/skills/update-changelog/SKILL.md

@@ -79,6 +79,3 @@ RUN sh -c "$(wget -O- https://github.com/deluan/zsh-in-docker/releases/download/
 # Copy and set up dev environment script
 COPY setup-dev-environment.sh /usr/local/bin/
 RUN chmod +x /usr/local/bin/setup-dev-environment.sh
-
-# Copy CLAUDE.md and settings to Claude config directory
-COPY CLAUDE.md /root/.claude/

.devcontainer/Dockerfile

@@ -29,7 +29,7 @@
         "python-envs.terminal.autoActivationType": "command",
         "python.testing.pytestEnabled": true,
         "python.testing.unittestEnabled": false,
-        "python.testing.pytestArgs": ["-s", "."],
+        "python.testing.pytestArgs": ["."],
         "debugpy.debugJustMyCode": false,
         "files.associations": {
           "*.xtce": "xml"
@@ -43,6 +43,18 @@
         },
         "ruff.organizeImports": true,
         "ruff.fixAll": true
+      },
+      "launch": {
+        "configurations": [
+          {
+            "name": "Python Debugger: Current File",
+            "type": "debugpy",
+            "request": "launch",
+            "program": "${file}",
+            "console": "integratedTerminal",
+            "justMyCode": false
+          }
+        ]
       }
     }
   },

.devcontainer/devcontainer.json

@@ -49,11 +49,11 @@ if [ "$SSH_AVAILABLE" = "true" ]; then
     if ssh -T git@github.com 2>&1 | grep -q "successfully authenticated"; then
         echo "Successfully authenticated with GitHub via SSH."
     else
-        echo "SSH agent available but GitHub SSH authentication failed."
+        echo "SSH agent available but GitHub SSH authentication failed. This is probably because either your IDE isn't forwarding your SSH agent or you have forgotten to add your SSH key to your ssh-agent."
     fi
 else
     echo "SSH authentication not available. Using HTTPS authentication."
-    echo "You will need to authenticate either by forwarding your HTTP credentials through (should happen automatically) or by using the gh CLI."
+    echo "You will need to authenticate either by forwarding your HTTP credentials through (may happen automatically) or by using the gh CLI."
 fi
 
 # Configure Git commit signing
@@ -80,8 +80,8 @@ fi
 if { [ "$COMMIT_GPGSIGN" = "true" ] || [ "$TAG_GPGSIGN" = "true" ]; } && [ -n "$(git config --get user.signingkey)" ]; then
     SIGNING_KEY=$(git config --get user.signingkey)
     if ! gpg --list-keys "$SIGNING_KEY" >/dev/null 2>&1; then
-        echo "Warning: The signing key '$SIGNING_KEY' is not available in GPG keyring."
-        echo "Commits/tags may fail to sign."
+        echo "Warning: The signing key '$SIGNING_KEY' is not available in GPG keyring. This probably means your IDE isn't forwarding your GPG agent."
+        echo "Commits/tags may fail to sign. If you don't care about signing, run `git config --unset commit.gpgsign` and `git config --unset tag.gpgsign` to disable signing."
     else
         echo "Configured GPG signing key '$SIGNING_KEY' is available."
     fi
@@ -94,4 +94,4 @@ echo "  Signing key: $(git config --get user.signingkey | cut -c1-50)..."
 echo "  Sign commits: $(git config --get commit.gpgsign || echo 'NOT SET')"
 echo "  Sign tags: $(git config --get tag.gpgsign || echo 'NOT SET')"
 echo "  User name: $(git config --get user.name || echo 'NOT SET')"
-echo "  User email: $(git config --get user.email || echo 'NOT SET')"
+echo "  User email: $(git config --get user.email || echo 'NOT SET')"

.devcontainer/setup-dev-environment.sh

@@ -1,223 +1,5 @@
 # GitHub Copilot Instructions for Space Packet Parser
 
-## Project Overview
-
-Space Packet Parser is a Python library for decoding CCSDS (Consultative Committee for Space Data Systems) telemetry packets according to XTCE (XML Telemetric and Command Exchange) packet structure definitions. The library is based on the UML model of the XTCE specification and aims to support all but the most esoteric elements of the XTCE telemetry packet specification.
-
-### Key Concepts
-
-- **CCSDS**: Space data systems standard for space communications
-- **XTCE**: XML-based format for describing telemetry and command data structures
-- **Telemetry Packets**: Binary data packets from spacecraft/instruments that need to be parsed and decoded
-
-## Technical Requirements
-
-### Python Version
-
-- **Minimum**: Python 3.9+
-- **Tested on**: Python 3.9, 3.10, 3.11, 3.12, 3.13
-
-### Core Dependencies
-
-- `lxml>=4.8.0` - XML parsing for XTCE definitions
-- `click>=8.0` - CLI framework
-- `rich>=13.0` - Terminal formatting and output
-- `xarray` (optional) - Multi-dimensional data arrays
-- `numpy` (optional) - Numerical computing
-
-## Development Setup
-
-### Installation
-
-```bash
-# Install with development dependencies using pip
-pip install ".[test,xarray]"
-
-# For development with uv (creates and manages virtual environment)
-uv sync --all-extras
-```
-
-### Pre-commit Hooks
-
-The project uses pre-commit hooks for code quality. Install them with:
-
-```bash
-pre-commit install
-```
-
-The hooks include:
-
-- `ruff` for linting and code formatting
-- `prettier` for YAML, JSON, and Markdown formatting
-- `codespell` for spell checking
-- Security checks (AWS credentials, private keys)
-- Metadata validation
-
-## Code Style and Linting
-
-### Ruff Configuration
-
-- **Line length**: 120 characters
-- **Formatter**: ruff format (follows Black-compatible style)
-- **Linter**: Enabled rules include:
-  - E/W (pycodestyle errors and warnings)
-  - F (pyflakes)
-  - I (isort import sorting)
-  - S (flake8-bandit security)
-  - PT (flake8-pytest-style)
-  - UP (pyupgrade syntax upgrader)
-
-### Running Linters
-
-```bash
-# Format code
-ruff format
-
-# Check and fix linting issues
-ruff check --fix
-
-# Run all pre-commit hooks
-pre-commit run --all-files
-```
-
-## Testing
-
-### Running Tests
-
-```bash
-# Run all tests with coverage
-pytest --color=yes --cov --cov-report=xml
-
-# Run specific test module
-pytest tests/unit/test_xtce/
-
-# Run with verbose output
-pytest -v
-```
-
-### Test Structure
-
-- `tests/unit/` - Unit tests for individual components
-- `tests/integration/` - Integration tests for end-to-end scenarios
-- `tests/benchmark/` - Performance benchmarks
-- `conftest.py` - Shared test fixtures and configuration
-
-### Test Conventions
-
-- Use pytest fixtures defined in `conftest.py`
-- Test data is stored in `tests/test_data/`
-- Use pytest parametrize for testing multiple scenarios
-- Security checks (S-prefixed rules) are disabled in test files
-
-## Project Structure
-
-### Main Package: `space_packet_parser/`
-
-- `__init__.py` - Public API exports (`load_xtce`, `ccsds_generator`, etc.)
-- `cli.py` - Command-line interface using Click
-- `common.py` - Common data structures (SpacePacket, etc.)
-- `definitions.py` - Core definitions and base classes
-- `exceptions.py` - Custom exception classes
-- `packets.py` - Packet parsing and handling logic
-- `xtce/` - XTCE parsing and validation
-  - `definitions.py` - XTCE packet definitions
-  - `validation.py` - XTCE schema validation
-- `generators/` - Binary data generators and readers
-- `xarr.py` - XArray integration (optional feature)
-
-### Examples
-
-Example usage scripts are in `examples/` directory.
-
-### Documentation
-
-- Built with Sphinx
-- Uses MyST Parser for Markdown support
-- Hosted on ReadTheDocs: https://space-packet-parser.readthedocs.io
-- Source files in `docs/source/`
-
-## CLI Tool
-
-The package provides a command-line tool:
-
-```bash
-spp <command> [options]
-```
-
-Entry point defined in `space_packet_parser.cli:spp`
-
-## Making Changes
-
-### Before Submitting a PR
-
-1. Ensure all tests pass: `pytest`
-2. Run linters: `pre-commit run --all-files`
-3. Update tests for new functionality
-4. Update `docs/source/changelog.md` with your changes
-5. Ensure dependencies in `pyproject.toml` are current
-
-### PR Checklist (from template)
-
-- [ ] Changes are fully implemented without dangling issues or TODO items
-- [ ] Deprecated/superseded code is removed or marked with deprecation warning
-- [ ] Current dependencies have been properly specified and old dependencies removed
-- [ ] New code/functionality has accompanying tests and any old tests have been updated
-- [ ] The changelog.md has been updated
-
-## Code Review
-
-- Code changes will be reviewed by @medley56 (see CODEOWNERS)
-- Follow the project's Code of Conduct
-
-## CI/CD
-
-### GitHub Actions Workflows
-
-- `tests.yml` - Runs tests on Windows, Ubuntu, and macOS across Python 3.9-3.13
-- `test_examples.yml` - Validates example scripts
-- `release.yml` - Handles package releases
-
-### Coverage
-
-- Code coverage reports are uploaded to Codecov
-- Target: Maintain high test coverage for critical components
-
-## Common Tasks
-
-### Adding a New Parameter Type
-
-1. Define the parameter type class in `space_packet_parser/xtce/`
-2. Add parsing logic to handle the XTCE element
-3. Add unit tests in `tests/unit/test_xtce/test_parameters.py`
-4. Add integration test with a real XTCE file if applicable
-5. Update documentation
-
-### Adding a New CLI Command
-
-1. Add command function to `space_packet_parser/cli.py`
-2. Use Click decorators for arguments/options
-3. Use Rich for formatted terminal output
-4. Add tests in `tests/unit/test_cli/` (if test directory exists)
-
-### Updating XTCE Validation
-
-1. Modify validation logic in `space_packet_parser/xtce/validation.py`
-2. Update schema files if needed
-3. Add test cases for the validation scenario
-4. Ensure backward compatibility with existing XTCE files
-
-## Important Notes
-
-- The library focuses on **telemetry parsing only** (not command generation)
-- Binary data parsing is performance-critical - consider efficiency
-- XTCE files can be very large - optimize for memory efficiency
-- Support for edge cases in XTCE spec is important for mission use
-- This is production code used by real space missions (IMAP, CLARREO, Libera, CTIM-FD, MMS)
-
-## Resources
-
-- [XTCE Green Book (Informational Report)](https://public.ccsds.org/Pubs/660x2g2.pdf)
-- [XTCE Element Description (Green Book)](https://public.ccsds.org/Pubs/660x1g2.pdf)
-- [XTCE Blue Book (Recommended Standard)](https://public.ccsds.org/Pubs/660x0b2.pdf)
-- [Project Documentation](https://space-packet-parser.readthedocs.io)
-- [PyHC (Python in Heliophysics Community)](https://heliopython.org)
+This is the Space Packet Parser repository. Detailed instructions for coding rules, patterns, and testing are in
+[`instructions/space_packet_parser.instructions.md`](instructions/space_packet_parser.instructions.md).
+Please refer to that file for the most up-to-date and comprehensive guidelines on contributing to this project.