Critical Rules Enforced by the Engineering Agents in agency-agents

The engineering agents in the msitarzewski/agency-agents repository enforce non-negotiable constraints—such as "never disable security controls" and "all code examples must run"—through dedicated "Critical Rules You Must Follow" sections in their role definitions.

These rules function as policy-as-code, guiding every commit, deployment, and documentation update across the agency-agents ecosystem. Each agent—from the Technical Writer to the AI Engineer—declares specific mandates in its markdown specification file, creating a self-documenting governance layer that integrates directly into CI/CD pipelines.

Documentation and Content Integrity

Technical Writer Rules

The Technical Writer agent enforces four immutable standards in engineering/engineering-technical-writer.md#L37-L45:

• All code examples must run – No broken snippets or pseudo-code allowed
• No hidden context – Every document must be self-contained
• Consistent voice – Second-person, present tense throughout
• Immutable versioning – Docs are versioned and never deleted

These rules ensure that documentation remains a reliable, executable artifact rather than static text.

# .github/workflows/docs-lint.yml

name: Docs Lint
on:
  push:
    paths:
      - '**/*.md'
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Vale lint
        run: |
          npm install -g vale
          vale --config=.vale.ini .
      - name: markdownlint
        uses: github/super-linter@v5
        env:
          VALIDATE_MARKDOWN: true

Security and Compliance

Security Engineer Rules

The Security Engineer agent maintains the strictest constraint set in engineering/engineering-security-engineer.md#L38-L46, enforcing a safety-first posture:

• Never suggest disabling security controls – No exceptions for convenience
• Assume all input is malicious – Validate and sanitize at every trust boundary
• Prefer vetted libraries over custom crypto – No homemade encryption algorithms
• Treat secrets as first-class citizens – Never hard-code credentials; use secret management
• Default-deny whitelist approach – Explicit allowlisting for access control

# .github/workflows/security-scan.yml

name: Security Scan
on:
  pull_request:
    branches: [ main ]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Trivy (container & FS scan)
        uses: aquasecurity/trivy-action@0.9.1
        with:
          scan-type: 'fs'
          severity: 'CRITICAL,HIGH'
      - name: Gitleaks (secret detection)
        uses: gitleaks/gitleaks-action@v2

AI Engineer Safety Protocols

The AI Engineer agent in engineering/engineering-ai-engineer.md#L37-L45 enforces model governance through three critical rules:

• All AI models must be sandboxed during inference – Isolated execution environments
• Enforce prompt-guardrails – Automated filtering of disallowed content
• Continuous evaluation – Ongoing monitoring for bias and hallucination metrics

Development Velocity and Quality

Senior Developer Standards

The Senior Developer agent in engineering/engineering-senior-developer.md#L31-L41 enforces stack consistency and UX standards:

• Use only official FluxUI component docs – No third-party UI libraries
• Alpine.js is bundled with Livewire – Never install Alpine.js separately to avoid version conflicts
• Mandatory light/dark/system theme toggle – Every site must include theme switching

// components/ThemeToggle.tsx
import { useTheme } from 'next-themes';
export default function ThemeToggle() {
  const { theme, setTheme } = useTheme();
  return (
    <button onClick={() => setTheme(theme === 'light' ? 'dark' : 'light')}>
      Switch to {theme === 'light' ? 'dark' : 'light'}
    </button>
  );
}

Rapid Prototyper Constraints

The Rapid Prototyper agent in engineering/engineering-rapid-prototyper.md#L40-L52 prioritizes speed-to-feedback:

• Prioritize speed – Select tools that minimize setup time
• Re-use pre-built components/templates – No building from scratch
• Core functionality first, polish later – Ship working features before optimization
• Build only to test hypotheses – Include feedback collection from day one

Frontend Developer Requirements

The Frontend Developer agent in engineering/engineering-frontend-developer.md#L48-L56 enforces quality gates:

• All UI components must be unit-tested – No untested components in production
• Enforce accessibility (WCAG 2.1 AA) – Every interactive element must meet accessibility standards
• Performance-first – Audit bundle size and aim for sub-1-second first paint

Backend Architect Governance

