| name | pypots-developer |
| description | Convert a local paper and local implementation into a PyPOTS-style model integration draft with matching test drafts; use this skill when the user wants to migrate an existing model into PyPOTS, add task exports, add HPO registration, or produce a structured migration draft instead of editing the real PyPOTS source tree directly. |
PyPOTS Developer
Overview
This skill turns a local paper + local existing codebase into a PyPOTS-style migration draft.
It does not write directly into the real PyPOTS source tree. Instead, it writes all generated results into output/<task>-<model-name>/, using mirrorable pypots/ and tests/ roots so the new files can be copied into PyPOTS with minimal reshaping.
When To Use
Use this skill in these situations:
- The user wants to migrate a paper implementation into PyPOTS.
- The user provides an existing open-source implementation and wants it reorganized into PyPOTS-style
model.py / core.py / data.py / tests.
- The user wants to add the required task export patch, HPO registry patch, and test draft for a new PyPOTS model.
- The user wants a migration feasibility pass first and then a complete patch draft.
Do not use this skill when:
- The task is only to explain an existing PyPOTS model.
- The task is only to write end-user API documentation.
- The task is a small bug fix rather than a model migration.
Required Inputs
Prefer to gather these inputs first:
- local paper PDF path
- local extracted source-code directory path
- target model name
- optional target task
If the user does not provide the task, infer it first. If the inference is not stable, stop and ask instead of guessing.
Workflow Decision Tree
- Read the paper and source code, then build a migration manifest.
- Use
scripts/build_manifest.py to extract task clues, training-loop clues, input tensor clues, and output-semantic clues.
- Identify the PyPOTS task.
- See
references/task-routing.md
- Identify the implementation path.
- See
references/path-selection.md
- Choose from
standard-nn, complex-nn, or non-nn
- Map the model into the PyPOTS file layout.
- See
references/workflow.md
- Reuse templates from
assets/ instead of starting from scratch
- Initialize the output directory.
- Use
scripts/init_output.py
- Generate the complete patch draft.
- New files go to
output/<task>-<model-name>/pypots/...
- Tests go to
output/<task>-<model-name>/tests/...
- Existing-file changes are written as
.patch files under the mirrored pypots/... target paths
- Check integration points and test coverage.
- Exports and HPO:
references/integration-points.md
- Test coverage:
references/test-matrix.md
- Run
scripts/validate_output.py at the end.
Non-negotiable Rules
- Do not write directly into the real PyPOTS source tree.
- Write all generated results into
output/.
- If task routing is unstable, describe the conflict first and then ask the user.
- If the training-path decision is unstable, explain why
standard-nn vs complex-nn is unclear before asking.
pypots_cli.py usually does not need a patch in v1; do not add a new CLI subcommand just to make the output look more complete.
non-nn models do not get an HPO registry patch by default; the reason must be stated explicitly in migration-report.md.
Worked Example
- Input example:
example/
2202.08516v5.pdf
SAITS-main/
- Output example:
output/imputation-saits/
- mirrorable
pypots/ draft
- mirrorable
tests/ draft
- task export patch
- HPO patch
- migration report
Read the worked example first before migrating a new model.
Resources
references/
workflow.md: full migration workflow
task-routing.md: task-routing rules
path-selection.md: standard / complex / non-NN path rules
integration-points.md: exports, HPO, and external package path rules
test-matrix.md: test generation matrix
maintenance.md: internal maintenance rules for extending this skill
scripts/
build_manifest.py: scan the paper and source code, then produce a migration manifest
init_output.py: initialize the output directory
validate_output.py: validate whether the generated output reaches the minimum deliverable bar
assets/
standard-nn/: standard NN skeletons
complex-nn/: complex NN skeletons
non-nn/: non-NN skeletons
common/: shared migration-report template