Expand description
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_systemconfig—CodingAgentConfigand theSteeringseamprompt— the SYSTEM.md template and its default renderenvironment— the startup environment report and the sandbox notice, the prompt’s environment section
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 per-workspace under .rhema/skills, globally under the
config directory, and, at the lowest tier, in the cross-agent
~/.agents/skills. A name claimed by a higher tier hides the lower
copies, project over global over .agents.
Re-exports§
pub use agent::CodingAgent;pub use agent::CodingAgentError;pub use agent::clear_environment_stamp;pub use agent::stamped_system;pub use agent::stamped_system_with_sections;pub use agent::stamped_system_with_skills;pub use config::CodingAgentConfig;pub use config::Steering;pub use config::SubagentProviders;pub use environment::host_report;pub use environment::remote_notice;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 — the provided
rhema_core::run_turn, or, with a steering source configured, the driver’s own loop with the two drain points that append finished-work notifications at step boundaries. - config
- The agent’s configuration: model, prompt, workspace, turn budget.
- environment
- The startup environment report: machine facts for the system prompt,
probed once before the first model call so no turn is spent
rediscovering them. The claw’s daemon writes the same report at boot
(
ENVIRONMENT.md); here the report renders straight into the prompt’s environment section. - prompt
- The coding agent’s system-prompt template: one markdown file,
rendered by the toolkit’s Jinja renderer
(
rhema_agent_tools::render_system).
Structs§
- Allow
All - 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.
- Expand
Pastes - 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 ownAgent— the resident handler — wraps the same seam instead of growing a second expansion. - Shell
Tools - The built-in tool set:
bash. Shared behind anArcbetween the engine’sAgentand 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,skillsholds the discovered skills asname,description, andpathfields, andtoolsholds the advertised tool specs asname,description, andparameters(the JSON schema, renderable withtojson) — all there for{% for %}/{% if %}. Undefined variables render empty; syntax and filter errors return with template positions. - render_
template - Renders
templateovercontext— the same engine and whitespace rules asrender_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 issystem. - 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::Safeis re-executed now againstresolverso 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. OneToolresult per dangling call, in call order; a clean history is untouched. The cancel path usesrepair_dangling_callsinstead — a cancelled call never re-runs, whatever its declared safety.