Future Scope

Specwright is designed to evolve. This page covers planned directions — multi-LLM support, CI integration, and team features.

Multi-LLM Support

The Specwright agent pipeline is model-agnostic by design. Every agent and skill is defined in plain Markdown files (.md, .mdx) with a frontmatter model: field. Switching models requires changing that field — no pipeline code changes needed.

Models in use today

Specwright runs on top of Claude Code CLI, which means it inherits whatever Claude models Anthropic makes available through the CLI. In the Specwright Desktop app, the pipeline currently runs on claude-sonnet-4-6 (Claude Sonnet 4.6).

What switching requires (Plugin + CLI)

To run a specific agent on a different Claude model, change its frontmatter:

---
name: code-generator
model: claude-opus-4-7
tools: Read, Write, Edit
---

No changes to skills, the pipeline orchestration, or Playwright BDD are needed. The agent contract (inputs, outputs, file paths) is model-independent.

Note: Browser exploration (Phase 4) is the most model-sensitive phase. It requires strong tool-use, multi-step reasoning, and accurate Playwright selector generation.

Future: broader model support

Support for non-Claude models (GPT-4.1, Gemini, local models via Ollama) is on the roadmap but not currently implemented. It would require either a Claude Code model override layer or a separate agent runner that speaks each provider's SDK.

Roadmap

Specwright Desktop — Overlay plugin auto-install

When a project's .specwright.json specifies an overlay field, the Desktop app will automatically detect and install the overlay plugin on top of the base plugin during project bootstrap — no manual install.sh run needed.

{
  "plugin": "@specwright/plugin",
  "overlay": "fourkites-e2e",
  "overlayPath": "../fourkites-ai-plugins/plugins/fourkites-e2e"
}

Parallel multi-module runs

Currently, config entries in instructions.js are processed sequentially (one module at a time). A future mode will allow concurrent Phase 4 exploration across multiple modules, reducing total wall-clock time for projects with 5+ modules.

CI mode

A headless, non-interactive pipeline mode for GitHub Actions and other CI systems:

• No approval gate (Phase 6 auto-skipped)
• JSON result export per module (pass/fail, scenario count, healing stats)
• Exit code reflects pipeline success/failure for CI gate decisions
• Compatible with --reporter=json Playwright output

Visual regression

Phase 8 healing could optionally run expect(page).toHaveScreenshot() assertions against a stored baseline — detecting unintended UI changes without writing explicit visual assertions in feature files.

Specwright Cloud (opt-in)

A shared layer for teams — agent memory, generated test files, and quality score history synced across developers. Local-first by default; cloud sync is entirely opt-in and self-hostable.

Migration from existing test frameworks

Specwright will support importing and converting existing test suites written in other frameworks into Playwright BDD:

• Selenium (Java/Python/JS) — parse existing test classes and map driver.findElement / driver.click calls to equivalent Playwright locators and BDD steps
• Cypress — convert cy.get, cy.click, cy.type, and cy.intercept chains to Playwright BDD step definitions
• WebdriverIO, TestCafe, Nightwatch, and other frameworks — extract test intent from existing spec files and regenerate as .feature + steps.js pairs

The migration agent will analyse the source test file, infer the user intent behind each action, and produce idiomatic Gherkin scenarios backed by Playwright step definitions — rather than a line-by-line mechanical translation. This preserves readability and allows the healing pipeline to maintain the migrated tests going forward.