ワンクリックでManusで任意のスキルを実行

system-architecture

スター4

フォーク0

更新日2026年7月3日 02:00

Use when designing a system, choosing an architecture pattern, making a technology decision, or doing capacity/scalability planning — BEFORE drilling into framework-specific mechanics. A lean MAP over three reference docs: pattern selection (monolith → modular monolith → microservices → event-driven → CQRS → event sourcing → hexagonal → clean → API gateway, with trade-offs), the how-to system-design workflows (system-design-interview approach, capacity planning, API design, DB schema design, scalability assessment, migration planning), and the technology-choice frameworks (database, caching, message queue, auth, frontend framework, cloud provider, API style). Trigger on: 'design the system', 'choose an architecture pattern', 'which pattern fits', 'tech decision', 'SQL or NoSQL', 'REST vs GraphQL vs gRPC', 'capacity/scalability planning', 'plan the migration'. This is general system-design knowledge; for Phoenix bounded-context/Ecto/authz/Oban specifics use the architecture-phx skill.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

endorphin-ai

endorphin-ai/hasbrains-agent-kit

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

When to use this skill

KNOWLEDGE USE_WHEN - "Choosing an architecture pattern for a new system or a milestone (and weighing its trade-offs)." - "Making a technology decision — database, cache, message queue, auth, frontend framework, cloud provider, API style." - "Running a system-design workflow — capacity planning, API design, schema design, scalability assessment, migration planning." - "Doing the PLAN-FIRST step of a design: settle pattern + data/access model + boundaries before drilling into framework mechanics." NOT_FOR - "Phoenix-specific bounded-context / Ecto schema / Oban / can?/3 policy design — that is the architecture-phx skill." - "Writing or verifying implementation code — this skill informs design decisions, it does not produce code."

Core knowledge (the map)

KNOWLEDGE METHOD - "PLAN before mechanics: a design starts by choosing a PATTERN, settling the DATA + ACCESS model, and naming the BOUNDARIES — then drills into technology-specific implementation." - "Every pattern and technology choice is a TRADE-OFF, not a default. Start simple (a monolith / modular monolith) and adopt complexity (microservices, CQRS, event sourcing) only when a concrete force — scale, team autonomy, independent deploy, audit/replay — demands it." - "Right-size the decision to the requirements you actually have: estimate scale FIRST (capacity-planning workflow), then let the numbers drive the pattern and the technology choices." - "Make decisions with a framework, not a hunch: each technology choice in tech_decision_guide.md carries a decision matrix + a 'when to use each' so the choice is defensible."

References (open the one that matches the question)

Three reference docs. Read the map above, then open exactly one.

MAP references "references/architecture_patterns.md" -> PATTERN SELECTION. Open when choosing/comparing an architecture pattern. Monolith, Modular Monolith, Microservices, Event-Driven, CQRS, Event Sourcing, Hexagonal, Clean Architecture, API Gateway — each with its forces, trade-offs, and a pattern-selection quick reference. "references/system_design_workflows.md" -> HOW-TO WORKFLOWS. Open when you need a step-by-step design procedure: the system-design-interview approach, capacity planning, API design, database schema design, scalability assessment, and migration planning. "references/tech_decision_guide.md" -> TECHNOLOGY CHOICE. Open when picking a specific technology: database (SQL vs NoSQL + type), caching strategy, message queue, authentication strategy (JWT vs sessions, OAuth flows), frontend framework (SSR vs SPA vs SSG), cloud provider, and API style (REST vs GraphQL vs gRPC).

How it fits the squad

KNOWLEDGE FITS - "Supporting knowledge for the architect-phx agent's DESIGN mode (phase 2): consulted during the PLAN-FIRST step (pattern selection + tech decisions + the system-design workflows) BEFORE the Phoenix-specific technical sub-steps." - "Does NOT replace architecture-phx: that skill owns the Phoenix bounded-context/Ecto/Oban/can?/3 policy mechanics and the verify gate; this skill informs the architectural choices that feed them."

このリポジトリの他の Skills

同じリポジトリ

docs-project-management

endorphin-ai/hasbrains-agent-kit

