What makes Software Architecture Design SOP notable?

1.1K downloads. Trust evidence available

How should Software Architecture Design SOP be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

Software Architecture Design SOP

Produces a complete software architecture design document following a 12-phase SOP. Supports web backend, mobile, ML/AI, data pipeline, embedded/IoT. Generat... Skill: Software Architecture Design SOP Owner: 1231111 Summary: Produces a complete software architecture design document following a 12-phase SOP. Supports web backend, mobile, ML/AI, data pipeline, embedded/IoT. Generat... Tags: architecture:1.1.0, latest:1.1.0, mermaid:1.1.0, plantuml:1.1.0, sop:1.1.0, system-design:1.1.0 Version history: v1.1.0 | 2026-05-28T03:01:16.413Z | user Initial public release: 12-phase SO

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.1k

Updated

Oct 11, 2026

Version

1.1.0

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1.1K downloads reported by the source. Last updated 10/11/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 11, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 11, 2026
Adoption signal: 1.1K downloadsadoption · observed Oct 11, 2026
Latest release: 1.1.0release · observed May 28, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s17e7zph9qn5y9mzfzrhqew20n87keef:software-architecture-design

Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.
Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-1231111-software-architecture-design/snapshot"

Documentation

CLAWHUB

52,600 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: software-architecture-design
version: 1.1.0
author: sunbinbin
license: MIT
tags: architecture, system-design, technical-design, sop, mermaid, plantuml, web, mobile, ml, embedded, data-pipeline
description: "Produces a complete software architecture design document following a 12-phase SOP. Supports web backend, mobile, ML/AI, data pipeline, embedded/IoT. Generates Mermaid and PlantUML diagrams. Use when asked to do architecture design, system design, technical design, or says: 做架构设计 系统设计 技术方案 架构文档."
metadata: {"openclaw": {"emoji": "🏗️", "os": ["darwin", "linux", "win32"]}}
---

# Software Architecture Design SOP

## Step 0 — Identify Architecture Type First

Before starting the 12 phases, identify the architecture type and load the matching specialization:

| Type | Trigger keywords | Specialization file |
|------|-----------------|---------------------|
| Web / API backend | API, 后端, 服务端, REST, 微服务, SaaS | `{baseDir}/specializations/web-backend.md` |
| ML / AI system | 模型, 推理, 训练, 算法平台, AI, LLM | `{baseDir}/specializations/ml-system.md` |
| Data pipeline | ETL, 数据仓库, 数据湖, Kafka, Spark | `{baseDir}/specializations/data-pipeline.md` |
| Embedded / IoT | 嵌入式, 固件, MCU, RTOS, 硬件, CAN | `{baseDir}/specializations/embedded.md` |
| Mobile app | iOS, Android, Flutter, React Native | `{baseDir}/specializations/mobile.md` |
| General / Mixed | (none of the above match clearly) | Use base SOP only |

Read the matched specialization file for domain-specific guidance on Phases 3, 6, 7, 9.

---

## Core Principles (apply throughout)

- **Constraint-driven** — Every decision traces back to a hard constraint (compliance, budget, team, deployment env).
- **Decision explicit** — For every non-trivial choice, show Option A vs Option B and the reason for selection.
- **MVP-first** — Define a clear MVP boundary. Defer everything not critical to v1.
- **Diagram every concept** — Each major phase produces at least one diagram (see diagram guide in `{baseDir}/reference.md`).
- **Executable** — The architecture must be buildable by the stated team with the stated tech stack.

---

## Phase 1 — Requirement Intake

**Input**: Requirements doc, RFP, PRD, user stories, or verbal description.

1. Classify all requirements:
   - **Functional** — what the system does (features, user journeys)
   - **Non-functional** — performance, availability SLA, latency, throughput, data volume
   - **Compliance / regulatory** — industry standards, data residency, audit requirements
   - **Deployment constraints** — air-gap, on-prem, cloud, edge, hardware limits, OS
2. List the top 5 user roles and their primary use cases.
3. Capture all explicit exclusions ("out of scope").
4. List open questions / ambiguities — ask the user to resolve before proceeding.

---

## Phase 2 — System Context & Boundary

1. Draw **System Context Diagram** (C4 Level 1): system as a black box + external actors + external systems.
2. Define MVP de

_meta.json

