FATE

Use this repository skill when a task involves FATE / FederatedAI/FATE 2.2.x: installing or checking the package, starting FateFlow-backed services, writing service-backed FateFlowPipeline jobs, running service-free local launchers, or inspecting the local component runtime exposed by python -m fate.components.

Start here

1. Read references/package-overview.md for package names, installed surfaces, backend boundaries, and the sub-skill map.
2. Run scripts/check_fate_install.py to summarize the active Python environment before giving commands that depend on installed FATE packages.
   • Add --include-service when the user needs fate_flow, pipeline, or FateFlow-backed Pipeline workflows.
   • Add --strict only when the task should fail on missing optional/service surfaces.
3. Route to the smallest matching sub-skill below; keep root guidance for package-wide setup, routing, and cross-cutting troubleshooting.
4. If a user reports behavior from a newer or older checkout, compare against references/repo-provenance.md before assuming this skill is current.

Sub-skill routing

User task	Read this first
Install FATE, choose PyPI vs Docker/Compose/host deployment, initialize or check FateFlow services, diagnose ports/Docker/SSH/service startup	sub-skills/deployment/SKILL.md
Upload data, build FateFlowPipeline DAGs, use Reader/PSI/preprocessing/train/evaluate/deploy/predict, validate upload YAML	sub-skills/pipeline-workflows/SKILL.md
Run without FateFlow using fate.arch.launchers, multiprocessing parties, dataframe readers, or direct fate.ml trainers	sub-skills/local-launchers/SKILL.md
Inspect component descriptors, component list, hyphenated task-schema, artifact types, task config schema, or custom component discovery	sub-skills/component-runtime/SKILL.md

Root operating boundaries

• The verified baseline is a CPU Python inspection/runtime surface. Do not claim GPU, DeepSpeed, Spark, Eggroll cluster, RabbitMQ, Pulsar, or Docker-cluster execution is verified unless the user provides and you verify that backend.
• Service-backed workflows require a running FateFlow service and initialized pipeline client. Local launchers and component CLI inspection do not require FateFlow.
• Treat deployment shell scripts and cluster rollout scripts as reference workflows by default. Do not run destructive service, Docker, SSH, or root OS mutation commands unless the user explicitly requests that action and the target is clear.
• The bundled references and scripts are self-contained for operating guidance. Do not rely on the original repository checkout for runtime instructions.
• When in doubt between Pipeline and local launcher APIs, ask whether the user wants a FateFlow-backed job or a service-free local simulation.

Repository-wide references

• references/package-overview.md — package/import/CLI surfaces, install footprint, backend limits, and capability ownership.
• references/troubleshooting.md — cross-cutting install/import, service, CLI, data/config, and backend diagnostics.
• references/repo-provenance.md — source commit, package versions, dirty-state note, and relative evidence paths for staleness checks.
• references/repo-routing-metadata.json — structured router placement metadata for this repo skill.

Safe root helper

python scripts/check_fate_install.py
python scripts/check_fate_install.py --include-service --strict
python scripts/check_fate_install.py --json

The helper only imports packages, checks versions, runs help commands, and reports backend/service surfaces. It does not start services, contact FateFlow, upload data, launch training, or mutate the host.