AI Commandments

These are not “prompt tricks”. They are durable rules for getting useful work from AI while keeping humans, evidence and system boundaries in control.

State the real objective

Tell the AI the outcome and the reason. Otherwise it may optimize the visible task while harming the actual goal.

Make authority explicit

When instructions, design, configuration and current implementation disagree, define which source wins. Do not let accidental existing behavior become the specification.

Supply context the AI cannot know

Private facts, local terminology, prior decisions and project rules belong in the context. Never assume a model can infer them reliably.

Separate facts, assumptions and proposals

Require the AI to say what it observed, what it inferred, what it had to assume and what it recommends.

Do not silently guess

Material missing information should become a visible uncertainty or hard stop, not a plausible invented value.

Put control in configuration, not hidden logic

If a value is meant to vary, make it explicit and inspectable. Hidden defaults and magic constants create invisible policy.

Reuse canonical mechanisms

Do not solve the same concern twice in different ways. A second source of truth is future disagreement waiting to happen.

Grant the least capability required

AI tools should expose named actions and allowlisted resources. Read access does not imply write access; one directory does not imply the whole filesystem.

Make failures visible

Do not hide real errors behind fallbacks that make the system appear healthy. A denied path, missing key or broken dependency should be clear.

Fix causes with mechanisms, not exceptions

Diagnose why the behavior is wrong. Prefer a correct underlying rule, cost, weight, permission or model over an accumulating set of special cases.

Preserve the WHY

Record the reason for important rules and changes. Future humans and future AI need intent, not only the final syntax.

Verify the product, not the claim

AI saying “done” is not evidence. Inspect the file, run the software, render the page, execute the test, check the source or otherwise verify the actual result.

Where these came from

These principles are generalized from real project discipline used in AdventureWorld. The project rules insist on root-cause fixes rather than bandaids, configuration-owned control, version/history, minimal patches, WHY comments, reuse, safe I/O, deterministic decision paths and product-level verification. The design authority order also explicitly places current code below locked decisions and design documentation.

The point is not obedience for its own sake. Persistent rules make AI useful on long-lived work because each new session inherits the project's engineering values instead of improvising them.

Use these ideas in real prompts →