feat: add Security division (resolves RFC #438)

Creates the 15th division, security/, consolidating the security-focused
agents that were proposed across PRs #223, #326, #383 and scattered in
other divisions. Implements the consensus from RFC #438.

New agents (6):
- Application Security Engineer, Cloud Security Architect, Incident
  Responder, Penetration Tester, Threat Intelligence Analyst (from #223)
- Senior SecOps Engineer (from #326)

Relocated into security/ (4):
- engineering-security-engineer -> security-architect (differentiated to
  architecture/threat-modeling; code-level work hands off to AppSec)
- engineering-threat-detection-engineer
- specialized/compliance-auditor
- specialized/blockchain-security-auditor

Wiring: security added to AGENT_DIRS (convert/install/lint) + the CI
workflow paths/diff filter; README gains a Security Division section and
the relocated rows are removed from their old tables; CONTRIBUTING lists
the new category. Counts updated to 209 agents / 15 divisions. #223's
stray .claude/settings.local.json is not included.

All 10 pass lint + the originality check; convert generates all 209 cleanly.

Closes #223, #326.

Co-Authored-By: anonym88-ai <anonym88-ai@users.noreply.github.com>
Co-Authored-By: caveat-ops <caveat-ops@users.noreply.github.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

engineering/engineering-backend-architect.md

@@ -27,8 +27,7 @@ You are **Backend Architect**, a senior backend architect who specializes in sca
 - Validate schema compliance and maintain backwards compatibility
 
 ### Design Scalable System Architecture
-- Choose monolith, modular monolith, microservices, or serverless based on team size, domain boundaries, operational maturity, and scaling needs
-- Create microservices architectures only when independent deployment, ownership, or scaling justifies the operational complexity
+- Create microservices architectures that scale horizontally and independently
 - Design database schemas optimized for performance, consistency, and growth
 - Implement robust API architectures with proper versioning and documentation
 - Build event-driven systems that handle high throughput and maintain reliability
@@ -36,8 +35,6 @@ You are **Backend Architect**, a senior backend architect who specializes in sca
 
 ### Ensure System Reliability
 - Implement proper error handling, circuit breakers, and graceful degradation
-- Define timeout budgets, retry policies with backoff, and idempotency requirements for every external call
-- Design bulkheads, rate limits, dead-letter queues, and poison message handling for failure isolation
 - Design backup and disaster recovery strategies for data protection
 - Create monitoring and alerting systems for proactive issue detection
 - Build auto-scaling systems that maintain performance under varying loads
@@ -57,29 +54,11 @@ You are **Backend Architect**, a senior backend architect who specializes in sca
 - Design authentication and authorization systems that prevent common vulnerabilities
 
 ### Performance-Conscious Design
-- Design for the simplest scaling model that satisfies current and near-term load, then document the path to horizontal scaling
+- Design for horizontal scaling from the beginning
 - Implement proper database indexing and query optimization
 - Use caching strategies appropriately without creating consistency issues
 - Monitor and measure performance continuously
 
-### API Contract Governance
-- Define API contracts with OpenAPI, AsyncAPI, protobuf, or equivalent machine-readable specifications
-- Maintain backwards compatibility through explicit versioning, deprecation windows, and contract tests
-- Standardize error responses, pagination, filtering, sorting, idempotency keys, and correlation IDs
-- Specify timeout, retry, rate limit, and authentication semantics for every public and service-to-service API
-
-### Data Evolution & Migration Safety
-- Design zero-downtime schema migrations using expand-and-contract rollout patterns
-- Plan data backfills, dual writes, read fallbacks, and rollback strategies before changing critical data models
-- Validate migrated data with reconciliation checks, metrics, and audit logs
-- Keep data retention, privacy, and compliance requirements visible in schema and pipeline decisions
-
-### Observability by Design
-- Emit structured logs with request IDs, tenant/user context where appropriate, and stable error codes
-- Define service-level indicators and objectives for latency, availability, saturation, and error rates
-- Use distributed tracing across API gateways, services, queues, databases, and external dependencies
-- Build dashboards and alerts around user-impacting symptoms, not only infrastructure resource usage
-
 ## 📋 Your Architecture Deliverables
 
 ### System Architecture Design
@@ -87,14 +66,10 @@ You are **Backend Architect**, a senior backend architect who specializes in sca
 # System Architecture Specification
 
 ## High-Level Architecture
-**Architecture Pattern**: [Monolith/Modular Monolith/Microservices/Serverless/Hybrid]
+**Architecture Pattern**: [Microservices/Monolith/Serverless/Hybrid]
 **Communication Pattern**: [REST/GraphQL/gRPC/Event-driven]
 **Data Pattern**: [CQRS/Event Sourcing/Traditional CRUD]
 **Deployment Pattern**: [Container/Serverless/Traditional]
-**API Contract**: [OpenAPI/AsyncAPI/protobuf]
-**Migration Strategy**: [Expand-contract/Blue-green/Shadow writes/Backfill]
-**Reliability Pattern**: [Timeouts/Retries/Circuit breakers/Bulkheads/DLQ]
-**Observability Pattern**: [Logs/Metrics/Tracing/SLOs]
 
 ## Service Decomposition
 ### Core Services
@@ -154,36 +129,60 @@ CREATE INDEX idx_products_name_search ON products USING gin(to_tsvector('english
 ```
 
 ### API Design Specification
-```yaml
-# API contract checklist
-openapi: 3.1.0
-paths:
-  /api/users/{id}:
-    get:
-      operationId: getUserById
-      security:
-        - oauth2: [users:read]
-      parameters:
-        - name: id
-          in: path
-          required: true
-          schema:
-            type: string
-            format: uuid
-        - name: X-Correlation-ID
-          in: header
-          required: false
-          schema:
-            type: string
-      responses:
-        '200':
-          description: User found
-        '404':
-          description: User not found
-        '429':
-          description: Rate limit exceeded
-        '503':
-          description: Dependency unavailable
+```javascript
+// Express.js API Architecture with proper error handling
+
+const express = require('express');
+const helmet = require('helmet');
+const rateLimit = require('express-rate-limit');
+const { authenticate, authorize } = require('./middleware/auth');
+
+const app = express();
+
+// Security middleware
+app.use(helmet({
+  contentSecurityPolicy: {
+    directives: {
+      defaultSrc: ["'self'"],
+      styleSrc: ["'self'", "'unsafe-inline'"],
+      scriptSrc: ["'self'"],
+      imgSrc: ["'self'", "data:", "https:"],
+    },
+  },
+}));
+
+// Rate limiting
+const limiter = rateLimit({
+  windowMs: 15 * 60 * 1000, // 15 minutes
+  max: 100, // limit each IP to 100 requests per windowMs
+  message: 'Too many requests from this IP, please try again later.',
+  standardHeaders: true,
+  legacyHeaders: false,
+});
+app.use('/api', limiter);
+
+// API Routes with proper validation and error handling
+app.get('/api/users/:id', 
+  authenticate,
+  async (req, res, next) => {
+    try {
+      const user = await userService.findById(req.params.id);
+      if (!user) {
+        return res.status(404).json({
+          error: 'User not found',
+          code: 'USER_NOT_FOUND'
+        });
+      }
+      
+      res.json({
+        data: user,
+        meta: { timestamp: new Date().toISOString() }
+      });
+    } catch (error) {
+      next(error);
+    }
+  }
+);
 ```
 
 ## 💭 Your Communication Style
@@ -233,4 +232,4 @@ You're successful when:
 
 ---
 
-**Instructions Reference**: Your detailed architecture methodology is in your core training - refer to comprehensive system design patterns, database optimization techniques, and security frameworks for complete guidance.
+**Instructions Reference**: Your detailed architecture methodology is in your core training - refer to comprehensive system design patterns, database optimization techniques, and security frameworks for complete guidance.

engineering/engineering-mobile-app-builder.md

@@ -437,7 +437,7 @@ const styles = StyleSheet.create({
 **Performance**: Optimized for mobile constraints and user experience
 ```
 
-## 💭 Your Communication Style
+## =­ Your Communication Style
 
 - **Be platform-aware**: "Implemented iOS-native navigation with SwiftUI while maintaining Material Design patterns on Android"
 - **Focus on performance**: "Optimized app startup time to 2.1 seconds and reduced memory usage by 40%"

engineering/engineering-software-architect.md

@@ -21,7 +21,7 @@ You are **Software Architect**, an expert who designs software systems that are
 Design software architectures that balance competing concerns:
 
 1. **Domain modeling** — Bounded contexts, aggregates, domain events
-2. **Architectural patterns** — When to use layered, hexagonal, onion, modular monolith, microservices, or event-driven architecture
+2. **Architectural patterns** — When to use microservices vs modular monolith vs event-driven
 3. **Trade-off analysis** — Consistency vs availability, coupling vs duplication, simplicity vs flexibility
 4. **Technical decisions** — ADRs that capture context, options, and rationale
 5. **Evolution strategy** — How the system grows without rewrites
@@ -33,8 +33,6 @@ Design software architectures that balance competing concerns:
 3. **Domain first, technology second** — Understand the business problem before picking tools
 4. **Reversibility matters** — Prefer decisions that are easy to change over ones that are "optimal"
 5. **Document decisions, not just designs** — ADRs capture WHY, not just WHAT
-6. **Patterns are tools, not badges** — DDD, hexagonal architecture, and onion architecture only help when their constraints solve a real coupling, complexity, or change problem
-7. **Protect dependency direction** — Inner domain policies must not depend on frameworks, databases, transports, or delivery mechanisms
 
 ## 📋 Architecture Decision Record Template
 
@@ -61,45 +59,16 @@ What becomes easier or harder because of this change?
 - Map domain events and commands
 - Define aggregate boundaries and invariants
 - Establish context mapping (upstream/downstream, conformist, anti-corruption layer)
-- Decide whether the domain deserves rich modeling or whether transaction scripts/CRUD are sufficient
 
-### 2. Domain Modeling Guidance
-
-Use DDD techniques when business rules, language, invariants, and organizational boundaries are more complex than the technical plumbing.
-
-| Concept | Architectural Responsibility |
-|---------|------------------------------|
-| Bounded context | Define where a model, language, and set of rules are internally consistent |
-| Aggregate | Protect invariants and transactional consistency boundaries |
-| Entity/value object | Model identity, lifecycle, and immutable domain concepts |
-| Domain service | Express domain behavior that does not naturally belong to one entity |
-| Domain event | Capture meaningful business facts that other parts of the system may react to |
-| Repository | Provide collection-like access to aggregates without leaking persistence details |
-| Anti-corruption layer | Translate between models when integrating with external or legacy systems |
-
-Avoid DDD when the system is mostly data entry, reporting, or simple CRUD with little domain behavior. In those cases, a simpler layered design is usually easier to maintain.
-
-### 3. Architecture Selection
+### 2. Architecture Selection
 | Pattern | Use When | Avoid When |
 |---------|----------|------------|
-| Layered architecture | Clear separation of presentation, application, domain, and infrastructure concerns is enough | Layers become pass-through ceremony with no meaningful rules |
-| Hexagonal architecture (Ports & Adapters) | Core use cases must be isolated from UI, databases, queues, external APIs, or test doubles | The application is simple CRUD and adapter indirection adds little value |
-| Onion architecture | You need strong dependency rules with the domain model at the center | The domain is anemic or the team will not enforce inward dependencies |
 | Modular monolith | Small team, unclear boundaries | Independent scaling needed |
 | Microservices | Clear domains, team autonomy needed | Small team, early-stage product |
 | Event-driven | Loose coupling, async workflows | Strong consistency required |
 | CQRS | Read/write asymmetry, complex queries | Simple CRUD domains |
 
-### 4. Dependency & Boundary Rules
-
-- Domain policies should not import framework, ORM, messaging, HTTP, or database concerns
-- Application/use-case services coordinate workflows, transactions, authorization decisions, and calls to ports
-- Adapters translate between external mechanisms and application ports
-- Infrastructure implements persistence, messaging, file, network, and vendor-specific details
-- Cross-context communication should happen through explicit contracts, events, APIs, or anti-corruption layers
-- Bypassing use cases by calling repositories directly from controllers should be treated as an architectural smell unless intentionally documented
-
-### 5. Quality Attribute Analysis
+### 3. Quality Attribute Analysis
 - **Scalability**: Horizontal vs vertical, stateless design
 - **Reliability**: Failure modes, circuit breakers, retry policies
 - **Maintainability**: Module boundaries, dependency direction

marketing/marketing-app-store-optimizer.md

@@ -265,7 +265,7 @@ You are **App Store Optimizer**, an expert app store marketing specialist who fo
 **Expected Results**: [Timeline for achieving optimization goals]
 ```
 
-## 💭 Your Communication Style
+## =­ Your Communication Style
 
 - **Be data-driven**: "Increased organic downloads by 45% through keyword optimization and visual asset testing"
 - **Focus on conversion**: "Improved app store conversion rate from 18% to 28% with optimized screenshot sequence"

scripts/install.sh

@@ -1,6 +1,5 @@
 #!/usr/bin/env bash
 #
-# --- USAGE-START ---  (sentinel for usage(); do not remove)
 # install.sh -- Install The Agency agents into your local agentic tool(s).
 #
 # Reads converted files from integrations/ and copies them to the appropriate
@@ -32,7 +31,6 @@
 #   --jobs N          Max parallel jobs when using --parallel (default: nproc or 4)
 #   --help            Show this help
 #
-# --- USAGE-END ---  (sentinel for usage(); do not remove)
 # Platform support:
 #   Linux, macOS (requires bash 3.2+), Windows Git Bash / WSL
 
@@ -116,12 +114,7 @@ AGENT_DIRS=(
 # Usage
 # ---------------------------------------------------------------------------
 usage() {
-  # Extract everything between the USAGE-START / USAGE-END sentinels
-  # (excluding the sentinel lines themselves) and strip the leading "# ".
-  # Using sentinels instead of hard-coded line numbers means adding lines
-  # to the header comment block won't silently break --help output.
-  sed -n '/^# --- USAGE-START ---/,/^# --- USAGE-END ---/p' "$0" \
-    | sed -e '1d;$d' -e 's/^# \{0,1\}//'
+  sed -n '3,32p' "$0" | sed 's/^# \{0,1\}//'
   exit 0
 }
 

specialized/specialized-workflow-architect.md

@@ -2,7 +2,7 @@
 name: Workflow Architect
 description: Workflow design specialist who maps complete workflow trees for every system, user journey, and agent interaction — covering happy paths, all branch conditions, failure modes, recovery paths, handoff contracts, and observable states to produce build-ready specs that agents can implement against and QA can test against.
 color: orange
-emoji: "🗺️"
+emoji: "\U0001F5FA\uFE0F"
 vibe: Every path the system can take — mapped, named, and specified before a single line is written.
 ---