dft-siesta · v0.1.0 · 2026-03-24 · sha256 f652552e39d0c7b2
dft-siesta v0.1.0A
Immutable. This exact content is served forever at /api/v1/blob/f652552e39d0c7b2.
--- name: dft-siesta description: Route SIESTA requests to task-specific subskills based on user intent. Use when the user asks for SIESTA workflows and you must decide between static, relaxation, molecular dynamics, or electronic-analysis preparation. This orchestration skill dispatches to the correct SIESTA subskill and enforces consistent handoff to submission skills. compatibility: Requires a runnable SIESTA environment and compatible pseudopotential/basis setup for target elements. license: MIT metadata: author: qqgu version: 0.1.0 repository: https://gitlab.com/siesta-project/siesta --- # SIESTA Task Router Use this skill as the **top-level SIESTA orchestration layer**. ## Purpose This skill routes requests to one task-specific SIESTA subskill path: - `dft-siesta/static` - `dft-siesta/relax` - `dft-siesta/md` - `dft-siesta/electronic` ## Scope This router skill should: - require user-provided structure or prerequisite context - classify request intent into one SIESTA task type - collect minimal shared context before dispatch - delegate detailed parameter handling to selected subskill - enforce consistent output/handoff policy across subskills This router skill should **not**: - own detailed templates for all SIESTA tasks - execute or submit calculations - bypass subskill-specific guardrails ## Hard requirement The user must provide enough starting context: - structure input for `static` / `relax` / `md` - prerequisite converged context for `electronic` If prerequisites are missing, stop and ask for them. ## Routing rules 1. If user requests single-point SCF/energy: route to `dft-siesta/static`. 1. If user requests geometry optimization: route to `dft-siesta/relax`. 1. If user requests molecular dynamics: route to `dft-siesta/md`. 1. If user requests electronic analysis workflow: route to `dft-siesta/electronic`. 1. If intent is ambiguous, ask one focused clarification question before routing. ## Shared policy for all subskills - do not invent missing pseudopotential files - expose assumptions and unresolved scientific choices explicitly - return handoff-ready task layout - if execution is requested, hand off to `dpdisp-submit` ## Output from router Provide: 1. selected subskill path 1. why it was selected 1. minimal missing inputs (if any) 1. explicit next step (invoke selected subskill)