重要前提
安装AI Skills的关键前提是:必须科学上网,且开启TUN模式,这一点至关重要,直接决定安装能否顺利完成,在此郑重提醒三遍:科学上网,科学上网,科学上网。查看完整安装教程 →
scope-appropriate-architecture by yonatangross/orchestkit
npx skills add https://github.com/yonatangross/orchestkit --skill scope-appropriate-architecture根据项目的实际需求,为每个架构决策选择恰当的规模。并非每个项目都需要六边形架构、CQRS 或微服务。
核心原则: 首先检测项目层级,然后将所有后续的模式选择限制在该层级的复杂度上限内。
| 层级 | LOC 比率 | 架构 | 数据库 | 认证 | 测试 |
|---|---|---|---|---|---|
| 1. 面试/带回家项目 | 1.0-1.3x | 扁平文件,无分层 | SQLite / JSON | 无或基础 | 8-15 个聚焦测试 |
| 2. 黑客松/原型 | 0.8-1.0x | 尽可能单文件 | SQLite / 内存数据库 | 无 | 零 |
| 3. 初创公司/MVP | 1.0-1.5x | MVC 单体应用 | 托管 Postgres | Clerk/Supabase Auth |
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
| 快乐路径 + 关键路径 |
| 4. 成长期 | 1.5-2.0x | 模块化单体应用 | Postgres + Redis | 认证服务 | 单元 + 集成 |
| 5. 企业级 | 2.0-3.0x | 六边形/DDD | Postgres + 消息队列 | OAuth2/SAML | 完整金字塔 |
| 6. 开源项目 | 1.2-1.8x | 最小化 API 接口 | 可配置 | 可选 | 详尽的公共 API |
LOC 比率 = 总代码行数 / 核心业务逻辑行数。比率越高,意味着相对于业务价值的基础设施代码越多。
| 信号 | 层级指示器 |
|---|---|
| README 包含"带回家"、"作业"、"面试" | 层级 1 |
| 提及时间限制(例如,"4小时"、"周末") | 层级 1-2 |
| < 10 个文件,无 CI,无 Docker | 层级 1-2 |
存在 .github/workflows/ 目录 | 层级 3+ |
package.json 包含 20+ 依赖项 | 层级 3+ |
| 存在 Kubernetes/Terraform 文件 | 层级 4-5 |
存在 CONTRIBUTING.md、CODE_OF_CONDUCT.md | 层级 6 |
包含 packages/ 或 apps/ 目录的单体仓库 | 层级 4-5 |
当置信度较低时: 使用 AskUserQuestion 询问用户。
| 模式 | 面试 | 黑客松 | MVP | 成长期 | 企业级 |
|---|---|---|---|---|---|
| 仓储模式 | 过度设计 | 过度设计 | 临界 | 适用 | 必需 |
| 事件驱动架构 | 过度设计 | 过度设计 | 过度设计 | 选择性 | 适用 |
| 依赖注入容器 | 过度设计 | 过度设计 | 轻量级 | 适用 | 必需 |
| 独立的 DTO 层 | 过度设计 | 过度设计 | 1 个额外层 | 2 个层 | 所有层 |
| 微服务 | 绝不 | 绝不 | 绝不 | 仅提取 | 适用 |
| CQRS | 过度设计 | 过度设计 | 过度设计 | 过度设计 | 有理由时 |
| 六边形架构 | 过度设计 | 过度设计 | 过度设计 | 临界 | 适用 |
| DDD(限界上下文) | 过度设计 | 过度设计 | 过度设计 | 选择性 | 适用 |
| 消息队列 | 过度设计 | 过度设计 | 临界 | 适用 | 必需 |
| API 版本控制 | 跳过 | 跳过 | URL 前缀 | 基于头部 | 完整策略 |
| 错误处理 | try/catch | console.log | 错误边界 | 错误服务 | RFC 9457 |
| 日志记录 | console.log | 无 | 结构化 JSON | 集中式 | OpenTelemetry |
经验法则: 如果一个模式在检测到的层级显示为"过度设计",则不要使用它。建议使用更简单的替代方案。
| 选择 | 面试 | 黑客松 | MVP | 成长期 | 企业级 |
|---|---|---|---|---|---|
| 数据库 | SQLite / JSON 文件 | 内存 / SQLite | 托管 Postgres | Postgres + Redis | Postgres + 消息队列 + 缓存 |
| 认证 | 硬编码 / 无 | 无 | Clerk / Supabase Auth | 认证服务 | OAuth2 / SAML / SSO |
| 状态管理 | useState | useState | Zustand / Context | Zustand + React Query | Redux / 自定义 + 缓存 |
| CSS | 内联 / Tailwind | Tailwind | Tailwind | Tailwind + 设计令牌 | 设计系统 |
| API | Express 路由 | 单文件处理器 | Next.js API 路由 | FastAPI / Express | 网关 + 服务 |
| 部署 | localhost | Vercel / Railway | Vercel / Railway | Docker + 托管 | K8s / ECS |
| CI/CD | 无 | 无 | GitHub Actions 基础版 | 多阶段流水线 | 完整流水线 + 门控 |
| 监控 | 无 | 无 | 仅错误追踪 | APM + 日志 | 完整的可观测性栈 |
对于面试、黑客松和 MVP 层级,始终优先购买而非自建:
| 能力 | 购买(使用 SaaS) | 自建(仅在以下情况) |
|---|---|---|
| 认证 | Clerk, Supabase Auth, Auth0 | 核心产品就是认证 |
| 支付 | Stripe | 核心产品就是支付 |
| 邮件 | Resend, SendGrid | 核心产品就是邮件 |
| 文件存储 | S3, Cloudflare R2 | 合规性要求本地部署 |
| 搜索 | Algolia, Typesense Cloud | > 1000 万文档或自定义排名 |
| 分析 | PostHog, Mixpanel | 独特的数据需求 |
节省时间: 仅认证一项,自建需要 2-4 周,而集成只需 2 小时。
当项目增长超出当前层级时,逐步升级:
Tier 2 (Prototype) → Tier 3 (MVP)
添加:Postgres、基础认证、错误边界、CI
Tier 3 (MVP) → Tier 4 (Growth)
添加:Redis 缓存、后台任务、监控、模块边界
Tier 4 (Growth) → Tier 5 (Enterprise)
添加:DI、限界上下文、消息队列、完整的可观测性
提取:第一个微服务(仅针对已证实的瓶颈)
关键见解: 你总是可以在以后增加复杂度。但很难轻易地移除它。
此技能在以下情况加载:
brainstorm 阶段 0(上下文发现)implement 步骤 0(上下文发现)quality-gates YAGNI 检查检测到的层级将作为上下文传递,以限制后续决策。
ork:brainstorm - 在阶段 0 使用层级检测来约束想法ork:implement - 在步骤 0 使用层级检测来约束架构ork:quality-gates - YAGNI 门控参考此技能的层级矩阵ork:architecture-patterns - 架构验证(受层级约束)使用 Read("${CLAUDE_SKILL_DIR}/references/<file>") 按需加载:
| 文件 | 内容 |
|---|---|
interview-takehome.md | 层级 1-2 详情 |
startup-mvp.md | 层级 3 模式和决策 |
enterprise.md | 层级 4-5 模式和合理性标准 |
open-source.md | 层级 6 的独特考虑因素 |
每周安装次数
71
仓库
GitHub 星标数
132
首次出现
Feb 14, 2026
安全审计
安装于
gemini-cli69
opencode68
github-copilot68
codex67
cursor65
kimi-cli64
Right-size every architectural decision to the project's actual needs. Not every project needs hexagonal architecture, CQRS, or microservices.
Core principle: Detect the project tier first, then constrain all downstream pattern choices to that tier's complexity ceiling.
| Tier | LOC Ratio | Architecture | DB | Auth | Tests |
|---|---|---|---|---|---|
| 1. Interview/Take-home | 1.0-1.3x | Flat files, no layers | SQLite / JSON | None or basic | 8-15 focused |
| 2. Hackathon/Prototype | 0.8-1.0x | Single file if possible | SQLite / in-memory | None | Zero |
| 3. Startup/MVP | 1.0-1.5x | MVC monolith | Managed Postgres | Clerk/Supabase Auth | Happy path + critical |
| 4. Growth-stage | 1.5-2.0x | Modular monolith | Postgres + Redis | Auth service | Unit + integration |
| 5. Enterprise | 2.0-3.0x | Hexagonal/DDD | Postgres + queues | OAuth2/SAML | Full pyramid |
| 6. Open Source | 1.2-1.8x | Minimal API surface | Configurable | Optional | Exhaustive public API |
LOC Ratio = total lines / core business logic lines. Higher ratio = more infrastructure code relative to business value.
| Signal | Tier Indicator |
|---|---|
| README contains "take-home", "assignment", "interview" | Tier 1 |
| Time limit mentioned (e.g., "4 hours", "weekend") | Tier 1-2 |
| < 10 files, no CI, no Docker | Tier 1-2 |
.github/workflows/ present | Tier 3+ |
package.json with 20+ dependencies | Tier 3+ |
| Kubernetes/Terraform files present | Tier 4-5 |
CONTRIBUTING.md, CODE_OF_CONDUCT.md | Tier 6 |
Monorepo with packages/ or |
When confidence is low: Ask the user with AskUserQuestion.
| Pattern | Interview | Hackathon | MVP | Growth | Enterprise |
|---|---|---|---|---|---|
| Repository pattern | OVERKILL | OVERKILL | BORDERLINE | APPROPRIATE | REQUIRED |
| Event-driven arch | OVERKILL | OVERKILL | OVERKILL | SELECTIVE | APPROPRIATE |
| DI containers | OVERKILL | OVERKILL | LIGHT ONLY | APPROPRIATE | REQUIRED |
| Separate DTO layers | OVERKILL | OVERKILL | 1 EXTRA | 2 LAYERS | ALL LAYERS |
| Microservices | NEVER | NEVER |
Rule of thumb: If a pattern shows OVERKILL for the detected tier, do NOT use it. Suggest the simpler alternative instead.
| Choice | Interview | Hackathon | MVP | Growth | Enterprise |
|---|---|---|---|---|---|
| Database | SQLite / JSON file | In-memory / SQLite | Managed Postgres | Postgres + Redis | Postgres + queues + cache |
| Auth | Hardcoded / none | None | Clerk / Supabase Auth | Auth service | OAuth2 / SAML / SSO |
| State mgmt | useState | useState | Zustand / Context | Zustand + React Query | Redux / custom + cache |
| CSS | Inline / Tailwind | Tailwind | Tailwind | Tailwind + design tokens |
For Interview, Hackathon, and MVP tiers, always prefer buying over building :
| Capability | BUY (use SaaS) | BUILD (only if) |
|---|---|---|
| Auth | Clerk, Supabase Auth, Auth0 | Core product IS auth |
| Payments | Stripe | Core product IS payments |
| Resend, SendGrid | Core product IS email | |
| File storage | S3, Cloudflare R2 | Compliance requires on-prem |
| Search | Algolia, Typesense Cloud | > 10M docs or custom ranking |
| Analytics | PostHog, Mixpanel | Unique data requirements |
Time savings: Auth alone is 2-4 weeks build vs 2 hours integrate.
When a project grows beyond its current tier, upgrade incrementally:
Tier 2 (Prototype) → Tier 3 (MVP)
Add: Postgres, basic auth, error boundaries, CI
Tier 3 (MVP) → Tier 4 (Growth)
Add: Redis cache, background jobs, monitoring, module boundaries
Tier 4 (Growth) → Tier 5 (Enterprise)
Add: DI, bounded contexts, message queues, full observability
Extract: First microservice (only the proven bottleneck)
Key insight: You can always add complexity later. You cannot easily remove it.
This skill is loaded by:
brainstorm Phase 0 (context discovery)implement Step 0 (context discovery)quality-gates YAGNI checkThe detected tier is passed as context to constrain downstream decisions.
ork:brainstorm - Uses tier detection in Phase 0 to constrain ideasork:implement - Uses tier detection in Step 0 to constrain architectureork:quality-gates - YAGNI gate references this skill's tier matrixork:architecture-patterns - Architecture validation (constrained by tier)Load on demand with Read("${CLAUDE_SKILL_DIR}/references/<file>"):
| File | Content |
|---|---|
interview-takehome.md | Tiers 1-2 in detail |
startup-mvp.md | Tier 3 patterns and decisions |
enterprise.md | Tiers 4-5 patterns and justification criteria |
open-source.md | Tier 6 unique considerations |
Weekly Installs
71
Repository
GitHub Stars
132
First Seen
Feb 14, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykWarn
Installed on
gemini-cli69
opencode68
github-copilot68
codex67
cursor65
kimi-cli64
React 组合模式指南:Vercel 组件架构最佳实践,提升代码可维护性
122,000 周安装
apps/| Tier 4-5 |
| NEVER |
| EXTRACT ONLY |
| APPROPRIATE |
| CQRS | OVERKILL | OVERKILL | OVERKILL | OVERKILL | WHEN JUSTIFIED |
| Hexagonal architecture | OVERKILL | OVERKILL | OVERKILL | BORDERLINE | APPROPRIATE |
| DDD (bounded contexts) | OVERKILL | OVERKILL | OVERKILL | SELECTIVE | APPROPRIATE |
| Message queues | OVERKILL | OVERKILL | BORDERLINE | APPROPRIATE | REQUIRED |
| API versioning | SKIP | SKIP | URL prefix | Header-based | Full strategy |
| Error handling | try/catch | console.log | Error boundary | Error service | RFC 9457 |
| Logging | console.log | none | Structured JSON | Centralized | OpenTelemetry |
| Design system |
| API | Express routes | Single file handler | Next.js API routes | FastAPI / Express | Gateway + services |
| Deployment | localhost | Vercel / Railway | Vercel / Railway | Docker + managed | K8s / ECS |
| CI/CD | None | None | GitHub Actions basic | Multi-stage pipeline | Full pipeline + gates |
| Monitoring | None | None | Error tracking only | APM + logs | Full observability stack |