Describe which checks apply, what agents may change, and when work must stop for approval instead of relying on every conversation to remember.
The project—not the current agent—decides what safe completion requires.Start with a conversation
Tell your agent the outcome and the safety boundary.
Skopos can help translate the request into its technical model after the intent is clear.
“Review this project's existing engineering rules and checks. Propose which rules should become deterministic Skopos Guards, which accepted standards belong in Policies, and which exact project Actions or observations can prove them. Keep advice separate from enforceable requirements.”
A reviewed path from intent to project behavior.
- 01
State the rule
Start with the real project expectation, such as requiring payment recovery proof after checkout changes.
- 02
Bind it to work
Match the rule by changed paths, Scope, Task phase, risk, and dependency impact.
- 03
Explain the result
Skopos reports why a rule and its check were selected, skipped, blocked, or approval-sensitive.
USE IT FOR
Common project uses.
- Require migration checks after schema changes
- Block deployment without approval
- Require design proof for rendered UI
- Skip unrelated tests for docs-only changes
The Skopos names for what you just configured.
- Guard
- A deterministic decision about when an Action or proof is required, allowed, or blocked.
- Policy
- A project-accepted standard that names the protection expected.
- Readiness
- The explanation of whether the bounded Task has enough fresh proof to finish.
WHAT THIS CANNOT DO
Policies do not guess shell commands, and Actions do not decide their own necessity. The project owns the Guard that connects a standard to its real provider.
NEXT
Add specialist guidance