Per-individual data contract skill: builds/manages a single-individual slice of the pipeline at stages 0-2 (RawDataStore, SourceStore, RecStore) under _WorkSpace/A-User-Store/UserGroup-{dataset}/Subject-{id}. Use to create, inspect, or clean per-individual folders, build individual samples, or prepare data for endpoint inference. Trigger: individual, per-individual, single-individual, UserGroup, Subject-ID, A-User-Store, inference data, endpoint data, sample patient.
Standardmรครig ist der Prompt ausgewรคhlt, der zuerst die Quelle prรผft. Sie kรถnnen zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prรผfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich fรผr eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fรผgen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prรผfen und installieren.
Ein direkter Befehl รผberspringt den Prรผf-Prompt. Prรผfen Sie die Quelle, bevor Sie ihn ausfรผhren.
Per-individual data contract skill: builds/manages a single-individual slice of the pipeline at stages 0-2 (RawDataStore, SourceStore, RecStore) under _WorkSpace/A-User-Store/UserGroup-{dataset}/Subject-{id}. Use to create, inspect, or clean per-individual folders, build individual samples, or prepare data for endpoint inference. Trigger: individual, per-individual, single-individual, UserGroup, Subject-ID, A-User-Store, inference data, endpoint data, sample patient.
argument-hint
[command] [args...]
metadata
{"version":"0.1.1","last_updated":"2026-07-04","summary":"Per-individual data contract skill."}
Skill: haipipe-individual
Per-individual data contract covering stages 0-2.
One folder per individual, holding just the data needed to serve them via a deployed endpoint.
Stages 3-6 are for model development and never appear per-individual โ at inference time the individual calls the endpoint directly.
Why stages 0-2 only
Stage Role Per-individual?
0-RawDataStore original dataset files YES โ individual's raw slice
1-SourceStore typed source frames YES โ individual's rows
2-RecStore individual-centered records YES โ individual's record(s)
3-CaseStore cohort cases NO โ training-time
4-AIDataStore model-ready tensors NO โ training-time
5-ModelInstance trained weights NO โ training artifact
6-Endpoint deployable NO โ shared by all individuals
A deployed endpoint reads the individual's 2-RecStore, runs inference, and returns a prediction.
It does NOT need 3-6.
Folder Layout (FLAT โ no dataset-name or partition wrappers nested inside)
Wrapper names preserved in manifest.yaml for provenance (source_set, rec_set, rec_partitions_found_in), so you can always trace back to the global store that seeded an individual.
DatasetTag matches _WorkSpace/0-RawDataStore/ directory name (short form
for long names):
OhioT1DM โ OhioT1DM
mimiciv-3.1 โ mimiciv-3.1
WellDoc2022CGM โ WellDoc2022CGM
SubjectID is the dataset's native identifier WITHOUT the dataset prefix
(the prefix lives on the parent UserGroup-* folder):
OhioT1DM โ 540, 544, 552, 559, 563, ...
MIMIC-IV โ 10004235, 10009628, ... (numeric individual_id)
WellDoc โ 26, 48, ... (study's individual number)
Rationale: dataset-qualifying the PARENT folder instead of every individual
folder name keeps individual paths short and makes cohort-level operations
(list all MIMIC individuals, wipe one cohort) trivial.
Commands
/haipipe-individual โ dashboard: list existing Subject-* folders
/haipipe-individual dashboard โ same as above
/haipipe-individual list [dataset] โ list individuals for one dataset
/haipipe-individual inspect <Subject-> โ show folder tree + manifest
/haipipe-individual build โ build one individual folder
/haipipe-individual build-samples โ build N samples per dataset (config-driven)
/haipipe-individual clean <Subject-> โ remove an individual folder (reversible via rebuild)
/haipipe-individual spec โ show full per-stage content spec
Sub-skills (inference chain)
Three sibling skills in this bucket consume the Subject-* folders this skill builds:
/haipipe-individual-inference serve one Subject-* through a local endpoint (ctx load + predict)
/haipipe-individual-inference-report render the inference output as a patient-facing report
/haipipe-individual-inference-judge judge report quality (persona panel)
Given {dataset, individual_id} the build proceeds in 5 steps:
Step 1 โ mkdir
Create Subject-{id}/ under _WorkSpace/A-User-Store/UserGroup-{DatasetTag}/.
If folder exists and manifest is fresh โ skip (idempotent).
Step 2 โ slice raw
Copy or filter raw files from _WorkSpace/0-RawDataStore/{dataset}/
scoped to individual_id. Format-specific:
OhioT1DM โ copy {id}-ws-training.xml + {id}-ws-testing.xml
MIMIC-IV โ filter each CSV on individual_id column, write slice
WellDoc โ filter study CSV rows on individual_id
Write into Subject-*/0-RawDataStore/.
Step 3 โ filtered source
Run the existing fn_source.run() pipeline with an individual filter
(Partition_Args['individual_id_filter'] = [individual_id]).
Reads: Subject-/0-RawDataStore/ (or global 0-RawDataStore/ + filter).
Writes: Subject-/1-SourceStore/ (FLAT โ dataset/source-set wrappers stripped per the flattening rules; names preserved in manifest.yaml).
Step 4 โ filtered record
Run fn_record.run() against the filtered source from Step 3.
Reads: Subject-/1-SourceStore/.
Writes: Subject-/2-RecStore/ (FLAT Record-* dirs โ rec-set wrapper stripped, name preserved in manifest.yaml).
The build MUST be deterministic and reproducible.
A single script (fn/build_sample_individuals.py) owns this:
Read sample config (which datasets, which individual IDs, N per dataset).
For each (dataset, individual_id):
a. Steps 1-5 from Build Logic.
b. Idempotent: skip if manifest.built_at is fresh.
Emit a build report (what was built, what was skipped, any errors).
Do NOT hand-edit per-individual folders.
They are derived, not source of truth.
Source of truth = global _WorkSpace/0-RawDataStore/ + the build script.
Consumers
Deployed endpoints (stage 6) read:
manifest.yaml โ dataset + rec_set identification
2-RecStore/ โ the record for inference
(NEVER read 3-6 โ those don't exist per-individual anyway.)
Tutorials and demos read:
0-RawDataStore/ โ "here's what one individual's raw data looks like"
manifest.yaml โ attribution and provenance
Privacy / deletion:
rm -rf UserGroup-{DatasetTag}/Subject-{id}/ โ wipes ALL derived data for one individual.
Global stores untouched; re-run build to regenerate.
Relationship to Project-Wide Stores
Global _WorkSpace/ stores = BATCH work (training, cohort analysis):
0-RawDataStore/{dataset}/* โ whole dataset
1-SourceStore/{SourceSet}/* โ all individuals combined
2-RecStore/{RecSet}/* โ all records
Per-individual UserGroup/Subject-*/ = SINGLE-INDIVIDUAL serving:
0-RawDataStore/ โ one individual's raw slice
1-SourceStore/ โ one individual's source rows
2-RecStore/ โ one individual's record
A per-individual folder is a VIEW of the global store, scoped to one ID,
built by running the SAME pipeline with an individual filter.
Rules
NEVER create stages 3-6 inside a Subject-*/ folder. Those are not per-individual.
NEVER dataset-qualify the child folder name: it is Subject-{id}; the dataset tag lives on the parent UserGroup-{DatasetTag}/ (see Naming Convention).
ALWAYS write manifest.yaml โ it's the provenance record.
If a dataset's raw format can't be cleanly sliced (e.g. proprietary binary),
store a pointer manifest in 0-RawDataStore/ instead of copying.
The build script is the source of truth for how each dataset is sliced.
Hand-curated individual folders drift and break โ do not do it.
Individual folders are reproducible: rm -rf and re-run build must produce
an equivalent folder (differences only in built_at timestamp).