10  The PROSE Specification

You’ve been using agent instructions for a few weeks. Some tasks produce clean output; others produce confident garbage. The difference isn’t the model or the prompt — it’s whether your setup follows five core constraints that determine how agents handle scope, context, and boundaries. This chapter specifies each one.

This is the reference chapter. Return to it when you are designing your instruction hierarchy, sizing a task for an agent, or debugging why a workflow that used to be reliable has started producing inconsistent results.

---

10.1 The Constraint Model

PROSE defines five constraints. Each addresses a fundamental property of language models (finite context, stateless reasoning, probabilistic output) and each induces a desirable property in the system that follows it. The constraints are independent in definition and interdependent in practice.¹

Constraint	Addresses	Induces
Progressive Disclosure	Context overload	Efficient context utilization
Reduced Scope	Scope creep	Manageable complexity
Orchestrated Composition	Monolithic collapse	Flexibility, reusability
Safety Boundaries	Unbounded autonomy	Reliability, verifiability
Explicit Hierarchy	Flat guidance	Modularity, domain adaptation

The remainder of this chapter specifies each constraint: definition, implementation patterns, anti-patterns, and, in the final section, what goes wrong when constraints are missing in combination.

---

10.2 P — Progressive Disclosure

Definition. Structure information to reveal complexity progressively. Context arrives just-in-time (loaded when the agent needs it for the current task) not just-in-case, where everything is loaded upfront on the assumption it might be relevant.

Why it matters. Context is finite and attention degrades under load. Here is how to implement that insight. The issue is not capacity (context windows keep growing) but attention. Information competes for focus, and material far from the active task gets deprioritized. A context window packed with architecture documents, coding standards, API specifications, and every source file that might be relevant is not a well-informed agent. It is a diluted one. The signal-to-noise ratio determines quality, not the volume of signal.

10.2.1 Implementation patterns

Markdown links as lazy-loading pointers. The simplest mechanism for progressive disclosure is a link. When an instruction file references [authentication patterns](../../docs/auth-patterns.md) rather than inlining the full authentication guide, the agent loads that content only when the current task involves authentication. The link acts as a pointer, a declaration that deeper context exists, with a path to reach it.

# API Development Guidelines

## Authentication
Follow the [authentication patterns](../../docs/auth-patterns.md) for all
protected endpoints. Token refresh logic is documented in
[token lifecycle](../../docs/token-lifecycle.md).

## Error Handling
Use the project's [error taxonomy](../../docs/errors.md). Every public
endpoint must return structured error responses.

The agent reads the guidelines. If the task involves authentication, it follows the link. If the task involves error handling, it follows a different link. Neither loads material for the other.

Descriptive labels for relevance assessment. Links work only when the agent can determine whether to follow them. Descriptive text (not just a filename, but a statement of what the linked content contains) enables the agent to assess relevance before loading.

Bad: See [docs](./docs/auth.md).

Good: See [JWT validation and refresh token rotation patterns](./docs/auth.md) for all endpoints requiring authentication.

The second version gives the agent enough information to decide whether the link is relevant to the current task without following it.

Skills metadata as capability indexes. A skill’s frontmatter describes what it does and when to activate. This metadata acts as an index: the agent reads the description, determines relevance, and loads the full skill content only when the task matches.

---
name: form-validation
description: >
  Activate when building or modifying form validation logic.
  Covers schema definition, error message formatting, and
  accessibility requirements for form feedback.
---

The agent working on a database migration sees this description and skips it. The agent building a user registration form loads the full content.

10.2.2 Anti-pattern: Context dumping

The most common violation of Progressive Disclosure is loading everything upfront. A single instruction file that inlines the full coding standards, the complete API reference, the authentication guide, and the error taxonomy, all in one document, wastes context capacity on material that is irrelevant to most tasks. The agent’s attention spreads across thousands of tokens of guidance, most of which do not apply.

Before — everything inlined in one file:

# Project Rules

[2,000 words of coding standards]
[1,500 words of authentication patterns]
[800 words of error handling]
[1,200 words of deployment procedures]
[600 words of accessibility requirements]

After — pointers with descriptive labels:

# Project Rules

