Meet ChimpHands: TestChimp's Native QA Cloud Agent on Your CI
TL;DR: We shipped ChimpHands—TestChimp's native QA cloud agent. It runs on your GitHub Actions runner (full code checkout, your secrets, your branches), executes the same /testchimp workflows you already use locally, and stays wired into the platform for automations, workflow executions, and live chat. Skill + CLI are packaged on every run—no mcp.json wiring per host. Attach stories, scenarios, issues, releases, and batch invocations from chat; add repo line ranges, upload local files, and co-edit in the diff pane. Built on OpenCode with GPT 5.6-range models tuned for cost-effective QA—not your Cursor or Claude dev subscriptions. The differentiator: async runs and interactive clarification share one session. Fire an automation overnight; jump into the same ChimpHands chat when the agent needs you. One-click setup.
Full docs: ChimpHands.
The wrong agent for the job (and the wrong bill)
Agentic QA is working. Teams run /testchimp fix-issue, /testchimp upkeep, /testchimp author-plans—and Automations route those workflows when issues, batches, and releases change.
But the executor still matters:
| Pain | What teams feel today |
|---|---|
| Subscription bleed | Nightly fix-test-execution and upkeep burn Cursor / Claude seats meant for implementation |
| Wiring tax | Labelled GitHub issues, MCP dashboards, per-provider secrets—different path per agent product |
| Async vs interactive | Fire a cloud job, wait for a PR—or sit in a separate chat UI. Clarification mid-run means a new conversation and lost context |
| Opaque spend | Dev-agent invoices mix feature work with QA housekeeping; hard to budget "spend on QA?" |
| Thin audit trail | External agent UXs don't always line up with TestChimp workflow executions and policy versions |
We built ChimpHands to be the native answer: QA workloads on your CI, orchestrated by TestChimp, metered for QA, traceable at the workflow level.
What is ChimpHands?
ChimpHands is TestChimp's own cloud agent for QA—not a generic coding-agent integration you bolt on later.
- Runs on your repo's GitHub Actions runner — not on TestChimp VMs. The agent checks out your branch, uses your tree, and opens PRs from CI.
- Full code context — same environment your SmartTests and policies already live in.
- Same workflow catalog —
fix-issue,implement,upkeep,author-plans,instrument-truecoverage,run-qa, and the rest. One skill, one MCP, oneworkflow-execution-idtimeline. - OpenCode + TestChimp skill — each job installs OpenCode and
@testchimp/cli, clones testchimp-skills, and runstestchimp chimphands serve. - Cost-optimized models — LLM traffic routes through GPT 5.6-range models suited to playbook-driven tool use, not always the priciest frontier tier.
Think: the QA agent your platform already knows how to schedule, audit, and budget.
Platform context and IDE-agent ergonomics—without the wiring tax
BYO cloud agents mean committing mcp.json, configuring MCP in Cursor/Copilot dashboards, and pasting issue ids into prompts. ChimpHands ships differently:
Packaged on CI: every job installs OpenCode, @testchimp/cli@latest, and clones testchimp-skills. You set TESTCHIMP_API_KEY once as a GitHub secret—not per-agent MCP setup.
Platform entities in chat: the composer + menu attaches removable tags for stories, scenarios, issues, tests, releases, and automation batches—searchable pickers, stable ref: lines in the outbound prompt (ordinal ids where applicable). Handoffs from Plans and Issues can pre-fill that context.
Repo + file parity with typical agents:
| Capability | ChimpHands |
|---|---|
| Line ranges in repo files | Select in diff/content pane → context tag |
| Whole files | Repo explorer, drag from changed-files list |
| Upload local context | Artifact upload → short-lived URL in prompt |
| Live diffs + human edits | Side pane writes back to the CI worktree |
So you get the "attach the failing test batch and lines 42–88 of checkout.spec.ts" workflow—native to TestChimp, not duct-taped through a generic coding-agent product.
Details: Chat with platform and repo context.
How it runs (one-click, then forget)
Setup is deliberately boring—in a good way:
- Connect the TestChimp GitHub App and map your repository.
- Open ChimpHands in the sidebar → install
.github/workflows/chimphands.yml(direct commit or PR if branch rules require it). - Add
TESTCHIMP_API_KEYas a GitHub Actions secret.
After that, ChimpHands sessions start from chat, Plans (Spec out / Scope out / Implement / Test), Issues, or Automations when you pick ChimpHands as the invocation strategy.
Trigger (automation / chat / Plans handoff)
↓
ChimpHands session + workflow execution
↓
GitHub Actions: checkout → OpenCode → TestChimp skill → /testchimp …
↓
Tunnel ↔ TestChimp UI (stream tools, diffs, messages)
↓
Pull request + Done / Failed in Workflow Executions
You can always drop to the GitHub Actions run for raw logs. The product UI is for humans; CI is the source of truth for the run.
Mechanics: How ChimpHands runs.
Async → in-convo without losing the thread
Most cloud agents force a tradeoff:
- Async: great for overnight
upkeep, terrible when the agent hits an ambiguous requirement at 2am. - Interactive: great for pairing, terrible for "fix every failed batch without me watching."
ChimpHands bridges both on one session id:
| Mode | Experience |
|---|---|
| Async | Automations dispatch; optional human gates before invoke or plan execute; you review the PR when done |
| Interactive | Open ChimpHands chat; watch reasoning, tool calls, and file diffs live from CI |
| Async → in-convo | Agent pauses for clarification; you reply in the same ChimpHands UI; the runtime on CI picks up your message and continues |
External agents (labelled issues, separate cloud UIs) usually break continuity here—you re-paste context or start over. ChimpHands keeps one session, one workflow execution, one Actions run.
That's the seamless human-in-the-loop story we wanted for policy-traceable workflows: attend when it matters, ignore when it doesn't—without losing the audit trail.
Why separate QA agent economics
ChimpHands metered usage enables you to have your QA workloads isolated from dev-agent subscriptions.
Your Claude Code and Cursor seats stay for implementation. ChimpHands credits cover the long tail:
- Fix failing SmartTests after CI
- Windowed
upkeepdigests author-planswith full repo context- TrueCoverage instrumentation and gap fixes
- Release
run-qacomposites
You set a QA budget per billing cycle. The platform enforces gates before metered runs and shows remaining credits in-product. Within that budget, ChimpHands aims for the best feasible protection—high-signal automations first, predictable spend, fail-closed when credits run out.
Value prop deep dive: Why ChimpHands.
Automations, now native
When we shipped Workflow Automations, the missing piece was a first-class executor that didn't require you to operate another agent product.
ChimpHands is now the recommended invocation strategy:
| Signal | Workflow | ChimpHands fit |
|---|---|---|
| High-severity issue | fix-issue | Full bug context + repo checkout → PR |
| Story / scenario → ready | implement | Plan-execute gates + same session for clarifications |
| CI batch failed | fix-test-execution | Buffered aggregation → one run per push |
| Release → Ready | run-qa | Composite QA without pasting prompts |
| Steady hygiene | upkeep | Windowed overnight digests |
Configure once under Workflows → Automations, choose ChimpHands, tune aggregation and gates. Same workflow-execution-id reporting as local /testchimp.
Recipes: Typical automation setups · Best practices.
ChimpHands vs bring-your-own cloud agents
| ChimpHands | GitHub Issue / Webhook | |
|---|---|---|
| Setup | GitHub App + one workflow file | Skill, MCP, secrets, per-agent docs |
| Host | Your GitHub Actions runner | Varies (Copilot, Codex Action, custom) |
| Platform UX | Native chat + execution timeline | External UI or issue thread |
| Cost | ChimpHands credits (QA-metered) | Your agent provider's billing |
| Default? | Yes | When you must keep an existing stack |
Bring-your-own paths remain: Cloud agents · Setting up cloud agents.
Why this matters in the agentic era
We've argued that skills are SaaS distribution—the playbook travels with the agent. That automations close the routing gap—events in, workflow executions out. That requirements need governance before agents spend tokens.
ChimpHands closes the executor gap: a cloud agent that is of TestChimp, on your CI, for QA economics.
Local Cursor / Claude for the interactive dev loop. ChimpHands for the overnight fix, the failed batch, the ready story, the release gate—and for jumping into the same session when the agent has a question.
That's how you boil the QA lake without standing next to every kettle or duct-taping five agent products together.
Frequently asked questions
What is ChimpHands?
ChimpHands is TestChimp's native QA cloud agent. It runs catalog /testchimp workflows on your GitHub Actions runner with full repository context, OpenCode, and the TestChimp skill—reachable from automations, Plans, Issues, and in-product chat.
Where does ChimpHands run?
On your GitHub Actions infrastructure. TestChimp dispatches .github/workflows/chimphands.yml; the job checks out your branch and executes the workflow there. TestChimp orchestrates sessions and streams UI updates over a tunnel—it does not host your source code.
How is ChimpHands different from Cursor or Claude for QA?
ChimpHands isolates QA spend from dev-agent subscriptions, uses cost-optimized GPT 5.6-range models for playbook-driven work, and ties every run to workflow executions in TestChimp. Use Cursor/Claude for IDE pair-programming; use ChimpHands for async QA, automations, and repo-context plan authoring.
How does human-in-the-loop work?
Automations can run fully async. If the agent needs clarification, open the same ChimpHands session in TestChimp chat—your reply reaches the CI runtime and the turn continues without a new conversation or copy-pasted context.
How do I set up ChimpHands?
Connect the TestChimp GitHub App, map the repo, install the ChimpHands workflow from the ChimpHands page, and add TESTCHIMP_API_KEY as a GitHub Actions secret. Step-by-step: ChimpHands intro.
Does ChimpHands replace local /testchimp?
No. Local agents with the TestChimp skill remain ideal for fast iteration and heavy IDE work. ChimpHands is the native cloud path—especially for automations and fire-and-forget QA runs.
Can I still use GitHub Issue or Webhook automations?
Yes. ChimpHands is the recommended default. Via GitHub Issue and Webhook stay available for bring-your-own agent stacks.
Do I need to commit mcp.json for ChimpHands?
No. The Actions job installs the TestChimp skill and @testchimp/cli on every run. You only need TESTCHIMP_API_KEY as a GitHub secret—unlike BYO cloud agents that require per-host MCP configuration.
Can I attach platform entities and file ranges in chat?
Yes. Tag stories, scenarios, issues, tests, releases, and automation batches from the composer + menu; add repo line ranges or whole files from the diff pane or explorer; upload local files as artifacts. Edit files collaboratively in the side pane when the runtime allows.
Try it
- Open ChimpHands in your TestChimp project sidebar
- Connect GitHub and Install the workflow (direct or via PR)
- Add
TESTCHIMP_API_KEYto GitHub Actions secrets - Start a chat session—or create an automation with ChimpHands as invocation strategy
- Watch Executions → Workflow Executions (and join chat if the agent asks)
Start here:
When QA work needs doing, the agent should already be on your CI—not eating your dev subscription or waiting for you to wire another product.
Further reading
TestChimp
Related posts
- Put QA on Auto-Pilot with Workflow Automations
- Policy-traceable workflows
- SKILLs as SaaS distribution
- Test planning as code
- Boiling the QA lake
Concepts