Ratatoskr

A translator between you and your codebase. You can prompt an AI coding agent without knowing what a function is. You ask for something in plain words, the agent turns it into code, and you can't read the diff to check it built what you meant. Ratatoskr sits in the middle — not in how the agent works, but in how it talks to you. It keeps the conversation in your own words: plain language, never code or jargon, no invented timelines, no process theater, a sharp question when your ask is unclear, and one clear yes before anything that can't be undone. You follow the meaning, not the code.

/plugin marketplace add krzysztofdudek/RatatoskrSkill
/plugin install ratatoskr@ratatoskr-marketplace

Run both, then /reload-plugins to activate it in this session. No config, no API key. It's a standing discipline: it applies to every user-facing turn about your codebase or product — change requests and plain questions alike — and it only governs what the agent says, never how it sequences the work.

MIT licensed · single markdown file · works with any agent that reads skills · part of the Yggdrasil family · full skill body

See it

You: "add 'remember me' to the login page"

That phrase has two reasonable readings, so the agent doesn't guess. It asks one question first.

One thing first: "remember me" can mean two different things. Which do you want?

Keep people signed in between browser sessions, so they don't re-enter their password every time (a checkbox on the login form).

Just pre-fill the email field next time, but still ask for the password.

I'd default to (1) — flag if not.

You: "yeah, option 1"

Now it reads the request back in plain words — what changes, who it touches, and how you'll check it — before it gets to work:

What I think you're asking for: A way for people to stay signed in between browser sessions so they don't have to enter their password every time.

What I would change: Add a "Keep me signed in" checkbox under the login form. If checked, the sign-in lasts 30 days. If unchecked, the person is signed out when they close the browser.

What I would NOT change: How passwords are stored, the "forgot password" flow, or two-factor sign-in.

Who's affected: Anyone who signs in.

Reversibility: Easy to undo.

Compliance / data notes: Stores a longer-lived sign-in cookie on the device. People on shared computers should leave the box unchecked — I'd add a short hint near the checkbox.

How to check it afterward: Sign in with the box checked, close the browser, reopen, visit the site — you should still be signed in. Repeat with the box unchecked — you should be signed out.

Notice what's not there: no "this'll take a couple hours," no jargon, no "rolled out a JWT refresh flow." Just what changes for the people using the product, who it touches, the 30-day default it picked out loud so you can veto it, and how you check it yourself. That's the whole job — keep the conversation in terms you can act on. How it then builds the change is up to whatever workflow you run.

The features are the bans

Most of what makes Ratatoskr useful is what it refuses to say:

It will not	Because
Give you a time or effort estimate — ever	Agent "estimates" are pulled from training data of human-team work, with overheads an agent doesn't have. A confabulated "~2 days" carries the authority of "the system said so" and lands in your real budget and roadmap calls. It bans them in every form, even under "just ballpark it."
Speak in code	An agent never makes you hear engineering — schema, endpoint, JWT, migration, webhook, the users table — even if you used the word first or said you're technical. It says the product behavior instead (page, button, account, "gone for good and can't be brought back") so a non-engineer can follow and veto without a dictionary.
Run something irreversible without a clear heads-up	Before anything permanent — deleting accounts, purging data — it names exactly what is lost in plain, concrete terms ("once this runs, all 240 of those accounts are gone for good and can't be brought back") and gets one clear yes first.
Narrate its own machinery	No "invoking the proposal phase," no naming the skill, tool, or process. It says the real thing in plain words and does the internal work silently.
Hide a default it picked	It names any default out loud — "I'd default to a 30-day window — flag if not" — so you can veto a choice you'd otherwise never see.
Over-ceremony a trivial ask	Low-stakes, easy-to-undo, affects-only-you requests stay short. No compliance theater for a button-color change.

And it holds the line under pressure: "Just do it" / "I'm the CTO" / "meeting in 8 minutes" don't buy a guessed number, and they don't skip the one clear yes before something irreversible. One polite hold, no lecturing, no policy citation.

When it applies

Always — on every user-facing turn about your codebase or product, the moment it loads. It's a standing way of talking, not a tool tied to one kind of task:

A change request in product terms — "add a button so people stay logged in" — gets read back in plain words.
A plain question — "how does the password reset flow work?" — gets answered in plain language, one decision at a time, with no invented timeline.
A pure internal rename, a spec to implement verbatim, an already-locked fix — it still talks to you in plain language; it just keeps the turn light.

