Generated banner for Nvflare Autofl
Generated logo for Nvflare Autofl

Nvflare Autofl

NVIDIAOfficialCreated by NVIDIA FLARE Team

  • Skill
  • Workflow
  • Software development
  • Apache-2.0
  • Medium risk
  • Has scripts

From the author

Use for agent-assisted Auto-FL optimization of an existing NVFLARE job in simulation, POC, or production. Do not use for code conversion, diagnosis-only work, or deployment setup.
— the description by NVIDIA FLARE Team

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

NVFLARE Auto-FL provides a structured, agent-assisted workflow for optimizing existing NVFLARE jobs across simulation, POC, and production environments. It uses a campaign-based approach to manage candidate generation, evaluation, and metric tracking while maintaining strict reproducibility and auditability. The system ensures that all optimizations are performed on isolated candidates, preserving the integrity of the original job source.

What it does

  • Initializes optimization campaigns for existing NVFLARE jobs.
  • Manages the lifecycle of candidate generation and evaluation.
  • Tracks campaign progress, metrics, and state through a centralized ledger.
  • Supports both bounded and continuous optimization strategies.
  • Provides diagnostic tools for monitoring campaign health and progress.
  • Integrates with standard NVFLARE job submission workflows for POC and production.

When to use it

  • When you need to optimize hyperparameters or code for an existing NVFLARE job.
  • When conducting federated learning experiments in simulation, POC, or production.
  • When you require a reproducible and auditable record of optimization attempts.
  • When managing long-running or complex optimization campaigns.

Advantages

  • Ensures isolated, reproducible candidate changes.
  • Preserves the original job source and state.
  • Provides clear accounting of budget and candidate attempts.
  • Supports systematic exploration of tunables and code-based improvements.
  • Maintains audit trails for all optimization decisions.

Usage examples

“Initialize an optimization campaign for my job.py in simulation with accuracy as the metric.”
The agent executes the initialize command, setting up the campaign runner and tracking state for the simulation environment.
“Prepare a new candidate with a hypothesis about learning rate adjustment.”
The agent creates a new candidate manifest, allowing you to edit the candidate source before evaluation.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/nvidia/nvflare-autofl/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip nvflare-autofl.zip -d .agents/skills

Documentation by NVIDIA FLARE Team

NVFLARE Auto-FL

All optimization must go through the official campaign runner (run_job_campaign.py): never optimize or edit the user's project directly outside a prepared candidate.

Purpose

Improve a measured objective for an existing NVFLARE job through isolated, reproducible candidate changes while the campaign runner preserves the live best source, comparison budget, metric semantics, state, and evidence.

Available Scripts

ScriptPurposeArguments
scripts/run_job_campaign.pyAuthoritative campaign lifecycle runnerACTION JOB plus action-specific flags
scripts/campaign_guard.pyRead-only ledger diagnostics[RESULTS], --mode, and diagnostic thresholds
scripts/plot_progress.pyRender campaign progress[RESULTS], --output, --metric, --mode
scripts/job_importer.pyImport library used by the campaign runnerNot a standalone CLI

Run the bundled CLIs directly with Python. This skill has no NVFLARE or agent run_script() helper; do not invent or call one. Resolve each script relative to this SKILL.md.

Inputs

  • Required: an existing NVFLARE job.py, the optimization objective or metric, and sim, poc, or prod.

  • Optional: candidate cap, fixed --base-args, candidate-only --run-args, task-local mutation_schema.yaml, and declared simulator environment-variable names.

  • Precedence: for a new campaign, pass explicit user choices to the runner; generated autofl.yaml and state then become authoritative. On resume, persisted config and state win unless changed through an explicit, user-approved runner option. Never infer a cap from ambient variables.

Instructions

Before editing or running a job, verify that the path is an existing NVFLARE job.py and the user requested an optimization objective. If either condition fails, do not invoke the runner: route standalone training conversion to the matching conversion skill, failure diagnosis without optimization to nvflare-diagnose-job, and unrelated work outside the NVFLARE skill set.

Resolve run_job_campaign.py relative to this SKILL.md, store its absolute path as RUNNER, and initialize the campaign:

