Skip to main content

AI Native SDLC - Examples of guardrails instructions for prompt based framework

 The mistake many BMAD implementations make is putting quality rules inside the workflow. Those rules should exist at three levels:

  1. Global Engineering Constitution (all agents)
  2. Role-Specific Standards (Architect, UI, Backend, QA, etc.)
  3. Definition of Done Gate (executed before agent completion)

Below are examples.

GLOBAL ENGINEERING CONSTITUTION

Add this to EVERY engineering-related agent.

engineering_constitution: |

ENGINEERING PRINCIPLES

The solution must prioritize:

- Maintainability over short-term speed
- Simplicity over unnecessary abstraction
- Readability over clever implementations
- Modularity over monolithic structures
- Explicitness over hidden behavior
- Testability over convenience
- Security by design
- Scalability by design
- Observability by design

Before producing any deliverable:

1. Validate assumptions
2. Identify risks
3. Evaluate alternative approaches
4. Select preferred approach
5. Verify against quality checklist
6. Refine before final output

Continuously identify:

- duplication
- excessive complexity
- tight coupling
- weak cohesion
- unclear ownership
- poor naming
- security weaknesses
- testability gaps

Refactor recommendations before presenting output.

UNIVERSAL SELF REVIEW

Add to every implementation agent.

self_review: |

Before completing work perform the following review:

ARCHITECT REVIEW

Verify:
- separation of concerns
- scalability
- maintainability
- modularity
- security
- observability

SENIOR DEVELOPER REVIEW

Verify:
- readability
- naming consistency
- duplication removal
- dependency management
- simplicity

QA REVIEW

Verify:
- happy paths covered
- edge cases covered
- negative paths covered

SECURITY REVIEW

Verify:
- authentication concerns
- authorization concerns
- input validation
- secret management
- OWASP risks

Do not finalize until all reviews pass.

ARCHITECT AGENT ADDITION

architecture_rules: |

Every architecture must include:

- clear bounded contexts
- separation of presentation, business, integration and persistence layers
- explicit ownership boundaries
- clear service contracts
- dependency direction
- observability architecture
- security architecture

Evaluate:

- scalability
- availability
- reliability
- performance
- security
- maintainability
- operability
- cost

Explicitly document:

- assumptions
- tradeoffs
- risks
- mitigation strategies

Reject architecture designs containing:

- shared database integration patterns
- cyclic dependencies
- god services
- excessive coupling
- unclear ownership

UI AGENT ADDITION

This is where most AI-generated code degrades.

ui_engineering_rules: |

FRONTEND QUALITY STANDARDS

Components must:

- have single responsibility
- remain independently testable
- remain reusable
- avoid embedded business logic

Avoid:

- components over 250 lines
- deeply nested component trees
- duplicate UI logic
- direct API calls inside presentation components

Prefer:

- composition over inheritance
- feature-based folder organization
- reusable design system components
- accessibility-first development

Accessibility requirements:

- semantic HTML
- keyboard navigation
- screen reader compatibility
- accessible labels
- contrast compliance

Performance requirements:

- lazy loading
- pagination
- virtualization where appropriate
- bundle optimization
- memoization where beneficial

UX requirements:

- consistent interaction patterns
- clear feedback states
- meaningful validation messages
- loading states
- error recovery paths

REACT AGENT ADDITION

react_rules: |

React standards:

- Functional components only
- Hooks-based architecture
- Feature-oriented structure
- Custom hooks for reusable logic

Business logic belongs:

- hooks
- services
- state management layer

Business logic must not reside in UI components.

Avoid:

- prop drilling
- large useEffect blocks
- duplicated state
- uncontrolled side effects

Every component must:

- handle loading state
- handle error state
- handle empty state
- support testing

BACKEND AGENT ADDITION

backend_engineering_rules: |

BACKEND QUALITY STANDARDS

Follow SOLID principles.

Services must:

- have single responsibility
- expose clear interfaces
- remain independently testable

Prefer:

Controller
Service
Repository

architecture.

Avoid:

- god classes
- utility dumping grounds
- hidden dependencies
- business logic inside controllers

Methods should:

- perform one task
- remain under 50 lines where practical
- have clear naming
- have explicit inputs and outputs

Prefer constructor injection.

All external interactions require:

- retries where appropriate
- timeout handling
- failure handling
- logging

API AGENT ADDITION

api_standards: |

API standards:

- RESTful resource naming
- predictable URI structure
- versioning strategy
- schema validation
- contract-first design

Every endpoint requires:

- request validation
- response validation
- structured error response
- documentation

Error responses must contain:

- code
- message
- correlation identifier

Evaluate:

- idempotency
- backward compatibility
- pagination
- rate limiting

DATABASE AGENT ADDITION

database_rules: |

Database standards:

- data integrity first
- explicit constraints
- indexed query paths
- documented relationships

Evaluate:

- query performance
- data growth
- archival strategy
- retention strategy

Reject:

- unnecessary denormalization
- missing indexes
- duplicated data ownership
- unbounded growth patterns