The Backend Architect agent in engineering/engineering-backend-architect.md#L46-L54 maintains API integrity:

• Zero critical vulnerabilities after security audits – No exceptions for shipping insecure code
• All new services must include automated contract tests – API contracts tested automatically
• Use API versioning and deprecation policies – Explicit versioning strategy required

Data and Infrastructure Automation

Data Engineer Quality Gates

The Data Engineer agent in engineering/engineering-data-engineer.md#L43-L51 enforces data integrity:

• Explicitly handle nulls – Impute, flag, or reject based on field-level rules
• Enforce data-quality suites – Use tools like Great Expectations with ≥99.9% pass rate on critical Gold-layer checks

# tests/data_quality.py

import great_expectations as ge
df = ge.read_pandas(my_dataframe)

expectation_suite = df.expect_table_row_count_to_be_between(min_value=1000, max_value=100000)

result = df.validate(expectation_suite=expectation_suite)
assert result.success, "Critical data quality checks failed"

DevOps Automator Mandates

The DevOps Automator agent in engineering/engineering-devops-automator.md#L40-L48 enforces zero-touch operations:

• Eliminate manual steps – Everything must be automated
• Build self-healing systems – Automated recovery without human intervention
• Security scanning & secrets rotation – Baked into CI/CD pipelines
• Monitoring & alerting – Must preempt issues rather than react to them

# .github/workflows/deploy.yml

name: Deploy
on:
  push:
    branches: [ main ]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build Docker image
        run: |
          docker build -t myapp:${{ github.sha }} .
          docker push myregistry/myapp:${{ github.sha }}
      - name: Deploy green
        run: |
          kubectl set image deployment/myapp myapp=myregistry/myapp:${{ github.sha }}
          kubectl rollout status deployment/myapp
          kubectl patch svc myapp -p '{"spec":{"selector":{"version":"green"}}}'

Summary

The critical rules enforced by the engineering agents in the agency-agents repository establish a comprehensive governance framework across four pillars:

• Safety and Security – Zero tolerance for disabled controls, mandatory secret management, and sandboxed AI inference
• Quality Assurance – Runnable documentation, unit-tested components, WCAG 2.1 AA compliance, and 99.9% data quality pass rates
• Operational Excellence – Fully automated deployments, self-healing infrastructure, and explicit API versioning
• Velocity with Constraints – Pre-built component reuse, hypothesis-driven prototyping, and mandatory observability from day one

These constraints are codified in role-specific markdown files under the engineering/ directory and validated through CI/CD pipelines that enforce the rules automatically.

Frequently Asked Questions

What happens if an engineering agent violates its critical rules?

The repository treats these rules as non-negotiable constraints rather than suggestions. If an agent's output violates a critical rule—such as the Security Engineer's mandate to "never suggest disabling security controls"—the CI/CD pipeline fails and blocks deployment. The rules act as automated policy gates that prevent non-compliant code from reaching production.

How are these critical rules enforced in CI/CD pipelines?

Each engineering agent's rules map to specific pipeline stages. For example, the Technical Writer rules trigger Vale and markdownlint in .github/workflows/docs-lint.yml, while the Security Engineer rules activate Trivy and Gitleaks scans in security-scan.yml. The DevOps Automator mandates are implemented through automated deployment workflows that eliminate manual approval steps and enforce zero-downtime releases.

Can I modify the critical rules for my own agency deployment?

Yes, the rules are defined in standard markdown files within the engineering/ directory (e.g., engineering-security-engineer.md, engineering-data-engineer.md). You can fork the repository and adjust the "Critical Rules You Must Follow" sections to match your organization's compliance requirements. However, modifying the rules requires updating the corresponding CI/CD validation logic to ensure the new constraints are automatically enforced.

Which engineering agent handles AI safety and model governance?

The AI Engineer agent (defined in engineering/engineering-ai-engineer.md#L37-L45) specifically governs AI safety through three critical rules: sandboxing all models during inference, enforcing prompt guardrails to filter disallowed content, and conducting continuous evaluation against bias and hallucination metrics. This agent ensures that autonomous optimization and machine learning components operate within strict safety boundaries.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}