Remogram 0.1.0-beta.5: forge facts agents can actually use

Give agents the same small set of trustworthy forge facts on every host, so they spend tokens on the work instead of recovering from wrong assumptions.

Agents working on real repos hit the same wall over and over. Forge CLIs dump huge JSON. Web UI text isn't machine-safe. “Just run gh” breaks as soon as you switch to Gitea or GitLab. Humans feel this as wrong summaries and missed blockers. Agents feel it as conflicting instructions and invented merge readiness.

Remogram 0.1.0-beta.5 is built around a simple job: give an agent the same small set of trustworthy facts, every time, on any supported forge, so it can decide what to do next without improvising from prose.

Remogram was developed by and for Topogram. You don't need Topogram to use it. Install: github.com/attebury/remogram.

npm install -g @remogram/cli@beta @remogram/mcp@beta

The problem we were solving

An agent reviewing or implementing a change usually needs answers like:

• Who am I on this forge, and can this token write?
• What branch rules apply?
• What files did this PR actually touch?
• What did reviewers say, as data rather than HTML?
• What changed on the forge since we last looked?
• Are checks real, missing, or failed? Is merge planning blocked for reasons git cleanliness hides?
• If I need to post a status or open a PR, can I do it through the same packet model I use to read?

Before beta.5, Remogram helped with PR state and checks. After beta.5, those questions have first-class commands with the same envelope on Gitea, GitHub, and GitLab, in both CLI and MCP.

What got easier for agents (and the humans behind them)

Less guessing about identity and permissions

whoami answers “who is this token?” and “does the forge think I can write?” in one packet. Agents stop inferring auth from error messages mid-task.

branch protection answers “what contexts or rules matter for this branch?” without scraping settings pages.

Benefit: fewer dead-end tool chains and fewer “try merge and see what happens” loops.

Review with evidence, not vibes

cr files returns changed paths from the forge (bounded, truncated honestly), so an agent knows what the PR touches, not what a local branch happens to contain.

cr comments returns review threads as structured records. Titles and bodies stay semantically untrusted; envelope fields and enums are what you gate on.

Benefit: review classifications bind to what changed and what was said, not to a PR title paraphrase.

Memory of the forge since last tick

forge changes --since … gives a time-bounded slice of lifecycle events: opens, closes, merges, head moves, check conclusions observed.

Benefit: observer-style routing and “what happened while I was implementing?” stop depending on chat history or manual git fetch storytelling.

Merge readiness agents can fail closed on

merge plan already exposed blockers beyond mergeability: clean. Beta.5 ties it to cr files: pass --allowed-path globs and get path_scope_violation or changed_paths_unavailable as normalized blockers, not a skill author's memory of repo layout.

Benefit: autonomous review/merge can stop on scope the same way it stops on failed checks, with a field in JSON instead of an essay.

Writes that behave like reads

Agents shouldn't special-case “read commands” vs “suddenly use curl.”

• cr open (Gitea, opt-in) opens or reuses a change request; reused_existing when the forge already has one.
• status set (all three API providers, opt-in) posts commit statuses with the same idempotency discipline: scan limits, idempotency_scan_incomplete when proof is impossible, reused_existing when nothing new is needed.

Both require explicit write_commands in .remogram.json. Otherwise you get write_not_configured: use forge/CI on your system. pr checks still tells you what landed.

Benefit: agents get a single contract for “I tried to act on the forge” instead of one packet world for reads and a separate undocumented shell world for writes.

Safety that respects how agents copy output

GitHub ghs_ tokens get redacted in normalization paths so forge blobs don't become accidental secrets in logs or the next prompt.

Benefit: less risk that an agent treats tool output as safe to repeat.

One surface, not a scavenger hunt

Beta.5 completes a coherent agent toolkit:

When the agent needs…	It can ask Remogram…
Config / health	doctor, provider capabilities, repo status
Inventory	refs inventory, cr inventory
This PR	pr view, pr checks, cr files, cr comments
Can we merge?	merge plan (+ optional path allowlist)
What changed lately?	forge changes --since …
Who am I / what rules apply?	whoami, branch protection
Post status / open CR (if opted in)	status set, cr open

17 MCP tools, same JSON as CLI. No workflow keys in packets. Agents orchestrate elsewhere; Remogram stays forge-shaped.

Merge execute is still not Remogram's job. That boundary is intentional: agents plan and prove; humans or forge policy merge.

When you want Remogram to post, opt in once in .remogram.json:

"write_commands": ["cr_open", "status_set"]

Skills: npx skills add attebury/remogram --skill remogram-consumer -g -a cursor,codex -y

MCP: see examples/mcp/ in the Remogram repo.

In one line

Beta.5 treats agents as users who need predictable forge facts and explicit gates, so they spend tokens on the work instead of recovering from wrong assumptions about what Remogram can see, say, or do.