Define the danger rule set

Enumerate what must never run silently - concretely.

First time here? Paste the Context Pack first so the AI understands your project - open it from the header above.

Prompt Capsule

Write the danger rules as data. COMMAND PATTERNS (normalized before matching: resolve quoting, collapse whitespace): recursive deletion (rm -rf and equivalents on any path), git destructive ops (force-push, hard reset on shared branches, clean -fdx), bulk data ops (DROP/TRUNCATE, mass UPDATE without WHERE), package/system mutations (global installs, chmod -R 777, curl piped to shell). PROTECTED PATHS for writes and deletes: .env* and secret/key files, .git internals, paths outside the workspace root, CI and infra configs (approval, not block). Assign each rule a verdict (approval vs block) and a reason string. Store as a versioned config file. Review the list against my actual toolset and add tool-specific rules where needed.

Paste into EmergentFull Build: complete implementation prompt with explicit requirements

Quick is short. Full Build is recommended for most steps. Strict forces real logic when the AI keeps faking output.

Actual change check

Expected after this step

A versioned danger-rule config with verdicts and reasons.

Should NOT happen

An existing feature broke
A button only logs to console
Data disappears after refresh
Errors fail silently with no visible state

This is what should exist before you continue. If reality does not match, do not move on.

Your notes for this step

Track what changed, failed, or needs follow-up. Notes export with the flow.

Pass the Verify Gate to complete this step

Verify before continuing

Do not move on until every check is true. The complete button stays locked until then.

Patterns match normalized commandsProtected paths cover secrets and workspace escapeEvery rule has a verdict and reason

Do not continue if…

! Safety rules living in the system prompt where clever phrasing routes around them
! Pattern rules so naive that rm -rf ./ passes because the pattern expected rm -rf /
! Hooks that crash the loop instead of returning verdicts
! No project extensibility, so real deployments disable the layer entirely

If the AI messes this up

Use this when:

- it only made visual forms or placeholder UI
- buttons do nothing or only log to console
- data is not persisted - state disappears on refresh
- something that worked before is now broken

Use this when the AI fakes progress or breaks the feature. It forces a real fix.

The list is generic. Walk each of my tools asking 'what is the worst call this accepts?' and write a rule for every answer - the rule set must reflect this harness, not a textbook.