Using wemol-cli

Overview

INLINECODE0 is the operational client for Wemol modules and flows. Use it to discover modules/flows, inspect real input schemas, submit jobs, track execution, and recover outputs.

Primary rule:

• - Prefer executing CLI commands and reading real output over assumptions.

This SKILL.md is now self-sufficient for normal operation. references/ and examples/ are secondary for edge cases and domain-specific patterns.

When To Use

Use when:

• - user asks for a biology/chemistry/AI workflow that may map to Wemol modules or flows
• task requires live module params, job status, logs, outputs, downloads
• session/host/lang/install behavior affects task execution

Do not use when:

• - task is SDK/CLI source implementation work
• user only asks for static code edits unrelated to running CLI

Quick Start

When context is unknown:

CODEBLOCK0

If authentication error appears, stop and run:

CODEBLOCK1

If interactive login is not possible (non-TTY), use:

CODEBLOCK2

Quick Reference

Situation	Required Action	Avoid
User asks capability but no ID	INLINECODE4 / flow search first	guessing module/flow by name only
Any submit intent

fetch schema (--params-json or flow get) first | building payload from natural language | | Flow submit | enforce task-keyed JSON | flat JSON submit | | job output missing/empty | job tasks then job download | concluding job failed immediately | | Auth/session issue | login / account / host / lang checks | continuing API probes while unauthenticated | | User asks “need update?” | run update workflow and conclude directly | asking user to compare versions manually |

Command Routing (Default)

• - Capability request, no module ID:

- wemol-cli module search <keywords...>

• - Catalog browsing/filtering:

- wemol-cli module list ...

• - Pipeline/workflow request:

- wemol-cli flow search <keywords...> then wemol-cli flow get <flow_id>

• - Need exact module payload:

- wemol-cli module get <module_id> --params-json

• - Need flow payload shape:

- wemol-cli flow get <flow_id> --params-template

• - Submitted job, need progress:

- wemol-cli job status <job_id> and wemol-cli job progress <job_id>

• - Need task_id:

- wemol-cli job tasks <job_id>

• - Output unclear:

- wemol-cli job diagnose <job_id> then wemol-cli job download <job_id>

• - Historical run, unknown job_id:

- wemol-cli job list ... or INLINECODE29

Core Commands And Rules

Global Options

CODEBLOCK3

Environment equivalents:

• - INLINECODE30
• INLINECODE31
• INLINECODE32

Rules:

• - Prefer persisted host --set and cached login for routine work.
• Use --host / --session-id for one-off overrides.
• Use --user-agent only when explicit routing/debugging requires it.
• INLINECODE37 exists on root and command groups (module, flow, job, host, lang, account); some leaf commands also support it depending on version.

Host / Language / Session / Account

CODEBLOCK4

Rules:

• - module get and module get --params-json follow current language.
• use account to confirm active identity and resource summary.
• use logout to clear current host session before relogin/switch account.

Module Discovery And Inspection

CODEBLOCK5

Rules:

• - module list and module search currently return enabled modules.
• INLINECODE50 is repeatable and uses AND semantics.
• INLINECODE51 includes tag matching.
• Before submit, always read --params-json; do not guess keys/types/options.

Flow Discovery And Inspection

CODEBLOCK6

Rules:

• - flow list --tag is repeatable and uses AND semantics.
• INLINECODE54 includes tag matching.
• INLINECODE55 is source of truth for task names and nested input keys.
• use --params-template whenever payload structure is uncertain.

Job Submit

Module submit:

CODEBLOCK7

Flow submit:

CODEBLOCK8

Rules:

• - Select exactly one target: --module-id / --module-name / --flow-id / --flow-name.
• INLINECODE61 is module-only; do not use with flow submit.
• INLINECODE62 and --params-file are mutually exclusive.
• INLINECODE64 supports repeatable --tag; CLI auto-adds Wemol CLI source tag.
• Module payload keys must match --params-json field values exactly.
• Flow payload must be task-keyed JSON ({"Task Name": {"Input": value}}).
• File args accept local file path; CLI uploads automatically.
• For file args, check format / value_formats from --params-json before submit.
• For MultipleChoice, send array even for one option (for example {"Numbering Scheme":["imgt"]}).

Job Read / Track / Diagnose

CODEBLOCK9

Rules:

• - use job list for status/history filters; job search for topic/module keyword recovery.
• INLINECODE77 defaults to --until done; use --until terminal to stop on Done/Abort/Cancel.
• INLINECODE81 is preferred when status is too coarse.
• INLINECODE83 gives focused suggestions and executable next_commands.

