robotframework-chat

Sets up new rfc (robotframework-chat) work on its own branch in an isolated git worktree at ../AI/rfc/worktree/<branch>. Branches from a base of the user's choice (defaults to origin/claude-code-staging), copies .env, runs `uv sync`, and runs the CLAUDE.md baseline checks so you land on a green, isolated checkout. Prefer this over the generic using-git-worktrees skill when the working directory is rfc.

Audits Robot Framework coverage from `make run-local-models` in the rfc repo (robotframework-chat) — i.e. answers "which models have been tested against which suites?". Builds a model × test-suite coverage matrix for the latest rfc version, writes a markdown report to `.claude/audits/`, and commits the latest results (the `results/` submodule is LFS-tracked). Also the entry point for launching the multi-hour `make run-local-models` run detached and doing status check-ins.

The shared triage + engage policy for the rfc (robotframework-chat) issue/PR monitoring agents. Defines the label taxonomy, when to assign/comment/flag stale, what to auto-handle versus escalate to the owner, hard safety rails (never close/merge/force-push/delete), idempotency rules, a per-sweep action cap to prevent comment floods, and where to write reports. Invoked identically by all three monitoring layers — the 30-min cloud heartbeat, the GitHub Actions checkpoint workflow, and the local webhook listener — so behaviour is the same no matter what woke the agent.

Closes the loop on the rfc self-healing listener: analyse and heal real suite failures, and ratchet difficulty upward (the IQ scale) for suites that always pass. Trigger when a robot suite fails repeatedly, when SelfHealingListener events show exhausted retries, when the coverage audit shows a suite at 100% pass across all models, or when the user says "self-heal this suite", "tests are too easy", "raise the IQ", or "why does this suite always pass".

The robotframework-chat pull-request workflow: rebase onto claude-code-staging, self-review the full diff, run the verification suite and capture output, bump the version, fill in every section of the PR template (summary, how-to-review, evidence of testing, critical changes, checklist), create the PR, and monitor it for feedback.

How to review a pull request in robotframework-chat: picking the right scope (whole-branch vs remote-only vs uncommitted), gh tooling caveats, verifying claims against the actual files before recommending changes, and the exact report structure (quality, suggestions, risks, coverage, security, verdict).

How to run real Robot Framework suites in robotframework-chat and where output lands: the 5-tuple watermark (rfc_version, model/harness, suite, hostname, session_id), when you are the agent harness vs when the LLM under test is the model, the MODEL_HARNESS vs DEFAULT_MODEL distinction, terminal vs web session constraints, and committing output.xml.

Migrates tests from other frameworks (pytest-only, unittest, shell scripts, ad-hoc scripts) into the robotframework-chat tiered test system. Covers the tier decision tree, mapping assertions to Robot Framework keywords, extracting Python logic into keyword libraries, parameterized tests, fixtures, tagging, and suite registration.

Creates a pure Robot Framework (tier:0, verify:robot) test that verifies behaviour using only deterministic RF built-in assertions — no LLM calls and no Python-backed keywords. Covers good tier:0 candidates, required tags, the allowed built-in keywords, shared resources, and registering the suite in config/test_suites.yaml and config/local_models.yaml.

Creates a tier:1 (verify:python) test that pairs a Robot Framework suite with a Python keyword library in src/rfc/ and a pytest in tests/. Covers writing the failing pytest first (TDD), implementing the typed keyword library, the Robot test that calls it, shared resources, and suite registration.

Imports external LLM-evaluation benchmarks/datasets from Hugging Face (GSM8K, MMLU, TruthfulQA, ARC, HellaSwag, HumanEval) as test inputs for the robotframework-chat framework. Covers the static-import approach (download once, convert to YAML, commit) versus the dynamic-import approach (load at runtime), authentication, licensing/contamination considerations, and suite registration.

Use when a user brings a product, design, or strategy decision and wants help thinking it through. Runs a short interview to gather context before proposing anything, then frames the decision as a "win-win-win" — a good outcome for the user/customer, the team, and the business. Resists jumping to solutions, names trade-offs explicitly, and invites pushback. Trigger on requests like "help me redesign X", "should we ship/deprecate/add Y", "what's the best Z for my app", or "write the launch email" where the right answer depends on context the user has not yet given.