## Core Standards
- [Coding standards and naming conventions](./standards/coding.md)
- [Authentication patterns and token lifecycle](./standards/auth.md)
- [Error taxonomy and response formatting](./standards/errors.md)
- [Deployment procedures and environment configuration](./standards/deploy.md)
- [Accessibility requirements for user-facing components](./standards/a11y.md)

Same information. Fraction of the context cost per task.

---

10.3 R — Reduced Scope

Definition. Match task size to context capacity. Complex work is decomposed into tasks sized to fit available context. Each sub-task operates with fresh context and focused scope.

The sizing heuristic. The best-sized task is one the agent can complete without asking a follow-up question. That is the headline. If the agent needs to ask “which error format should I use?” or “where is the existing session logic?”, either the task is too large (decompose it) or the context is insufficient (add the missing information). Both are scope problems. If you find yourself adding context mid-session to keep the agent on track, the scope was wrong from the start.

Three examples of tasks that were too big, and how they got split:

• “Add JWT authentication.” Too big: spans token schema, middleware, refresh endpoint, tests, and frontend. Split into five sessions (one per component), each with fresh context and a single deliverable.
• “Fix the login bug and update the session tests.” Two domains in one session. The bug fix accumulates context that degrades the quality of the test updates. Split: fix in one session, test updates in a follow-up with the fix already committed.
• “Refactor the payment service to use the new API client.” The agent needs to understand the old client, the new client, every call site, and the test suite simultaneously. Split by call site: each session migrates one module, with only the old→new API mapping and the target module’s source files in context.

10.3.1 Implementation patterns

Phase decomposition. Separate planning from implementation from testing. Each phase gets a fresh context window with only the information relevant to that phase.

Phase 1: Diagnose
  Input: error logs, relevant source files
  Output: root cause analysis with 2-3 candidate fixes

Phase 2: Implement
  Input: chosen fix from Phase 1, relevant source files
  Output: code changes

Phase 3: Validate
  Input: changed files, test suite
  Output: test results, regression check

Each phase operates with a clean context. The diagnosis phase does not carry the implementation context. The validation phase does not carry the diagnosis context. Quality remains consistent across phases because attention is never split.

Session splitting across domains. When a change spans multiple domains (frontend, backend, database) use separate sessions for each. A backend agent does not need the frontend component tree in its context. A database migration agent does not need the UI routing logic.

10.3.2 Anti-pattern: Scope creep

A session starts with a focused task. Mid-session, additional requests accumulate:

User: Fix the login timeout bug.
Agent: [analyzes, proposes fix]
User: Good, also update the session management tests.
User: While you're at it, refactor the token refresh logic.
User: And can you add the new /logout endpoint?

By the fourth request, the agent is operating with the accumulated context of four different tasks, attention split across all of them. The quality of the logout endpoint, the newest and least-contextualized task, is significantly lower than the quality of the original bug fix.

Fix: Each of those requests becomes its own session. The cost is four sessions instead of one. The benefit is four tasks done well instead of four tasks done poorly.

---

10.4 O — Orchestrated Composition

Definition. Favor small, chainable primitives over monolithic frameworks. Build complex behaviors by composing simple, well-defined units.

Why it matters. A 3,000-word mega-prompt that covers role definition, coding standards, error handling, testing requirements, security rules, documentation format, and output structure is not a well-specified agent. It is an unpredictable one. Small changes to any section produce unexpected changes in behavior across all sections, because the model processes the entire block as a single context. Composition preserves clarity. Each primitive is small enough to understand, test, and debug independently. Complex behavior emerges from combining primitives, not from making any single unit more complex.

10.4.1 Implementation patterns

Primitive types as atomic units. The building blocks are instruction files, skills, agents, prompts, and specifications. Each has a focused purpose:

.github/
├── instructions/
│   ├── frontend.instructions.md     # applyTo: "**/*.{tsx,jsx}"
│   ├── backend.instructions.md      # applyTo: "**/*.py"
│   └── testing.instructions.md      # applyTo: "**/test/**"
├── chatmodes/
│   ├── architect.chatmode.md        # Planning — cannot execute
│   └── backend-dev.chatmode.md      # Implementation — scoped tools
├── prompts/
│   └── feature-impl.prompt.md       # Multi-step workflow
└── skills/
    └── form-validation/
        └── SKILL.md                 # Auto-activated by relevance

