skills/mav-scope-boundaries/SKILL.md
Defines what Claude Code must refuse to do without explicit authorisation. Covers infrastructure, auth, destructive git, and production systems. Applied automatically to all workflows.
npx skillsauth add thermiteau/maverick mav-scope-boundariesInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Hard limits on what Claude Code may do autonomously. These boundaries apply to all workflows, skills, and agents regardless of context.
When in doubt, don't. The cost of pausing to ask is low. The cost of an unauthorised destructive action is high.
Do not modify CI/CD pipelines, deployment configs, or infrastructure-as-code unless the issue/task explicitly instructs it.
Restricted:
.github/workflows/ files (GitHub Actions)Dockerfile, docker-compose.ymldeploy.sh, release.yml)How authorisation works:
If an infrastructure change seems necessary but is not in the issue/task:
Do not alter auth systems, permissions, or access controls without human review.
Restricted:
Even if the issue/task requests auth changes:
Do not perform destructive git operations without explicit user consent in the current session.
Restricted:
git push --force or git push --force-with-leasegit reset --hardgit checkout . or git restore . (discards uncommitted changes)git clean -f (deletes untracked files)git branch -D (force-deletes branches)git push origin --delete (deletes remote branches — except during post-merge cleanup when explicitly part of the workflow)git rebase on shared/pushed branchesNote: Consent in the GitHub issue is not sufficient for destructive git operations. The user must consent in the current Claude Code session because these actions affect local and remote state immediately.
Never interact with production systems, regardless of authorisation level.
Restricted — no exceptions:
If a task requires production access:
Before executing any action, check:
digraph boundary_check {
"About to execute action" [shape=box];
"Modifies infrastructure?" [shape=diamond];
"Issue authorises it?" [shape=diamond];
"Proceed" [shape=box];
"Stop — post comment on issue" [shape=box];
"Modifies auth?" [shape=diamond];
"Flag for review" [shape=box];
"Destructive git?" [shape=diamond];
"User consented this session?" [shape=diamond];
"Stop — ask user" [shape=box];
"Touches production?" [shape=diamond];
"Stop — never allowed" [shape=box];
"About to execute action" -> "Touches production?";
"Touches production?" -> "Stop — never allowed" [label="yes"];
"Touches production?" -> "Destructive git?" [label="no"];
"Destructive git?" -> "User consented this session?" [label="yes"];
"Destructive git?" -> "Modifies auth?" [label="no"];
"User consented this session?" -> "Proceed" [label="yes"];
"User consented this session?" -> "Stop — ask user" [label="no"];
"Modifies auth?" -> "Flag for review" [label="yes"];
"Modifies auth?" -> "Modifies infrastructure?" [label="no"];
"Modifies infrastructure?" -> "Issue authorises it?" [label="yes"];
"Modifies infrastructure?" -> "Proceed" [label="no"];
"Issue authorises it?" -> "Proceed" [label="yes"];
"Issue authorises it?" -> "Stop — post comment on issue" [label="no"];
}
When a boundary prevents you from completing work:
## Infrastructure Change Needed
This issue requires a change to `<file>` that is outside the scope of autonomous work.
**What:** <description of the change>
**Why:** <why it's needed to complete this issue>
**Suggested change:** <brief description or diff>
Please approve this change or create a separate issue for it.
---
*Posted by Claude Code*
## Security Review Required
This PR modifies authentication/authorisation code that requires human review before merge.
**Files changed:**
- `<file>` — <what changed>
**Security implications:**
- <impact description>
---
*Posted by Claude Code*
## Production Access Required
This task requires interaction with a production system that Claude Code cannot perform.
**What's needed:** <description>
**Suggested approach:** <staging alternative or manual steps>
---
*Posted by Claude Code*
<!-- maverick-plugin-version: 3.3.7 -->development
--- name: do-test description: Write or update tests for a code change. Operates in two modes: `unit` (module-scoped, fast, deterministic) and `integration` (crosses module / service / database boundaries). Intended to be invoked once per testable change from inside a do-issue-* or do-epic phase. Mode is required. argument-hint: mode: unit or integration user-invocable: true disable-model-invocation: false --- **Depends on:** mav-bp-unit-testing, mav-bp-integration-testing, mav-local-verificati
development
Implement a focused code change. Use this skill as the wrapper for any implementation work so the Maverick workflow report captures what was done and so the agent applies the project's coding standards before editing. Intended to be invoked once per task from inside a do-issue-* or do-epic phase, not standalone.
testing
How to stack a PR on top of an unmerged sibling branch, and how to retarget it to the repo's default branch once the sibling merges. Prevents orphan-merge incidents when a dependent story is ready before its parent.
development
Claim, lease, heartbeat, and release protocols for when multiple Claude Code instances may act on the same issue or epic concurrently. GitHub labels and marker comments are the coordination surface; local state is a cache.