Docs — What We Build
What We Build
A soft harness: the smallest surrounding system that lets a capable model do routine work inside your constraints. Not a longer prompt, and not a runtime that the model has to operate.
A Soft Harness, Not a Longer Prompt
The instinct when an agent gets something wrong is to write more prompt — teach it to analyse code, teach it to search, teach it to think step by step. That treats a capable model as if it were incapable, and it grows without limit.
A harness does the opposite. It supplies only what the model has no way to infer: your business facts, your project realities, your preferences, your authoritative sources, and the edges of what it may decide alone. Reasoning stays with the model. The test for any instruction is one question — would a better model make this unnecessary? If yes, it is scaffolding and needs evidence to stay.
Every Concern Has One Home
The landscape is a mapping. An artifact must not absorb a concern that belongs somewhere else, because two homes for one rule is how instruction systems start contradicting themselves.
Facts and preferences
context
Universal authority limits
the root contract
Task-scoped policies
skills
Procedures and sequence
workflows
Fresh-context responsibilities
agents
Data shapes
contracts
Hard guarantees
deterministic enforcement
Reasoning
the model
Layers exist only when the project earns them. A repository small enough to read in one sitting gets almost nothing; one instruction file has nothing for an evaluator to review.
What the Plugin Ships
Three skills, one agent, and five workflows. The skills route requests (ai-landscape), resolve decisions with real alternatives (brainstorm), and keep documentation aligned with completed changes (documentation-maintenance). The agent, Claude Code only, reviews a landscape read-only against a schema. Full instructions load on invoke; discovery metadata costs about 189 tokens per session.
Deliberately absent: no hooks, no MCP servers, no LSP servers, no mandatory manager, no generated project-convention layer, and no scenario-test machinery by default. Codex reports honestly when independent evaluation is unavailable rather than pretending it ran.
How a Change Moves
Every workflow that touches files runs the same shape. Approved scope is data, not prose: the proposal is a change-proposal contract that a script can check against the actual diff.
1
inspect
Read the repository, the existing landscape, and the working tree before asking anything.
2
propose
Emit a change-proposal contract: the exact file effects, which are destructive, and which paths stay local.
3
approve
Wait for an explicit answer. Moves, renames, and deletions are never assumed.
4
implement
Change only the approved paths, adding no adjacent speculative capability.
5
validate
Check the diff against the approved proposal with a script, not a promise.
6
evaluate
Review the changed instructions in fresh context, read-only by tool grant.
Guarantees Are Mechanical Where Possible
Prompt instructions influence behaviour; they do not guarantee it. So the things that must never drift move out of prose and into permissions, hooks, schemas, tests, and linters. The Claude evaluator is read-only because its tool grant excludes writing, not because a sentence asks it to behave.
The same logic covers approval. Rather than trusting that the agent stayed inside the scope you agreed to, the validator compares the working-tree delta and the locked content hashes against the approved proposal, and reports anything outside it.
Compatible With Any Capable Agent
Claude Code and Codex have native plugin marketplaces, so the framework ships as a plugin for both. Elsewhere, the workflows run straight from their YAML files. Portability means preserving the same intent across each tool's native representation — not forcing every tool into one fictional runtime.