adapt-model-to-easytsf

Category: Data & AI | Uploader: smilehanCN | Downloads: 0 | Version: v1.0（Latest）

Inspect external prediction model implementations and adapt them to EasyTSF task contracts. Use when the user provides model code, class definitions, forward logic, or config fragments and wants Codex to classify the target task as `sequence_prediction`, `graph_prediction`, or `grid_prediction`, determine the current repository fit, and produce either a direct adaptation plan or a repository extension plan.

Changelog: Source: GitHub https://github.com/smilehanCN/EasyTSF

Directory Structure

Current level: tree/next/skills/adapt-model-to-easytsf/

📁 agents/
- 📄 openai.yaml 338 B
📁 assets/
- 📄 benchmark_stub.py 886 B
- 📄 graph_prediction_experiment_stub.yaml 650 B
- 📄 grid_prediction_experiment_stub.yaml 608 B
- 📄 model_stub.py 620 B
- 📄 sequence_prediction_experiment_stub.yaml 721 B
📁 references/
- 📄 adaptation-playbook.md 1.4 KB
- 📄 model-interface-mapping.md 1.6 KB
- 📄 repo-contract.md 1.8 KB
- 📄 task-taxonomy.md 791 B
📄 SKILL.md 4.5 KB

SKILL.md

---
name: adapt-model-to-easytsf
description: Inspect external prediction model implementations and adapt them to EasyTSF task contracts. Use when the user provides model code, class definitions, forward logic, or config fragments and wants Codex to classify the target task as `sequence_prediction`, `graph_prediction`, or `grid_prediction`, determine the current repository fit, and produce either a direct adaptation plan or a repository extension plan.
---

# Adapt Model to EasyTSF

## Overview

Use this skill to adapt external prediction models to EasyTSF by task, not by forcing everything into one existing runtime path. Work from code first. Use papers only to recover intent when the implementation is incomplete or ambiguous.

Before editing code, read:

- `references/task-taxonomy.md`
- `references/repo-contract.md`
- `references/model-interface-mapping.md`
- `references/adaptation-playbook.md`

Use `assets/model_stub.py`, the task-specific experiment stubs, and `assets/benchmark_stub.py` when you need a stable starting point for generated output.

## Workflow

1. Inspect the source model code.
   Read the external `__init__`, `forward`, helper modules, and config fragments. Extract:
   - constructor parameters
   - forward inputs
   - tensor layout assumptions
   - side inputs or runtime state
   - output shape
2. Classify the target prediction task.
   Decide whether the model most naturally fits `sequence_prediction`, `graph_prediction`, or `grid_prediction`.
3. Check the current repository fit.
   If the model aligns with the current sequence path, produce a direct adaptation plan. If it depends on graph or grid inputs, produce a repository extension plan instead of treating those inputs as automatic blockers.
4. Map the model onto the target EasyTSF contract.
   - convert constructor arguments into explicit task-aware parameters
   - map those parameters onto flat experiment config keys
   - define the target model interface for the classified task
   - spell out which datamodule outputs and task responsibilities are required
   - choose the correct task-specific experiment stub and the shared benchmark stub
   - identify benchmark `param_space` candidates from source code, scripts, or close EasyTSF baselines
   - define the target benchmark file placement under `config/benchmarks/<model_id>/`
5. Produce adaptation output.
   Default deliverable:
   - task classification
   - current repository fit
   - target `Model.__init__` parameter list
   - target model interface and shape mapping
   - required repository additions, if any
   - one example experiment preset draft
   - one example benchmark config draft

## Stop Conditions

Stop and report blockers when any of the following is true:

- the source model is not a prediction model
- the source code is too incomplete to classify the task or infer the interface
- the requested adaptation depends on hidden runtime behavior that is not visible in code or config
- the user asks for invented inputs that do not exist in the source task

Do not stop just because the model needs graph inputs, grid tensors, or richer side inputs. Those should trigger an extension plan.

## Output Format

When giving the adaptation result, organize it in this order:

1. Task classification
2. Current repository fit
3. EasyTSF constructor mapping
4. Target model interface and shape mapping
5. Required repository additions
6. Example experiment preset fields
7. Example benchmark config draft

When drafting benchmark output, follow these rules:

- always produce a complete `benchmark_config` draft, even when the task still needs repository extensions
- point `experiment` at the matching experiment preset draft path, for example `config/experiments/<model_id>/<dataset>.yaml`
- place `search_save_dir` under `save/benchmarks/<benchmark_name>`
- prefer benchmark search keys and ranges that are visible in source code, original scripts, or close EasyTSF baselines
- if no trustworthy search range exists, keep the search narrow or single-valued and mark uncertain ranges with a short comment such as `replace with validated search range`
- keep `search_config` aligned with the current EasyTSF benchmark surface instead of inventing a model-specific runner contract
- for graph or grid tasks that are not yet runnable, clearly mark the benchmark draft as a planning draft rather than a runnable config

If the user asks for implementation, generate the model, experiment preset, and benchmark sample config from the mapped contract instead of copying the source project structure wholesale.

Comments 0

Latest | Hot

Please login before commenting.

Loading comments...

adapt-model-to-easytsf

Directory Structure

SKILL.md

Report

Notice