| name | sdframe |
| description | Software design framework knowledge base with 317 curated frameworks across 13 categories. Use this skill when users need to: select frameworks for a project, compare architectural approaches, implement a specific design pattern, or find best practices for reliability, security, performance, maintainability, and other quality concerns. Trigger on: architecture decisions, design patterns, system design, best practices, framework selection, "how should I structure this", technical debt, refactoring strategies, "what pattern should I use", code organization, API design.
|
SDFrame โ Software Design Framework Skill
317 curated frameworks for software engineers, architects, and AI agents.
Bilingual (EN/ZH), 13 categories. Source: https://sdframe.caldis.me/
Two Modes of Operation
Determine which mode based on user intent:
Mode A: Framework Selection
User is unsure what to use. They say things like "help me choose an architecture",
"what patterns should I use for X", "best practices for building Y".
Phase 1 โ Identify the decision. What is the user actually deciding?
Common decision points (if the user's question maps to one, skip to Phase 2
with the alternatives pre-loaded):
| Decision | Alternatives (pick one) |
|---|
| UI architecture? | mvc, mvvm, mvp, flux-unidirectional |
| System layering? | clean-architecture, hexagonal-architecture, onion-architecture, n-tier-layered, ports-and-adapters |
| Data access? | active-record-pattern, repository-pattern, data-mapper-pattern |
| Data pipeline? | lambda-architecture, kappa-architecture |
| Testing approach? | tdd, bdd |
| Test shape? | test-pyramid, testing-trophy |
| Monitoring method? | four-golden-signals, red-method, use-method |
| Release strategy? | blue-green-deployment, canary-deployment |
| Team organization? | team-topologies, spotify-model, amazon-two-pizza-teams |
If the decision is clear, go directly to Phase 3 with the alternatives.
If the decision is NOT clear, clarify with these questions (one at a time):
- Describe your system in 1-2 sentences. What does it do?
- What quality attributes matter most?
Options: reliability, security, performance, maintainability, scalability, usability, testability, observability, portability
- What abstraction level are you working at?
Options: code, component, system, organization
- Team experience level? Options: beginner, intermediate, advanced
- Project stage? Options: greenfield, evolving, legacy migration
Phase 2 โ Search. Read references/catalog.md from this skill.
Filter candidates by the user's answers. Narrow to 5-8 matches.
If you need more context on a category, read references/categories/{key}.md.
Phase 3 โ Evaluate. Read top 3 candidates from
references/frameworks/{slug}.md. Compare:
- "When to Use" vs user's described context
- "When NOT to Use" vs user's constraints
- Complexity vs team's experience level
Phase 4 โ Recommend. Present 2-3 frameworks with:
Mode B: Framework Application
User has already decided. They say things like "teach me DDD",
"how do I implement CQRS in my project", "apply clean architecture here".
- Identify the framework slug. Read
references/frameworks/{slug}.md
- Follow the "Before You Start" section โ ask the user context questions
- Walk through Implementation Steps one by one, adapting to the user's codebase
- Reference Do's and Don'ts as guardrails throughout
- When done, suggest Related Frameworks for complementary practices
API and Agent Integration
Machine-readable entry points:
Authentication: none. The API is public and read-only.
Error handling:
- Validate slugs against
api/frameworks.index.json before fetching a detail
JSON file.
- If a static endpoint returns 404, do not retry the same unknown slug. Search
the index and ask the user to clarify.
- For transient CDN or host errors, retry after 5 seconds, 30 seconds, and 2
minutes, then report the failure with the URL.
- Cache successful responses during one task. Avoid repeatedly downloading the
full dataset if the compact index is enough.
Dimensions for Filtering
Quality Concerns
reliability, security, performance, maintainability, scalability, usability, testability, observability, portability
Abstraction Levels
- code: single module or function level
- component: service or package boundary
- system: multi-service or full system
- organization: cross-team or organizational
Complexity
- beginner: straightforward to adopt, low learning curve
- intermediate: requires some experience, moderate learning curve
- advanced: significant expertise needed, steep learning curve
Maturity
foundational, established, emerging, experimental
Categories
thinking (23) | Design Thinking | ่ฎพ่ฎกๆ่
Mental models, philosophies, and thinking tools for approaching software design problems.
architecture (31) | Architecture Decisions | ๆถๆๅณ็ญ
Making and documenting architectural decisions โ choosing patterns, evaluating trade-offs.
coding (46) | Coding Practices | ็ผ็ ๅฎ่ทต
Implementation-level design โ structuring code, managing complexity, writing maintainable software.
quality (25) | Quality Engineering | ่ดจ้ไฟ้
Testing strategies, reliability patterns, observability, and verification approaches.
deployment (20) | Deployment & Operations | ้จ็ฝฒ่ฟ็ปด
Deploying, operating, and running software systems in production.
evolution (21) | Evolution & Iteration | ๆผ่ฟ่ฟญไปฃ
How software evolves โ refactoring, tech debt, migration, team scaling.
ai (25) | AI Collaboration | AI ๅไฝ
Frameworks for the AI Agent era โ human-AI collaboration, agent architecture, LLM application design.
data (20) | Data Architecture | ๆฐๆฎๆถๆ
Patterns for data-intensive systems โ storage, processing, streaming, and data modeling.
security (21) | Security & Privacy | ๅฎๅ
จไธ้็ง
Threat modeling, secure design, privacy patterns, and zero-trust architectures.
distributed (22) | Distributed Systems | ๅๅธๅผ็ณป็ป
Patterns for building reliable, scalable systems across multiple nodes.
api (21) | API Design & Integration | API ่ฎพ่ฎกไธ้ๆ
Designing, versioning, and integrating APIs across service boundaries.
team (21) | Team & Organization | ๅข้ไธ็ป็ป
How team structure and organizational design shape software architecture.
observability (21) | Observability & DX | ๅฏ่งๆตๆงไธๅผๅ่
ไฝ้ช
Understanding system behavior through logging, tracing, metrics, and developer tooling.