Crate rhema_coding_agent 

rhema-coding-agent — the coding-agent driver, the first consumer of rhema-core’s step engine.

Wires a ModelProvider into a CodingAgent whose turns drive rhema_core::run_turn over the shared toolkit (rhema-agent-tools): the approval-gated shell, its spec and discovered skills presented in the system prompt, the model loading skill bodies via the shell. Tool errors surface in-band to the model (SPEC.md §4); approval arrives per turn through the Approval hook; the session is plain data the driver can persist and resume, with a commit hook so an intent is durable before its first side effect, revive-on-resume for calls a crash left unanswered, and cancel-path repair for those a user stopped.

Layout:

• agent — CodingAgent, CodingAgentError, stamped_system
• config — CodingAgentConfig
• prompt — the SYSTEM.md template and its default render

The toolkit itself — the Approval seam, ShellTools, skills, paste expansion, dangling-call repair, the renderer — lives in rhema-agent-tools and re-exports here: the TUI and ACP drivers import these names from this crate, and the claw’s forge handler takes the approval policy the same way.

Skills

A skill is a folder with a SKILL.md whose frontmatter carries a description (the trigger). Only name, trigger, and file enter the system prompt, as the prompt module’s skills list; the model reads a body itself through the bash tool when a trigger applies. Skills live globally under the config directory and per-workspace under .rhema/skills, project shadowing global.

Re-exports

pub use agent::CodingAgent;

pub use agent::CodingAgentError;

pub use agent::stamped_system;

pub use config::CodingAgentConfig;

pub use prompt::DEFAULT_SYSTEM_MD;

pub use prompt::default_system;

Modules

agent

The coding-agent driver: a provider, the built-in workspace tools, and the per-turn loop over rhema_core::run_turn.

config

The agent’s configuration: model, prompt, workspace, turn budget.

prompt

The coding agent’s system-prompt template: one markdown file, rendered by the toolkit’s Jinja renderer (rhema_agent_tools::render_system).

Structs

AllowAll

Approves everything; used by non-interactive drivers and tests.

DenyAll

Rejects every gated call: the headless default, where nobody is present to approve. Pair with an explicit opt-in to run tools unattended.

ExpandPastes

Expands embedded pastes in user text before a request leaves (rhema_core::paste): the session carries the compact chip form a UI renders, the model sees only the plain text. Wrapped around every provider the agent is built with, so fresh and resumed histories expand alike. Public so a driver that assembles its own Agent — the resident handler — wraps the same seam instead of growing a second expansion.

ShellTools

The built-in tool set: bash. Shared behind an Arc between the engine’s Agent and the driver.

Traits

Approval

Decides whether a gated tool call (bash) may run. Called once per gated call, before execution.

Functions

render_system

Renders a SYSTEM.md template: {{ workspace }} becomes the workspace path, skills holds the discovered skills as name, description, and path fields, and tools holds the advertised tool specs as name, description, and parameters (the JSON schema, renderable with tojson) — all there for {% for %}/{% if %}. Undefined variables render empty; syntax and filter errors return with template positions.

render_template

Renders template over context — the same engine and whitespace rules as render_system, with the caller’s own variables. A value’s own text is inserted verbatim, never re-parsed, so a section’s braces survive; the template name in errors is system.

repair_dangling_calls

Appends failure results for tool calls a dropped turn left hanging. A provider rejects an assistant tool call with no matching result, so without this the next turn would fail before saying a word. The drop can land between a committed call and its result — cancellation by future-drop (the TUI) and by session/cancel (ACP) both unwind this way — and the history must stay load-bearing for the next turn.

revive_dangling_calls

Closes calls a crash left committed-but-unanswered, with replay awareness: a call whose tool declared ReplaySafety::Safe is re-executed now against resolver so the round completes; an unsafe one gets an in-band failure telling the model the call was interrupted before its result landed, so it can verify state before retrying. One Tool result per dangling call, in call order; a clean history is untouched. The cancel path uses repair_dangling_calls instead — a cancelled call never re-runs, whatever its declared safety.