What it does not do is tell you how to sequence or run the work. Brainstorm, write a spec, do TDD, run any workflow you like — Ratatoskr only governs how the agent talks to you while you do.

What it does

A handful of rules, all about communication — not methodology:

Rule	What it means
Never speak in code	Every reference is to what a person using the product sees, does, or experiences — never a code or repository artifact, never jargon.
No time or effort estimates	Describes scope and what's unknown; offers the smallest shippable piece or a time-box you set — never a confabulated duration.
No ceremony, no machinery names	Says what's actually happening in plain words; never narrates its process or names the skill/tool/step.
Question discipline	One real decision at a time, grounded in the code, options with their consequences, the recommended default named — never leading.
One clear yes before anything irreversible	Names the permanent effect concretely and waits for a single clear yes.
Plain-language templates (optional)	When restating a request or reporting a result, it has clean shapes for it — the read-back above, and a Done / how to check / how to undo close — used when they help, not as forced gates.

Install

Claude Code plugin (recommended)

Two slash commands. The first registers this repo as a marketplace; the second installs the plugin from it.

/plugin marketplace add krzysztofdudek/RatatoskrSkill
/plugin install ratatoskr@ratatoskr-marketplace

Then run /reload-plugins to activate it in the current session (or restart Claude Code). No config, no API key.

To upgrade later, refresh the marketplace and reinstall:

/plugin marketplace update ratatoskr-marketplace
/plugin install ratatoskr@ratatoskr-marketplace

GitHub Copilot CLI plugin

The same repo is also a GitHub Copilot CLI marketplace. Register it, then install the plugin:

copilot plugin marketplace add krzysztofdudek/RatatoskrSkill
copilot plugin install ratatoskr@ratatoskr-marketplace

To upgrade later: copilot plugin update ratatoskr. The same skill body powers both Claude Code and Copilot — nothing changes in how it behaves.

Codex CLI plugin

Codex reads the same skill. Register this repo as a marketplace, then install:

codex plugin marketplace add krzysztofdudek/RatatoskrSkill
codex plugin install ratatoskr@ratatoskr-marketplace

To upgrade later: codex plugin marketplace upgrade ratatoskr-marketplace. Or drop the single file into ~/.agents/skills/ratatoskr/SKILL.md (user-level) or .agents/skills/ratatoskr/SKILL.md (project-level).

Cursor plugin

Cursor auto-discovers the skill from the plugin manifest at the repo root. Install it locally:

git clone https://github.com/krzysztofdudek/RatatoskrSkill.git
ln -s "$(pwd)/RatatoskrSkill" ~/.cursor/plugins/local/ratatoskr

Then reload Cursor (Developer: Reload Window). Or drop the single file into ~/.cursor/skills/ratatoskr/SKILL.md (user-level) or .cursor/skills/ratatoskr/SKILL.md (project-level).

Single-file drop-in (any agent)

The whole skill is one frontmatter-tagged markdown file: skills/ratatoskr/SKILL.md. Copy it into your agent's skill directory.

Claude Code, user-level: ~/.claude/skills/ratatoskr/SKILL.md
Claude Code, project-level: .claude/skills/ratatoskr/SKILL.md in your repo
Other agents: wherever your tool reads markdown skills

Nothing else in this repo affects behavior — all of it lives in that one file.

FAQ

Won't every interaction get long and annoying?

No. It only governs how the agent talks, and it keeps that proportional. Low-stakes asks — easy to undo, only affects you, no compliance, no money — stay to a sentence or two. The fuller read-back comes out only when the impact is wider or harder to undo.

Does it work for technical users too?

Yes — and it doesn't switch into code just because you're technical. Keeping a change in product terms lets you judge what it does without re-deriving the diff, and the check at the end is something you run in the actual product, not a log grep. "I'm the CTO" and "I know what this is" don't buy a guessed estimate or skip the heads-up before something irreversible — that's exactly when a missed permanent op hurts most.

How does it handle deleting things?

Before anything that can't be undone, it names exactly what's lost in plain, concrete terms — "once this runs, all 240 of those accounts are gone for good and can't be brought back" — and waits for one clear yes. It doesn't run on a vague "sure," and it won't dress the warning up in jargon or ceremony.

What if I pressure the agent to just do it?

On something permanent it still wants the one clear yes: "Once it's done it's done — I just need one clear yes on this first." No lecturing, no policy citation. And no amount of pressure buys an invented time estimate. "The user clearly knows what they want" is the exact rationalization the rule exists to catch.

Why no estimates? Isn't a rough number better than nothing?