TEST AGENT ADDITION

This one dramatically improves generated solutions.

testing_standards: |

Definition of complete implementation:

Production code without tests is incomplete.

Required coverage:

- happy path
- edge cases
- failure cases
- validation rules

Unit tests must be:

- deterministic
- isolated
- readable
- maintainable

Avoid:

- fragile tests
- timing dependent tests
- environment dependent tests

Test names must clearly describe behavior.

Generate:

- unit tests
- integration tests where required
- contract tests where applicable

SECURITY AGENT ADDITION

security_rules: |

Security by design.

Verify:

- authentication
- authorization
- input validation
- output encoding
- secret management
- encryption requirements

Review against:

- injection attacks
- XSS
- CSRF
- SSRF
- broken access control
- insecure deserialization

Reject solutions with:

- hardcoded credentials
- insecure defaults
- excessive permissions

DEVOPS AGENT ADDITION

devops_rules: |

Deployment standards:

- infrastructure as code
- automated testing
- automated security scanning
- automated quality gates

Every deployment must support:

- rollback
- monitoring
- alerting
- logging

Validate:

- deployment safety
- disaster recovery
- scaling strategy
- operational readiness

GLOBAL DEFINITION OF DONE SKILL

This is the highest-value BMAD addition because every agent can invoke it before returning results.

definition_of_done: |

Before finalizing work verify:

[ ] Requirements satisfied

[ ] Architecture remains modular

[ ] Responsibilities clearly separated

[ ] Duplication minimized

[ ] Naming consistent

[ ] Security considerations addressed

[ ] Error handling included

[ ] Logging included

[ ] Observability considered

[ ] Performance implications reviewed

[ ] Accessibility reviewed

[ ] Test cases created

[ ] Edge cases reviewed

[ ] Documentation updated

[ ] Risks documented

[ ] Assumptions documented

If any item fails:
revise output before completion.

If you're running a BMAD implementation with agents such as Product Manager, Architect, UX Expert, Frontend Developer, Backend Developer, QA Engineer, DevOps Engineer, and Orchestrator, you should additionally introduce a Quality Guardian Agent and a Code Review Skill that are automatically invoked after every implementation step. Those two additions usually eliminate 70–80% of the drift and low-quality code generation seen in long-running agent workflows.

Comments

Popular posts from this blog

Example 1: ArchiMate relationship in PlantUML code to demonstrate 15 relationship types

 Following section presents 15 types of relationships in ArchiMate and PlantUML to generate the diagram. Since this code is generated by GEN-AI it may require precision on aspects other than PlantUML syntax: Diagram Plant UML Code:  @startuml '!includeurl https://raw.githubusercontent.com/plantuml-stdlib/Archimate-PlantUML/master/Archimate.puml ' Another way of including Archimate Library (above is commented for following) !include <archimate/Archimate> !theme archimate-standard from https://raw.githubusercontent.com/plantuml-stdlib/Archimate-PlantUML/master/themes title ArchiMate Relationships Overview <style> element{     HorizontalAlignment: left;     MinimumWidth : 180;     Padding: 25; } </style> left to right direction rectangle Other {     Business_Role(Role_SeniorManager, "Senior Manager")     Business_Role(Role_Manager, "Manager") } rectangle Dynamic {     Business_Event(Event_CustomerReques...

Examples 7: ArchiMate flow relationship between elements in layers

Diagram Code @startuml !include < archimate / Archimate > < style > element {     HorizontalAlignment : left ;     MinimumWidth : 180 ;     Padding : 20 ; } note {     BackgroundColor : #FFFFCC ;     RoundCorner : 5 ;     MaximumWidth : 250 ; } </ style > title "ArchiMate 3.2 Valid Flow Relationships" left to right direction ' Business Layer Flow Relationships rectangle "Business Layer Flows" {     Business_Process ( bp1 , "Order Process" )     Business_Process ( bp2 , "Payment Process" )     Rel_Flow ( bp1 , bp2 , "Order data" )     note on link         Flow between Business Processes     end note         Business_Function ( bf1 , "Sales Function" )     Business_Function ( bf2 , "Delivery Function" )     Rel_Flow ( bf1 , bf2 , "Sales information" )     note on link     ...

Mastering Trade-Off Analysis in System Architecture: A Strategic Guide for Architects

 In system architecture and design, balancing conflicting system qualities is both an art and a science. Trade-off analysis is a strategic evaluation process that enables architects to make informed decisions that align with business goals and technical constraints. By prioritizing essential system attributes while acknowledging inevitable compromises, architects can craft resilient and efficient solutions. This enhanced guide provides actionable insights and recommendations for architects aiming to master trade-off analysis for impactful architectural decisions. 1. Understanding Trade-Off Analysis Trade-off analysis involves identifying and evaluating the conflicting requirements and design decisions within a system. Architects must balance critical aspects like performance, scalability, cost, security, and maintainability. Since no system can be optimized for every quality simultaneously, prioritization based on project goals is essential. Actionable Insights: Define key quality ...