Skip to main content

Quick start

Content reaches a workspace through a connector, and every route meets in the same place: the same profiles, the same vocabulary, the same content memory, the same review session. Pick the route that matches where your source lives.

Your source lives inStart hereAnything to install?
A content platform, a design tool, or documentsFrom your contentNo
A repository, and nobody wants a pipelineFrom a repositoryNo
A repository a developer works in every dayFrom a checkoutThe kapi CLI

From your content​

You write and publish content; you want it on profile for the audience it was written for, and optionally in more languages. Nothing to install: open app.bowrain.cloud (or your own server) and sign in. A personal workspace is created on first login.

  1. Establish the context. Run a context scan over content you already trust. It proposes the axes your content varies along, a voice profile and term candidates for you to review and approve. Vocabulary and content memory grow in the workspace from there.
  2. Create a project and bring content in. Upload files directly in the web app, or connect the systems your content lives in (WordPress, HubSpot, Figma) so source flows in and published results flow back. See First login and first project and Connectors.
  3. Draft and check. A run checks the source against the context and drafts any target languages against the voice profile, vocabulary, and memory in force at each point; checks flag what drifts.
  4. Review and publish. Step through the review session, approve what is right (corrections feed the learning loop), then export, or publish back through the connector.

The end-to-end path for this route is Publish on brand.

From a repository​

Your source files live in a GitHub or GitLab repository, and you would rather not add a pipeline to it. Connect the repository server-side: a push webhook triggers a run, and the results arrive as one open pull/merge request that every later delivery updates in place.

Nothing is installed and nothing is checked out; the server holds the credentials and does the work. With a GitHub App registered for your server, installing the app on a repository and binding it to a project is the only per-repository step.

See the GitHub / GitLab connector for setup, and The Bowrain GitHub App for the walkthrough.

From a checkout​

A developer edits the source files every day and wants the results in the working tree they already have open. This is the kapi connector: the kapi CLI with the bowrain plugin installed:

brew install neokapi/tap/bowrain-cli

Connect the repository to a workspace, then catch it up:

kapi init        # write kapi.yaml + .kapi/, sign in, connect to a workspace
kapi up          # catch the project up; runs on the server
kapi status      # per-scope coverage, ship standing, server standing, and venue

kapi up pushes what drifted, runs on the server with the organization's keys and shared memory, streams progress into the terminal, and pulls the results down. What a machine cannot decide parks into the team's review session.

The full command set, flows, and the CI contract are in the CLI section; Installation covers the other platforms.

Next steps​