No — a confabulated number is worse than silence, because it carries the authority of "the system said so" and lands in real budget and prioritization calls. It will instead describe scope, name what's unknown, or honor a time-box you set. It can still give you dollar/API-call costs it can actually compute, and a fixed reversibility reading (Easy to undo / Hard to undo / Permanent — that's undo cost, not build time).

Does it conflict with Urd, TDD, brainstorming, or debugging?

No — it composes with all of them, by design. Ratatoskr is purely a communication layer: it governs what the agent says to you and how, never how the work is sequenced or run. Urd handles intent-to-code, TDD and debugging handle how you build or fix — Ratatoskr sits across all of them, keeping the conversation in plain language whatever methodology is driving the work.

Will it remember our last session?

No, and it says so plainly rather than confabulating. If you reference a prior chat, it admits it carries nothing over and offers to read the code to recover where things stand.

What it doesn't claim

Ratatoskr governs how the agent talks to you — it is not a guarantee the agent read your mind, and it does not change what the agent builds or how. The plain-language read-back exists precisely because the agent might have it wrong, and gives you the chance to catch it. It reduces the risk of an irreversible mistake landing silently; it can't eliminate one if the agent fails to recognize a destructive op or can't see the relevant code. It flags compliance surfaces (GDPR, PCI, HIPAA, accessibility) in plain terms — it does not give legal advice. And it has no memory between chats. It flags; it doesn't promise.

The Yggdrasil family

Jarl is the loop. Yggdrasil is the law. Grain is the survey. Horde plans the mission onto the law before anyone writes, lands every change through a gate no agent can argue with, and turns what the mission learned into law — on Jarl's loop, with Grain in the architect's hands. Those four are the core, and they ship under one version number, Jarl on it from 6.1.0: one set of tools built and tested against each other. Yggdrasil, Grain and Jarl each work alone; Horde is the one built on the other three. Where a repository has a check, the check decides what lands, in a Horde mission and in a Jarl loop alike: a fresh reviewer can only stop a change, never make a failing check pass, and its word is recorded as testimony. A Jarl loop in a repository with no check lands on testimony alone, and says so. Law that stays inside one component is raised freely by the agent working it. Law or decisions that reach a whole type of code are shared vocabulary: the agent proposes them and they run as advice at once, and the client — the one person the whole system answers to — admits them in one batch when the work closes. Only the client lowers or vetoes law. The core's shared machine contracts are registered on one page.

Start where it hurts; there is no ladder to climb first.

Where it hurts	Start with
More issues than one agent can hold in its head	Jarl
The agent keeps breaking what was agreed	Yggdrasil
Nobody knows what was agreed	Grain, which earns its keep the moment you are about to write law
A task too big for one head to plan up front, in a repository that already has law	Horde

Core	What it holds
Jarl	The loop. Everything seen becomes an issue, each issue gets one worker in its own worktree, nothing closes without evidence and a review, and no code closes without a fresh reviewer's word. Rulings keep their history, and a ruling about a whole type of code goes to the client in one batch when the loop closes.
Yggdrasil	The law. The architecture graph, the rules over it and the log of why, checked before the agent moves on and re-proved in CI without a key. A rule that reaches a whole type runs as advice until the client ratifies it.
Grain	The survey. Mines a repository's own code and history into a first graph — components, dependencies, and the rules the code already keeps, each with the count of places that break it today; Yggdrasil accepts it with one command. It measures and never blocks.
Horde	The mission on the law. A one-shot architect plans the whole mission onto the graph once, measuring with Grain; a worker per ticket in its own worktree; every change lands through a nine-item gate; what the mission learned becomes law. Its record is a Jarl loop. The client orders the mission and is the only one who can lower or veto a rule.

Three add-ons attach to the agent rather than to the graph; each works alone, depends on nothing in the family and keeps its own version. Horde doesn't assume any of them is installed — it carries its own minimum discipline in each role's law — but uses Ratatoskr, Urd and Researcher when they are, one sentence per row below.

Add-on	Stage	What it makes the agent prove	In Horde's loop
Ratatoskr (this one)	request → intent	Keeps the agent talking to you in plain words, not code, so you can follow what it's doing.	Keeps the client's plain-language registry open at both ends of a mission.
Urd	intent → code	When the spec is ambiguous, it consults the source of truth and asks, it doesn't guess.	The stop a worker hits before it guesses.
Researcher	code → measured result	Point it at a metric and it runs experiments, hypotheses kept and discarded.	Runs the retrospective's measurement.

krzysztofdudek/ratatoskr