菜单
Map of the boettiger-lab data-and-agent stack — which GitHub repo owns which piece of the data → STAC → MCP → LLM-agent chain. Use when unsure which repo to edit for a given problem, when routing cross-repo issues, or when the root cause could plausibly be in more than one layer.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Manage S3 object storage on the NRP (National Research Platform) Nautilus cluster, which uses Ceph S3 (not AWS). Covers public vs internal endpoints, rclone usage, bucket creation, public-read policies, CORS configuration, credential handling, and syncing to source.coop. Use when working with S3 buckets on NRP Nautilus, uploading or downloading data, configuring bucket access, or syncing datasets to source.coop.
Use when storing, versioning, or sharing large files alongside a GitHub repo — model checkpoints, datasets, build artifacts, binaries, fixtures — and you want collaborators to use their GitHub access rather than separate cloud credentials. Covers ghcr.io, oras CLI, content-addressing, public/private access, and the tradeoffs vs git-lfs, S3 buckets, and GitHub Releases.
Use when browsing, querying, or reasoning about what datasets exist in a STAC catalog — especially before concluding a dataset is missing or absent. Triggers include STAC browser URLs, s3 stac-collection.json links, or any question about what data is available in a catalog.
Analyze geo-agent app behavior from LLM proxy and MCP server logs, identify inefficiencies, and trace root causes to the correct layer: STAC metadata, MCP tool descriptions, geo-agent framework, or app system prompt. TRIGGER when: reviewing agent behavior, analyzing LLM logs, improving system prompts based on observed failures, debugging tool-use loops, or optimizing query patterns in geo-agent apps.
Deploy and manage workloads on the NRP Nautilus Kubernetes cluster. Covers batch jobs (opportunistic priority class, resource requests, GPU node avoidance), ingress with HAProxy CORS and timeout annotations, NRP usage policies, and credential wiring. TRIGGER when the user mentions: kubectl, k8s, kubernetes, NRP, Nautilus, rollout, restart deployment, apply yaml, pod, job, namespace, ingress, or any cluster operation. Namespace is 'biodiversity'. Always load this skill BEFORE running any kubectl command.
Apply preferred branch-protection rulesets and squash-merge-only settings to GitHub repos. Two profiles: 'standard' (no approval required) for smaller projects and 'strict' (1 approval, dismiss stale reviews) for larger ones. TRIGGER when: setting up a new repo, applying branch protection, configuring merge settings, or the user mentions rulesets.
| name | boettiger-lab-stack |
| description | Map of the boettiger-lab data-and-agent stack — which GitHub repo owns which piece of the data → STAC → MCP → LLM-agent chain. Use when unsure which repo to edit for a given problem, when routing cross-repo issues, or when the root cause could plausibly be in more than one layer. |
The stack is a pipeline. Data flows upward; requests flow downward. Each layer has exactly one primary repo. Edit the repo that owns the behavior, not a downstream consumer that works around it.
LLM agent (browser)
│
▼
geo-agent ← client: map + chat UI. static site from CDN.
│ MCP over HTTP
▼
mcp-data-server ← server: DuckDB SQL + STAC tool-use + tile serving
│ reads
▼
STAC catalog on S3 ← metadata about the data: public-data/stac/catalog.json
│ generated by
▼
data-workflows ← pipelines that process datasets and emit STAC JSON
│
▼
raw + CNG data on S3 (Ceph via NRP)
All of this runs on NRP Nautilus (Kubernetes, Ceph S3 under the biodiversity namespace). Platform concerns live in separate skills: nrp-k8s, nrp-s3.
boettiger-lab/geo-agent — clientThe browser app. Configured per-deployment by layers-input.json + system-prompt.md + optional k8s/. JavaScript is loaded from CDN; we do not edit it here. If a user-visible bug is in the chat flow, map rendering from configured layers, or the system prompt, it's here. If the fix needs new JS capabilities, that's the upstream geoagent-app repo (CDN source), not this one. See the geo-agent skill for config details.
boettiger-lab/mcp-data-server — serverThe MCP server that LLM agents talk to. Owns: DuckDB SQL execution, STAC tool-use (browse_stac_catalog, get_stac_details, get_collection), PMTiles tile proxy, auth, k8s deployment for duckdb-mcp / dev-duckdb-mcp. Reads the STAC catalog at startup. Does NOT own the catalog content — only how it's presented to agents.
boettiger-lab/data-workflows — STAC catalog and dataset pipelinesGenerates and maintains the STAC catalog at s3-west.nrp-nautilus.io/public-data/stac/catalog.json and all per-collection stac-collection.json files. Also owns dataset-import workflows and the legacy pipelines that produced the current catalog shape. If a table:columns is wrong, missing, or a collection is structurally malformed, the fix is here, not in mcp-data-server. Note: the repo name is historical — it's really the data-and-catalog repo. See the cng-datasets skill for the current dataset-processing CLI used inside this repo.
boettiger-lab/cng-datasets — dataset-processing CLIThe tool used inside data-workflows for new datasets: URL verification, raw S3 upload, YAML-driven cloud-native conversion (GeoParquet + PMTiles + H3 hex), deployment to NRP. Emits STAC metadata as a side effect. See the cng-datasets skill for the full workflow.
get_stac_details(X) return the right columns? If the STAC has wrong columns → data-workflows. If STAC is fine but the tool output is malformed → mcp-data-server. If the output is fine but the prompt doesn't consume it → geo-agent.stac-navigation skill). If X is missing from STAC → data-workflows. If X is present but browse_stac_catalog doesn't surface it → mcp-data-server. If it surfaces but the agent doesn't use it → geo-agent (probably a system-prompt / tool-description issue).mcp-data-server fix if the code can bound the load time; nrp-k8s if it's a rollout / admission issue.data-workflows, don't patch around it in mcp-data-server. Rendering logic should assume a well-formed catalog.Edit the repo where the behavior is defined, not a repo that happens to display the symptom. The downstream repos are consumers and should stay thin. When in doubt: trace the data from its source (raw → pipeline → STAC → MCP → agent) and fix the earliest point where the wrong thing enters the chain.