Agent Manifestov3.0.0

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. 1

    inspect

    Read the repository, the existing landscape, and the working tree before asking anything.

  2. 2

    propose

    Emit a change-proposal contract: the exact file effects, which are destructive, and which paths stay local.

  3. 3

    approve

    Wait for an explicit answer. Moves, renames, and deletions are never assumed.

  4. 4

    implement

    Change only the approved paths, adding no adjacent speculative capability.

  5. 5

    validate

    Check the diff against the approved proposal with a script, not a promise.

  6. 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.