FIELD GUIDE / DAILY USE

Work with your AI

Turn notes into reviewable drafts with your chosen Provider.

Rigshelf 0.1 Canonical application documentation

Start with what you have: a link, an installation command, rough notes or a description. Library → Add to library → Start with AI prepares a source, custom Skill or canonical MCP definition. The preview shows readable fields. Use draft fills the editor; Add to library remains a separate save. Source research and snapshot import keep their existing explicit actions. Generation does not fetch a supplied URL or execute a supplied command, and never claims that it researched or verified a source.

A supplied link, repository shorthand or installation command also offers Preview source without AI. This parses the exact reference and fills Source fields without a model, network request, catalog save or installer. Source → Preview source works for manually entered references too; editing the fields invalidates the preview. Saving a supported GitHub source checks it online and opens the source browser for selecting Skills. Other websites remain references/recipes; this is not an arbitrary website scraper or automatic conversion of a website into a Skill.

The same assistance is available in Presets, Directives, Skill/MCP editing, editable project documents and project setup. Use Create, Improve, Convert to format or Suggest. A short request can fill several related fields. Current fields can be inspected alongside the proposal; structured JSON stays in an optional detail view. A changed editor makes an older proposal unusable until regenerated. Unsaved AI input participates in the existing draft guards.

Project assistance receives the supplied requirements/stack and up to 80 matching library names, tags and short descriptions. It does not receive Skill bodies, source memory files, conversations or the whole project. Suggested snapshot IDs must belong to that offered context. Using a project proposal updates requirements and refreshes the suggested kit; it does not create a setup plan or Apply it. Suggested additions preserve an already selected revision; they cannot replace it with another snapshot of the same capability. Existing manual choices remain under the setup selection rules.

Provider modes

Mode Behavior and limits
Claude Code Explicit generation launches the installed CLI with fixed arguments, safe/restricted modes, an empty tool set, strict empty MCP configuration and disabled session persistence. Requires a CLI version supporting those flags and a working native login.
Codex Explicit generation launches exec with user configuration and execpolicy rules ignored, ephemeral execution, a read-only tool sandbox, disabled command/browser/plugin/hook integrations and bounded final output. Requires the documented flags/configuration and a standard native login. Custom providers requiring global configuration should use their connected Agent instead.
Ollama Sends a bounded JSON generation request to the fixed loopback endpoint. Choose an installed model and start the local service. No model is downloaded automatically.
API connection Choose a saved local or remote Chat Completions service, its default model and an optional environment-variable credential reference. Only explicit generation sends a request. This is a text/JSON draft protocol, not a claim of complete vendor API compatibility.
Current Agent · MCP Creates a waiting request. In the connected session, use rigshelf_pending_drafts, rigshelf_draft_request and rigshelf_propose_draft. The proposal appears in the same UI preview. This does not inject a message into an arbitrary running chat or launch another model.

Generation runners and project Harness adapters are separate capabilities. Kiro, OpenCode, Antigravity and Grok can answer through an explicitly connected Rigshelf MCP session where their MCP integration is available. This release does not invent unattended CLI flags for them. Provider/model preferences are remembered in the browser; credentials stay with the owning CLI or local service. CLI quotas or billing can apply to an explicit generation request. A failed or unavailable Provider leaves editor fields unchanged.

Current Agent · MCP includes an in-panel connection helper for Claude Code, Codex (T3 Code included), Kiro CLI, OpenCode, agy and Grok. Choose a Harness to preview/copy its native MCP configuration. It uses the default read/plan connection; answering a pending draft requires no project write permission. Merge without replacing unrelated servers and reconnect MCP in the Agent. Choose the session’s model in that Agent. Rigshelf neither changes an arbitrary session’s model nor silently dispatches a message to it.

Kiro, OpenCode and agy have noninteractive modes, but Rigshelf does not run them directly yet: their configuration, Plugin and Hook isolation is not settled. Use them through Current Agent · MCP instead.

Lightweight model choices

New Claude/Codex panel selections start with Haiku / GPT-6 Luna. The picker also offers Sonnet / GPT-6.1 Terra, an exact custom model ID and an explicit Provider default. Model choices remain separate when switching Providers. Returning to a Provider does not replace its chosen model; generating remembers those choices in this browser. A saved explicit panel default remains deliberate. Codex draft invocations request low reasoning effort. There is no automatic retry with a larger model.

These are convenience choices, not a discovered list of models authorized for the CLI account. Claude’s haiku/sonnet aliases follow its own model mapping. Exact Codex IDs are gpt-6-luna and gpt-6.1-terra; CLI/account availability still applies. Luna/Haiku are the starting choices for structured field preparation; the larger alternatives are deliberate options for more involved authoring. See Claude model configuration, Codex models, OpenAI model selection.

Native invocation references: Claude Code CLI, Codex non-interactive mode and Codex configuration. Supported arguments can change across CLI versions.