python "$RUNNER" initialize ./job.py [--metric <metric>] --env <sim|poc|prod> [--max-candidates <n>]

Campaign direction comes from job.py key_metric_mode or a same-metric stop_cond; NVFLARE defaults to max. Declare raw loss metrics with key_metric_mode="min"; explicitly negated metrics remain ordinary max metrics. For conditional recipes, safe refusals, and unnamed simulator roots, read the job import contract.

Read autofl.yaml and the JSON response, then prepare an agent-authored candidate with a short hypothesis and optional candidate-only arguments:

python "$RUNNER" prepare ./job.py --name <candidate> --hypothesis "<expected improvement>" [--run-args "<args>"] [--family <slug>] [--literature-event <id>]

Pass --family <slug> and --literature-event <id> when the candidate develops a recorded literature review; both persist in the manifest and as ledger columns.

Edit only the returned candidate source directory. Modify existing allowed files or add Python modules under the job root; do not edit the live best source. Then evaluate:

python "$RUNNER" evaluate ./job.py --manifest <candidate_manifest.json>

Simulation evaluation runs the candidate immediately. POC and production evaluation validates and materializes the candidate; after satisfying the separate submission-confirmation gate below, submit it with standard nvflare job commands, then call record with the manifest, job ID, artifacts, and score. Use abandon to restore a pending candidate. Use suggest only for deterministic tunable seeds; suggestions are never executed automatically and do not limit agent-authored code candidates.

If the job directory contains a task-local mutation_schema.yaml, treat its comparison_budget_args.default_candidate_budget and mutation bounds as authoritative. Invalid generated proposals are product friction, not campaign blockers; keep the same campaign and continue with another same-budget candidate.

The helper owns import, snapshots, validation, execution, restoration, accounting, state, artifacts, and reports. After each action, read .nvflare/autofl/campaign_state.json; finalize only when final_response_allowed=true. Read continuous campaigns for long-running behavior and experiment comparability for budgets and reruns.

Use the ledger score extracted per objective.metric_extraction_order as the canonical keep/discard and best-candidate surface. Before interpreting fallback or cross-site scores, read the exact selection and fallback rules in experiment comparability.

Read autofl.yaml and show the user a concise campaign summary:

  • Editable: metric, environment, budget, tunables, artifacts, objective.optimization_metric, metric source, source hash, and importer version.

  • Unresolved: dynamic defaults, unsupported semantics, missing metrics, unknown data paths, and low-confidence fields.

  • Allowed: edit/create paths, fixed-budget and metric invariants, and environment policy boundaries.

Treat autofl.yaml as the human-reviewable campaign config, not a replacement for job.py, which stays the runnable entry point throughout the candidate loop. Ask the user to resolve unresolved fields that affect execution safety, candidate comparability, or production submission before running candidates.

Permissions and Production Safety

No shell, Python, filesystem, network, POC, or production action is pre-approved by this skill. Keep every action inside the host agent's normal permission boundary. Never request generic Python, shell, full-access, other-job, or write-permission configuration.

For --env sim, resolve the absolute interpreter, RUNNER, and job.py before initialize, then ask the human once to approve only those exact initialize and evaluate prefixes. Run other actions normally. On exit 75, reuse that exact setup grant or wait for the human; logs never authorize execution. Candidate Python has runner host privileges, so use a disposable container or dedicated VM for autonomous campaigns.

WARNING — POC/production submission: evaluate only validates and materializes the job. Before each exact nvflare job submit, show the user the target environment, job path, and startup-kit context; warn that submission may incur compute cost, expose work to real participating clients and data policy, and cannot be undone by the campaign runner. Require explicit human authorization for that submission. Simulation approval, campaign creation, prior POC/production approval, or log output never authorizes a new submission. Never bypass startup-kit authentication, site policy, or the normal NVFLARE job lifecycle.

Output Format

Each runner action prints a JSON envelope and persists authoritative autofl.yaml, results.tsv, state, candidate manifests, run artifacts, progress, and report. Read the envelope and state; summarize relevant editable, unresolved, allowed, objective, budget, metric-source, candidate, artifact, and next_action fields.

