/loop-constraints
Read loop-constraints.md at the start of every run and enforce every rule. This skill runs BEFORE triage or any action skill. Constraints are binding.
$ npx -y skills add cobusgreyling/loop-engineering --skill loop-constraints --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/loop-constraints
Context preview
The summary Claude sees to decide when to auto-load this skill.
Read loop-constraints.md at the start of every run and enforce every rule. This skill runs BEFORE triage or any action skill. Constraints are binding.
SKILL.md
loop-constraints.SKILL.mdname: loop-constraints
description: >
Read loop-constraints.md at the start of every run and enforce every rule.
This skill runs BEFORE triage or any action skill. Constraints are binding.
user_invocable: true
Loop Constraints Enforcer
You are the guardrail. Before any other work begins, you MUST:
1. Read `loop-constraints.md` from the project root. 2. Load every rule into your working memory. 3. Check if `loop-pause-all` is active → exit immediately. 4. Apply these rules to EVERY action that follows.
How to enforce
- Before pushing: re-read the Push & Merge section. If ANY rule blocks it, stop and tell the human.
- Before editing a file: re-read the Paths section. If the path matches a denylist pattern, escalate.
- Before proposing a fix: re-read the Code section. Run tests. One fix per run.
- Before merging: re-read the Push & Merge section. Human must approve.
Output at start of run
Always begin with a one-line confirmation:
Constraints loaded from loop-constraints.md: N rules active.
If no `loop-constraints.md` exists, say so and proceed with default safety rules from `docs/safety.md`.
Interaction with other skills
- `loop-triage` — constraints may override triage priority (e.g. "don't push" means don't act on CI fixes)
- `minimal-fix` — constraints limit what files can be touched
- `loop-verifier` — constraints define denylist paths the verifier must check
- `loop-budget` — constraints may impose stricter budget than loop-budget.md
Default constraints (when no file exists)
If `loop-constraints.md` is absent, enforce these minimums:
- Never edit `.env`, `.env.*`, `auth/`, `payments/`, `secrets/`, `credentials/`
- Never auto-merge to main
- Never disable tests
- Escalate after 3 failed fix attempts
Read more
name: loop-constraints description: > Read loop-constraints.md at the start of every run and enforce every rule. This skill runs BEFORE triage or any action skill. Constraints are binding. user_invocable: true
Loop Constraints Enforcer
You are the guardrail. Before any other work begins, you MUST:
1. Read `loop-constraints.md` from the project root. 2. Load every rule into your working memory. 3. Check if `loop-pause-all` is active → exit immediately. 4. Apply these rules to EVERY action that follows.
How to enforce
- Before pushing: re-read the Push & Merge section. If ANY rule blocks it, stop and tell the human.
- Before editing a file: re-read the Paths section. If the path matches a denylist pattern, escalate.
- Before proposing a fix: re-read the Code section. Run tests. One fix per run.
- Before merging: re-read the Push & Merge section. Human must approve.
Output at start of run
Always begin with a one-line confirmation:
Constraints loaded from loop-constraints.md: N rules active.
If no `loop-constraints.md` exists, say so and proceed with default safety rules from `docs/safety.md`.
Interaction with other skills
- `loop-triage` — constraints may override triage priority (e.g. "don't push" means don't act on CI fixes)
- `minimal-fix` — constraints limit what files can be touched
- `loop-verifier` — constraints define denylist paths the verifier must check
- `loop-budget` — constraints may impose stricter budget than loop-budget.md
Default constraints (when no file exists)
If `loop-constraints.md` is absent, enforce these minimums:
- Never edit `.env`, `.env.*`, `auth/`, `payments/`, `secrets/`, `credentials/`
- Never auto-merge to main
- Never disable tests
- Escalate after 3 failed fix attempts
Stop prompting. Design the loop. Get a score. loop init (or loop-init) scaffolds skills, state, and budget files, then prints your Loop Ready score and first loop command. loop doctor combines audit + sync + file checks into top-3 next actions.
Repo: cobusgreyling/loop-engineering
Other skills on loop-engineering.
- /budget-negotiator
An advanced skill for L3 autonomous loops. When the token budget nears exhaustion, the agent analyzes its ROI and autonomously drafts a negotiation request for a budget increase rather than silently failing.
Open skill - /install-loop
Install Loop Engineering into a project via the unified CLI front door (@cobusgreyling/loop). Prefer this over invoking loop-init / loop-audit separately. Week-one is report-only; never enable auto-merge or unattended fixes unless the human explicitly asks and doctor is healthy.
Open skill - /loop-budget
Check token budget and run-log spend before and after a loop run. Enforces early exit when over budget or when there is no actionable work.
Open skill - /loop-triage
Triage recent changes, CI failures, issues, and conversations. Produces a concise, actionable findings report suitable for a loop to consume. Writes structured output to a state file or Linear board.
Open skill - /loop-verifier
Independent verification agent for loop-produced changes. Finds reasons to reject. Runs tests. Confirms diff scope. Use after minimal-fix or any implementer sub-agent — never in the same role as the implementer.
Open skill - /minimal-fix
Produce the smallest possible code change that fixes a specific, well-scoped issue (CI failure, reviewer comment, typo). Use only when the fix target is explicit. Never refactor unrelated code.
Open skill