Logs / Output / Download

CODEBLOCK10

Rules:

• - job output normally requires --task-id; if missing, run job tasks first.
• If output key missing or empty-data style errors (DBDataNull/similar) appear, try job download before declaring failure.
• download resume is enabled by default with .wemol-download-manifest.json.
• INLINECODE91 disables state reuse.
• summary includes skipped artifacts and transient/permanent failures.

Hard Rules (Must Follow)

1. 1. No guessed payload keys

• - Never infer submit keys from natural language.
• Always derive from module get --params-json or flow get.

1. 2. No flow flat JSON submit

• - Flow submit must be task-keyed.
• If user gives flat JSON, fix structure first, then ask missing values.

1. 3. No blind retry

• - On validation error, re-read schema and payload shape first.
• On JobModuleTaskMaxNumLimit, treat as capacity/quota issue, not payload formatting.

1. 4. No premature failure conclusion

• - job output failure is not equal to job failure.
• Try job tasks + job download.

1. 5. No auth-ignore probing

• - After auth-required error, login/session handling comes first.

1. 6. No update-question deflection

• - For “需要更新吗 / latest?” do comparison work yourself, do not tell user to compare.

Detection Triggers (Auto-Branch)

When these signals appear, branch automatically:

• - Authentication required / DBUserNoLogin / session null:

- branch to session handling (login, account, host, lang) before further task commands.

• - user message contains flow_id / --flow-id / flow submit / pipeline submit:

- branch to flow-shape validation (flow get, optional --params-template) before accepting payload.

• - output errors contain Output '<name>' was not found or empty-data style (DBDataNull, DBDataNotFound):

- branch to artifact recovery (job download) before failure conclusion.

• - submit error contains JobModuleTaskMaxNumLimit:

- branch to capacity/quota diagnosis, not payload rewrite.

• - user asks 需要更新吗 / latest / should I update:

- branch to version/update decision workflow.

Version / Update Decision Workflow

When user asks whether update is needed:

1. 1. Check installed version:

CODEBLOCK11

1. 2. Compare against known baseline:

• - this skill baseline is v1.0.0 (minimum)
• if operating in this repo, also read repo CLI version from INLINECODE120

1. 3. Decision:

• - installed < v1.0.0 -> update required
• installed < repo version -> update required
• installed == repo version (or >= v1.0.0 and no higher trusted source available) -> no mandatory update from local evidence

1. 4. Upstream check:

• - if channel access is available, check official release channel directly
• if blocked, report explicit blocker and what was checked

Allowed final statements:

• - INLINECODE125
• INLINECODE126
• INLINECODE127

Response Contract

When answering operational questions, include:

• - what was checked (exact command(s))
• observed key evidence (version/status/error marker)
• decision/result category (for example update required / no update required / blocked)
• next concrete command when action is needed

Do not return generic uncertainty without evidence.

When To Read References (Secondary)

Use references for extra depth, not for basic operation:

• - references/install.md: installer, PATH/security, cross-platform details
• INLINECODE129: auth/session/host/lang/account nuances
• INLINECODE130: deeper module filtering/schema patterns
• INLINECODE131: flow payload troubleshooting patterns
• INLINECODE132: advanced diagnose/download behavior
• INLINECODE133: output ambiguity interpretation

Example Triggers

Use examples when task matches known pattern:

• - antibody numbering: INLINECODE134
• protein descriptors: INLINECODE135
• ADMET CSV: INLINECODE136
• MHC-I minimal output: INLINECODE137
• history recovery: INLINECODE138
• flow submit + download: INLINECODE139
• run-limit error: INLINECODE140

Completion Checklist

Before concluding:

• - Are command and payload shapes confirmed from live CLI output?
• If submit happened, were keys copied from schema (not guessed)?
• If output unclear, did you try job tasks/job download before declaring failure?
• If asked about update, did you run the full update decision workflow and return a direct conclusion?

Self-Check Scorecard (Pass/Fail)

Run this quick scorecard before sending the final answer:

1. 1. Evidence check (Pass/Fail)

• - Did I run or quote concrete command evidence (--version, status, error marker, etc.)?

1. 2. Decision check (Pass/Fail)

• - Did I provide an explicit result category (for example update required / no update required / blocked with reason)?

1. 3. Actionability check (Pass/Fail)

• - If action is needed, did I provide the exact next command?

1. 4. Deflection check (Pass/Fail)

• - Did I avoid pushing core comparison/diagnosis work back to the user?

If any item is Fail, revise the response before sending.