Each file has a single responsibility. The frontend instructions do not contain backend rules. The architect agent does not have implementation tools. The feature workflow composes these building blocks without duplicating their content.

Workflows as compositions. A prompt file orchestrates multiple instruction files into a sequence:

# Feature Implementation Workflow

1. Review the [project specification](${specFile})
2. Analyze [existing patterns](./src/patterns/) for consistency
3. Implement changes following active instructions
4. Run validation: tests pass, linting clean, no regressions
5. **STOP** — present implementation summary for human review

The workflow does not restate the coding standards; the instruction files handle that. It does not redefine the agent’s role; the agent configuration handles that. It composes existing building blocks into a sequence.

10.4.2 Anti-pattern: Monolithic prompt

All guidance in a single block. Role, rules, examples, constraints, output format, everything in one prompt:

You are an expert Python developer who follows PEP 8 and uses type hints
everywhere. Always use the BaseIntegrator pattern for new integrators.
Never use os.walk — use find_files_by_glob instead. Log all errors with
_rich_error(). Write tests for every public method. Use pytest fixtures,
not setUp/tearDown. Document all public APIs with Google-style docstrings.
Format output as JSON when returning structured data. Never modify files
outside the src/ directory. Always run the linter before committing...

This works until it does not. When the agent produces incorrect output, which instruction failed? Which rule contradicted which other rule? A monolithic prompt is impossible to debug because every instruction interacts with every other instruction in ways the model resolves internally, without explanation.

Fix: Each concern becomes its own primitive file. The Python conventions go in python.instructions.md. The integrator architecture goes in integrators.instructions.md with applyTo: "src/**/integration/**". The testing standards go in testing.instructions.md. Each is independently testable, independently debuggable, and independently versioned.

---

10.5 S — Safety Boundaries

Definition. Every agent operates within explicit boundaries: what tools are available (capability), what context is loaded (knowledge), and what requires human approval (authority).

Why it matters. Chapter 1 established that output is probabilistic; variance is inherent, not a bug. Here is how to constrain it. When a non-deterministic system has unbounded authority, the variance in its outputs translates directly into variance in its effects. Boundaries do not reduce the agent’s usefulness. They constrain its blast radius. An agent that can modify backend code but not frontend assets, that can run tests but not deploy to production, that must pause for approval before deleting files — this agent is both more useful and more trustworthy than one with no restrictions.

10.5.1 Standard role boundaries

The table below defines four common agent roles with concrete capability, knowledge, and authority boundaries. Adapt these for your team; the specific tools will vary by platform, but the shape of each boundary should not.

Role	Tools (capability)	Knowledge (scope)	Authority (approval gates)
Code writer	editFiles, runCommands, search, readFiles, testRunner	Files matching its domain (applyTo or directory scope). Cannot see infra config, CI/CD, or deploy scripts.	Must STOP before: modifying public API signatures, changing database schemas, touching auth logic.
Reviewer	readFiles, search, runCommands (read-only: lint, test, type-check)	Full repository read access. No write tools.	No approval gates — reviewer cannot change anything. Output is commentary only.
Test runner	runCommands, readFiles, testRunner	Test files + source files under test. No access to deploy config, secrets, or CI definitions.	Must STOP before: deleting test fixtures, modifying shared test infrastructure, skipping tests.
Deployer	runCommands (deploy scripts only), readFiles	Deployment manifests, environment config, release notes. No source code write access.	Must STOP before: every deployment action. Human approves each environment promotion.

A planning agent (architect chatmode) is a special case: it gets readFiles and search only, no write tools at all. Its output is a plan, not code. The implementation agent consumes that plan in a separate session.

10.5.2 Implementation patterns

Tool whitelists per agent. Each agent configuration declares the specific tools it can access:

---
description: "Backend development specialist"
tools: ["editFiles", "runCommands", "search", "testRunner"]
---

The backend agent cannot access deployment tools. It cannot modify CI/CD configuration. Its capability boundary is explicit and auditable.

Validation gates requiring human approval. Critical decisions (architectural changes, security-sensitive modifications, data migrations) require the agent to stop and present its plan before proceeding:

