Skip to main content
This feature is currently in beta and available to select customers. The exact CLI commands, API shapes, and workflow details may evolve during the beta period.

​
Overview

Tusk’s unit test generation experience is primarily designed around pull requests, merge requests, and the Tusk web app. The CLI and agent workflow beta extends that experience to local developer environments. With this beta, developers and coding agents (e.g., Claude Code, Codex, etc) can work with Tusk-generated test results in a more direct, machine-friendly way. This is especially useful for teams that already use local coding agents and want those agents to help review, refine, and incorporate Tusk’s output within agent workflows.

​
Use Cases

This is designed around three use cases:
  1. Retrieve Tusk test generation results
    • Fetch the latest Tusk run for a branch
    • Retrieve generated test scenarios and test code
    • Consume results in JSON for local tooling and agents
  2. Let local agents iterate on tests
    • Get Tusk to suggest test scenarios worth covering
    • Use Tusk’s test scenarios as a starting point
    • Refine generated tests locally for a faster feedback loop
    • Keep developers in control of what gets committed
  3. Send feedback back to Tusk
    • Tell Tusk which scenarios were helpful
    • Indicate which tests were incorporated locally
    • Share free-form feedback to improve future results
This is a good fit for teams that want:
  • A tighter local feedback loop for generated unit tests
  • More control over incorporation instead of relying only on the web app flow
  • A path to agent-assisted iteration without giving up Tusk’s scenario generation and test selection strengths

​
Agent Skills

Teams using coding agents can package these CLI workflows into reusable agent skills so their agents know when and how to fetch runs, review scenarios, pull patches, and send feedback. For example, a team could create a small SKILL.md that tells a coding agent to review Tusk-generated tests with a workflow like this: 
# Review Tusk Tests

Use this skill when the user wants help reviewing or iterating on Tusk-generated unit tests.

1. Run `tusk unit latest-run` for the current branch.
2. Run `tusk unit get-run` to inspect generated scenarios.
3. Pull the generated patch for the run.
4. Apply or adapt the test changes locally.
5. Run the relevant test command in the repo.
6. Send feedback back to Tusk with `tusk unit feedback`.

​
Example Workflow

1

Tusk generates unit tests for a PR or MR

Tusk continues to generate tests in the cloud as part of its normal pull request or merge request workflow.
2

A developer or coding agent retrieves the latest run

The CLI returns machine-readable output so a local agent can inspect the latest run, its status, and the generated test scenarios.
3

The agent reviews scenarios and test code

The local agent can analyze the generated tests, compare them to the current branch state, and decide which tests are worth keeping or refining.
4

The agent can pull full files or request suggestions

Depending on the workflow, the agent can either pull the full generated test files into the local checkout or ask Tusk to suggest new test scenarios based on local changes.
5

The agent iterates locally

Instead of waiting on another remote run, the agent can update tests in the local checkout and use the team’s existing developer workflow to run and validate them.
6

Feedback is sent back to Tusk

The developer or agent can report which scenarios were useful, which tests were incorporated, and what should improve in future runs.

​
Principles

We are designing this workflow around a few principles:
  • Agent-friendly by default: outputs should be easy to parse and consume programmatically
  • Local iteration when it matters: developers and agents should be able to refine tests without waiting on a full remote cycle
  • Clear ownership: Tusk suggests and generates, while the developer or local agent decides what to keep
  • Feedback loops back into the product: beta feedback should directly improve scenario quality and incorporation UX

​
Example CLI Workflow

Below is an example of the kind of workflow we are targeting in the beta.

​
1. Retrieve the latest Tusk run for a branch

tusk unit latest-run --repo acme/payments-service --branch feature/add-refund-guardrails

{
  "run_id": "tccr_123",
  "status": "success",
  "commit_sha": "abc123def456",
  "branch": "feature/add-refund-guardrails"
}

​
2. Fetch the full run details

tusk unit get-run tccr_123

{
  "run_id": "tccr_123",
  "status": "success",
  "commit_sha": "abc123def456",
  "failing_test_mode": true,
  "test_scenarios": [
    {
      "scenario_id": "ts_1",
      "is_passing": false,
      "file_path": "src/refunds/refundService.ts",
      "symbol_name": "validateRefundEligibility",
      "description": "Reject refunds when the original charge is already disputed"
    },
    {
      "scenario_id": "ts_2",
      "is_passing": true,
      "file_path": "src/refunds/refundService.ts",
      "symbol_name": "validateRefundEligibility",
      "description": "Allow partial refunds that stay within the remaining refundable amount"
    }
  ]
}

​
3. Fetch one test scenario

tusk unit get-scenario --run-id tccr_123 --scenario-id ts_1

{
  "scenario_id": "ts_1",
  "is_passing": false,
  "description": "Reject refunds when the original charge is already disputed",
  "symbol_name": "validateRefundEligibility",
  "file_path": "src/refunds/refundService.ts",
  "test_file_path": "src/refunds/__tests__/refundService.test.ts",
  "test_code": "it('rejects refunds for disputed charges', async () => { /* ... */ })",
  "test_output_summary": "Expected refund request to be rejected when charge.disputeStatus = 'open'"
}

​
4. Pull the generated test changes locally

tusk unit get-changes tccr_123

{
  "ok": true,
  "files": [
    {
      "path": "src/refunds/__tests__/refundService.test.ts",
      "patch": "@@ -42,6 +42,18 @@\n describe('validateRefundEligibility', () => {\n+  it('rejects refunds for disputed charges', async () => {\n+    /* ... */\n+  })\n })"
    }
  ]
}
Returning the generated test changes as a patch is often the safest workflow for local development. It lets a developer or coding agent review the proposed changes, apply them selectively, and resolve conflicts against local state when needed.

​
5. Suggest test scenarios from local state

In this workflow, the CLI uses your local branch state as input. Tusk compares your branch against its base branch, uploads the relevant diff and metadata to Tusk, and returns suggested test scenarios that a developer or coding agent can implement locally. 
tusk unit suggest

{
  "suggested_scenarios": [
    {
      "scenario_id": "ts_local_1",
      "file_path": "src/refunds/refundService.ts",
      "symbol_name": "validateRefundEligibility",
      "description": "Reject refunds when the charge has already been fully refunded"
    },
    {
      "scenario_id": "ts_local_2",
      "file_path": "src/refunds/refundService.ts",
      "symbol_name": "validateRefundEligibility",
      "description": "Allow refund requests that exactly match the remaining refundable balance"
    }
  ]
}
This is useful for teams that want Tusk to identify high-value scenarios while leaving the actual test authoring and iteration loop to a local coding agent.

​
6. Provide feedback back to Tusk

tusk unit feedback --run-id tccr_123 --scenario-id ts_1 --included true --comment "We kept this test and expanded the assertions locally."

{
  "ok": true
}
This feedback helps Tusk improve future test generation, and teams that want more direct control can also manage repo-specific instructions on the Customization page.

​
Questions?

Contact support@usetusk.ai. We are actively looking for feedback from early design partners as we shape this workflow.