Kensa

AI & terminal

AI Integration

Updated for v0.16.0Edit on GitHub

Kensa's defining feature is that your AI coding agent works on your test cases the same way it works on your code - because the cases are just files, and the agent runs in a terminal right inside the app.

Kensa does not bundle a model, ask for an API key, or send your data anywhere. You bring an agent you already pay for and are already logged into.


1. The embedded terminal

A real pseudo-terminal lives next to the editor (right side by default, or bottom). It runs your actual shell, supports full-screen TUI apps (Claude Code, vim, tmux), and stays alive across case switches - one persistent session per project, rooted at the project folder.

See features/terminal.md for the full terminal feature set (multi-tab, true color, selection → editor, etc.).

2. The current case is wired into the environment

Whenever you open a case, Kensa updates environment variables in the terminal:

TMS_CASE=/path/to/project/suites/auth/218.md
TMS_PROJECT_ROOT=/path/to/project
KENSA_PROJECT_ROOT=/path/to/project
KENSA_VERSION=0.16.0

So you can say, without copy-pasting any path:

BASH
claude "read $TMS_CASE and add negative test cases for invalid input"
codex  "translate the steps in $TMS_CASE to Gherkin"

The agent edits the file in place; the editor picks up the change live.

3. Copy @-reference

Right-click any case in the sidebar → Copy @-reference puts a terminal-ready path like @suites/auth/218.md on your clipboard, for pasting into an agent prompt that uses @file references.

4. Pull agent output back into the editor

When an agent prints a draft case in the terminal, select the text, right-click, and choose:

  • Insert as new case in the current suite,
  • Append to the current case,
  • Replace the current case body, or
  • Copy to clipboard as Markdown.

Kensa tries to parse the selection as a Markdown case (detecting a "Steps" section and numbered steps); if it can't, it drops the text in as-is.

5. The bundled kensa CLI

The kensa command-line tool ships with the app and is automatically on the embedded terminal's PATH - no install step. Agents can call it to query, filter, edit, and lint cases programmatically:

BASH
kensa filter "tag:smoke and priority:high" --format ids
kensa context 218            # minimal editing context for one case
kensa lint                   # rule checks across the project

Full reference: cli.md.

6. One-click AI-plugin setup

The biggest convenience: Kensa can install a QA agent plugin into your project so your agent arrives already knowing the Kensa case format, conventions, and CLI - no prompt-engineering on your side.

Open it from the AI-plugin button in the top bar, or accept the prompt that appears right after you create an on-disk project ("soft onboarding").

What the dialog offers

Engines are listed dynamically from the QA-agents catalog, plus an "empty project" option. The two first-class engines:

Claude Code

  • Copies the plugin build into <project>/.claude/marketplace/kensa-qa/ - visible in your tree and committable, so the whole team gets it.
  • Registers a local directory marketplace in <project>/.claude/settings.json and enables the plugin there. On the next Claude Code session the plugin loads in place: agents, slash commands, skills, hooks, and an MCP server - with no network call and no /plugin install step.
  • Appends a QA-agents section to your <project>/CLAUDE.md so Claude has written guidance on the case format.

Codex

  • Copies .codex/agents/*.toml + AGENTS.md into the project root, which Codex auto-loads.

After install, the file tree, CLAUDE.md, and the detection badge refresh immediately. Kensa detects an existing install on open and shows which engines are set up.

Safety

  • App-driven install runs through a compiled Rust command with a pinned program allowlist and argument validation - no arbitrary shell execution capability is granted.
  • Paths are confined to the project root (symlink-escape and .. traversal are rejected); settings files are merged idempotently and never clobbered.
  • Both engines require an on-disk project. In-memory/demo projects show copy-the-commands instructions instead.
  • If you'd rather do it yourself, the dialog gives you the exact commands to copy.