## Validation Gate
Before modifying any authentication logic:
1. Present the proposed changes with rationale
2. **STOP** and wait for explicit human approval
3. Do not proceed until approval is received

The gate is part of the instruction, not an external enforcement mechanism. The agent’s context includes the requirement to pause.

Knowledge scoping. Instructions load only when the agent is working on matching files. Backend security rules do not load when the agent edits CSS. Frontend accessibility requirements do not load during database migrations.

Note: the applyTo pattern serves double duty. It is primarily an Explicit Hierarchy mechanism (see next section), defining which rules apply where. But it also functions as a knowledge boundary, constraining what the agent knows during a given task. The hierarchy section defines how applyTo works; this section explains why constraining knowledge matters for safety.

Deterministic tools as truth anchors. When an agent claims a test passes, a boundary-constrained system requires the agent to actually run the test and report the deterministic result. Code execution, API calls, file system operations: these are deterministic tools that ground probabilistic generation in verifiable reality.

10.5.3 Anti-pattern: Unbounded agent

An agent with access to every tool, every file, and no approval requirements:

---
description: "General development assistant"
tools: ["*"]
---

This agent can modify production configuration, delete test fixtures, rewrite CI pipelines, and access credentials, all without human oversight. When (not if) it produces an unexpected output, the blast radius is the entire repository.

Fix: Start with the role table above. Find the closest match, copy its boundaries, and tighten from there. The minimum set of tools is always fewer than you think.

---

10.6 E — Explicit Hierarchy

Definition. Instructions form a hierarchy from global to local. Local context inherits from and may override global context. Agents resolve context by walking from the most specific scope to the most general.

Why it matters. Different domains require different guidance, but they also share common ground. Hierarchy solves both problems. Global rules establish consistency: naming conventions, commit message format, documentation standards. Local rules enable specialization: the authentication module gets security-specific instructions, the frontend gets accessibility-specific instructions, the database layer gets migration-specific instructions. Each domain inherits the global rules and adds or overrides with local ones.

10.6.1 Implementation patterns

Directory-scoped context files. The AGENTS.md standard uses directory placement to define scope. A file at the project root applies everywhere. A file in frontend/ applies only to frontend code. A file in frontend/components/ applies only to components:

project/
├── AGENTS.md                    # Global: naming, commits, documentation
├── frontend/
│   ├── AGENTS.md               # Frontend: React patterns, accessibility
│   └── components/
│       └── AGENTS.md           # Components: prop conventions, testing
└── backend/
    ├── AGENTS.md               # Backend: API design, error handling
    └── auth/
        └── AGENTS.md           # Auth: security patterns, token handling

An agent editing backend/auth/token.py resolves context by walking up: auth/AGENTS.md + backend/AGENTS.md + root AGENTS.md. An agent editing frontend/components/Button.tsx resolves: components/AGENTS.md + frontend/AGENTS.md + root AGENTS.md. Neither loads the other’s domain-specific rules.

Pattern-scoped instruction files. The applyTo frontmatter targets instructions by file pattern, achieving hierarchical specificity without requiring directory-level files:

# General Python rules
---
applyTo: "**/*.py"
---

# Stricter rules for the public API surface
---
applyTo: "src/api/**/*.py"
---

# Most specific: authentication module security rules
---
applyTo: "src/api/auth/**/*.py"
---

More specific patterns override or extend less specific ones. The authentication module inherits general Python rules and general API rules, then adds its own security requirements.

Compilation for portability. Instruction files authored in tool-specific formats (.instructions.md with applyTo) can be compiled into hierarchical AGENTS.md files for universal portability. The source of truth is the authored instructions. The compiled output is the portable delivery format. This separation means the hierarchy works regardless of which AI coding tool the developer uses.

This hierarchical structure is what makes context files distributable. Package managers for agent primitives — such as APM — automate the scaffolding and sharing of instruction hierarchies across repositories and teams. The constraint (hierarchical context) drives the tooling, not the reverse.

10.6.2 Anti-pattern: Flat instructions

A single instruction file at the project root containing every rule for every domain:

# Project Instructions

## Python
Use type hints. Follow PEP 8...

