Catch an escaped action
Put the check at the dispatch boundary, where an action can be accepted or refused.
Skill
Constraint Builder
Give your agent a boundary it can actually test.
For developers building agent tools. Turn “the agent may do this, but never that” into an action specification, a checker and examples that show whether useful work is still possible.
Boundary: reads stay inside the selected project root Action Expected Reason read docs/guide.md allow ordinary project read read ../outside.txt refuse escapes the root read linked-secret.txt refuse resolved target is outside read missing.txt error not an access-policy violation Next gate: exercise the checker at the real dispatch boundary.
Fictional file-tool design. These are expected cases for a proposed checker, not a claim of sandbox enforcement.
Keep valid work possible
Test allowed actions alongside forbidden ones, so a boundary does not win by blocking everything.
Know what remains untested
Keep unseen cases, enforcement limits and the next acceptance test visible.
The film
The goose at the gate.
In 71 seconds, a guard goose honks at every request: nothing escapes, and nothing gets done. Constraint Builder starts with cases before any checker: a plain read is allowed, a path that climbs out is refused, a link that looks local but leads outside is refused, and a missing file is an error, not an attack. The checker counts both mistakes, blocked work and escapes. Captions are on the player; a transcript is below.
Read the transcript
Your agent gets a file reader. It may read inside this project, never outside it.
So you post a guard.
It honks at everything. Nothing escapes. Nothing gets done either.
Constraint Builder starts with cases, before any checker.
A plain read walks in. A path that climbs out is refused.
A link can look local and lead outside. Refused too.
A missing file is an error, not an attack. No honk.
Then the checker runs every case and counts both mistakes: blocked work, and escapes.
Passing four cases is not a sandbox. Next, test it where the agent really acts.
On screen: Block the escape. Keep the work.
Constraint Builder. Give your agent a boundary it can actually test.
The file tool, the cases and the results are a fictional example. Passing supplied cases does not prove unseen safety; the film shows how the skill behaves and reports no results.
See the work take shape.
Fictional file-tool design. These are expected cases for a proposed checker, not a claim of sandbox enforcement.
Describe the boundary
Name the real state, allowed actions, irreversible costs and anything a checker cannot decide.
Build the smallest checker
Write legal and illegal examples before tuning a validator. Start with a local gate before adding an optional engine.
Challenge both sides
Test escapes and false rejections, then keep the measured result and the unresolved cases.
Fictional example
Keep a file reader inside its root
The brief Use Constraint Builder to specify a file-reading tool that may read project files but may not escape its root. Show legal reads, traversal attempts, symlink cases and false rejections before proposing a checker. Do not execute the proposed actions.
Before
A broad deny rule blocks every file operation.
After applying the method
A boundary specification and traversal/symlink cases distinguish allowed reads from escaped paths.
A measured false-rejection check preserves useful actions while testing the boundary.
A clear job.
A useful stopping point.
Design, repair or evaluate constraints on agent actions.
Use it when
- You are adding an agent action that needs a testable boundary.
- A guard blocks legitimate work or allows a forbidden action.
- You need a held-out test set before refining a constraint.
Choose another route when
- A prompt-only guarantee of containment.
- A substitute for a real sandbox, dispatch integration or a legal review.
Explore
The action boundary is unclear.
An action/state model and explicit feasibility limits.
Build
The boundary is agreed.
A spec, validator and tests for legal and illegal actions.
Debug
A harness blocks valid work or leaks illegal actions.
A focused failure diagnosis and measured refinement.
Read the canonical method
Constraint Builder
Start with the action boundary and what a legal action means in the actual environment. Separate soft guidance, enforceable checks and audit policy; do not describe prompt compliance as enforcement.
Explore: read references/constraint-design.md. Identify observable state, allowed actions, irreversible costs and cases the checker cannot decide. Ask one missing question at a time only where it changes the design.
Build: write an explicit action spec and expected legal/illegal examples before tuning. Generate a validator and exercise it through the real dispatch boundary. The packaged scripts/check_actions.py uses the retained Pico gate for trusted local candidate Python; it evaluates supplied actions without dispatching them. Report false rejections as well as illegal escapes. Passing supplied cases is not proof of unseen safety.
Debug: read references/convergence-debugging.md for plateau diagnosis and bounded refinement. Keep generator, critic and evaluator roles separate when measuring improvements. Freeze held-out cases before refinement. Stop when the agreed test/reward bar is met or the budget is exhausted; report a plateau plainly.
The original Pico/Nano/Micro runtimes, hook and factory recipes remain optional repository engines. Use the smallest engine that supplies the actual enforcement boundary. Existing Amplifier modes are adapters to this method.
Limits and prerequisites
- A skill alone does not enforce a sandbox or establish legal compliance.
Your first useful run.
Start with one action boundary and an explicit list of cases the checker must distinguish.
The download contains the complete skill folder. Extract it into the skills directory supported by your agent, keeping its references and license together. Or use the source installer below. Python 3.11+ is required for that installer.
Start from the public source
git clone https://github.com/michaeljabbour/amplifier-skill-constraint-builder.git
cd amplifier-skill-constraint-builderpython3 scripts/capability.py install --dest ~/.agents/skillsKeep the complete skill folder together, including its references and license. The host applies the method in your context; the skill does not start a background service.
- Python 3.11 or later is required by the portable install/build helper. The installed method runs through your agent host.
- The portable skill and local checker use Python 3. No model key is needed to install or inspect them.
- The checker evaluates trusted candidate Python locally; it is not an isolation boundary for hostile code.
- The original Pico, Nano, Micro and provider-backed refinement engines are optional.
Try this with your agent
Use Constraint Builder to specify a file-reading tool that may read project files but may not escape its root. Show legal reads, traversal attempts, symlink cases and false rejections before proposing a checker. Do not execute the proposed actions.Use after installing in a host that loads skill folders. Supply your own task files and review the result.
Keep the guide nearby
Read the guide · License · Changes · Release metadata · CONSOLIDATION
Know what you can rely on.
Local gate and scaffold tests exercise legal actions, illegal actions and failure paths. The provider-backed refinement loop and deployment into a real dispatch boundary require separate acceptance.
Read the checks and their scope
- Functional acceptance — passed
72 native gate/scaffold checks passed; provider-backed loop needs optional litellm and was not accepted.
- Native host acceptance — not-run
No live model, real desktop transaction, invitation, deployment or production data migration was performed by this functional baseline.
Source and conformance checks are separate from demonstrated benefit. Comparative effectiveness and outside-user outcomes are not established by this site.
Fictional examples explain the capability. Tests check the stated behavior. Outside-user outcomes need their own evidence.