Menü
ARB process design, RFC governance, decision log and technical review workflows
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
**Architecture Decision Record (ADR) — Philosophy-First**: Creates well-structured ADRs using a 3-phase process: (1) Define the architectural philosophy and identity of the system, (2) Explore options through the lens of that philosophy, (3) Adversarial review by a devil's advocate agent. Use this skill whenever the user wants to document a technical decision, create an ADR, record why a technology or approach was chosen, compare architectural alternatives, or mentions 'ADR', 'architecture decision', 'decision record', 'technical decision', 'why did we choose', or 'document this decision'. Also trigger when the user is evaluating trade-offs between technical approaches and wants to formalize the reasoning.
**AI/ML Engineering Review**: Reviews AI/ML systems for production readiness — model serving, MLOps pipelines, LLM integration patterns, prompt engineering, evaluation frameworks, and responsible AI. Covers model deployment, feature stores, experiment tracking, monitoring/drift detection, and AI safety. Use when the user mentions ML, AI, machine learning, model, LLM, GPT, Claude, embeddings, RAG, fine-tuning, MLOps, model serving, feature store, or any AI/ML infrastructure.
**API Documentation & Design (OpenAPI/Swagger)**: Helps write and review API documentation, generate OpenAPI/Swagger specs, design RESTful APIs, and document GraphQL schemas. Use whenever the user mentions 'API docs', 'Swagger', 'OpenAPI', 'API specification', 'API design', 'REST API', 'endpoint documentation', 'API contract', 'API versioning', 'GraphQL schema', 'API reference', or asks to document their API, generate a Swagger spec, design API endpoints, or review API contracts for consistency.
API Gateway design patterns including rate limiting, authentication, versioning, BFF and circuit breaking
**Backend Code Review (Node.js, Java, Microservices)**: Expert review of backend code focusing on Node.js, Java, Clean Architecture, SOLID principles, microservices patterns, SQL/database design, messaging (Kafka, SQS, SNS), and payment flows. Use whenever the user wants a review of backend code, API design, service architecture, database queries, or mentions Node, Java, Spring, NestJS, Express, microservices, REST API, gRPC, or asks to review server-side code. Also trigger for database schema reviews, query optimization, and message queue patterns.
**Chaos Engineering**: Designs and reviews resilience testing strategies — fault injection, game days, failure mode analysis, and blast radius assessment. Covers chaos experiments for distributed systems, database failures, network partitions, and dependency outages. Use when the user mentions chaos engineering, resilience testing, fault injection, game day, failure testing, blast radius, circuit breaker testing, or wants to verify system reliability under failure conditions.
| name | architecture-review-board |
| description | ARB process design, RFC governance, decision log and technical review workflows |
| triggers | {"score-below":60} |
| preferred-model | opus |
| min-confidence | 0.4 |
| depends-on | ["design-patterns","adr"] |
| category | management |
| estimated-tokens | 6000 |
| tags | ["arb","governance","rfc"] |
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ Proposal │───►│ Review │───►│ Decision │───►│ Record │
│ (RFC) │ │ (Meeting) │ │ (Vote) │ │ (ADR) │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
Author ARB Board Approve/ Decision
writes reviews Reject/ logged
Defer
# RFC: [Title]
**Author**: [name]
**Date**: YYYY-MM-DD
**Status**: Draft / In Review / Approved / Rejected
## Problem Statement
[What problem are we solving and why now?]
## Proposed Solution
[Technical approach with diagrams]
## Alternatives Considered
| Option | Pros | Cons |
|--------|------|------|
| Option A | ... | ... |
| Option B | ... | ... |
## Impact Analysis
- Services affected: [list]
- Database changes: [yes/no, describe]
- API changes: [breaking/non-breaking]
- Performance impact: [estimate]
- Security implications: [describe]
## Migration Plan
[How to get from current state to proposed state]
## Risks
1. [Risk with mitigation]
## Open Questions
1. [Question that needs ARB input]
| Change Type | Review Required? |
|---|---|
| New external dependency | ✅ Yes |
| New database | ✅ Yes |
| New programming language | ✅ Yes |
| New microservice | ✅ Yes |
| Architecture pattern change | ✅ Yes |
| API breaking change | ✅ Yes |
| Internal refactoring | ❌ No (team decision) |
| Library update | ❌ No (unless major version) |
| Bug fixes | ❌ No |
| New feature (existing patterns) | ❌ No |
| ID | Date | Title | Decision | Rationale |
|----|------|-------|----------|-----------|
| ARB-001 | 2026-01 | Database choice | PostgreSQL | ACID, JSON support, team expertise |
| ARB-002 | 2026-02 | API framework | NestJS | TypeScript, modular, good ORM integration |
| ARB-003 | 2026-03 | Mobile framework | Flutter | Cross-platform, Dart performance, single codebase |