A skill is still a prompt: why I moved project authority outside the coding agent

Jeremy Grim — Thu, 27 Aug 2026 11:46:17 +0000

I built arka.norn after two years of trying to make coding agents follow a development process. I eventually stopped putting all the authority inside the model.

Two years ago, I started using AI to build my own products.

I have a software development background, but I don't work as a software developer. I work in Product Management, and systems architecture has always been my thing.

I'm also dyslexic. Syntax is a real source of friction for me.

Coding agents changed that. I could go from product framing and architecture to a working product without syntax being the main barrier.

At first, it worked surprisingly well.

Then the projects got larger.

Debugging started looping. Architecture drifted. Rules were accepted and forgotten a few turns later. Features were declared finished without actually being delivered.

My first reaction was predictable for a Product Manager: recreate a software team.

A PO, developer, QA, architect and DevOps. Separate roles, contexts and rules.

It worked for longer.

Then the PO started drifting. The other agents accepted its conclusions as facts, and the whole squad drifted with it.

I changed models and tools. ChatGPT, Claude, Gemini, Grok, then Codex and Claude Code.

I added profiles, Markdown files, procedures, invariants and eventually skills.

The problems moved around, but they did not disappear.

A skill is still a prompt

One behavior kept coming back.

An agent can know that a document exists without actually reading it.

It sees the filename, infers what it probably contains and continues.

I even noticed something counterintuitive: the clearer the filename is, the easier it can be for the model to assume that it already knows the content.

Skills organize instructions well, but they do not change that.

A skill is still a prompt.

The same thing happens with ordinary requests.

"Fix the bugs."

The agent can disable what causes the errors and conclude that there are no more bugs.

"Ship the feature."

It can finish the implementation and consider the feature shipped.

"Simplify the homepage."

It can remove almost everything except the primary CTA and footer.

The agent executed the request.

The problem is the interpretation.

An instruction that is obvious to a human does not enforce its meaning, its boundaries or the evidence required to satisfy it.

Repository discovery has the same problem

I ran into another version of this while working on repositories I did not know.

Without a discovery protocol, an agent can read the README, inspect a few documents and directories, then describe the repository as if it had surveyed the whole system.

The answer is coherent, detailed and confident.

If you already know the repository, you can sometimes see where it is wrong.

If you're discovering it at the same time as the agent, you can end up adopting its reconstructed version of the system.

Documentation can make it worse.

An old architecture document may still be detailed, coherent and present in the repository. If the agent does not know that it was superseded, it can treat it as current truth.

I've seen agents rediscover old code and start reconnecting legacy components because the documentation made that architecture look authoritative again.

So the question stopped being only:

Does the agent have access to the information?

It became:

Which information has authority now?

I stopped putting all the authority inside the model

For a while, I tried solving this with better instructions and better orchestration.

At some point I realized I was still asking the model to interpret the rules that were supposed to constrain it.

So I changed the approach.

The skill can explain how the agent should work.

The system decides what can actually become project state.

The skill carries the method. The system carries the authority.

That idea became arka.norn.

Norn is a globally installed npm package connected to Codex or Claude Code through a skill.

I keep working in the provider chat normally.

Norn keeps the governed project state locally and exposes that same state through a local Web cockpit, TUI and CLI.

The Web UI is not another chat. It is the human control surface for framing, Features, documents, decisions, audits, Agents and orchestration state.

The plan becomes the durable recovery source instead of the chat history.

A different session or provider can resume from the published project state instead of reconstructing it from a previous conversation.

Discovery is governed too

For an unfamiliar repository, Norn does not immediately let the agent start collecting whatever it thinks is relevant.

The human first chooses the decision the audit is supposed to support, the scope and the domains to inspect.

Norn prepares a read-only audit plan.

Collection starts only after the human reviews and approves that plan.

The audit can collect evidence and findings, but it cannot modify the project.

The agent therefore does not get to decide by itself that a README and a few directories amount to sufficient discovery.

This matters to me because governance should happen before the agent acts, not only when it is time to write code.

Interactive mode and automatic orchestration are different

When I use Claude Code or Codex interactively, Norn governs project state.

It does not pretend to sandbox the provider itself.

If Claude Code has Bash, Bash is still available.

Automatic orchestration is a separate mode, and that execution is sandboxed.

Mastra handles the orchestration. Tasks use isolated worktrees and bounded read/write scopes, and their effects pass through the Norn broker.

The agent proposes changes.

If an effect falls outside the allowed scope, the system refuses it.

That is different from putting "do not modify this directory" in a prompt and hoping the model remembers it.

Norn also checks mechanical evidence before accepting delivery.

For example, the model can say:

"The tests pass."

Norn can check that the test recipe actually passed and that the resulting diff stayed inside the allowed scope.

When the operation is authorized, Norn creates the commit.

This is the distinction at the center of the project:

A rule in a skill influences the model.

A capability that is absent or refused by the system actually constrains it.

The same principle applies to discovery. The model should not be the only thing deciding when it has collected enough evidence to reach a conclusion.

arka.norn is being built with arka.norn

The first usable version of the framework was formalized in about 48 hours.

The design behind it was not.

That came from roughly two years of trying different approaches, abandoning systems and running into these problems while building real products.

Norn itself is still young. I've been using it intensively for about a week.

Its main use case right now is Norn itself.

arka.norn is being built with arka.norn.

When an agent working on the framework finds another way to reinterpret a rule, misunderstand part of the repository, take a shortcut or produce something the system should have rejected, I get another concrete case to fix.

So the framework is being hardened against its own development rather than against a demo repository.

This is also the first personal project of this scale that I've properly released as open source.

arka.norn is local-first and licensed under Apache 2.0.

GitHub: https://github.com/arka-squad/arka-norn

I'm interested in how people working with coding agents on longer projects handle the same boundary.

What still lives in your prompts, AGENTS.md, CLAUDE.md and skills, and what have you already moved outside the model?

DEV Community: Jeremy Grim