{
  "ownerId": "kn7fp5s80ck78fqh36fht9sdcd87jhp9",
  "slug": "software-architecture-design",
  "version": "1.1.0",
  "publishedAt": 1779937276413
}

reference.md

# Architecture Design — Reference

## Phase-by-Phase Checklist

### Phase 1: Requirement Intake
- [ ] All source documents read in full
- [ ] Functional requirements listed and numbered
- [ ] Non-functional: performance, availability, latency, throughput, data volume
- [ ] Compliance standards identified (ISO, GDPR, HIPAA, GB, IEC, etc.)
- [ ] Deployment constraints captured (air-gap, GPU, OS, cloud/on-prem, hardware)
- [ ] Top 5 user roles and use cases written
- [ ] Open questions listed for user to resolve

### Phase 2: System Context & Boundary
- [ ] System Context Diagram exists with all external actors and systems labeled
- [ ] MVP Includes table with success criteria per feature
- [ ] MVP Excludes table with target version per exclusion
- [ ] Performance targets table with measurement method

### Phase 3: Layered Architecture
- [ ] Architecture pattern named and justified against constraints
- [ ] Every layer: name / stack / responsibility / inter-layer protocol
- [ ] Layer architecture diagram exists

### Phase 4: Module Decomposition
- [ ] Every module: one-sentence responsibility
- [ ] No circular dependencies (verified)
- [ ] Module dependency diagram exists (DAG)

### Phase 5: Core Business Flows
- [ ] At least 3 critical flows documented with diagrams
- [ ] State machines for all stateful entities
- [ ] Exception paths documented per flow

### Phase 6: Data Architecture
- [ ] ER diagram covering all core entities
- [ ] Storage selection justified per data type
- [ ] Key schemas with field names and types
- [ ] Backup / retention policy stated

### Phase 7: Technology Selection
- [ ] Option A vs Option B table for each component
- [ ] Each selection validated against Phase 1 constraints
- [ ] No orphaned technologies (every tech appears in the architecture)
- [ ] Deliberate tech debt documented with rationale

### Phase 8: Interface Design
- [ ] All endpoints in a table (method, path, purpose, sync/async, auth)
- [ ] SPI/plugin contract defined if extensibility required
- [ ] Async protocol (WebSocket / SSE / queue) described
- [ ] Error response schema defined
- [ ] Versioning strategy stated

### Phase 9: Deployment Architecture
- [ ] Deployment topology diagram exists
- [ ] Server/hardware specs for min / recommended / production
- [ ] All runtime components with ports and resource requirements
- [ ] Volume / filesystem / data flow described
- [ ] CI/CD pipeline steps listed

### Phase 10: Non-Functional Design
- [ ] HA: failure scenarios and recovery strategies
- [ ] Performance: each metric + implementation strategy
- [ ] Security: auth, secrets, data isolation, audit
- [ ] Observability: MVP health endpoints + future metrics plan

### Phase 11: MVP Scope Lock
- [ ] MVP Includes / Excludes finalized
- [ ] Success criteria measurable
- [ ] Tech debt register complete

### Phase 12: Risk Register
- [ ] ≥ 5 risks documented
- [ ] Each risk: probability + impact

skill-card.md

## Description:

Produces complete software architecture design documents through a 12-phase SOP for web backend, mobile, ML/AI, data pipeline, and embedded/IoT systems, with Mermaid and PlantUML diagram guidance.

This skill is ready for commercial/non-commercial use.

## Publisher:

