Kensa
Kensa bot reaches toward a holographic AI hand, a green spark bridging them

KENSA-QA PLUGIN · CLAUDE CODE & CODEX

The plugin that brings a manual-QA team into Claude Code or Codex.

Point it at a ticket, get committed test cases. Free, MIT, no API keys.

View on GitHubDownload Kensa

HOW IT WORKS

A test lead and QA engineers, working in parallel.

All roles are agents. All artifacts are plain .md files in your repo.

Sources of truth

  • Linear
  • Jira
  • Confluence
  • Notion
  • Figma
  • Free text

Test Lead

Test Lead

Test Lead

  • scope-analysis
  • test-planning
  • reads project memory
  • pulls spec via MCP
  • finds neighbor cases
  • builds the plan

Human gate

you approve the plan before engineers spawn

QA Engineers · spawned in parallel

  • QA Engineer 1

    QA Engineer 1

    • Stage 1 - checklist
    • Stage 2 - reviews
    • Stage 3 - cases
  • QA Engineer 2

    QA Engineer 2

    • Stage 1 - checklist
    • Stage 2 - reviews
    • Stage 3 - cases
  • QA Engineer N

    QA Engineer N

    • Stage 1 - checklist
    • Stage 2 - reviews
    • Stage 3 - cases

Output

  • new + updated test cases
  • project memory
  • report: gaps, open Qs

HOW IT WORKS · /BRAINSTORM

When the strategy is contested, deliberate before you author.

Not every task is straightforward. When the strategy is contested - how to cut the scope, how deep to go, which technique to lead with - run /brainstorm first. Three strategists deliberate, you decide, then /new-feature builds from that decision.

Trigger

  • /brainstorm <topic>

contested scope · coverage depth · test approach · prioritization

Read-only - no test cases written.

Test Lead · frames the question

Test Lead

Test Lead

frames the question

  • classifies the topic - decomposition / coverage-strategy / test-approach / prioritization
  • picks 3 distinct axes from a strategy catalog - Scope, Decomposition, Test strategy, Effort, Maintainability…
  • assigns one stance per strategist

Human gate

you approve the 3 angles before strategists spawn

Round 1 · 3 strategists in parallel

each argues ONE angle as if it's right - no consensus, no hedging

  • Strategist 1

    Strategist 1

    aggressive-scope
    • proposal
    • scope in / out
    • est. case count
    • trade-offs
  • Strategist 2

    Strategist 2

    decompose-by-risk
    • proposal
    • scope in / out
    • est. case count
    • trade-offs
  • Strategist 3

    Strategist 3

    negative-first
    • proposal
    • scope in / out
    • est. case count
    • trade-offs

Round 2 · cross-review in parallel

fresh spawns - forced to engage with each other's ideas

  • Strategist 1

    Strategist 1

    aggressive-scope
    • what I'd steal
    • where I disagree
    • what both missed
    • updated stance
  • Strategist 2

    Strategist 2

    decompose-by-risk
    • what I'd steal
    • where I disagree
    • what both missed
    • updated stance
  • Strategist 3

    Strategist 3

    negative-first
    • what I'd steal
    • where I disagree
    • what both missed
    • updated stance

Test Lead · synthesis

Test Lead

Test Lead

synthesis - reads all 6 artifacts (3 proposals + 3 critiques)

Convergence
where ≥2 agreed
Disagreements
each side, untruncated

Finalists

  • Gold-standard
  • Balanced
  • Minimal

Human gate · you pick

You pick

the decision is yours - the Lead never auto-picks

  • Gold
  • Balanced
  • Minimal
  • Hybrid
  • Refine topic

