メニュー
Design for scale while keeping implementation simple (KISS).
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/nguyenthienthanh/aura-frog --skill scalable-thinkingコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Vision feedback loop for UI — render the running UI, screenshot it across viewports + dark mode, run deterministic gates then a multimodal critique against the design system, and iterate until it passes. Use after building or changing a UI component/page, when asked to 'check the UI', make it 'look right', or verify a build matches a design spec / Stitch screen.
UI/UX design expertise — component design, design system selection, responsive layout. Includes auto-detection from package.json and Context7 integration for library docs.
Generate a cohesive color-token system from ONE OKLCH brand hue — primary/secondary/background/foreground/muted/border with semantic light + dark, emitted as a Tailwind v4 @theme block or a CSS-variables fallback. Use when starting a design system, defining brand colors, setting up theming/dark-mode, or replacing scattered hardcoded colors with a derived palette.
SKILL.md を表示中
SOC 職業分類に基づく
| name | scalable-thinking |
| description | Design for scale while keeping implementation simple (KISS). |
| autoInvoke | false |
| priority | high |
| triggers | ["architecture","API design","data modeling","database schema"] |
| user-invocable | false |
AI-consumed reference. Optimized for Claude to read during execution. Human-readable explanation: see docs/architecture/HIERARCHICAL_PLANNING.md or docs/getting-started/ depending on topic.
Principle: Think Scalable, Build Simple.
| Aspect | Scalable Thinking (WHAT) | KISS (HOW) |
|---|---|---|
| Data Model | Normalized, indexed | Simple queries |
| API | Versioned, RESTful | Standard CRUD |
| Code Structure | Feature-based | Flat hierarchy |
| Config | Centralized | Single file |
Separate related data into proper tables (not JSON strings). Enables querying, indexing, partitioning.
RESTful resource paths with versioning: /api/v1/users/:userId/processes. Cacheable, evolvable.
Normalized tables with foreign keys and indexes. Not JSON blobs that can't be filtered.
Feature-based: src/features/{feature}/{hooks,components,api}/ + src/shared/.
?limit=20&cursor=abc with { nextCursor, hasMore }AppError with code + statusCode| Anti-Pattern | Instead |
|---|---|
| Build for hypothetical 1M users | Simple monolith first |
| Pre-optimize with Redis | In-memory cache, add Redis when measured |
| Abstract for 1 use case | Direct impl, abstract at 2-3 examples |
| Microservices from day 1 | Monolith, split when team/features grow |
Before designing: Can model support 10x? Can I query needed data? Natural partition keys? API versioned? Pagination for lists?
During: Standard patterns? Simplest solution? Junior dev understandable? No abstractions until 3+ examples?
Add complexity when: DB queries > 2s, API p95 > 500ms, error rate > 1%, 10x growth in 3 months, team > 5. Until then: keep simple, measure everything.