robotframework

name	robotframework
description	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.
metadata	{"author":"kundeng","version":"2.1.0"}

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

Need	Default
Reusable flow in .robot	user keyword or resource file
Shared imports / variables / keywords	resource file
Same-shape tests with different rows	Test Template
Heavy data logic or external APIs	Python library
Fast structure validation	robot --dryrun
Merge or regenerate reports	rebot
Parallel runs	pabot
Library docs	libdoc

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