A repository can tell a coding agent never to deploy to production while leaving the production command and credentials available. The sentence helps communicate intent; it does not remove the capability. Tessl’s four-part framework is useful because it separates that advisory role from procedures and controls with different loading and enforcement behavior.
The framework organizes team-owned files into persistent context, path-scoped rules, reusable skills and lifecycle hooks. Its concrete examples use Claude Code rather than a universal configuration format. The broader architectural question is which knowledge should always be present, which procedure should load only when needed, and which dangerous operation must be blocked outside the model’s judgment.
Four layers are different contracts, not four copies of the same policy
CLAUDE.md supplies project context needed across tasks: build commands, directory conventions, architecture boundaries and testing expectations. A service’s package manager or append-only migration convention can belong there. The root file works better as an overview or index than as a complete manual of every exception.
Focused rules under .claude/rules/ can load instructions through path patterns. An API validation rule need not compete for attention during a documentation change. A cross-cutting rule can cover handlers or migrations across packages without reproducing the same paragraph in several directories.
Reusable capabilities package a longer procedure in a folder with SKILL.md, metadata, instructions and supporting scripts or references. The overview can point to a release process, while a release skill owns its ordered checks. Claude Code initially loads a skill’s name and description; its full instructions enter context when relevant or explicitly invoked.
Hooks attach behavior to lifecycle events through settings or related configuration. A pre-tool check can inspect a proposed operation; a post-edit check can format or validate changed material; a completion check can require evidence before stopping. These purposes differ from merely adding another instruction the model must remember.
Tessl’s ownership argument is that this knowledge becomes a versioned repository asset. Engineers can inspect a diff, assign maintainers, review changes, revert a bad rule and give a fresh session the same shared context. The provider still owns the hosted model and runtime. Owning files does not mean owning every enforcement mechanism.
Context grows expensive when it becomes a policy database
Teams often begin with one instruction file because it immediately improves command selection and naming. Security rules, release steps, frontend conventions and personal exceptions then accumulate until every session loads them. Always-present material competes with task details, source code, tool results and conversation history; more prose is not automatically stronger adherence.
The cited Anthropic guidance recommends keeping CLAUDE.md under 200 lines, giving it an owner and reviewing it like code. The significance is attention and maintenance, not a guarantee tied to a line count. A concise instruction can still be misunderstood, and an important restriction does not become enforceable merely by being moved higher.
Nested instruction files can load when the agent accesses the relevant part of a tree. Path-scoped rules address another case: one concern spans several directories. Both reduce irrelevant context, but their exact loading, matching and precedence must be understood for the runtime in use.
The practical classification is functional. Project facts and judgment-heavy conventions belong in context; a repeatable multistep operation belongs in a skill; a prohibited action needs permissions, a blocking check or stronger system isolation. Long sessions, conflicts and hostile text can all affect model adherence. Seeing a policy sentence in a repository proves its existence, not its enforcement rate.
A hook can always trigger without making every decision deterministic
A model interprets persistent instructions, scoped rules and skill procedures. A hook is different because the runtime initiates it at a configured event rather than waiting for the model to recall a checklist. A PreToolUse check can inspect the proposed tool call before execution and return a blocking result when a command violates policy.
However, the handler determines how the decision is made. Command handlers execute scripts; prompt and agent handlers can use model judgment. A hook that reliably starts can still reach a probabilistic conclusion. Conditions software can evaluate directly are better candidates for command-based checks than for another model’s opinion.
For generated files, guidance can explain why editing is discouraged while a target-aware pre-action check rejects a prohibited write. For deployment, a skill can describe the approved route while permissions or hooks prevent a direct shortcut. The explanation and the barrier reinforce one another because they solve different problems.
Permissions provide allow and deny rules for tools and commands; the cited Claude Code controls give matching deny rules precedence over allows. Hooks can inspect richer conditions, but neither an allowed tool nor a successful check should imply unrestricted access to the operating system. Restricted credentials, containers, protected branches and read-only mounts remain relevant for serious consequences.
Post-edit automation also needs proportionality. A formatter or focused validator may be cheap enough after each edit, while running an entire test suite each time can obstruct work. Larger checks can fit commits or completion. A stop hook must avoid repeatedly demanding continuation without a useful path forward; otherwise a supposed gate becomes an expensive loop.
Review the control plane as code that can itself cause harm
Hooks are executable infrastructure. A flawed script can leak data, block legitimate work or add latency to every matching event. Repository ownership gives a team accountability for maintaining that code; it does not make unfamiliar repository configuration trustworthy. Workspace trust, review and isolated execution still matter.
Mutability creates a further boundary problem. If the agent can edit the same files that constrain it, a routine change can weaken a nearby rule or disable a check. Critical settings need stronger ownership and review, protected branches or read-only execution arrangements, rather than relying on the agent’s willingness to preserve its own restrictions.
A command-pattern block can miss an equivalent package task, indirect script or another tool with the same effect. Tests should attempt prohibited behavior through alternative routes, not just replay the example the rule was designed to catch. Legitimate work needs tests too: overbroad denials encourage exceptions, bypasses or wholesale disabling.
Untrusted issue text, documentation, dependencies and generated artifacts can contain prompt injection. A model may interpret those instructions alongside repository guidance. Deterministic permissions and isolated execution limit the resulting capabilities; prose alone cannot create that security boundary.
Skills preserve procedures only if teams maintain and activate them
Skills can make release, migration, dependency-upgrade and incident knowledge inspectable beyond one engineer’s chat. A repository-owned validator can handle a deterministic subtask while the agent handles judgment. A searchable engineering knowledge base can preserve the supporting decisions and documents; the skill defines how selected knowledge becomes a procedure.
Presence is not activation. Descriptions must explain when a skill applies, and evaluations need to verify that the right procedure actually loads. Explicit invocation can reduce ambiguity for sensitive work. Commands and architecture also change, so owners, examples and review cycles are maintenance requirements rather than optional polish.
Duplicating one rule in the root file, several scoped files and multiple skills creates competing versions of authority. One primary home for each fact, with links or brief indexes elsewhere, makes later changes easier to review. Personal configuration and managed organizational settings can still conflict with repository expectations; operators need visibility into which files loaded and which rules or permissions affected the action.
Portability and governance must be demonstrated through behavior
Other coding agents provide similar instruction, workflow and event-control concepts, but their directories and semantics differ. Tessl’s product interest in reusable context does not make its exact Claude Code paths a portable standard. Even a shared Markdown format must preserve triggering, scope, precedence and blocking behavior to offer meaningful portability.
Repeatable evaluations should start from clean environments, present the same tasks across runs and record loaded configuration, tool decisions and results. They should check adherence, correct skill activation, blocked operations and ordinary successful work. Independent repetition matters more than one convincing demonstration.
Three developments would strengthen the framework: practical instruction evaluations; capability formats with precise cross-runtime semantics; and interfaces that distinguish advice, guaranteed triggers and actual denials. Logs should make the reason for an allowed or rejected operation understandable. File count and documentation size cannot substitute for these outcomes.
The useful deliverable is an explainable control map. Another engineer should be able to identify the context that guides a decision, the procedure that appears on demand, and the external boundary that can stop a consequential mistake. Team-owned files make that map reviewable and recoverable. Safe autonomy still depends on tested enforcement and the infrastructure around it.
Sources and related reading
Tessl’s four-file framework · Anthropic steering guidance · Project memory and loading · Hook handler guide · Tool permissions · Skill packaging and invocation · Related reading: searchable engineering knowledge bases