Universal, project-agnostic playbook for managing an ENTIRE project inside the repo's docs/ folder — the docs/-native system of record, reusable in any project, new or existing, with no external issue tracker. Defines WHAT it manages: the work-item TAXONOMY (Roadmap → docs/ROADMAP.md + docs/roadmap.json, PRD → docs/prd/, TRD → docs/trd/, Epic → docs/epics/, User Story → docs/user_stories/, Test Case → docs/test_cases/, Bug → docs/bugs/, per-session team reports → docs/sessions/, feature work-log → docs/reports/), the cross-document LINK GRAPH written as relative-markdown links (User Story part-of Epic; Test Case is-tested-by User Story; Bug blocks its story; PRD↔TRD), the YAML-frontmatter STATUS lifecycle + the bookend rule (transition status: forward before starting work, again when done), required frontmatter fields, the mandatory Test Case Template and the Bug+RCA report format, the TEAM WORK-REPORTING convention (one session folder per run; every agent bookends a start/completion report there + appends to

2026-07-034

four-principles

endorphin-ai/hasbrains-agent-kit

Four always-on engineering principles for ALL work before, during, and after coding — Think Before Coding (surface assumptions/tradeoffs, never guess silently), Simplicity First (minimum code that solves it, nothing speculative), Surgical Changes (touch only what the request needs, every changed line traces to the ask), and Goal-Driven Execution (define verifiable success criteria, loop until verified). Use on EVERY task that writes, edits, refactors, or fixes code, designs an approach, or interprets a request — not just large features.

2026-07-034

test-driven-development

endorphin-ai/hasbrains-agent-kit

Use when implementing any feature or bugfix, in any language or framework, before writing implementation code — write the test first, watch it fail, then write minimal code to pass. Covers the red-green-refactor loop, test-quality principles, rationalization counters, and test-layer selection.

2026-07-034

soc-media-writer

endorphin-ai/hasbrains-agent-kit

Write high-performing social media content engineered around named copywriting frameworks, scroll-stopping hooks, and retention mechanics. For video it produces three coordinated outputs — the spoken DIALOGUE (voiceover), the VIDEO SCENARIO (timed two-column shot list with visual cues), and the EXPLANATION (notes on the frameworks, hook, and retention beats used) — plus standalone written posts for LinkedIn, X, Instagram, and YouTube. Use whenever the user wants a social post, a Reel/Short/TikTok script, a video scenario or shot list, a hook or hook bank, a content matrix, a Hub-and-Spoke repurposing plan, a VSL, or any short- or long-form distribution content. Trigger even on casual asks like "write me a Reel about X," "give me hooks for Y," "script a 30-second video," "make this go viral," "write a LinkedIn post," or "turn this into TikToks." Also trigger when the user wants retention engineered in (e.g. "keep them watching," "re-hook every N seconds," "high retention script").

2026-07-034

build-brain

endorphin-ai/hasbrains-agent-kit

Turn a skill or raw data into an AI-optimized "second brain" skill — a lean SKILL.md map backed by atomized, tagged references and JSON navigation maps. Analyzes the source, triple-checks, and writes a before/after improvement report.

2026-07-034

pipeline-state

endorphin-ai/hasbrains-agent-kit

Durable, file-backed pipeline handoff BUS for the WHOLE squad (all worker agents + el-capitan). Persists per-run variables, per-phase outputs, and `.ai_log/` evidence-PATH references to a PER-SESSION, git-ignored JSON file under `.ai_log/` (`.ai_log/session-<id>-<name>.json`, one per run) that survives context compression; cleans stale `.ai_log/` artifacts on init. On phase START, READ it to pull this phase's inputs (key fields + evidence paths); on phase COMPLETION, WRITE this phase's outputs (key result fields + `.ai_log/` paths — never large inlined blobs). The standing pattern (R17): evidence -> `.ai_log/`; references + key fields -> pipeline-state; handoffs = state lookups, not inlined dumps. Coexists with the docs/ reports (R7/R8, the human record) + the `.ai_log/` offload (R15). Originally built for the e2e-test-healer; now squad-wide. Use for ANY cross-phase handoff.

2026-07-034

name

system-architecture

description

TASKLANG TYPE SKILL

IDENTITY "System Architecture"

General-purpose system-design knowledge for the planning step that comes BEFORE technology-specific mechanics: pick the right architecture PATTERN, make the load-bearing TECHNOLOGY decisions, and run the system-design WORKFLOWS (capacity, API, schema, scalability, migration). This skill is a lean MAP — the substance lives in three reference docs under references/. Read the map, then open the one reference that matches the question.