robotframework

Use this skill for general Robot Framework work: authoring `.robot` suites, tasks, keywords, variables, resource files, execution, dry runs, tags, Rebot/Libdoc usage, and Python test-library patterns. Trigger when the user mentions Robot Framework, `.robot` files, keywords, libraries, resource files, tasks, listeners, Libdoc, Rebot, or Robot Framework syntax and execution.

Robot Framework

Use this skill for general Robot Framework authoring, refactoring, execution, and Python library work.

This is the broad Robot Framework skill. It is not wise-rpa-bdd, which is for browser-extraction-oriented BDD/RPA suites with a fixed generic-keyword contract.

Start Here

Classify the task first:

  1. Suite work: write or refactor .robot suites
  2. Keyword design: extract or reshape user keywords and resources
  3. Execution: run robot, --dryrun, tags, Rebot, pabot
  4. Library work: create or edit Python libraries
  5. Framework extension: listeners, remote libraries, dynamic APIs

Pick the narrowest layer that solves the problem.

Strong Defaults

  • Prefer .robot suites plus resource files before Python libraries.
  • Prefer high-level user keywords over repeated low-level calls.
  • Prefer *** Test Cases *** unless the work is genuinely task/RPA shaped.
  • Prefer Test Template when many rows share one interaction shape.
  • Prefer robot --dryrun as the first validation step.
  • Prefer Python libraries when suite logic starts hiding business intent.

Core Model

Choose the right layer:

  • suite file: scenario intent and visible assertions
  • resource file: shared domain flows, imports, and reusable keywords
  • Python library: external-system mechanics, parsing, retries, heavy logic

If the suite starts reading like general-purpose program code, move logic down into Python.

What Good Looks Like

Good Robot Framework code usually has:

  • short test/task bodies
  • intention-revealing user keywords
  • shared flows in resources instead of copy-paste
  • variables in the right place for their scope
  • clear execution commands

Bad Robot Framework code usually has:

  • giant inline test cases
  • one keyword that hides the whole scenario
  • duplicated low-level steps across files
  • nested control flow doing data shaping in .robot
  • environment values hardcoded in the suite

Fast Heuristics

  • If a test repeats the same 4-8 steps with different values, use a template or shared keyword.
  • If multiple suites share the same vocabulary, move it into a resource file.
  • If you need nested loops, conditionals, retries, or parsing, use Python.
  • If a value varies by environment, do not hardcode it in the suite.
  • If the keyword name tries to describe an entire workflow, split it.

Decision Table

NeedDefault
Reusable flow in .robotuser keyword or resource file
Shared imports / variables / keywordsresource file
Same-shape tests with different rowsTest Template
Heavy data logic or external APIsPython library
Fast structure validationrobot --dryrun
Merge or regenerate reportsrebot
Parallel runspabot
Library docslibdoc

Working Pattern

When implementing:

  1. choose suite vs resource vs library
  2. shape the suite body around behavior, not mechanics
  3. factor repeated flows into keywords
  4. validate with robot --dryrun
  5. run the narrowest real selection possible

Read Next

  • references/syntax.md for exact grammar, variables, control structures, RETURN, BDD prefixes, continuation rows, and __init__.robot
  • references/authoring.md for suite layout, templates, resources, BDD style, variable placement, and refactor boundaries
  • references/execution.md for robot, tag selection, reserved tags, argument files, pabot, output files, and Rebot
  • references/library-authoring.md for Python libraries, decorators, type conversion, listeners, dynamic/hybrid APIs, remote libraries, and Libdoc