## React
Use functional components. Follow accessibility guidelines...

## Authentication
Use JWT with RS256. Rotate refresh tokens...

## Database
Use migrations for all schema changes...

## CSS
Use CSS modules. Follow BEM naming...

Every agent, regardless of what it is working on, loads all of this. The Python backend agent processes CSS naming conventions. The database migration agent processes React accessibility guidelines. Attention is wasted. Worse, rules from unrelated domains can interfere — the agent might apply the “use modules” CSS guidance to Python module organization, producing unexpected results.

Fix: Split by scope. Python rules in a Python-scoped file. React rules in a frontend-scoped file. Authentication rules in an auth-scoped file. Each agent loads only what applies to its current task. Chapter 11 covers the engineering details: how to size each layer for the context budget, compose the hierarchy at runtime, and maintain it as your codebase evolves (see §The Instruction Hierarchy in Chapter 11).

---

10.7 When Constraints Are Missing: Three Failure Stories

The five constraints are defined independently but produce their strongest effects in combination. Theory says each pair closes a gap that neither constraint addresses alone. Practice is more memorable. Here are three teams that had one constraint in place and discovered the hard way what the missing partner cost them.

NoteAbout These Stories

The failure scenarios below are fictional composites, distilled from the author’s consulting observations and distorted to protect client confidentiality. They illustrate real patterns, not specific engagements.

The team with hierarchy but no progressive disclosure. A fintech startup (12 engineers, 18 months into their product) built a meticulous instruction hierarchy: global rules at the root, domain rules per service, module-specific rules for payments and auth. Textbook Explicit Hierarchy. But every instruction file was self-contained — the auth instructions inlined the full OWASP token reference (1,400 words), the complete session management spec (900 words), and the rate-limiting policy (600 words). When an agent worked on a simple token-validation bugfix, it loaded the auth-level file and received nearly 3,000 words of guidance for a 15-line change. The agent “solved” the bug by refactoring the token validation to also implement a rate-limiting improvement mentioned in the same file, a change no one asked for that introduced a subtle race condition in the refresh flow. The hierarchy got the right rules to the agent. Without progressive disclosure, it got all of them at once, and the agent could not distinguish the relevant from the adjacent.

The team with reduced scope but no composition. A platform team (8 engineers supporting 40+ microservices) was disciplined about task sizing — every agent session had a single, focused objective, fresh context, clean scope. Textbook Reduced Scope. But they had no composition layer. Each task carried its own copy of the coding standards, the error-handling patterns, and the testing requirements, pasted into the prompt rather than referenced from shared context files. When the team updated their error format from string messages to structured error objects, they updated the canonical doc but missed the pasted copies in four prompt templates. For two weeks, agents working on different services produced two different error formats depending on which prompt they received. The scope constraint kept each task reliable in isolation. Without composition, there was no single source of truth to keep them consistent with each other.

The team with safety boundaries but no reduced scope. An enterprise team (200+ engineers, regulated healthcare domain) enforced strict boundaries — tool whitelists per agent, mandatory approval gates for security-sensitive files, knowledge scoping via applyTo. Textbook Safety Boundaries. But they routinely dispatched broad tasks: “implement the full OAuth2 integration,” spanning token exchange, PKCE flow, session management, and error handling in one session. The agent operated within its tool boundaries but accumulated so much context over the long session that its attention degraded. Late in the session, it generated a refresh-token endpoint that stored tokens in a client-accessible cookie, a pattern explicitly forbidden by the security instructions loaded at session start, now buried under 40,000 tokens of accumulated implementation context. The safety boundaries constrained what the agent could do. Without reduced scope, they could not ensure the agent still remembered what it should not do.

The general pattern: each constraint addresses one failure mode, and each partner constraint catches the failures the first one cannot see.

graph TD
    P["P<br/>Progressive<br/>Disclosure"] <-- "controls<br/>attention" --> E["E<br/>Explicit<br/>Hierarchy"]
    R["R<br/>Reduced<br/>Scope"] <-- "constrains<br/>safety scope" --> S["S<br/>Safety<br/>Boundaries"]
    O["O<br/>Orchestrated<br/>Composition"] <-- "single source<br/>of truth" --> R
    P <-- "loads what<br/>fits scope" --> R
    E <-- "hierarchy defines<br/>boundaries" --> S
    O <-- "composable units<br/>enable disclosure" --> P