[1231111](https://clawhub.ai/user/1231111)

### License/Terms of Use:

MIT-0

## Use Case:

Developers and engineers use this skill to turn requirements, PRDs, RFPs, or verbal system descriptions into structured architecture design documents with MVP scope, architecture decisions, interfaces, deployment, non-functional design, and risk registers.

### Deployment Geography for Use:

Global

## Known Risks and Mitigations:

Risk: Generated ML/AI architecture guidance may include detailed health endpoints that expose resource status if copied directly into production designs.

Mitigation: Keep public liveness checks minimal and move detailed health and resource reporting to authenticated internal metrics endpoints before production use.

Risk: The default output template is Chinese, which may not match every team's documentation language.

Mitigation: Ask the agent for the required output language at the start of the architecture-design request.

Risk: Architecture proposals can be incomplete or misaligned when requirements are ambiguous.

Mitigation: Resolve the Phase 1 open questions and review generated decisions, diagrams, and risk registers with domain owners before adoption.

## Reference(s):

- [Architecture Design Reference](artifact/reference.md)
- [Architecture Design Document Template](artifact/template.md)
- [Standalone Software Architecture Design SOP](artifact/STANDALONE.md)
- [Web / API Backend Specialization](artifact/specializations/web-backend.md)
- [ML / AI System Specialization](artifact/specializations/ml-system.md)
- [Data Pipeline / Data Platform Specialization](artifact/specializations/data-pipeline.md)
- [Embedded / IoT System Specialization](artifact/specializations/embedded.md)
- [Mobile App Specialization](artifact/specializations/mobile.md)

## Skill Output:

**Output Type(s):** [Text, Markdown, Code, Guidance]

**Output Format:** [Markdown architecture document with Mermaid and PlantUML code blocks]

**Output Parameters:** [1D]

**Other Properties Related to Output:** [Default output template is Chinese unless the user asks for another language.]

## Skill Version(s):

1.1.0 (source: frontmatter and server release metadata)

## Ethical Considerations:

Users should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.

specializations/data-pipeline.md

# Specialization: Data Pipeline / Data Platform

Apply this guidance for ETL, ELT, data warehouse, data lake, streaming, and analytics platform designs.

## Phase 3 — Data Pipeline Architecture Patterns

| Pattern | When to choose |
|---------|---------------|
| Batch ETL | Latency tolerance hours/days; large volume; simple transforms |
| Streaming (Lambda) | Real-time + batch coexist; complex state management |
| Streaming-only (Kappa) | All processing as streams; late data handled by reprocessing |
| ELT (load first, transform in warehouse) | Cloud DW available; raw data preservation needed |
| Medallion (Bronze/Silver/Gold) | Data lake; incremental quality improvement; multiple consumer types |

## Phase 5 — Critical Flows for Data Pipelines

1. **Ingestion flow**: source → extract → validate → land (raw)
2. **Transform flow**: raw → clean → enrich → aggregate
3. **Serving flow**: aggregated data → query engine → consumer (BI, API, ML)
4. **Backfill / reprocessing flow**: historical data re-ingestion on schema/logic change
5. **Data quality check flow**: record → validation rules → quarantine or pass

## Phase 6 — Storage Layers

| Layer | Purpose | Technology options |
|-------|---------|-------------------|
| Landing (raw) | Exact copy of source, immutable | Object storage (S3/MinIO), file system |
| Staging | Cleaned, typed, deduplicated | Parquet on object storage |
| Curated | Business-ready aggregates | Data warehouse (PostgreSQL, ClickHouse, BigQuery) |
| Serving | Low-latency query | Columnar DB, materialized views, Redis cache |
| Metadata | Lineage, schema, quality stats | Relational DB (PostgreSQL) |

## Phase 7 — Data Pipeline Decision Points

| Decision | Key question | Options |
|----------|-------------|---------|
| Batch vs stream | What is the acceptable latency? | minutes → micro-batch; seconds → streaming |
| Orchestration | How many pipelines? Complex dependencies? | Cron → Airflow → Prefect/Dagster |
| Transform engine | Data volume? Team language? | SQL (dbt) vs Python (Spark/Pandas) vs Beam |
| Messaging | Throughput and durability? | Redis Streams → RabbitMQ → Kafka |
| Schema management | Schema evolution needed? | None → JSON Schema → Avro/Protobuf |

## Phase 8 — Data Pipeline Interface Design

Define these contracts explicitly:

- **Source connectors**: protocol, auth, extraction mode (full / incremental / CDC), rate limits
- **Schema registry**: where schemas are defined, how consumers discover them
- **Data quality contract**: which fields are required, valid ranges, uniqueness constraints
- **SLA contract**: ingestion frequency, max latency, freshness guarantee

## Phase 9 — Deployment Patterns

| Pattern | Scale | Notes |
|---------|-------|-------|
| Single server + cron | Small, < 10 pipelines | Simple, low ops overhead |
| Docker Compose + Airflow | Medium, < 100 pipelines | Managed scheduling |
| Kubernetes + Helm | Large, 100+ pipelines, multi-tenant

Github ReposUpdated 2d agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.