Menu
>-
The review-first prompt is selected by default. You can switch to a direct command or download a local copy.
Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/CleanExpo/NodeJS-Starter-V1 --skill execution-guardianThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Based on SOC occupation classification
Showing SKILL.md
| id | execution-guardian |
| name | execution-guardian |
| type | skill |
| version | 1.0.0 |
| created | 20/03/2026 |
| modified | 20/03/2026 |
| status | active |
| metadata | {"author":"NodeJS-Starter-V1","version":"1.0.0","locale":"en-AU"} |
| description | >- |
| context | fork |
Dynamic validation gates and risk assessment for operations that could harm system integrity. Evaluates blast radius, reversibility, and confidence before allowing execution to proceed.
Provides a pre-execution safety layer that auto-detects operation types, generates prerequisite validation gates, scores risk and confidence, and produces structured error output when operations are blocked. Complements the Council of Logic (code quality) with operation safety assessment.
git reset, DROP TABLE, rm -rfScan the proposed operation and classify it into one or more operation types:
| Operation Type | Detection Signals | Default Risk |
|---|---|---|
DATABASE_MIGRATION | Alembic revision, ALTER TABLE, DROP, schema changes |
| HIGH |
AUTH_CHANGE | JWT config, RBAC rules, password hashing, session management | HIGH |
API_CONTRACT_CHANGE | Endpoint signature change, response model change, status code change | MEDIUM |
DEPLOYMENT | Docker push, vercel deploy, environment variable changes | HIGH |
DESTRUCTIVE_FILE_OP | rm -rf, git reset --hard, git clean -f, file overwrites | HIGH |
SECURITY_CHANGE | CORS policy, CSP headers, rate limit config, secret rotation | HIGH |
MULTI_LAYER_CHANGE | Changes in 2+ of: apps/web/, apps/backend/, scripts/, docker-compose.yml | MEDIUM |
DEPENDENCY_CHANGE | pnpm add, uv add, major version bumps, removing packages | LOW |
CONFIG_CHANGE | next.config, pyproject.toml, tsconfig.json, .env files | LOW |
For each detected operation type, generate prerequisite gates. Gates are checks that must pass before execution proceeds.
GATE: Backup exists or migration is reversible
CHECK: Verify downgrade() function exists in Alembic revision
BLOCKING: YES
GATE: No data loss in migration
CHECK: Scan for DROP COLUMN, DROP TABLE, ALTER TYPE without data preservation
BLOCKING: YES
GATE: Migration tested locally
CHECK: uv run alembic upgrade head (on local database)
BLOCKING: YES
GATE: No secret exposure in code
CHECK: Grep for hardcoded secrets, JWT keys, API keys in diff
BLOCKING: YES
GATE: Existing sessions handled
CHECK: Verify session invalidation strategy for JWT secret rotation
BLOCKING: YES
GATE: Auth tests pass
CHECK: uv run pytest tests/test_auth.py
BLOCKING: YES
GATE: Breaking change documented
CHECK: Verify changelog entry or API version bump
BLOCKING: NO (warning only)
GATE: Frontend contract updated
CHECK: Verify corresponding Zod schema change in apps/web/
BLOCKING: YES
GATE: API tests pass
CHECK: uv run pytest tests/test_api_*.py
BLOCKING: YES
GATE: Files are not uncommitted work
CHECK: git status — verify target files are committed or backed up
BLOCKING: YES
GATE: No shared resources affected
CHECK: Verify files are not imported/referenced by other modules
BLOCKING: YES
GATE: All tests pass
CHECK: pnpm turbo run test
BLOCKING: YES
GATE: Type checks pass
CHECK: pnpm turbo run type-check
BLOCKING: YES
GATE: No secrets in build output
CHECK: Scan build artifacts for .env patterns
BLOCKING: YES
GATE: Change follows OWASP guidelines
CHECK: Reference input-sanitisation or csrf-protection skill
BLOCKING: NO (advisory)
GATE: Security tests pass
CHECK: uv run pytest tests/ -k "security or auth"
BLOCKING: YES
GATE: API contract consistency
CHECK: Backend response models match frontend Zod schemas
BLOCKING: YES
GATE: Cross-layer tests pass
CHECK: pnpm turbo run test (full suite)
BLOCKING: YES
GATE: No known vulnerabilities
CHECK: pnpm audit / uv pip audit
BLOCKING: NO (warning for non-critical)
GATE: Peer dependency compatibility
CHECK: pnpm install --dry-run succeeds
BLOCKING: YES
GATE: Config syntax valid
CHECK: Validate JSON/TOML/YAML syntax
BLOCKING: YES
GATE: Environment variables documented
CHECK: New variables added to .env.example
BLOCKING: NO (warning)
Each operation is scored across three dimensions:
| Dimension | LOW (1) | MEDIUM (2) | HIGH (3) |
|---|---|---|---|
| Blast Radius | Single file/function | Single service/layer | Multiple services or shared infrastructure |
| Reversibility | Easily undone (git revert, config rollback) | Requires manual steps (data restore, migration rollback) | Irreversible or extremely costly to reverse |
| Confidence | Well-understood pattern, high test coverage | Partially tested, some unknowns | Novel pattern, low coverage, complex domain |
composite_score = max(blast_radius, reversibility, confidence)
| Composite Score | Risk Level | Required Response |
|---|---|---|
| 1 | LOW | Proceed. Log the operation. |
| 2 | MEDIUM | Require user approval before execution. State the risk clearly. |
| 3 | HIGH | Mandatory review. Require rollback plan. Block until approval received. |
LOW Risk:
[GUARDIAN: LOW RISK] Proceeding with {operation}.
Gates passed: {list}. No rollback plan required.
MEDIUM Risk:
[GUARDIAN: MEDIUM RISK] {operation} requires approval.
Blast radius: {assessment}
Reversibility: {assessment}
Confidence: {assessment}
Approval required before proceeding.
HIGH Risk:
[GUARDIAN: HIGH RISK] {operation} blocked pending review.
Blast radius: {assessment}
Reversibility: {assessment}
Confidence: {assessment}
Rollback Plan:
1. {step 1}
2. {step 2}
3. {step 3}
Approval required. Respond with "proceed" to continue.
Confidence is scored 0-100% based on four factors:
| Factor | Weight | High Confidence | Low Confidence |
|---|---|---|---|
| Pattern Novelty | 30% | Well-known pattern used elsewhere in codebase | First-time pattern, no precedent |
| Test Coverage | 30% | Relevant tests exist and pass | No tests cover this path |
| Domain Complexity | 20% | Simple CRUD, config change | Auth, payment, distributed state |
| Change Scope | 20% | Single file, < 50 lines | 5+ files, 200+ lines |
| Range | Label | Action |
|---|---|---|
| 80-100% | High | Proceed with standard gates |
| 50-79% | Moderate | Require explicit approval |
| 0-49% | Low | Recommend spike/prototype first, or request additional review |
When the Guardian blocks an operation, output uses this format. This is distinct from error-taxonomy (which handles runtime API errors). Guardian errors are governance-level blocking decisions.
ERROR: {What failed or was blocked}
CAUSE: {Why the gate failed or risk is too high}
RISK: {LOW | MEDIUM | HIGH} — {one-line risk summary}
FIX: {Specific action to resolve the block}
BLOCKING: {YES | NO}
See references/error-format.md for complete examples per operation type.
| BLOCKING | Meaning | When Used |
|---|---|---|
| YES | Operation cannot proceed until resolved | Data loss risk, security vulnerability, test failure |
| NO | Warning only — operation may proceed | Documentation missing, advisory best practice |
When BLOCKING: NO and risk is LOW:
FIX automaticallyBLOCKING: YESSelf-healing is never applied to:
BLOCKING: YES gates| Council Member | Feeds Into | How |
|---|---|---|
| Turing (complexity) | Confidence scoring | High complexity = lower confidence |
| Von Neumann (architecture) | Blast radius assessment | Multi-service = higher blast radius |
| Shannon (compression) | Guardian output format | Structured, compressed error format |
Boundary: Council validates code quality; Execution Guardian validates operation safety.
| Pattern | Problem | Correct Approach |
|---|---|---|
| Gating every file edit | Over-governance, kills momentum | Only gate destructive/multi-layer/security ops |
| Skipping gates because "it's just a small change" | Small changes to auth/security can be catastrophic | Gate based on operation type, not change size |
| Blocking on advisory warnings in BUILD mode | Momentum loss | Advisory = BLOCKING: NO, proceed with warning |
| Applying self-healing to security gates | Could mask real vulnerabilities | Self-healing only for LOW risk, non-security gates |
| Generating rollback plans for LOW risk ops | Token waste, over-engineering | Rollback plans for HIGH risk only (MEDIUM in SCALE mode) |
ERROR / CAUSE / RISK / FIX / BLOCKING)BLOCKING: NO + LOW risk[AGENT_ACTIVATED]: Execution Guardian
[MODE]: {EXPLORATION | BUILD | SCALE | STRATEGY}
[OPERATION]: {detected operation type(s)}
[RISK]: {LOW | MEDIUM | HIGH}
[STATUS]: {gates_passed | approval_required | blocked}
{gate results, risk assessment, or structured error}
[NEXT_ACTION]: {proceed | await approval | apply fix | escalate}
Route complex requests to the right specialist agent or chain of agents. This skill acts as the central brain of an agent swarm — it analyses what the user needs, determines which specialist domain(s) are required, and coordinates parallel or sequential agent execution. Use this skill when a request spans multiple domains (e.g., "research competitors and create a pitch deck"), when you need to decide which specialist should handle an ambiguous request, or when a task requires a multi-step pipeline across different skills. Triggers on: multi-step requests, cross-domain tasks, "coordinate", "plan this out", "I need help with multiple things", or any complex request that touches more than one specialist area. Also triggers when the user seems unsure which tool or approach to use.
>-
Hybrid DAG execution primitive combining deterministic and agentic nodes with hard iteration caps