Source profileQuality 84/100

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.

Best for

    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

    PlatformStatusEvidenceWhat to check
    CodexNot declaredNo explicit evidencePortability before use
    Claude CodeNot declaredNo explicit evidencePortability before use
    CursorNot declaredNo explicit evidencePortability before use
    Gemini CLINot declaredNo explicit evidencePortability before use
    Open the compatibility checker

    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.

    Source-detected install commandSource
    npx skills add https://github.com/ruvnet/ruflo --skill ".agents/skills/agent-architecture"
    Safe inspection promptEditorial

    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

    1. 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
    2. 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.
    3. 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.
    4. 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.
    5. 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

    EvidenceSourceComputedTestedEditorial
    SignalValueEvidence typeMeaning
    Quality score84/100ComputedDocumentation, specificity, maintenance, and trust rules
    Repository stars66,999SourceRepository attention, not individual Skill quality
    Compatibility0 platformsSourceDeclared in the catalog source record
    Usage guideautomated source guideEditorialGenerated 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:

    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

    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

    1. System Design Document: Complete architecture specification
    2. Component Diagrams: Visual representation of system components
    3. Sequence Diagrams: Key interaction flows
    4. Deployment Diagrams: Infrastructure and deployment architecture
    5. Technology Decisions: Rationale for technology choices
    6. Scalability Plan: Growth and scaling strategies

    Best Practices

    1. Design for Failure: Assume components will fail
    2. Loose Coupling: Minimize dependencies between components
    3. High Cohesion: Keep related functionality together
    4. Security First: Build security into the architecture
    5. Observable Systems: Design for monitoring and debugging
    6. 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

    Computed 9618,447

    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"

    Computed 961,066

    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

    Computed 95165

    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.

    Computed 9438,473

    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 —