Skip to content

For Workshop developers and coding agents

Workshop tooling that shows its work.

Wright checks, lints, and analyzes raw Workshop and OverPy projects. Every finding points to the exact line and says how sure it is, and the same results come as structured data for your editor, your CI, and your coding agent.

curl -fsSL https://wrightkit.dev/install.sh | bash
Terminal
$ wright check src/main.opyerror[unknown-member]: unknown member 'setHealht'  --> src/main.opy:3:5$ wright lint src/main.opywarning[min-wait-loop]: loop body waits at the workshop minimum rate  --> src/main.opy:3:5$ wright lint src/main.opy --format json{ "command": "lint", "ok": true, "result": { "findings": [ … ] } }

Tooling first

Built for checking real projects.

Diagnostics, lints, and analysis share one semantic model, so each result carries a stable code and a source location. Compilation exists to connect languages; it is not the point.

  • Diagnostics

    Errors and warnings with stable codes, severity, and exact source spans.

    wright check
  • High-confidence lints

    A small built-in rule set for loop, wait, and condition patterns that load the server. Each finding says how strong its evidence is.

    wright lint
  • Analysis

    Control-flow hotspots, loops and waits, and variables shared across rules, with every fact labelled static or heuristic.

    wright analyze
  • Inspection

    The full structural and semantic picture of a program, for tools that need more than a summary.

    wright inspect
  • Editor support

    wright-lsp adds hover, go to definition, references, completion, rename, and live diagnostics to any LSP editor.

    wright-lsp
  • CI

    Documented exit codes, one JSON result format, and GitHub Actions annotations detected automatically.

    wright lint --format json

Developers and agents

One set of tools for you and your coding agent.

Agents get the same semantic results you do, as deterministic structured data. No scraping terminal output, no reimplemented parsers. WrightKit is Workshop tooling for agents, not an agent framework.

For developers

  • Readable terminal output that points at the offending line
  • Editor integration through wright-lsp
  • Per-project lint configuration: turn a rule off or change its severity
  • Pull request annotations when Wright runs in GitHub Actions

For coding agents

  • One versioned JSON result for every command
  • Stable diagnostic codes, rule IDs, and exit codes to branch on
  • Edit transactions validated as a whole, refusing overlapping or order-dependent edits
  • The wright Agent Skill, published in wrightkit/skills

Where this is heading

The goal is intent-driven development: an agent takes a requirement and uses WrightKit at every step below, so you can focus on design instead of Workshop syntax. Parts of this loop ship today; a versioned agent contract is still in progress.

  1. 01

    Inspect

    Read the project, its rules, and dependencies.

  2. 02

    Edit

    Apply targeted, validated source changes.

  3. 03

    Check

    Re-run diagnostics and lints.

  4. 04

    Assess

    Estimate cost and flag server-load risk.

  5. 05

    Report

    State what cannot be proven statically.

Languages

Raw Workshop at the center. Established languages around it.

Workshop is the shared representation. Each source language has its own implementation, and conversions route through Workshop rather than bespoke bridges. Support grows with real projects, not a feature checklist.

  • Workshop

    Supported

    A first-class source form, not just compiler output. Parsing, validation, analysis, canonical emission, and en-US ↔ zh-CN conversion.

    workshop-rs
  • OverPy

    Partial

    Check, lint, and analyze existing OverPy projects in Wright. Compilation to Workshop covers the supported constructs; anything else gets a structured diagnostic.

    opy-rs
  • OSTW

    In development

    Parsing, projects, and type analysis live in deltin-rs. Advanced lowering is incomplete, and Wright does not ship OSTW support yet.

    deltin-rs

What “compatible” means

For OverPy and OSTW, the upstream compiler is the specification. Wright and upstream compile the same source; both results are parsed as canonical Workshop programs and compared structure for structure.

  • Rule order
  • Element identities
  • Control flow
  • Condition shape
  • Value construction
  • Variable names and indices
  • Element cost
  • Formatting, whitespace, and comments do not count. Text diffs are never the measure.
  • Any deviation from upstream output, even for an apparent upstream bug, needs an approved, recorded exception.
  • New heroes, maps, actions, and settings land in workshop-rs without waiting for upstream releases.

Install

Get Wright.

One install gives you wright and wright-lsp. The language engines also publish their own libraries from their repositories.

Homebrew

Apple silicon & Intel
brew install wrightkit/tap/wright

Installs the released wright and wright-lsp binaries.

Installer script

curl -fsSL https://wrightkit.dev/install.sh | bash

Release archives and checksums for every platform are on the GitHub Releases page.

Open source

How WrightKit fits together.

Wright is the product you install. The language engines underneath are independent projects you can also use on their own, each with its own tests, releases, and license.

  • Honest about limits

    Wright explains its static reasoning and flags what it cannot prove. It does not promise how code behaves on a live server.

  • Technical, not taste

    WrightKit tracks verified Workshop facts such as element catalogs and resource limits. It does not judge balance or game design.

  • Small, predictable core

    Built-in rules aim for few false positives. Broader checks belong in optional rule sets.

Not in scope

  • A generic compiler framework
  • A full IDE
  • Project hosting
  • A generic AI agent framework
  • A game runtime simulator
  • A transpiler collection