You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/agents/agent_instructions.md
+14-14Lines changed: 14 additions & 14 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -39,20 +39,20 @@ Your mission is twofold:
39
39
To assist with specific domains, specialized instruction files are available in `docs/agents/instructions`.
40
40
**Mandate:** You MUST read and apply the relevant project-specific context file when working within these domains. These files outline architectural constraints, preferred tools, and forbidden patterns for this specific repository.
Copy file name to clipboardExpand all lines: docs/agents/instructions/analytics.md
+10-8Lines changed: 10 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,15 +1,17 @@
1
+
---
2
+
name: analytics
3
+
description: Analytics Skill Instructions
4
+
---
1
5
# Analytics Skill Instructions
2
6
3
-
\<primary_directive>
7
+
## Primary Directive
4
8
Your primary objective is to extract truth from experimental data without fooling yourself or others.
5
9
**MANDATE:** Apply the project-specific rules outlined below for all analytics and EDA tasks.
6
-
\</primary_directive>
7
10
8
-
<context>
11
+
## Context
9
12
In a geospatial research setting, data analysis must account for spatial dimensions, non-standard projections, and highly skewed physical measurements (e.g., radar reflectivity, atmospheric depth).
10
-
</context>
11
13
12
-
<standards>
14
+
## Standards
13
15
You MUST adhere to the following project-specific standards when performing or reviewing data analysis:
14
16
15
17
### 1. Geospatial Exploratory Data Analysis (EDA)
@@ -33,11 +35,11 @@ You MUST adhere to the following project-specific standards when performing or r
- ❌ **Ignoring Nodata:** You MUST NOT silently calculate statistics over arrays containing raw nodata values (e.g., averaging `-9999` with valid data). Use `xarray.where()` or masked arrays.
41
43
- ❌ **"Magic" Outlier Removal:** You MUST NOT remove spatial data points just because they "look wrong" without explicit domain-specific justification.
Copy file name to clipboardExpand all lines: docs/agents/instructions/formal_planning.md
+5-2Lines changed: 5 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,8 +1,11 @@
1
+
---
2
+
name: formal_planning
3
+
description: Formal Planning Protocol
4
+
---
1
5
# Formal Planning Protocol
2
6
3
-
\<primary_directive>
7
+
## Primary Directive
4
8
**MANDATE:** Ensure any generated plan adheres to the structure below.
5
-
\</primary_directive>
6
9
7
10
When the user explicitly asks for a "plan," "architecture," "design," or "proposal"—or when embarking on a multi-step/multi-domain implementation—you must use the **Formal Design Document** structure below, saving it to `docs/agents/planning/<TASK_DESCRIPTION>_PLAN.md`.
Your goal is to help build state-of-the-art models and data pipelines that are reproducible, reliable, and well-documented.
5
9
**MANDATE:** Apply the project-specific rules outlined below for all ML and geospatial processing tasks.
6
-
\</primary_directive>
7
10
8
-
<context>
11
+
## Context
9
12
This project deals heavily with geospatial datasets (Sentinel-2, Radar, etc.) which introduce unique memory and projection challenges compared to standard ML pipelines.
10
-
</context>
11
13
12
-
<standards>
14
+
## Standards
13
15
You MUST enforce the following project-specific standards:
14
16
15
17
### 1. Geospatial Data Handling
@@ -27,11 +29,11 @@ You MUST enforce the following project-specific standards:
27
29
28
30
-**Config-Driven:** Hyperparameters and dataset paths MUST be externalized to configuration files and loaded via Pydantic models.
29
31
30
-
</standards>
32
+
31
33
32
-
\<forbidden_patterns>
34
+
## Forbidden Patterns
33
35
34
36
- ❌ **Silent OOMs:** You MUST NOT write data loaders that attempt to load massive raster datasets entirely into RAM.
35
37
- ❌ **Ignoring CRS:** You MUST NEVER perform spatial joins or distance calculations without first asserting both datasets share the exact same CRS.
36
38
- ❌ **Fitting on Test Data:** You MUST NEVER allow data transformations to be fitted on the validation or test sets.
Your primary responsibility is the horizontal integration of all research components.
5
9
**MANDATE:** Apply the project-specific rules outlined below for all orchestration and integration tasks.
6
-
\</primary_directive>
7
10
8
-
<context>
11
+
## Context
9
12
In this repository, successful orchestration means tying together raw geospatial data fetching (STAC/Copernicus), pre-processing (Rasterio/Xarray), and output generation (COGs/Zarr).
10
-
</context>
11
13
12
-
<workflow>
14
+
## Workflow
13
15
For any task requiring more than a minor fix, you MUST enforce the following framework:
14
16
15
17
### 1. The Written Plan (Mandatory)
@@ -25,11 +27,11 @@ Before writing implementation code, you MUST create or update a `<TASK_DESCRIPTI
25
27
26
28
- Implement exactly ONE step from the plan at a time.
27
29
- After completing a step, you MUST STOP and ask the user to validate the output before moving to the next step.
28
-
</workflow>
30
+
29
31
30
-
\<forbidden_patterns>
32
+
## Forbidden Patterns
31
33
32
34
- ❌ **Vertical Myopia:** You MUST NOT focus entirely on optimizing one specific file while ignoring how it breaks integration with the rest of the project (e.g., changing a config structure without updating `geospatial_tools_ini.yaml.example`).
33
35
- ❌ **Implied Contracts:** You MUST NOT build components that pass raw, untyped dictionaries to each other. Always enforce explicit data contracts (e.g., Pydantic Models, Dataclasses).
34
36
- ❌ **Skipping E2E Testing:** You MUST NOT declare a complex integration "complete" without verifying that the data flows from start to finish via `nox` testing sessions or test notebooks.
Copy file name to clipboardExpand all lines: docs/agents/instructions/plan_to_tasks.md
+5-2Lines changed: 5 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,8 +1,11 @@
1
+
---
2
+
name: plan_to_tasks
3
+
description: Plan To Tasks
4
+
---
1
5
# Plan To Tasks
2
6
3
-
\<primary_directive>
7
+
## Primary Directive
4
8
**MANDATE:** Decompose a plan into modular, atomic tasks, each documented in its own file (or a structured document) with all the context needed for implementation and verification.
Your objective is to elevate research scripts into robust, maintainable, and type-safe software.
5
9
**MANDATE:** Apply the project-specific rules outlined below for all Python development and QA tasks.
6
-
\</primary_directive>
7
10
8
-
<context>
11
+
## Context
9
12
This project relies heavily on modern Python tooling and strictly enforced quality assurance.
10
13
-**Pre-commit is Central:** All QA tasks (linting, formatting, type checking) are orchestrated via `pre-commit`.
11
14
-**Environment & Build:** We use `uv` for package management and `hatchling` as the build backend (defined in `pyproject.toml`).
12
15
-**Task Automation:** We use `nox` for isolated test environments and task execution.
13
16
-**Makefile:** We use a makefile to automate and orchestrate most things in this project. Use `make targets` to discover the available targets.
14
-
</context>
15
17
16
-
<standards>
18
+
## Standards
17
19
You MUST strictly adhere to the following project-specific Python standards:
18
20
19
21
### 1. QA & Tooling
@@ -27,19 +29,20 @@ You MUST strictly adhere to the following project-specific Python standards:
27
29
-**Strict Typing:** You MUST use type hints for ALL function arguments and return values (e.g., `def process(data: str | Any) -> pd.DataFrame`).
28
30
-**Filesystem Paths:** You MUST NEVER use `os.path`. ALWAYS use `pathlib.Path` for all file and directory manipulations.
29
31
-**Logging:** Use `structlog` for application flow. NEVER use `print()` for production code.
32
+
-**Function Calls:** Prefer keyword arguments for complex function calls to enhance readability and maintainability.
30
33
-**Data Structures:** ALWAYS use `@dataclass` or `pydantic` models for complex structures instead of untyped dictionaries.
31
34
-**Type Hints Format:** Always prefer X | Y format over Union[X, Y].
32
-
-**Docstrings:** Always add docstrings to your functions and classes. Use the Google standard for docstrings. Don't show types in docstrings.
35
+
-**Docstrings:** Always add docstrings to your functions and classes. Use the Google standard for docstrings and follow the Diátaxis framework for documentation structure. Don't show types in docstrings.
33
36
34
37
### 3. Testing & Performance
35
38
36
39
-**Vectorization:** ALWAYS prefer vectorized operations (NumPy, Pandas, Polars, Xarray) over native Python `for` loops when processing geospatial data.
37
-
</standards>
40
+
38
41
39
-
\<forbidden_patterns>
42
+
## Forbidden Patterns
40
43
41
44
- ❌ **Bypassing Pre-commit:** Do not commit code that fails `pre-commit` checks. Fix the underlying linting or typing issue.
42
45
- ❌ **Global Mutable State:** You MUST NEVER define or mutate global variables to pass state between functions.
43
46
- ❌ **Magic Numbers/Strings:** You MUST NOT hardcode numeric constants. Extract them to Pydantic settings or config classes.
44
47
- ❌ **Bare Except Blocks:** You MUST NEVER use `except: pass` or `except Exception: pass`.
0 commit comments