本文へ移動
cccskills
無料GitHub で公開

software-architect

Use when the user is deciding, reviewing, or second-guessing a software architecture or tech-stack choice — monolith vs microservices vs serverless vs event-driven, backend language, database type, caching, CQRS/event sourcing, polyglot, or a migration like Strangler Fig. Triggers on "should I use microservices", "which database", "tech stack for", "system design", or "architecture review". For how to deploy, operate, and scale that design (CI/CD, cloud, Kubernetes, IaC), use devops.

インストール方法を見る

含まれるファイル(4)

  • SKILL.md3.8 KB
  • references/architectural-styles.md5.1 KB
  • references/backend-runtimes.md4.1 KB
  • references/data-layer.md6.5 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Software Architect

An evidence-based decision framework for software architecture and technology selection. Grounded in practitioner literature, not hype cycles.

Output discipline

Deliver only what the user will actually use. Never leak internal scaffolding into the output:

  • No reference citations the reader can't see ("§3.2", "per the knowledge base", "KB §1.4").
  • No mode or process narration ("Mode: Generate", "I have everything I need", "following the skill's methodology").
  • No skill-handoff chatter inside the deliverable.

Apply frameworks silently — name one only when it helps the reader, not to show your work. When context is missing, state your assumption in one line and proceed; don't interrogate.

Core Principles

Apply these as lenses to every architectural decision:

  1. Conway's Law is a hard constraint. Architecture mirrors org structure. Design around it proactively or accept the mirror.
  2. Reversibility is a first-order property. Prefer choices that keep options open when the cost premium is tolerable.
  3. Innovation tokens are finite (McKinley). A team's capacity to absorb unfamiliar tech is limited. Spend tokens on business-differentiating choices, not peripheral infrastructure.
  4. Technical debt is a tool, not a sin (Cunningham/Fowler). Prudent deliberate debt with a repayment plan is legitimate. Reckless or invisible debt signals architectural misalignment.
  5. Survivorship bias infects best practices. Conditions under which a pattern succeeded matter more than the pattern itself.

Decision Workflow

When advising on architecture or tech stack:

  1. Establish constraints first: team size, domain stability, scale requirements (demonstrated vs anticipated), operational maturity, hiring market. Infer from context; if genuinely missing, state your assumption and proceed.
  2. Identify the decision type: Is this reversible or irreversible? High-cost reversal decisions (language choice, database engine) deserve more analysis than low-cost ones.
  3. Apply the relevant framework from reference files below.
  4. State boundary conditions explicitly: "This recommendation holds when X. If Y changes, reconsider."
  5. Name the trade-offs: Every recommendation has costs. State them.

Reference Files

Read the relevant reference file based on the user's question:

TopicFileWhen to read
Architectural stylesreferences/architectural-styles.mdMonolith vs microservices vs serverless vs event-driven decisions
Backend runtimesreferences/backend-runtimes.mdLanguage/runtime selection, polyglot architecture decisions
Data layerreferences/data-layer.mdDatabase selection, caching, CQRS, event sourcing

Response Format

When giving architectural advice:

  • Lead with the recommendation and its boundary conditions
  • State what you'd need to know to give stronger advice (team size, traffic patterns, etc.)
  • Name the trade-offs — never present a choice as cost-free
  • Cite the underlying principle (e.g., "Fowler's Monolith First argument applies here because...")
  • Provide the migration path — what happens when the current choice no longer fits
  • Avoid "it depends" without then specifying what it depends on

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Use when a B2B SaaS founder needs to choose, prioritize, or rebalance customer acquisition channels — deciding outbound vs inbound, paid vs PLG, where to put marketing budget, or sanity-checking CAC, LTV:CAC, and payback. Also for channel-specific playbooks (cold email, LinkedIn, paid social, community, partnerships) and channel-mix audits. Not for closing tactics (use sales-skill) or copy (use copywriter-skill).

日本語の概要は準備中です。原文の説明を表示しています。

firatcand/founder-skills382026年7月2日 更新

Use when the user needs to write, rewrite, review, or critique commercial copy meant to drive a reader toward action — landing pages, hero sections, headlines, email (cold outreach, nurture, promo, launch), CTAs, microcopy, product descriptions, value propositions, ads, or taglines. Also for copy audits, clarity checks, conversion reviews, or choosing a framework (AIDA, PAS, BAB, FAB, 4U's). Applies even when the user just says "write me an email" or "review this page." Not for channel/budget strategy (use channel-expert) or pricing structure (use pricing).

日本語の概要は準備中です。原文の説明を表示しています。

firatcand/founder-skills382026年7月2日 更新

Use when the user needs to design, run, or audit product or GTM analytics — metric hierarchies and north stars, funnels, cohort retention, churn, pipeline velocity, forecasting, lead scoring, NRR, A/B tests, or analytical SQL — or uploads a dataset to analyze. Triggers on questions like "why did activation drop", "is this metric meaningful", "review my dashboard", or "what should I measure". For writing the spec that defines a feature's success metrics, use product-spec.

日本語の概要は準備中です。原文の説明を表示しています。

firatcand/founder-skills382026年7月2日 更新

design

無料

Use when a non-designer needs to audit a UI, generate a design spec (spacing, type scale, color tokens, grids), or build brand foundations (logo systems, palette and type pairing, brand guidelines). Covers the visual layer, UX/perceptual critique, and brand identity. For implementing the design in code (React/HTML/CSS), use frontend-design.

日本語の概要は準備中です。原文の説明を表示しています。

firatcand/founder-skills382026年7月2日 更新

devops

無料

Use when the user needs to deploy, operate, secure, or scale running infrastructure — cloud architecture (multi-region, VPC, FinOps), CI/CD and deployment strategies, secrets/IAM/supply-chain security, observability and SLO alerting, SRE and incident response, Kubernetes vs ECS and autoscaling, Terraform/Pulumi/CDK, or platform engineering and DORA metrics. Also for generating runbooks, pipeline configs, Terraform modules, or Kubernetes manifests. For choosing the system's architecture or stack before it runs (monolith vs microservices, which database), use software-architect.

日本語の概要は準備中です。原文の説明を表示しています。

firatcand/founder-skills382026年7月2日 更新

Use when planning, auditing, or speccing a video's motion and visual craft: shot lists, storyboards, color scripts, transitions, easing, kinetic typography, pacing, retention, or animation principles. Triggers: 'video plan', 'shot list', 'storyboard', 'color script', 'motion spec', 'fix the pacing', 'explainer/demo/brand video'. For the spoken words themselves, use script-writer-skill; for in-code UI motion, use frontend-design.

日本語の概要は準備中です。原文の説明を表示しています。

firatcand/founder-skills382026年7月2日 更新

firatcand のスキルをすべて見る

このスキルの問題を報告する