Figure 10.1: Relationships between the five PROSE constraints

---

10.8 Applying the Constraints: A Worked Example

Consider a team adding JWT authentication to an existing Express.js application. Without PROSE constraints, this is a single task given to a single agent with all project documentation loaded. With PROSE constraints, the same work produces five focused sessions, each with explicit boundaries and purpose-built context.

Here is what the key artifacts look like.

10.8.1 The instruction hierarchy

Root instructions (AGENTS.md) — global rules every agent inherits:

# Project Instructions

- Use TypeScript strict mode. No `any` types without a justifying comment.
- Commit messages follow Conventional Commits: `type(scope): description`.
- All public functions require JSDoc with `@param` and `@returns`.
- See [error taxonomy and response formatting](./docs/errors.md) for API error patterns.
- See [testing strategy and fixture conventions](./docs/testing.md) for test standards.

Backend instructions (backend/AGENTS.md) — API-layer rules, inherited by all backend modules:

# Backend Development

Inherits: root AGENTS.md

- Express route handlers must use the `asyncHandler` wrapper from `src/middleware/async.ts`.
- All request bodies validated with Zod schemas before processing.
- Database access only through repository classes in `src/repositories/`.
- See [API design patterns and pagination](./docs/api-design.md) for endpoint conventions.

Auth module instructions (.github/instructions/auth.instructions.md) — the security-specific rules for this domain:

---
applyTo: "src/auth/**"
description: "Security patterns for the authentication module — token signing,
  refresh rotation, rate limiting, and session management"
---

# Authentication Module Rules

## Token Standards
- Sign access tokens with RS256 using keys from environment config (`JWT_PRIVATE_KEY`).
  Never use symmetric algorithms (HS256) for access tokens.
- Access token TTL: 15 minutes. Refresh token TTL: 7 days.
- Refresh tokens are single-use. On refresh, issue a new refresh token and
  invalidate the previous one (rotation).

## Security Constraints
- Never log token values — log token IDs (`jti` claim) only.
- Never store tokens in localStorage. Use httpOnly secure cookies for refresh
  tokens. Access tokens stay in memory only.
- Rate limit the `/auth/refresh` endpoint: 10 requests per minute per user.

## References
- See [OWASP token best practices](../../docs/security/owasp-tokens.md) for
  the threat model behind these rules.
- See [existing session management](../../src/services/session.ts) for the
  current session implementation this module replaces.

## Validation Gate
Before modifying token signing logic or refresh rotation:
1. Present the proposed changes with security rationale
2. **STOP** and wait for explicit human approval
3. Do not proceed until approval is received

An agent editing src/auth/middleware.ts loads this file plus the backend and root instructions. An agent editing src/billing/invoice.ts never sees it.

10.8.2 The agent configuration

The backend implementation agent is scoped to write code in its domain and run tests — nothing else:

---
description: "Backend auth implementation specialist. Writes and tests
  authentication module code. Cannot modify frontend, CI/CD, or deploy config."
tools: ["editFiles", "runCommands", "search", "readFiles", "testRunner"]
---

# Auth Backend Developer

You implement backend authentication features in `src/auth/`.

## Boundaries
- You may create and edit files under `src/auth/` and `tests/auth/`.
- You may read any file in the repository for reference.
- You may run tests with `npm test -- --grep auth`.
- You must NOT modify files outside `src/auth/` and `tests/auth/`.
- You must NOT modify CI/CD configuration, deployment scripts, or environment files.
- You must NOT install new dependencies without presenting the rationale first.

## Workflow
1. Read the task description and relevant source files.
2. Check active instructions (auth module rules will load automatically).
3. Implement the change.
4. Run tests and verify they pass.
5. **STOP** — present a summary of changes for human review.

10.8.3 The task decomposition

The work decomposes into five sessions. Each gets a fresh context window:

