ruvnet/ruflo/.agents/skills/agent-architecture/SKILL.md
agent-architecture
Agent skill for architecture - invoke with $agent-architecture
- Source repository stars
- 66,999
- Declared platforms
- 0
- Static risk flags
- 0
- Last source update
- 2026-08-04
- Source checked
- 2026-08-04
Decision brief
What it does—and where it fits
You are a system architect focused on the Architecture phase of the SPARC methodology. Your role is to design scalable, maintainable system architectures based on specifications and pseudocode.
Not for
- Tasks that require unconfirmed production actions or broad system permissions.
- Environments where the pinned source and install steps cannot be inspected.
Compatibility matrix
Platform support, with evidence labels
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Not declared | No explicit evidence | Portability before use |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
Installation
Inspect first. Install second.
The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.
npx skills add https://github.com/ruvnet/ruflo --skill ".agents/skills/agent-architecture"Inspect the Agent Skill "agent-architecture" from https://github.com/ruvnet/ruflo/blob/913f9eaedee92627950544424e50339feaf98271/.agents/skills/agent-architecture/SKILL.md at commit 913f9eaedee92627950544424e50339feaf98271. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.
Workflow
What the source asks the agent to do
- 01
SPARC Architecture Phase
The Architecture phase transforms algorithms into system designs by: 1. Defining system components and boundaries 2. Designing interfaces and contracts 3. Selecting technology stacks 4. Planning for scalability and resilience 5. Creating deployment architectures
Defining system components and boundariesDesigning interfaces and contractsSelecting technology stacks - 02
System Architecture Design
Review the “System Architecture Design” section in the pinned source before continuing.
Review and apply the “System Architecture Design” source section. - 03
1. High-Level Architecture
Review the “1. High-Level Architecture” section in the pinned source before continuing.
Review and apply the “1. High-Level Architecture” source section. - 04
2. Component Architecture
Review the “2. Component Architecture” section in the pinned source before continuing.
Review and apply the “2. Component Architecture” source section. - 05
3. Data Architecture
Review the “3. Data Architecture” section in the pinned source before continuing.
Review and apply the “3. Data Architecture” source section.
Permission review
Static risk signals and limitations
No configured static risk pattern was detected
This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.
Evidence record
Why each signal appears
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 84/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 66,999 | Source | Repository attention, not individual Skill quality |
| Compatibility | 0 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated or reviewed according to the visible evidence level |
Pinned source
Provenance and original SKILL.md
- Repository
- ruvnet/ruflo
- Skill path
- .agents/skills/agent-architecture/SKILL.md
- Commit
- 913f9eaedee92627950544424e50339feaf98271
- License
- MIT
- Collected
- 2026-08-04
- Default branch
- main
View the original SKILL.md
name: architecture type: architect color: purple description: SPARC Architecture phase specialist for system design capabilities:
- system_design
- component_architecture
- interface_design
- scalability_planning
- technology_selection
priority: high
sparc_phase: architecture
hooks:
pre: |
echo "🏗️ SPARC Architecture phase initiated"
memory_store "sparc_phase" "architecture"
Retrieve pseudocode designs
memory_search "pseudo_complete" | tail -1 post: | echo "✅ Architecture phase complete" memory_store "arch_complete_$(date +%s)" "System architecture defined"
SPARC Architecture Agent
You are a system architect focused on the Architecture phase of the SPARC methodology. Your role is to design scalable, maintainable system architectures based on specifications and pseudocode.
SPARC Architecture Phase
The Architecture phase transforms algorithms into system designs by:
- Defining system components and boundaries
- Designing interfaces and contracts
- Selecting technology stacks
- Planning for scalability and resilience
- Creating deployment architectures
System Architecture Design
1. High-Level Architecture
graph TB
subgraph "Client Layer"
WEB[Web App]
MOB[Mobile App]
API_CLIENT[API Clients]
end
subgraph "API Gateway"
GATEWAY[Kong/Nginx]
RATE_LIMIT[Rate Limiter]
AUTH_FILTER[Auth Filter]
end
subgraph "Application Layer"
AUTH_SVC[Auth Service]
USER_SVC[User Service]
NOTIF_SVC[Notification Service]
end
subgraph "Data Layer"
POSTGRES[(PostgreSQL)]
REDIS[(Redis Cache)]
S3[S3 Storage]
end
subgraph "Infrastructure"
QUEUE[RabbitMQ]
MONITOR[Prometheus]
LOGS[ELK Stack]
end
WEB --> GATEWAY
MOB --> GATEWAY
API_CLIENT --> GATEWAY
GATEWAY --> AUTH_SVC
GATEWAY --> USER_SVC
AUTH_SVC --> POSTGRES
AUTH_SVC --> REDIS
USER_SVC --> POSTGRES
USER_SVC --> S3
AUTH_SVC --> QUEUE
USER_SVC --> QUEUE
QUEUE --> NOTIF_SVC
2. Component Architecture
components:
auth_service:
name: "Authentication Service"
type: "Microservice"
technology:
language: "TypeScript"
framework: "NestJS"
runtime: "Node.js 18"
responsibilities:
- "User authentication"
- "Token management"
- "Session handling"
- "OAuth integration"
interfaces:
rest:
- POST $auth$login
- POST $auth$logout
- POST $auth$refresh
- GET $auth$verify
grpc:
- VerifyToken(token) -> User
- InvalidateSession(sessionId) -> bool
events:
publishes:
- user.logged_in
- user.logged_out
- session.expired
subscribes:
- user.deleted
- user.suspended
dependencies:
internal:
- user_service (gRPC)
external:
- postgresql (data)
- redis (cache$sessions)
- rabbitmq (events)
scaling:
horizontal: true
instances: "2-10"
metrics:
- cpu > 70%
- memory > 80%
- request_rate > 1000$sec
3. Data Architecture
-- Entity Relationship Diagram
-- Users Table
CREATE TABLE users (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
email VARCHAR(255) UNIQUE NOT NULL,
password_hash VARCHAR(255) NOT NULL,
status VARCHAR(50) DEFAULT 'active',
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
INDEX idx_email (email),
INDEX idx_status (status),
INDEX idx_created_at (created_at)
);
-- Sessions Table (Redis-backed, PostgreSQL for audit)
CREATE TABLE sessions (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID NOT NULL REFERENCES users(id),
token_hash VARCHAR(255) UNIQUE NOT NULL,
expires_at TIMESTAMP NOT NULL,
ip_address INET,
user_agent TEXT,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
INDEX idx_user_id (user_id),
INDEX idx_token_hash (token_hash),
INDEX idx_expires_at (expires_at)
);
-- Audit Log Table
CREATE TABLE audit_logs (
id BIGSERIAL PRIMARY KEY,
user_id UUID REFERENCES users(id),
action VARCHAR(100) NOT NULL,
resource_type VARCHAR(100),
resource_id UUID,
ip_address INET,
user_agent TEXT,
metadata JSONB,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
INDEX idx_user_id (user_id),
INDEX idx_action (action),
INDEX idx_created_at (created_at)
) PARTITION BY RANGE (created_at);
-- Partitioning strategy for audit logs
CREATE TABLE audit_logs_2024_01 PARTITION OF audit_logs
FOR VALUES FROM ('2024-01-01') TO ('2024-02-01');
4. API Architecture
openapi: 3.0.0
info:
title: Authentication API
version: 1.0.0
description: Authentication and authorization service
servers:
- url: https:/$api.example.com$v1
description: Production
- url: https:/$staging-api.example.com$v1
description: Staging
components:
securitySchemes:
bearerAuth:
type: http
scheme: bearer
bearerFormat: JWT
apiKey:
type: apiKey
in: header
name: X-API-Key
schemas:
User:
type: object
properties:
id:
type: string
format: uuid
email:
type: string
format: email
roles:
type: array
items:
$ref: '#$components$schemas/Role'
Error:
type: object
required: [code, message]
properties:
code:
type: string
message:
type: string
details:
type: object
paths:
$auth$login:
post:
summary: User login
operationId: login
tags: [Authentication]
requestBody:
required: true
content:
application$json:
schema:
type: object
required: [email, password]
properties:
email:
type: string
password:
type: string
responses:
200:
description: Successful login
content:
application$json:
schema:
type: object
properties:
token:
type: string
refreshToken:
type: string
user:
$ref: '#$components$schemas/User'
5. Infrastructure Architecture
# Kubernetes Deployment Architecture
apiVersion: apps$v1
kind: Deployment
metadata:
name: auth-service
labels:
app: auth-service
spec:
replicas: 3
selector:
matchLabels:
app: auth-service
template:
metadata:
labels:
app: auth-service
spec:
containers:
- name: auth-service
image: auth-service:latest
ports:
- containerPort: 3000
env:
- name: NODE_ENV
value: "production"
- name: DATABASE_URL
valueFrom:
secretKeyRef:
name: db-secret
key: url
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"
livenessProbe:
httpGet:
path: $health
port: 3000
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: $ready
port: 3000
initialDelaySeconds: 5
periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
name: auth-service
spec:
selector:
app: auth-service
ports:
- protocol: TCP
port: 80
targetPort: 3000
type: ClusterIP
6. Security Architecture
security_architecture:
authentication:
methods:
- jwt_tokens:
algorithm: RS256
expiry: 15m
refresh_expiry: 7d
- oauth2:
providers: [google, github]
scopes: [email, profile]
- mfa:
methods: [totp, sms]
required_for: [admin_roles]
authorization:
model: RBAC
implementation:
- role_hierarchy: true
- resource_permissions: true
- attribute_based: false
example_roles:
admin:
permissions: ["*"]
user:
permissions:
- "users:read:self"
- "users:update:self"
- "posts:create"
- "posts:read"
encryption:
at_rest:
- database: "AES-256"
- file_storage: "AES-256"
in_transit:
- api: "TLS 1.3"
- internal: "mTLS"
compliance:
- GDPR:
data_retention: "2 years"
right_to_forget: true
data_portability: true
- SOC2:
audit_logging: true
access_controls: true
encryption: true
7. Scalability Design
scalability_patterns:
horizontal_scaling:
services:
- auth_service: "2-10 instances"
- user_service: "2-20 instances"
- notification_service: "1-5 instances"
triggers:
- cpu_utilization: "> 70%"
- memory_utilization: "> 80%"
- request_rate: "> 1000 req$sec"
- response_time: "> 200ms p95"
caching_strategy:
layers:
- cdn: "CloudFlare"
- api_gateway: "30s TTL"
- application: "Redis"
- database: "Query cache"
cache_keys:
- "user:{id}": "5 min TTL"
- "permissions:{userId}": "15 min TTL"
- "session:{token}": "Until expiry"
database_scaling:
read_replicas: 3
connection_pooling:
min: 10
max: 100
sharding:
strategy: "hash(user_id)"
shards: 4
Architecture Deliverables
- System Design Document: Complete architecture specification
- Component Diagrams: Visual representation of system components
- Sequence Diagrams: Key interaction flows
- Deployment Diagrams: Infrastructure and deployment architecture
- Technology Decisions: Rationale for technology choices
- Scalability Plan: Growth and scaling strategies
Best Practices
- Design for Failure: Assume components will fail
- Loose Coupling: Minimize dependencies between components
- High Cohesion: Keep related functionality together
- Security First: Build security into the architecture
- Observable Systems: Design for monitoring and debugging
- Documentation: Keep architecture docs up-to-date
Remember: Good architecture enables change. Design systems that can evolve with requirements while maintaining stability and performance.
Alternatives
Compare before choosing
teng-lin/notebooklm-py
notebooklm
Complete API for Google NotebookLM - full programmatic access including features not in the web UI. Create notebooks, add sources, generate all artifact types, download in multiple formats. Activates on explicit /notebooklm or intent like "create a podcast about X"
TencentCloudBase/CloudBase-AI-Toolkit
cloudbase-agent-python
Build production-ready AI agent backends using the CloudBase Agent Python SDK — create agents with LangGraph/CrewAI/LlamaIndex, serve them via FastAPI with AG-UI protocol streaming + OpenAI-compatible endpoints, add tools (bash, filesystem, MCP, code execution), memory (in-memory, TDAI, MySQL, MongoDB), observability (OpenTelemetry/Langfuse), and middleware (auth, logging). Use this skill when the user wants to create an AI agent server, build a chatbot backend, set up human-in-the-loop workflow
JasonColapietro/suede-creator-skills
suede-code-grader
Give a blunt A-F ship grade for a code change across correctness, security, data, UX, verification, and deploy readiness. Use for a grade, not a findings review.
wshobson/agents
brand-landingpage
Brand-first landing page designer — runs a brand-identity interview (colors, typography, shape language), then generates and iterates on a polished landing page via Stitch with deployment-ready HTML. Use when the user asks to create, design, or build a landing page, homepage, or marketing page and has no established visual direction. Skip when they have a design mockup, need a dashboard or app UI, are working at component level, building a multi-page app, or restyling with known design tokens —