Rules, Standards, and Guardrails

Practical ways to write reusable AI Manager rules, show them in project files, and turn them into concrete execution constraints.

Introduction: put durable AI rules where the manager can reuse them

Rules only help if the AI Manager can load them as part of normal project work. Put lasting guidance in the files Wappler already uses for project context. For example, store product background in PROJECT_INFO.md, UI tone in DESIGN_STYLE.md, implementation conventions in STYLE_GUIDE.md, and subsystem-specific enforcement in instruction files. That makes the next task start from real project memory instead of a fresh explanation every time.

Project info

Use PROJECT_INFO.md for
project-specific context

Design style

Use DESIGN_STYLE.md for
visual direction and UI rules

Style guide

Use STYLE_GUIDE.md for
naming and implementation standards

Repo rules

Use instruction files for
enforced coding behavior

Place lasting guidance in the files the AI Manager already knows how to load.

Keep the rule set visible, reusable, and tied to the actual product direction.

Use project files to reduce repeated prompt setup across many tasks.

Text

Example rule file snippets
PROJECT_INFO.md
- Product: customer feedback portal for a support team
- Framework: Bootstrap 5
- Important flow: public feedback form + internal review dashboard
DESIGN_STYLE.md

Calm admin UI, clear hierarchy, compact filters, readable tables
Prefer reusable sections over decorative one-off blocks

STYLE_GUIDE.md

Reuse existing Wappler patterns
Keep generated structure editable in Design View and Properties
Prefer narrow iterative changes over broad rewrites

Write rules as direct decisions, not vague ideals

Reusable rules work best when they tell the AI Manager exactly what to prefer, what to avoid, and how to resolve a tradeoff. Short rules beat broad slogans. If the real instruction is “reuse existing Bootstrap 5 sections and do not invent helper abstractions for this area,” say that directly instead of writing something like “keep code clean.”

Prefer

State what the AI should
reach for first

Avoid

Name what should not be
introduced casually

Decide

Explain how to choose when
two options conflict

Write the real decision you want the AI Manager to follow.

Avoid vague rules like "write clean code" when you mean something much more specific.

Keep one rule per decision when possible so conflicts are obvious.

Text

Better rule examples
- Prefer existing Wappler UI patterns before creating new helper abstractions.
- Keep Bootstrap 5 class structure readable in Design View.
- Do not replace whole pages when a focused section update is enough.
- For AI-assisted backend work, ask for the next Server Connect slice before generating the whole workflow.

Keep standards short, scoped, and non-conflicting

The AI Manager works better when the rule set feels like one coherent operating manual. If the standards fight each other, the agent has to guess. Scope rules to the subsystem where they matter and remove outdated guidance instead of stacking new instructions forever.

Stable

Keep durable rules in
consistent files

Scoped

State where a rule applies
and where it does not

Concrete

Use examples when a rule
could be interpreted loosely

Aligned

Match the real product
patterns instead of wishful ones

Remove conflicting rules instead of making the AI guess which one wins.

Scope rules to the subsystem where they matter.

Keep standards short enough that they remain reusable across many tasks.

Tell the AI Manager to work from the rules on purpose

Project rules become useful only when you activate them in the prompt. When a task depends on standards, tell the AI Manager to review the relevant files, use them in the plan, and flag any tension before acting. That turns the rule files from passive documentation into active execution constraints.

Load

Ask the manager to review
the relevant project files

Plan

Make the rules visible in the
execution plan

Check

Call out conflicts before
the agent starts editing

Ask the AI Manager to plan against the relevant rules before editing.

When a result feels wrong, point to the violated standard instead of saying only that it is off.

Update the rules when the product direction truly changes instead of improvising a new standard each task.

Text

Prompt that activates the rules
"Review PROJECT_INFO.md, DESIGN_STYLE.md, and STYLE_GUIDE.md before planning this feedback dashboard update. Keep the Bootstrap 5 structure editable, reuse existing section patterns, and tell me if any requested change conflicts with those standards before you act."

Continue from rules into plan-driven execution

Move into planning and execution next, or return to the prompt-control hub for the full guidance branch.

Choose the next control tour

Continue with the related tours that turn rules into planning discipline and execution structure.