Build faster without losing the system around the code.
RapidKit provides project kits and reusable modules. Workspai connects those projects to the model, graph, Doctor, evidence, and agent context that keep the wider workspace understandable.
Product boundary
Chistiq
The company behind RapidKit and Workspai.
RapidKit
The build layer: kits, modules, audits, and the Python engine.
Workspai
The Workspace Intelligence layer shared by CLI, CI, IDEs, and agents.
23
project targets
4
creation categories
52
reusable modules
v0.75.0
Workspai CLI
RapidKit Core v0.6.1. Project-target counts come from the published create-planner contract. Categories: backend · frontend · desktop · extension.
Available, strengthening, exploring
No speculative dates and no feature-count race. We publish what exists, identify the reliability work in progress, and label longer-term directions honestly.
A production-shaped starting point
- Workspai-owned and official project generators across backend, frontend, desktop, and extension targets.
- Reusable RapidKit Core modules for AI, auth, data, security, billing, observability, and product operations.
- Create, adopt, and import flows that register projects and refresh the shared workspace model, graph, and agent context.
- Module audits, Doctor evidence, and CLI/website contract checks that keep public instructions aligned with shipped behavior.
Reliability before catalog growth
- Cross-platform smoke evidence for every published generator, including generated files, registration, Doctor, and build checks.
- Repeatable module stabilization with dependency, security, test, and coverage evidence.
- Clearer runtime requirements and version policies for latest-stable official generators and tested Workspai baselines.
- Stronger two-way links between modules, audits, documentation, and the Workspai command that owns each workflow.
More reach without fragmenting the architecture
- Additional project targets only where an official stable generator or a maintainable Workspai-owned contract exists.
- Contributor-ready module and kit validation so ecosystem additions meet the same evidence bar as first-party surfaces.
- Focused graph, security, protocol, and shared-contract packages after their boundaries are stable in the integrated CLI.
- Team and portfolio workflows built on the same workspace identity rather than separate product-specific truth.
The rule behind the roadmap
A new kit or module is not shipped because a template can be generated. It must have a clear owner, version policy, metadata, Doctor path, and repeatable evidence.
New product surfaces consume the same Workspai contracts; they do not create a second source of truth for projects, capabilities, or release state.
Start with what is already shipped.
Choose a project target, add the modules you need, and let Workspai keep the resulting workspace connected and verifiable.