Claude Skill

swe-devops-standards

Always invoke to review, repair, or deliver geospatial or GeoAI code, including contract compliance, security, error handling, transactions, tests, scripts, functions, notebooks, packages, CI/CD, and repository changes, even when deployment is not requested. Pair with the domain

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download muend-geoai-skills-skills_swe-devops-standards-096e5d4.zip · 4 KB
Part of muend/geoai-skills — 18 skills

Install

skills CLI npx skills add https://github.com/muend/geoai-skills/tree/main/skills/swe-devops-standards
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install muend-geoai-skills@llmmart
Git git clone https://github.com/muend/geoai-skills.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole muend/geoai-skills collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Geospatial SWE & DevOps Standards

Purpose: code produced as part of geospatial work should run in the user's real environment and meet peer-level engineering quality. Apply these rules only when code or repository artifacts are in scope.

1. Environment realities (the top error source)

  • Script-first by default: no %matplotlib inline, !pip install, or display() unless the user is explicitly in a notebook. Every file runs from a terminal via python script.py behind an if __name__ == "__main__": block. (Cell markers like # %% are fine as an addition — the script must also work without them.)
  • Cross-platform paths: always pathlib.Path; never string-concatenate or hardcode / or \\. Ask or detect the user's OS before giving shell commands; give CMD/PowerShell syntax on Windows, POSIX elsewhere — don't mix (export vs set, venv/bin/activate vs venv\Scripts\activate).
  • Encodings: explicit encoding="utf-8" on every text file open — Windows still defaults to legacy code pages, and non-ASCII content corrupts silently.
  • Modern Python (3.11+): X | None unions, type aliases, structural pattern matching where they clarify; state the minimum version if a feature requires it.

2. Code quality defaults

Applied to every generated function/module, even when not asked:

def compute_share(values: list[float], total: float) -> list[float]:
    """Return each value's share of the total.

    Args:
        values: Values to compute shares for.
        total: Denominator; must be non-zero.

    Returns:
        Shares in the same order as values.

    Raises:
        ValueError: If total is zero.
    """
    if total == 0:
        raise ValueError("total must be non-zero — share is undefined.")
    return [v / total for v in values]
  • Type hints on every signature; dataclass/TypeAlias for complex types.
  • Google-style docstrings; one-liners suffice for trivial functions.
  • Never bare except:; catch specific exceptions, handle or re-raise with raise ... from e. A silent pass costs a week of debugging.
  • logging over print (leveled, formatted), except user-facing CLI output.
  • Note algorithmic complexity where it matters ("this is O(n log n), safe at n>10⁶") — especially around nested loops and pandas apply.
  • Magic numbers → named module-level constants.

3. Testing and verification

  • Offer at least a skeleton pytest for every function carrying real logic:
# test_compute.py — run: python -m pytest -q
import pytest
from compute import compute_share

def test_basic() -> None:
    assert compute_share([1, 1], 2) == [0.5, 0.5]

def test_zero_total_raises() -> None:
    with pytest.raises(ValueError):
        compute_share([1.0], 0)
  • Numerical code: test edge cases — empty input, NaN, negatives, single element.
  • Run generated code yourself when an execution environment exists; otherwise mark it explicitly "not executed" — no silent assumptions.

4. Dependencies and reproducibility

  • New project → virtual environment + pinned requirements.txt (package==version); never "install the latest".
  • Seed randomness and put the seed in config (details in ml-experiment-standards).
  • Note environment-difference risks where relevant (BLAS, CUDA, locale).

5. Git practices

  • Conventional Commits: feat(scope): ..., fix: ..., refactor: ...; the body explains why — the diff already shows what.
  • Commit in meaningful units; warn against 500-line single commits.
  • Default .gitignore: venv/, __pycache__/, *.pyc, large data files (suggest DVC/LFS), IDE folders.

6. Automation / DevOps

  • CI: minimal GitHub Actions for test + lint (ruff); note OS-runner differences if jobs must run on Windows too.
  • Docker: start from python:3.12-slim, simple single-stage until size/caching demands more; note image size and build-cache implications.
  • Monitoring: any long-lived service/pipeline ships three signals minimum: structured logs, failure alerting, basic metrics (duration, volume). ML services add drift checks (see ml-experiment-standards).
  • Scheduled jobs: match the user's platform — cron on POSIX, Task Scheduler (schtasks) on Windows.

7. Code review mode

Review in this order and report findings by severity: correctness (edge cases, silent failures) → security (injection, secrets, path traversal) → performance (N+1, needless copies, O(n²)) → readability. Every finding ships with the suggested fix as code — never "this is bad" and nothing else.

Execution contract

  • Workflow: clarify the geospatial code's contract; reproduce the environment; inspect correctness and data invariants; implement the smallest safe change; test; package; document operations and rollback.
  • Decision rules: apply this skill to geospatial software and pipeline delivery, not generic non-spatial coding; scale CI, containers, and observability to the actual deployment risk.
  • Verification protocol: run focused and regression tests, lint and type checks where configured, exercise CRS/nodata/geometry edge cases, verify clean installation, and review CI artifacts.
  • Failure modes: block release for silent data loss, nondeterminism, mutable hidden state, unpinned critical dependencies, secrets, platform assumptions, missing rollback, or unhandled spatial edge cases.
  • Deliverables: reviewed code, tests, reproducible environment and lock data, CI configuration, operational notes, risk-ranked findings, observability plan, and rollback instructions.
  • Source freshness: consult the authoritative source registry before applying packaging, CI, testing, or supply-chain guidance.
Files (geoai-skills)
  • agents
    • openai.yaml 215 B
      interface:
        display_name: "Geospatial SWE and DevOps"
        short_description: "Ship reliable geospatial code and pipelines"
        default_prompt: "Use $swe-devops-standards to make this geospatial code production-ready."
      
  • references
    • authoritative-sources.md 844 B
      # Authoritative sources
      
      - Last verified: 2026-07-19
      - Review cadence: every 3 months
      - Refresh triggers: Python packaging, pytest, GitHub Actions, or supported runtime change
      
      ## Canonical sources
      
      - [Python Packaging User Guide](https://packaging.python.org/en/latest/) — environments, package metadata, builds, and dependency practice.
      - [pytest documentation](https://docs.pytest.org/en/stable/) — test discovery, fixtures, and configuration.
      - [GitHub Actions documentation](https://docs.github.com/en/actions) — workflow syntax, security, artifacts, and runners.
      - [OpenSSF Scorecard documentation](https://scorecard.dev/) — repository security posture checks.
      
      Pin production dependencies and CI actions by immutable version where practical. Revalidate operating-system matrices and supply-chain controls after platform changes.
      
  • SKILL.md 6.3 KB
    ---
    name: swe-devops-standards
    description: >-
      Always invoke to review, repair, or deliver geospatial or GeoAI code,
      including contract compliance, security, error handling, transactions,
      tests, scripts, functions, notebooks, packages, CI/CD, and repository
      changes, even when deployment is not requested. Pair with the domain skill
      for ETL and other production code. Covers CRS/data invariants, dependencies,
      cross-platform reproducibility, automation, and shipping. Do not trigger for
      unrelated software or analysis requesting no code or repository artifact.
    license: MIT
    metadata:
      author: Muhammed Enes Duran
    ---
    
    # Geospatial SWE & DevOps Standards
    
    Purpose: code produced as part of geospatial work should run in the user's
    real environment and meet peer-level engineering quality. Apply these rules
    only when code or repository artifacts are in scope.
    
    ## 1. Environment realities (the top error source)
    
    - **Script-first by default**: no `%matplotlib inline`, `!pip install`, or
      `display()` unless the user is explicitly in a notebook. Every file runs
      from a terminal via `python script.py` behind an
      `if __name__ == "__main__":` block. (Cell markers like `# %%` are fine
      as an addition — the script must also work without them.)
    - **Cross-platform paths**: always `pathlib.Path`; never string-concatenate
      or hardcode `/` or `\\`. Ask or detect the user's OS before giving shell
      commands; give CMD/PowerShell syntax on Windows, POSIX elsewhere —
      don't mix (`export` vs `set`, `venv/bin/activate` vs
      `venv\Scripts\activate`).
    - **Encodings**: explicit `encoding="utf-8"` on every text file open —
      Windows still defaults to legacy code pages, and non-ASCII content
      corrupts silently.
    - **Modern Python (3.11+)**: `X | None` unions, `type` aliases, structural
      pattern matching where they clarify; state the minimum version if a
      feature requires it.
    
    ## 2. Code quality defaults
    
    Applied to every generated function/module, even when not asked:
    
    ```python
    def compute_share(values: list[float], total: float) -> list[float]:
        """Return each value's share of the total.
    
        Args:
            values: Values to compute shares for.
            total: Denominator; must be non-zero.
    
        Returns:
            Shares in the same order as values.
    
        Raises:
            ValueError: If total is zero.
        """
        if total == 0:
            raise ValueError("total must be non-zero — share is undefined.")
        return [v / total for v in values]
    ```
    
    - Type hints on every signature; `dataclass`/`TypeAlias` for complex types.
    - Google-style docstrings; one-liners suffice for trivial functions.
    - **Never bare `except:`**; catch specific exceptions, handle or re-raise
      with `raise ... from e`. A silent `pass` costs a week of debugging.
    - `logging` over `print` (leveled, formatted), except user-facing CLI
      output.
    - Note algorithmic complexity where it matters ("this is O(n log n), safe
      at n>10⁶") — especially around nested loops and pandas `apply`.
    - Magic numbers → named module-level constants.
    
    ## 3. Testing and verification
    
    - Offer at least a skeleton pytest for every function carrying real logic:
    
    ```python
    # test_compute.py — run: python -m pytest -q
    import pytest
    from compute import compute_share
    
    def test_basic() -> None:
        assert compute_share([1, 1], 2) == [0.5, 0.5]
    
    def test_zero_total_raises() -> None:
        with pytest.raises(ValueError):
            compute_share([1.0], 0)
    ```
    
    - Numerical code: test edge cases — empty input, NaN, negatives, single
      element.
    - Run generated code yourself when an execution environment exists;
      otherwise mark it explicitly "not executed" — no silent assumptions.
    
    ## 4. Dependencies and reproducibility
    
    - New project → virtual environment + pinned `requirements.txt`
      (`package==version`); never "install the latest".
    - Seed randomness and put the seed in config (details in
      `ml-experiment-standards`).
    - Note environment-difference risks where relevant (BLAS, CUDA, locale).
    
    ## 5. Git practices
    
    - Conventional Commits: `feat(scope): ...`, `fix: ...`, `refactor: ...`;
      the body explains *why* — the diff already shows *what*.
    - Commit in meaningful units; warn against 500-line single commits.
    - Default `.gitignore`: `venv/`, `__pycache__/`, `*.pyc`, large data files
      (suggest DVC/LFS), IDE folders.
    
    ## 6. Automation / DevOps
    
    - **CI**: minimal GitHub Actions for test + lint (ruff); note OS-runner
      differences if jobs must run on Windows too.
    - **Docker**: start from `python:3.12-slim`, simple single-stage until
      size/caching demands more; note image size and build-cache implications.
    - **Monitoring**: any long-lived service/pipeline ships three signals
      minimum: structured logs, failure alerting, basic metrics (duration,
      volume). ML services add drift checks (see `ml-experiment-standards`).
    - **Scheduled jobs**: match the user's platform — cron on POSIX,
      Task Scheduler (`schtasks`) on Windows.
    
    ## 7. Code review mode
    
    Review in this order and report findings by severity: correctness (edge
    cases, silent failures) → security (injection, secrets, path traversal) →
    performance (N+1, needless copies, O(n²)) → readability. Every finding
    ships with the suggested fix as code — never "this is bad" and nothing
    else.
    
    ## Execution contract
    
    - **Workflow:** clarify the geospatial code's contract; reproduce the environment; inspect correctness and data invariants; implement the smallest safe change; test; package; document operations and rollback.
    - **Decision rules:** apply this skill to geospatial software and pipeline delivery, not generic non-spatial coding; scale CI, containers, and observability to the actual deployment risk.
    - **Verification protocol:** run focused and regression tests, lint and type checks where configured, exercise CRS/nodata/geometry edge cases, verify clean installation, and review CI artifacts.
    - **Failure modes:** block release for silent data loss, nondeterminism, mutable hidden state, unpinned critical dependencies, secrets, platform assumptions, missing rollback, or unhandled spatial edge cases.
    - **Deliverables:** reviewed code, tests, reproducible environment and lock data, CI configuration, operational notes, risk-ranked findings, observability plan, and rollback instructions.
    - **Source freshness:** consult [the authoritative source registry](references/authoritative-sources.md) before applying packaging, CI, testing, or supply-chain guidance.
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related