Our review
A contributor working guide for the mlcflow CLI that lays out the command-dispatch mental model and gives step-by-step playbooks for adding commands, dispatch branches, and meta.yaml schema keys.
Strengths
- Traces the full call chain (mlcr → get_action → ScriptAction.run → call_script_module_function → dynamic_import_module) as a compact readable diagram
- Playbooks are concrete: Python snippets plus the exact target file and insertion point, such as the build_parser loops near line 363
- Calls out real project hazards explicitly: permanent version drift between the bundled engine and mlperf-automations, the need for a companion PR, and the role of mlc_compat
- Documents the result dict contract every action method must honour (`{'return': 0}` on success, `{'return': N, 'error': ...}` on failure)
Limitations
- The document is truncated: the meta_schema.py section cuts off mid-sentence, so dependency-entry keys are not covered
- No install, prerequisite, or testing steps — it assumes existing familiarity with the repository layout
- Covers only three contribution tasks and offers no debugging or change-validation guidance
Use it when changing the mlcflow CLI driver or its script engine, for instance adding an mlc command, a ScriptAutomation dispatch branch, or a meta.yaml validation key.
Not suitable for authoring the content of an MLPerf automation script (meta.yaml, customize.py, run.sh) or for Python work unrelated to this repository.
Security analysis
SafeThe skill is a documentation/playbook file describing internal architecture and development workflows for mlcflow. It contains no executable instructions, no destructive commands, no data exfiltration, and no use of declared tools. The only command examples are for debugging (mlcr, mlc find, mlc reindex) and are non-destructive. No security concerns.
No concerns found
Examples
Add a new `mlc benchmark-report` command to mlcflow that delegates to ScriptAutomation via call_script_module_function, and register it in build_parser in main.py.A feature added in an mlperf-automations PR touching automation/ stops working silently once mlcflow was bundled — explain why, and how mlc_compat in meta.yaml guards against it.Add validation for a new top-level key `my_new_key` in meta_schema.py TOP_LEVEL_SCHEMA and show how a dependency entry key would be added to DEP_ENTRY_SCHEMA.skill.md — Claude working guide for mlcflow
Compact task playbooks. Read AGENTS.md for full technical detail.
Mental model
mlcr <tags> → mlc_expand_short("run") → main()
→ get_action("script", parent) → ScriptAction.run(run_args)
→ call_script_module_function("run", run_args)
→ find_target_folder("script") # bundled automation/script/ always preferred first,
# falls back to scanning registered repos only if absent
→ dynamic_import_module(module.py) # loads ScriptAutomation
→ ScriptAutomation(self, path).run(run_args) # engine bundled in this repo
This repo = CLI driver + script execution engine. Engine logic lives in
automation/script/module.py here (originally developed in
mlperf-automations, now bundled here as the copy mlcflow actually loads).
mlperf-automations keeps its own automation/ copy — it is not being
removed, so that pre-bundling mlcflow releases still have an engine to fall
back to. Script content (the 350+ script/<alias>/ directories with
meta.yaml, customize.py, run.sh) still lives there and is pulled into
~/MLC/repos/ as before.
Coexistence is safe (verified on real installs): bundled mlcflow loads the
bundled copy, pre-bundling mlcflow loads the repo copy, and in both cases
module.py + utils.py come from the same copy — never a hybrid.
Version drift is permanent, and it bites via coupled changes. The bundled
copy always wins, so any edit to mlperf-automations/automation/ is invisible
here. Engine and content changes usually land together in one
mlperf-automations PR (see #1061: MLC_SKIP_SUDO + script/detect-sudo/,
remote_shell + script/remote-run-commands/). A bundled mlcflow then gets
new content against a frozen engine, and the feature silently stops working —
no error. Any mlperf-automations PR touching automation/ needs a companion
PR here. mlc_compat in a script's meta.yaml is the guard that works.
Don't break from utils import …: dynamic_import_module() puts the
bundled automation/ dir on sys.path, and ~188 customize.py files in
mlperf-automations rely on that to resolve a bare from utils import ....
Touching that insertion breaks all of them at once.
Result dict contract — every action method must return:
{'return': 0}on success{'return': N, 'error': 'message'}on failure (N > 0)
Task playbooks
"I need to add a new mlc command"
-
Add method to the appropriate Action class (hyphens → underscores in name):
# script_action.py — for a command that delegates to ScriptAutomation def my_action(self, run_args): return self.call_script_module_function("my_action", run_args)# script_action.py — for a command handled entirely in mlcflow def my_action(self, run_args): self.action_type = "script" res = self.search(run_args) # ... do work ... return {'return': 0} -
Register the command in
build_parser()(main.py):# General (script/cache/repo): add to the first for-loop ~line 363 for action in ['run', 'pull', ..., 'my-action']: # Script-only: add to the second for-loop ~line 393 for action in ['docker', ..., 'my-action']: -
(Optional) Add a short command in
main.py+pyproject.toml:def mlcx(): mlc_expand_short("my-action")mlcx = "mlc.main:mlcx"
"I need to add a new dispatch branch for ScriptAutomation"
In call_script_module_function() (script_action.py), add an elif branch:
elif function_name == "my_action":
result = automation_instance.my_action(run_args)
"I need to add validation for a new meta.yaml key"
In meta_schema.py:
# Add to TOP_LEVEL_SCHEMA (top-level keys):
"my_new_key": DICT, # or STR, LIST, BOOL, etc.
# Add to DEP_ENTRY_SCHEMA if it goes inside a dep entry
# Add to VARIATION_ENTRY_SCHEMA if it goes inside a variation
Types are sets like STR = {"str"}, LIST = {"list"}, etc. validate_meta()
is called during indexing — errors halt the index build.
"I need to add a new error code or improve error messages"
In error_codes.py:
class ErrorCode(Enum):
MY_ERROR = (2008, "Description of the error")
To show actionable suggestions to the user, add a branch in get_error_guidance():
elif "my error pattern" in message:
guidance["error_message"] = "Likely cause"
guidance["suggestions"] = ["Do X to fix it."]
Error codes 2000–2007 are used; warning codes 1000–1006 are used. Pick the next available number in each range.
"I need to understand why mlcr <tags> fails"
mlcr <tags> --verbose # full debug output including ScriptAutomation logs
mlc find script --tags=<tags> # verify script is indexed
mlc reindex # rebuild index if stale
mlc list repo # verify mlperf-automations is registered
mlc find cache --tags=<failing-dep> # check if a dep is stale
mlc rm cache --tags=<failing-dep> # clear dep cache
Check for ScriptExecutionError in the output — it prints a rerun command, the
error code, likely cause, suggestions, and version info file path.
"I need to debug why the index is not picking up a script"
- Check
meta.yamlhas all four required keys:alias,uid,automation_alias,automation_uid - Run
mlc reindexto force a full rebuild - Check
~/MLC/repos/index_script.jsondirectly if needed - Run
mlcr <tags> --verbose— validation errors are logged during indexing
"I need to understand how args reach the automation engine"
convert_args_to_dictionary() in utils.py parses sys.argv extras:
--key=val→{"key": "val"}--flag→{"flag": True}--adr.compiler.tags=gcc→{"adr": {"compiler": {"tags": "gcc"}}}-v→{"v": True}(unless it matcheslog_flag_aliases)
The resulting run_args dict is passed directly to ScriptAutomation.run().
"I need to call mlcflow from Python"
from mlc.action import access
result = access({
'action': 'run',
'target': 'script',
'tags': 'detect,os'
})
if result['return'] > 0:
print(result['error'])
Or use the instance method on an Action object:
from mlc.action import Action
a = Action()
result = a.access({'action': 'find', 'target': 'script', 'tags': 'detect,os'})
"I need to write a test"
Look at existing tests for patterns:
tests/test_cache_mark_tmp.py
tests/test_action_invalid_meta_entries.py
Run tests with:
pip install -e .
python -m pytest tests/
"I need to review a PR"
Full spec — required structure, severity definitions, evidence rules — is in AGENTS.md → "PR review format". Follow it exactly; the short version:
> attribution block: AI-performed, on whose request, what was inspected
## Verdict ← 2-3 sentences + merge recommendation
## 🔴 High severity ← omit any tier with no findings
## 🟠 Medium severity
## 🟡 Low severity
## Suggested path to merge ← numbered, ordered, concrete
Investigate before writing:
gh pr diff <N> --repo mlcommons/mlcflow
SHA=$(gh pr view <N> --repo mlcommons/mlcflow --json headRefOid -q .headRefOid)
git fetch --depth 1 https://github.com/mlcommons/mlcflow.git refs/pull/<N>/head && git checkout FETCH_HEAD
- Read the callers and callees of changed code, not just the diff. A comment claiming "we now read X" is only true if some caller actually reads X — grep for readers before believing it.
- Check whether CI actually runs for the change: compare the touched paths
against each workflow's
paths:filter.automation/**is not covered bytest-unit.yml. - Check whether the change duplicates existing coverage in
tests/. - Run the changed shell functions where you can; quote the real output as evidence.
Post as a plain comment so no required review slot is consumed:
gh pr comment <N> --repo mlcommons/mlcflow --body-file review.md
Quick reference: key classes and where they live
| Class / function | File | What it does |
|---|---|---|
| main() | main.py | CLI entry point; parses args, dispatches to action |
| mlcr(), mlcd(), … | main.py | Short-form entry points registered in pyproject.toml |
| get_action(target, parent) | action_factory.py | Maps "script"/"cache"/"repo" → Action class |
| Action | action.py | Base: repo loading, index, CRUD (add/rm/cp/mv/search) |
| Action.access(i) | action.py | Python API: call any action programmatically |
| ScriptAction | script_action.py | Script actions; delegates to ScriptAutomation via call_script_module_function |
| ScriptExecutionError | script_action.py | Exception with script context; formatted by _report_error() |
| RepoAction | repo_action.py | pull/add/rm/find for repos |
| CacheAction | cache_action.py | find/rm/show/prune/list/mark-tmp for caches |
| Index | index.py | Incremental tag-based index; file-locked JSON |
| validate_meta() | meta_schema.py | Validates script meta.yaml; called during indexing |
| get_error_guidance() | error_codes.py | Pattern-matches error text → actionable suggestions |
| get_new_uid() | utils.py | Generates a 16-hex UID |
Don'ts
- Don't raise exceptions for recoverable errors in action methods — return
{'return': 1, 'error': '...'} - Don't call
print()for user-facing messages — uselogger.info/warning/error - Don't add
.in flat arg key names —.triggers nested dict parsing inconvert_args_to_dictionary() - Don't push directly to
main— open a PR; usedevonly for urgent merges without approval - Don't hard-code
~/MLC/repos— useself.repos_path(which readsMLC_REPOSenv var) - Don't edit
index_script.jsonormodified_times.jsonby hand — usemlc reindex - Don't call
ScriptAutomationdirectly — always go throughcall_script_module_function()
Design-to-Dev Specification Writer
Development
Translate your mockups into technical specifications for developers.
QCC Plus Git Workflow
Development
Defines the Git workflow for the QCC Plus project: branch strategy (test/main/prod), conventional commit format, and release process. Helps developers maintain consistency and avoid mistakes like force-pushing to main.
AXEL Skill Definition Reference
Development
Reference for structuring skill definition files, including frontmatter, templates, roles, and enforcement rules.