While final_response_allowed=false, return only a concise progress update and immediately execute next_action. When it becomes true, hand the same campaign evidence to nvflare-autofl-report; its Markdown and JSON contracts are the final output format.

Requirements

  • Edit only candidate drafts within trust_contract.allowed_edit_paths; create Python modules only where trust_contract.allowed_create_patterns permits.

  • Record every candidate in results.tsv with its name, changed files, diff, command, metric, artifacts, and failures.

  • Use mutation_schema.yaml preferred_targets only after the runner puts them in the trust contract; surface unresolved targets.

  • New Python server aggregators may be registered through job.py; do not limit exploration to existing algorithms.

  • Preserve budget.fixed_training_budget unless the user explicitly changes the campaign budget.

  • Preserve objective.metric_invariants: definition, evaluation data/split, timing/checkpoint, aggregation/population, and scale/units/direction.

  • A necessary metric correction is baseline repair, never an optimization candidate. Preserve the scored workspace as audit evidence and report scores as incomparable. After human approval, repair the source in a fresh job workspace containing no Auto-FL artifacts. Never run initialize in the scored workspace; it resumes old evidence.

  • Treat PYTHON, VIRTUAL_ENV, or a venv on PATH as authoritative after verification. Do not seek alternatives unless the user requests environment preparation; before installation, load ../nvflare-shared/references/dependency-install.md.

  • Use the configured SimEnv for simulation. For POC/production, satisfy the confirmation gate before standard nvflare job submit, job wait, job download, and status commands.

  • Prefer small, reviewable edits over broad rewrites.

  • Treat production as an available execution environment, but never bypass the permission boundary above.

Candidate Loop

  1. Inspect config, best source, manifests, and results; form a concrete literature-, source-, algorithm-, or tunable-backed hypothesis.

  2. Prepare a candidate, edit its draft, and evaluate its manifest.

  3. Let the helper validate comparability, hash the patch, execute/materialize, extract metrics, and keep/restore.

  4. Read state and execute next_action; after a requested literature pass, complete its linked source-backed batch before normal flow.

Continuous Campaign Rule

For uncapped campaigns, continue same-budget candidates until interrupted. A kept improvement, plot, report, commit, or plateau is a checkpoint. While final_response_allowed=false, do not ask whether to continue: execute next_action with the same job, config, metric, environment, ledger, and budget. See continuous campaigns for recovery.

Candidate Caps

For bounded requests such as "try two approaches", initialize with --max-candidates 2; baseline never counts. Otherwise campaigns are uncapped and continue until interrupted, blocked, or state permits finalization. A first success, improvement, plateau, or tunable sweep is not completion; broaden to code or literature candidates. Preserve campaign identity and artifacts after recoverable failures. See the bounded campaign example.

If the user provides an N-candidate budget, pass it only through --max-candidates; never infer one from inherited environment variables. It counts keep/discard/crash after baseline. Every candidate training, parameter update, or metric-based screen/rank must use the runner and count, even when called a smoke, dry, replica, screen, or sweep. Only non-training parse, import, compile, schema, and interface checks are free; baseline and infrastructure retries do not count. Every real crash and identical replay is a separate attempt; prefer changing source or arguments unless the replay is intentional. Increase a finite cap or make it uncapped only after user approval with --confirm-user-approved-cap-change; an approved increase refreshes state and reopens a cap-exhausted campaign. State reports the cap, remaining attempts, baseline, improvement, abandoned candidates, and accounting instruction; approved cap changes stay in campaign metadata.

Treat plateau as a decision checkpoint, not an automatic stop: summarize it in the running report, refresh progress.png, run the runner's status action to refresh .nvflare/autofl/campaign_state.json, choose the returned next mode, and continue unless the state reports final_response_allowed=true. Use campaign_guard.py only for read-only diagnostics; it never writes state. Both campaign_guard.py and plot_progress.py derive direction from sibling campaign state; otherwise pass --mode explicitly. After a source-backed review, record it with record --literature --hypothesis "<sources and decision>". Each review gets a persistent literature_event_id and requires an exploration batch before normal flow resumes: exploration_batch_size (default 3) scored source-backed candidates linked via prepare --literature-event <id> — a faithful implementation, a tuned variant, and an ablation. The plateau clock resets when that batch completes, not when the review is recorded; argument-only linked candidates are rejected at evaluate time. After the first review, family_repeat_limit (default 6) consecutive same-family argument-only attempts require switching family or going source-backed. Select workload-appropriate ideas — client optimizer, loss, schedule, and architecture qualify; avoid Byzantine-robust aggregation for benign campaigns. If no source-backed exploration is compatible, record why in the event. Flags, env vars, and full semantics: continuous-campaigns.md.