Output

  • comparison artifact → .tms/brainstorms/*.md
feeds into /new-feature

Skills library

Every agent is trained on a defined skill set.

31 skills across 6 groups - grounded in ISTQB, plus Kensa-specific tooling.

Foundation

01 skills

The shared ISTQB baseline every agent stands on.

  • testing-fundamentals

Test Design

06 skills

How coverage is derived - techniques, edge cases, case craft.

  • test-design-techniques
  • white-box-techniques
  • collaboration-based-approaches
  • negative-and-edge-cases
  • test-case-writing-craft
  • checklist-design

Test Management

06 skills

Planning, risk, scope and control - the lead's toolkit.

  • test-planning
  • risk-based-testing
  • scope-analysis
  • review-rubrics
  • test-monitoring-control-completion
  • defect-management

Static & Lifecycle

02 skills

Reviews, and where testing sits in the SDLC.

  • sdlc-and-test-lifecycle
  • static-testing-reviews

Platform

05 skills

Domain-specific surfaces - web, mobile, API, security.

  • web-testing
  • mobile-testing
  • backend-api-testing
  • security-testing
  • test-tools-and-automation-overview

Tooling (non-ISTQB)

11 skills

Kensa CLI, source-of-truth connectors and protocol skills.

  • kensa-cli
  • kensa-test-authoring
  • sot-linear
  • sot-jira
  • sot-confluence
  • sot-notion
  • sot-figma
  • figma-use
  • sequential-thinking
  • task-assignment
  • clarification-protocol

INSTALL

Install

kensa-qa ships two clean engine builds from one monorepo - one for Claude Code, one for OpenAI Codex. No installer script. The built, ready-to-use folders live under dist/claude/ and dist/codex/ - each fully self-contained (agents, skills, hooks, manifest all inside).

Via an IDE: the IDE reads engines.json, offers the engine picker, and copies the chosen build into the project.

Pick your engine

Claude Code
$/plugin marketplace add rpluzhnikov/QA_agents$/plugin install kensa-qa@rpluzhnikov
Codex
$git clone https://github.com/rpluzhnikov/QA_agents.git$cp -R QA_agents/dist/codex/. /path/to/your-project/

USAGE

Commands

First-time setup

/setup

Interactive: asks about your stack, case language, ticket tracker, wiki. Scans existing cases under .tms/suites/ to learn your style.

Writes

  • .tms/memory/ - conventions, glossary, SOT config (edit by hand any time)
  • .mcp.json - MCP servers for your sources (restart Claude Code after this to connect)

Commands

CommandWhat it does
/new-feature <ref>

Pulls spec, plans, you approve, QA Engineers write cases under .tms/suites/<suite>/

/update-feature <ref>

Finds cases by source_id, reads new spec, adds/removes/rewrites only what changed

/brainstorm <topic>

Three strategists deliberate in parallel, output 2–3 finalists you pick from

/audit

Schema validation, duplicates, drift, tag check on the whole .tms/. Read-only by default

/save-memory

Captures session learnings to .tms/memory/learned/. Auto-runs after authoring on Windows

/setup

Bootstraps .tms/memory/ and .mcp.json. Re-run to add a new SOT

Analysis & planning

These six write no test cases - each produces one committable markdown artifact in .tms/reports/ and never emits the memory checkpoint.

CommandWhat it does
/pull-context <ref>

Gathers all SOT content + related cases into a dossier. Building block for the rest

/review-spec <ref>

Static review of a requirement (ISO 20246) - finds defects in the spec before any case is written

/risk-assess <ref>

Product risk register (likelihood × impact → level → recommended test depth)

/test-plan <epic>

ISTQB §5.1 test plan; folds in existing risk / context / brainstorm artifacts

/analyze-cases [scope]

Semantic deep-audit of the case base by a fan-out of 1–N reviewers - contradictions, semantic dupes, coverage gaps, convention drift. Complements the mechanical /audit

/traceability [--deep]

Requirements→cases matrix from source_id; --deep maps each acceptance criterion to cases

Command details

/new-feature <ref>

example
/new-feature LIN-42/new-feature https://yourcompany.atlassian.net/wiki/spaces/.../new-feature "Free-text spec pasted here"

The Test Lead pulls the spec, plans coverage, gets your sign-off, spawns QA Engineers for checklists, reviews, then has QA Engineers write the case files. Reports total case count, assumptions made, open questions for product.

/update-feature <ref>

example
/update-feature LIN-42

The Test Lead finds cases referencing the changed source (via source_id in frontmatter), reads the new spec, decides what to add/remove/rewrite. Same review + report flow as /new-feature.

/brainstorm <topic>

example
/brainstorm how to split the Discount Engine for parallel QA engineers?/brainstorm should 2FA cases be negative-first or boundary-first?

The Test Lead picks three angles (scope, decomposition strategy, test technique), three strategists each argue one angle in parallel, cross-review round, then a comparison view with 2–3 finalists. Saved to .tms/brainstorms/, referenceable from /new-feature later.

/audit

Walks .tms/ via the kensa-cli CLI: schema validation, duplicates, stale drafts, orphan shared-steps, tag drift, qualitative sampling. Output to terminal + .tms/reports/audit-YYYY-MM-DD.md. Opt-in fixes per-batch with confirmation.

/save-memory

Auto-runs after /new-feature and /update-feature (enforced by the auto-checkpoint hook on Windows). Run manually mid-session to capture a new convention before more work happens.

SDLC coverage

SDLC stageCommand(s)ISTQB skill surfaced

Requirements / static testing

/pull-context, /review-spec

static-testing-reviews

Risk analysis & planning

/risk-assess, /test-plan, /brainstorm

risk-based-testing, test-planning

Test design / authoring

/new-feature, /update-feature

test-design-techniques

Test-base health & coverage

/audit, /analyze-cases, /traceability

review-rubrics

Everything except authoring is read-only. The whole suite stays inside the mission - it designs and reasons about tests, it does not execute them.