菜单
Discover what SYMFLUENCE offers by introspecting the live registry and config schema — available models, forcing/observation datasets, optimizers, calibration targets, metrics, presets, templates, and config keys. Start here before choosing a model/dataset to run, or before extending the platform.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Add or modify a SYMFLUENCE data handler — forcing, geospatial attributes, remote-sensing products, or streamflow/observation datasets — across the acquisition → preprocessing → model-ready pipeline. Covers the registry + import-list mechanism, base-class contracts, mixins, config-key dispatch, and output-path conventions.
Add or modify a SYMFLUENCE hydrological model — runner, preprocessor, postprocessor, config manager, and calibration wiring — via model_manifest() and the unified R.* registries. Covers the models/ taxonomy (process-based, conceptual, ML, LSM, framework, routing) and the settings/forcing/simulations path conventions.
Add a new optimization/search algorithm to SYMFLUENCE's calibration loop — subclass OptimizationAlgorithm, implement the callback-driven optimize(), and register it in ALGORITHM_REGISTRY. Covers the algorithm↔worker contract, normalized-parameter conventions, the evaluate/record/update callbacks, and gradient support.
Run the SYMFLUENCE workflow locally — full pipeline or single steps — via the `symfluence workflow` CLI (run/step/steps/resume/status/validate/clean). Covers the 16-step order + aliases, the config-hash stage-marker system (why a step is skipped or auto-re-runs), authoring/validating a config, and the domain_{NAME} layout.
Diagnose SYMFLUENCE calibration/optimization that misbehaves — flat or stuck scores, workers crashing, params not reaching the model, NaN metrics, parallel process-dir cross-talk, or regionalization not varying spatially. Fault-tree for the DDS/PSO/SCE-UA/DE loop and the BaseWorker apply→run→metrics cycle.
| name | explore-platform |
| description | Discover what SYMFLUENCE offers by introspecting the live registry and config schema — available models, forcing/observation datasets, optimizers, calibration targets, metrics, presets, templates, and config keys. Start here before choosing a model/dataset to run, or before extending the platform. |
| when_to_use | ["A user asks \"what models / forcings / optimizers / metrics are available?\"","Choosing a HYDROLOGICAL_MODEL, FORCING_DATASET, optimizer, or metric for a config","Checking whether a config key exists / finding the right key name","Before extending the platform (see what's already registered first)"] |
SYMFLUENCE is registry-driven: models, datasets, optimizers, metrics, calibration targets, presets, and the whole config schema are looked up from a live registry, not a fixed list. Always discover capabilities by querying the platform — never rely on a hardcoded or remembered list, which goes stale. This skill is the discovery entry point for both running the platform and extending it.
symfluence listsymfluence list # all catalogs + counts
symfluence list models # registered hydrological/routing models (HYDROLOGICAL_MODEL)
symfluence list forcings # forcing & attribute datasets (FORCING_DATASET, attribute sources)
symfluence list observations # streamflow / in-situ observation networks
symfluence list optimizers # calibration algorithms (OPTIMIZATION_ALGORITHM)
symfluence list targets # calibration targets (streamflow, snow, ET, ...)
symfluence list metrics # objective/evaluation metrics (OPTIMIZATION_METRIC)
symfluence list presets # project init presets
symfluence list templates # config templates you can copy
symfluence list steps # the workflow steps (= symfluence workflow list-steps)
symfluence list config-keys # every recognized config key (the public contract)
Each catalog is read straight from the registry / config schema at runtime, so what it prints is exactly what this install supports — including any plugins.
from symfluence.core.registries import R
sorted(R.runners.keys()) # models
sorted(R.acquisition_handlers.keys()) # forcing/attribute datasets
sorted(R.observation_handlers.keys()) # observation networks
sorted(R.calibration_targets.keys()) # calibration targets (e.g. SUMMA_STREAMFLOW)
sorted(R.metrics.keys()) # metrics
from symfluence.optimization.optimizers.algorithms import list_algorithms
list_algorithms() # optimizers
from symfluence.core.config.canonical_mappings import FLAT_TO_NESTED_MAP
sorted(FLAT_TO_NESTED_MAP) # every recognized config key
R exposes ~30 registries (core/registries.py) — the same .keys() works on
any of them (preprocessors, postprocessors, workers, parameter_managers,
evaluators, delineation_strategies, bmi_adapters, …).
The catalog names ARE the config values. To run something, set the matching key:
list models → HYDROLOGICAL_MODEL: <name>list forcings → FORCING_DATASET: <name>list optimizers → OPTIMIZATION_ALGORITHM: <name>list metrics → OPTIMIZATION_METRIC: <name>list config-keys → confirm spelling / discover an optionThen author and run the config — see the run-workflow-locally skill (CLI,
required keys, stage markers, config validate).
If symfluence list doesn't show what you need, add it — the registry is the
extension surface. Pick the matching skill:
After registering, re-run symfluence list <kind> to confirm the new entry
appears (registration runs at import; if it's absent, the import or entry point
isn't wired — see the relevant skill's troubleshooting).
When a user asks "can SYMFLUENCE do X?", run the matching symfluence list (or
R.*.keys()) and answer from the result — do not answer from memory. The live
registry is the source of truth.