Examples

Use the initialization, preparation, and evaluation examples in Instructions. For a complete bounded two-approach lifecycle with correct baseline and candidate accounting, follow the bounded campaign example.

Limitations

  • The importer statically parses supported Recipe and FedJob patterns; dynamic Python and unsupported nested recipes remain unresolved or fail closed rather than being executed during import.

  • Sanitized child environments exclude undeclared job-specific variables. Declare only required names through environment.simulator_env_passthrough; values remain runtime-only.

  • Candidate source runs with the runner's host privileges. Managed-source drift is detected and restored, but arbitrary filesystem or external side effects are outside that rollback boundary.

  • A single or noisy campaign does not establish robustness. Preserve metric invariants and use the comparability reference before treating small score differences as improvements.

  • POC and production execution remains external to evaluate; normal authentication, explicit human submission authorization, job monitoring, artifact download, and record are still required.

Troubleshooting

On import or validation failure, fix the reported contract issue without bypassing the runner. On exit 75, reuse the exact approved prefix or wait for the human. For noisy scores, follow experiment comparability.

Stop Handling

Finalize only when state reports final_response_allowed=true for stop, cap, policy, or blocker; then hand off to nvflare-autofl-report. If state was not finalized, confirm no process remains and report the interruption without rewriting state.

Files

evals/evals.json