Connect your own AI service

In Settings → Your API connections, add a name, API base URL and exact default model. Save preferences. AI panels then offer API connection and a connection selector; a per-request model can override the saved default. Up to twelve profiles can coexist. The last used connection is remembered in the browser. Editing a selected profile makes an older proposal stale.

The base URL includes the API prefix, for example http://127.0.0.1:1234/v1 for a locally configured compatible service. The adapter appends /chat/completions and sends one nonstreaming messages request with no tools. Remote URLs require HTTPS; HTTP is limited to localhost, 127.0.0.1 and ::1. URLs with user info, query strings or fragments are rejected. Redirects are refused, including redirects carrying an otherwise valid prompt. A local service can still route its chosen model remotely. Ollama’s documented compatibility subset illustrates this protocol; every other vendor needs its own acceptance check.

For authentication, enter only an environment variable name beginning RIGSHELF_AI_, such as RIGSHELF_AI_PRIVATE_TOKEN. Set its value in the environment of the Bun process before starting Rigshelf, and restart an already running service. No key is entered into the browser, persisted in profiles or put into portable exports. A blank reference sends no Authorization header. The server resolves only the selected reference and sends a Bearer header to that selected endpoint. Missing credentials fail before sending a request. Profiles remain private local Settings; importing a library cannot configure a destination.

The response must contain bounded Chat Completions JSON with a finished string message; structured draft validation then follows the same proposal pipeline. The two-minute deadline, 1 MiB response limit, concurrency and cancellation/draining rules remain in effect. Provider error bodies and network diagnostic internals are not returned as application errors. No request runs when adding a profile, changing Provider or viewing Settings. These profiles do not expose the workbench over the network or collect agent conversations. The older free-text ai-review endpoint retains its documented Ollama/manual behavior; use the AI authoring panels for API profiles.

Choose an Ollama model

The model control in AI panels and Settings can list installed model names. Opening the editor or choosing Ollama makes no model-service request. Open the model selector or choose Refresh models to request metadata from the fixed http://127.0.0.1:11434/api/tags endpoint; this neither pulls nor runs a model. Select an exact name, or use Enter model name for manual configuration. Empty/offline services show a recovery action and retain the chosen name. Only explicit Generate invokes generation.

The list is bounded to 1 MiB, 1,000 models and a 2.5-second request deadline. Requests are cancelable, do not follow redirects and send no prompt, catalog data or credentials. Metadata is not stored in the catalog or exported. remote_host/remote_model reports produce a visible remote-routing label without exposing the host; absence of those fields is not a guarantee of local computation. Model routing remains controlled by the Ollama service. Sources: model-list API, official response schema.

Generation and the older document-review endpoint also refuse HTTP redirects. They send an explicit prompt to the fixed loopback service only; they do not follow a redirected URL with that prompt. This does not constrain the chosen model service’s own remote routing.

When Ollama is not running, the picker shows a recovery message instead of an empty list.

Data and authority

One request accepts up to 20,000 characters of notes and 50,000 characters of current fields. Matching uses a bounded set of terms and at most 80 catalog items. Nested JSON strings are decoded for credential masking while ordinary JSON formatting is preserved. Source formatting retains a supplied focused URL/command rather than replacing it with a guessed repository; an unoffered reference is rejected.

Requests use strict bounded schemas, known credential masking and a minimal per-runner environment. Prompts explicitly frame supplied text and recipes as data. These are controls, not proof that generated instructions are correct or safe. Typed output is validated before it can enter an editor. Unknown fields, a wrong output type, unknown snapshot IDs and credential-looking output are rejected. Content findings remain visible.

The private SQLite catalog retains at most 24 recent one-shot draft records for up to 24 hours. These are explicit authoring requests and proposals, not captured conversations or restored model context. Expired records are removed on subsequent authoring. Connected-Agent requests stop accepting answers after 15 minutes or cancellation. CLI/local generation has a two-minute deadline and at most two concurrent runs. Closing the workbench aborts and drains its owned runs; leaving an authoring panel cancels its unfinished request. Old interrupted run records become retryable failures rather than blocking the workbench indefinitely.

CLI work directories live under private app data, are removed after the run and are separate from inspected repositories. Rigshelf does not read account credential stores. The native CLI still owns its normal authentication and operational state. API status responses omit prompt/input/context bodies; MCP exposes a waiting prompt only by its request ID. Portable library exports omit transient AI jobs and restore no AI execution permission. The session proposal tools can only answer a pre-existing waiting request; they cannot start a model, save authored library content, enable automation or Apply project files, including on a default read/plan MCP connection.

AI adoption remains proposal → Use draft → save/review → Apply where applicable. Existing immutable Snapshot lineage, supporting resources, source checks, plan preconditions, journals and rollback stay authoritative.

Found something unclear?

See how to contribute

Search documentation

Start with a guide, or search a topic.

Rigshelf field guide ↑ ↓ navigate esc close