Session	Task	Key context loaded	Deliverable
1	Design token schema and Zod validation types	Auth instructions, existing user model, JWT library docs	src/auth/schemas.ts
2	Implement auth middleware (verify + decode)	Auth instructions, token schemas from Session 1, Express middleware patterns	src/auth/middleware.ts
3	Build refresh endpoint with token rotation	Auth instructions, token schemas, session service reference	src/auth/routes/refresh.ts
4	Write integration tests for auth flow	Auth instructions, test conventions, all auth source files	tests/auth/ test suite
5	Update login form to use new auth endpoints	Frontend instructions (different agent), API contract from Sessions 2–3	src/components/LoginForm.tsx

Session 5 uses a different agent (frontend developer) with different instructions, different tools, and no access to src/auth/ internals. It receives only the API contract — endpoint URLs, request/response shapes — not the implementation details.

10.8.4 Where a constraint prevented a failure

During Session 2, the agent implemented the auth middleware and — following patterns it had seen in the codebase — started to also update the frontend API client to include the new auth headers. The safety boundary stopped it: the agent’s tool whitelist restricted file edits to src/auth/ and tests/auth/. It could not modify src/api/client.ts. The agent reported the suggested frontend change in its summary, and the team addressed it in Session 5 with the frontend agent that had the right context for that change.

Without the boundary, the backend agent would have modified the API client using only the backend context — missing the frontend’s existing interceptor pattern, the retry logic, and the error-handling conventions that the frontend instructions specify. The fix would have “worked” in isolation and broken the frontend’s error recovery flow.

---

10.9 Compliance Checklist

Use this checklist to evaluate whether your current setup satisfies PROSE constraints. Each question is specific enough to answer with a definitive yes or no.

#	Constraint	Question	Pass
P1	Progressive Disclosure	Does every instruction file over 100 lines use links (not inline content) for subsidiary topics?
P2	Progressive Disclosure	Does every cross-reference link include a description of what the target contains (not just a filename)?
R1	Reduced Scope	Can you state each agent task in one sentence with a single deliverable?
R2	Reduced Scope	Do multi-step workflows start each phase with a fresh context (no accumulated session state)?
O1	Orchestrated Composition	Does each instruction file address exactly one concern (check: could you name the file after its single topic)?
O2	Orchestrated Composition	Do workflow prompts reference shared instruction files by link rather than pasting their content?
S1	Safety Boundaries	Does every agent configuration have an explicit tools list (no wildcards)?
S2	Safety Boundaries	Is there a **STOP** gate before every operation that modifies auth, database schemas, or production config?
S3	Safety Boundaries	Does every agent have a file-path boundary (explicit list of directories it may modify)?
E1	Explicit Hierarchy	Do instructions exist at three or more specificity levels (e.g., root → domain → module)?
E2	Explicit Hierarchy	Can you add module-specific rules without editing any file above that module’s scope?

If you fail S1, S2, or S3 — start there regardless of your total score. Safety gaps have the highest blast radius and are the fastest to close (one YAML change per agent).

If you fail E1 or E2 — address these next. Hierarchy is the fastest architectural change to implement (create two scoped files and you have three levels).

If you fail P1, P2, R1, R2, O1, or O2 — these are discipline and refactoring issues. Prioritize whichever constraint maps to the failure mode you are currently experiencing. Scope creep? Fix R1/R2. Context dilution? Fix P1/P2. Debugging nightmares? Fix O1/O2.

---

The five constraints are the specification. The chapters that follow (context engineering in Chapter 11, multi-agent orchestration in Chapter 12, and the execution meta-process in Chapter 13) are the implementation. Every technique in those chapters traces back to one or more constraints defined here. When a technique works, it is because it satisfies the relevant constraint. When it fails, the constraint it violates tells you where to look.²

---

TipTry It

One implementation of PROSE scaffolding: pip install apm-cli && apm init — APM on GitHub. The primitives in this chapter can also be created manually following the file templates above.

---

1. The idea that constraints enable creativity rather than restricting it has deep roots in design thinking. See: Stokes, “Creativity from Constraints: The Psychology of Breakthrough,” Springer, 2005.

2. The shift from human-readable to machine-readable specifications parallels the evolution from informal requirements to formal methods in safety-critical systems. The difference: agentic specifications must be both — readable by the human reviewer and parseable by the agent consumer.