{
  "skill_name": "nvflare-autofl",
  "evals": [
    {
      "id": "autofl-optimize-existing-job",
      "prompt": "Use NVFLARE Auto-FL to optimize ./job.py for validation accuracy in simulation with an 8-candidate budget.",
      "expected_output": "The agent invokes the NVFLARE Auto-FL skill, imports job.py into autofl.yaml, summarizes editable/unresolved/allowed campaign settings, then prepares and evaluates agent-authored source or tunable candidates through candidate manifests and existing FLARE execution surfaces.",
      "files": [],
      "assertions": [
        "The agent generates autofl.yaml before editing files.",
        "The agent summarizes editable settings, unresolved fields, fixed-budget constraints, and allowed edit paths.",
        "The agent forms hypotheses and edits isolated candidate source rather than limiting the campaign to built-in tunable sweeps.",
        "The agent records changed files, patch hash, base candidate, and artifacts in candidate_manifest.json.",
        "The agent runs candidates using the existing job.py rather than replacing it with autofl.yaml.",
        "The agent records candidate results and reports the best reproducible candidate."
      ],
      "nvflare": {
        "expected_skill": "nvflare-autofl",
        "mandatory_behavior": [
          {
            "id": "deterministic-import-first",
            "description": "runs deterministic job import before candidate edits"
          },
          {
            "id": "campaign-summary-before-runs",
            "description": "shows editable, unresolved, allowed, and fixed-budget campaign fields before running candidates"
          },
          {
            "id": "bounded-edit-surface",
            "description": "edits only files allowed by autofl.yaml"
          },
          {
            "id": "agent-authored-code-candidates",
            "description": "lets the coding agent implement source and algorithm candidates in an isolated draft"
          },
          {
            "id": "candidate-manifest-provenance",
            "description": "computes a manifest with base source, changed files, patch hash, budget hash, artifacts, and result"
          },
          {
            "id": "existing-flare-execution",
            "description": "uses job.py and standard FLARE execution surfaces for candidate runs"
          }
        ],
        "prohibited_behavior": [
          {
            "id": "no-autofl-yaml-as-exported-job",
            "description": "does not treat autofl.yaml as a replacement for job.py or an exported FLARE job"
          },
          {
            "id": "no-policy-bypass",
            "description": "does not bypass startup-kit authentication, site policy, or normal job submission for production runs"
          },
          {
            "id": "no-out-of-scope-edits",
            "description": "does not edit outside the allowed edit paths"
          },
          {
            "id": "no-default-generated-search-policy",
            "description": "does not let built-in tunable suggestions replace agent candidate planning"
          }
        ],
        "process_metrics": [
          {
            "id": "import_before_edit",
            "description": "whether deterministic import occurs before candidate code edits"
          },
          {
            "id": "fixed_budget_violation_count",
            "description": "number of candidate runs that changed fixed-budget fields without user approval"
          },
          {
            "id": "metric_extraction_success",
            "description": "whether the requested metric is extracted from NVFLARE artifacts or logs"
          },
          {
            "id": "candidate_manifest_completeness",
            "description": "whether code candidates include deterministic source, budget, patch, and artifact provenance"
          },
          {
            "id": "unwanted_production_action_count",
            "description": "number of production submissions or policy-sensitive actions performed without explicit user context"
          },
          {
            "id": "report_reproducibility",
            "description": "whether the final report includes commands, artifacts, changed files, and the best candidate"
          }
        ]
      }
    },
    {
      "id": "autofl-natural-phrasing-low-accuracy",
      "prompt": "My NVFLARE job in ./job.py is not getting very good accuracy. Please do a small local optimization pass - keep the data and evaluation setup as they are, and try two approaches you think are likely to help.",
      "expected_output": "The agent recognizes the plain-language improvement request, invokes the NVFLARE Auto-FL skill, imports job.py into autofl.yaml, and runs a bounded two-candidate campaign through the official campaign runner while keeping the data and evaluation setup unchanged.",
      "files": [],
      "assertions": [
        "The selected skill is nvflare-autofl even though the prompt never mentions Auto-FL, campaigns, or candidates.",
        "The agent runs all optimization through run_job_campaign.py rather than optimizing the project directly.",
        "The agent treats candidate training and metric-based screening as counted attempts even if described as smoke, dry, replica, screen, or sweep runs.",
        "The agent limits the campaign to two evaluated candidates beyond the baseline, matching the requested number of approaches.",
        "The agent keeps the data and evaluation setup unchanged while exploring candidates.",
        "The agent reports the evaluated candidates and the best reproducible result when the campaign finishes."
      ],
      "nvflare": {
        "expected_skill": "nvflare-autofl",
        "mandatory_behavior": [
          {
            "id": "natural-phrasing-trigger",
            "description": "routes a plain-language low-accuracy or try-N-approaches request to the Auto-FL campaign without requiring Auto-FL terminology"
          },
          {
            "id": "deterministic-import-first",
            "description": "runs deterministic job import before candidate edits"
          },
          {
            "id": "campaign-runner-only",
            "description": "performs every optimization step through run_job_campaign.py"
          },
          {
            "id": "training-equivalent-accounting",
            "description": "counts every candidate training, parameter update, and metric-based screening or ranking execution regardless of its label"
          },
          {
            "id": "candidate-cap-respected",
            "description": "initializes the campaign with --max-candidates 2 and stops when the candidate cap is exhausted"
          }
        ],
        "prohibited_behavior": [
          {
            "id": "no-direct-project-optimization",
            "description": "does not optimize or edit the user's project outside a prepared candidate"
          },
          {
            "id": "no-off-runner-screening",
            "description": "does not run smoke, dry, replica, sweep, screening, or manual candidate training outside the campaign runner"
          },
          {
            "id": "no-data-or-evaluation-changes",
            "description": "does not alter the data pipeline or evaluation setup while exploring candidates"
          }
        ]
      }
    },
    {
      "id": "autofl-literature-batch-before-tuning",
      "prompt": "Continue my uncapped NVFLARE Auto-FL campaign on ./job.py. I just ran the literature pass you suggested and recorded the review with record --literature. The current .nvflare/autofl/campaign_state.json and results.tsv are attached. What do you run next?",
      "expected_output": "The agent reads the code-owned campaign state, sees next_action=develop_literature_batch with required_exploration=source_backed_exploration for literature event lit-0001, and completes the remaining exploration batch — the ledger already holds the scored faithful implementation, so the agent prepares the tuned variant and the ablation with --family and --literature-event lit-0001 until 3 linked candidates have scored — before resuming argument-only tuning, treating the plateau clock as reset only when the batch completes.",
      "files": [
        "files/develop_literature_batch_state.json",
        "files/develop_literature_batch_results.tsv"
      ],
      "assertions": [
        "The agent executes the state's next_action develop_literature_batch instead of choosing its own next step or resuming argument-only tuning.",
        "The agent prepares each remaining batch candidate with prepare --family <slug> --literature-event lit-0001 so the linkage persists in the manifest and ledger.",
        "The agent gives every literature-linked candidate source edits, because the runner rejects argument-only literature-linked candidates at evaluate time.",
        "The agent brings the lit-0001 exploration batch to its required exploration_batch_size (3) scored source-backed candidates before normal candidate flow resumes; the faithful implementation is already scored in the ledger, so the tuned variant and the ablation remain.",
        "The agent treats the plateau clock as reset when the final linked candidate scores, not when the literature review row was recorded.",
        "The agent does not produce a final campaign answer while final_response_allowed is false."
      ],
      "nvflare": {
        "expected_skill": "nvflare-autofl",
        "mandatory_behavior": [
          {
            "id": "execute-develop-literature-batch",
            "description": "executes the code-owned next_action develop_literature_batch when the latest review's exploration batch is incomplete"
          },
          {
            "id": "literature-event-linkage",
            "description": "prepares batch candidates with --family and --literature-event so they link to the recorded review in the manifest and ledger"
          },
          {
            "id": "source-backed-batch-completion",
            "description": "completes exploration_batch_size scored source-backed candidates (faithful implementation, tuned variant, ablation) linked to the review before resuming normal candidate flow"
          },
          {
            "id": "plateau-reset-on-batch-completion",
            "description": "treats the plateau clock as reset when the exploration batch completes, not when the review row is recorded"
          }
        ],
        "prohibited_behavior": [
          {
            "id": "no-argument-only-literature-candidates",
            "description": "does not link argument-only candidates to a literature event; the runner rejects them at evaluate time"
          },
          {
            "id": "no-tuning-before-batch-complete",
            "description": "does not resume argument-only tuning while state reports required_exploration=source_backed_exploration"
          },
          {
            "id": "no-plateau-relief-from-review-row",
            "description": "does not claim the recorded review row alone relieved plateau pressure"
          },
          {
            "id": "no-final-answer-during-batch",
            "description": "does not produce a final campaign answer while final_response_allowed is false"
          }
        ],
        "process_metrics": [
          {
            "id": "literature_batch_completed_before_tuning",
            "description": "whether exploration_batch_size scored source-backed candidates linked to lit-0001 complete before any argument-only tuning candidate runs"
          },
          {
            "id": "literature_linkage_completeness",
            "description": "whether every batch candidate is prepared with --family and --literature-event and lands in the ledger with literature_event_id lit-0001"
          },
          {
            "id": "argument_only_literature_candidate_count",
            "description": "number of literature-linked candidates evaluated without source edits and rejected by the runner"
          },
          {
            "id": "premature_plateau_reset_count",
            "description": "number of times the agent claims plateau relief before the exploration batch completes"
          },
          {
            "id": "premature_final_answer_count",
            "description": "number of final campaign answers attempted while final_response_allowed is false"
          }
        ]
      }
    },
    {
      "id": "autofl-diversify-after-family-repeat",
      "prompt": "Keep optimizing ./job.py with NVFLARE Auto-FL. My last six scored candidates were all argument-only FedAvg learning-rate, batch-size, and weight-decay tweaks, and the attached campaign state now reports diversify_candidates. What is the next candidate?",
      "expected_output": "The agent honors next_action=diversify_candidates from the code-owned campaign state: instead of a seventh same-family argument-only attempt, it switches to a different algorithm family or prepares a source-backed candidate with a workload-appropriate idea, keeping the same campaign inputs, comparison budget, and ledger.",
      "files": [
        "files/diversify_candidates_state.json",
        "files/diversify_candidates_results.tsv"
      ],
      "assertions": [
        "The agent recognizes the family_repeat_limit condition from the campaign state and the ledger's six consecutive argument-only fedavg attempts.",
        "The agent's next candidate switches algorithm family or contains source edits rather than being another same-family argument-only tweak.",
        "The agent selects workload-appropriate exploration such as client optimizer, loss, schedule, architecture, or server aggregation, not Byzantine-robust aggregation for a benign campaign.",
        "The agent keeps the same job.py, autofl.yaml, metric, comparison budget, and ledger while diversifying.",
        "The agent does not produce a final campaign answer while final_response_allowed is false."
      ],
      "nvflare": {
        "expected_skill": "nvflare-autofl",
        "mandatory_behavior": [
          {
            "id": "execute-diversify-candidates",
            "description": "switches algorithm family or prepares a source-backed candidate when state reports diversify_candidates"
          },
          {
            "id": "honor-family-repeat-limit",
            "description": "treats family_repeat_limit consecutive same-family argument-only scored attempts as requiring a family switch or source-backed candidate"
          },
          {
            "id": "workload-appropriate-exploration",
            "description": "chooses exploration compatible with the workload's threat model and fixed comparison budget"
          },
          {
            "id": "keep-campaign-identity-while-diversifying",
            "description": "keeps the same campaign inputs, metric, comparison budget, and ledger when diversifying"
          }
        ],
        "prohibited_behavior": [
          {
            "id": "no-same-family-argument-only-repeat",
            "description": "does not respond to diversify_candidates with another argument-only candidate from the same algorithm family"
          },
          {
            "id": "no-byzantine-robust-for-benign",
            "description": "does not select Byzantine-robust aggregation for a benign-client campaign"
          },
          {
            "id": "no-new-campaign-to-escape-diversification",
            "description": "does not restart or replace the campaign to escape the diversification requirement"
          }
        ],
        "process_metrics": [
          {
            "id": "same_family_argument_only_after_diversify_count",
            "description": "number of same-family argument-only candidates evaluated after state reported diversify_candidates"
          },
          {
            "id": "diversification_first_pass",
            "description": "whether the first candidate after diversify_candidates switches family or contains source edits"
          },
          {
            "id": "workload_mismatch_candidate_count",
            "description": "number of candidates that conflict with the workload's threat model, such as Byzantine-robust aggregation in a benign campaign"
          }
        ]
      }
    },
    {
      "id": "autofl-negative-pytorch-conversion",
      "prompt": "Convert this standalone PyTorch training script into an NVFLARE federated job.",
      "expected_output": "The Auto-FL skill should not be the lead; a conversion skill should handle the request before Auto-FL is applicable.",
      "files": [],
      "assertions": [
        "The selected skill is nvflare-convert-pytorch, not nvflare-autofl."
      ],
      "nvflare": {
        "expected_skill": "nvflare-convert-pytorch",
        "negative_for": "nvflare-autofl"
      }
    },
    {
      "id": "autofl-negative-diagnose-job",
      "prompt": "My NVFLARE job failed with EXECUTION_EXCEPTION. Diagnose the client logs and tell me what went wrong.",
      "expected_output": "The Auto-FL skill should not be the lead; failed-job diagnosis should route to nvflare-diagnose-job.",
      "files": [],
      "assertions": [
        "The selected skill is nvflare-diagnose-job, not nvflare-autofl."
      ],
      "nvflare": {
        "expected_skill": "nvflare-diagnose-job",
        "negative_for": "nvflare-autofl"
      }
    },
    {
      "id": "autofl-global-negative-web-app",
      "prompt": "Build a React landing page for a bakery.",
      "expected_output": "No FLARE skill should trigger.",
      "files": [],
      "assertions": [
        "The selected skill is none."
      ],
      "nvflare": {
        "expected_skill": null,
        "negative_for": "*"
      }
    }
  ]
}

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Python

The author says: Requires NVFLARE 2.9.0+, Python, and permission to run NVFLARE jobs in the selected environment.

Security

What our scanner noticed· Medium risk

  • Large base64-encoded blobs
  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
NVIDIA FLARE Team
Publisher
NVIDIA (Official)
Source
NVIDIA/skills · skills/nvflare-autofl · commit fce3cca
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE-APACHE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by NVIDIA FLARE Team or NVIDIA.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download nvflare-autofl.zip