From adr
This skill should be used when the user asks about "decision drivers", "architectural forces", "quality attributes", "how to identify trade-offs", "non-functional requirements for ADRs", or needs help identifying, documenting, and weighing the forces that influence architectural decisions.
npx claudepluginhub zircote/adrThis skill uses the workspace's default tool permissions.
Decision drivers are the forces, concerns, and requirements that influence architectural decisions. Identifying and documenting these drivers clearly is essential for creating ADRs that explain not just what was decided, but why.
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Uses ctx7 CLI to fetch current library docs, manage AI coding skills (install/search/generate), and configure Context7 MCP for AI editors.
Decision drivers are the forces, concerns, and requirements that influence architectural decisions. Identifying and documenting these drivers clearly is essential for creating ADRs that explain not just what was decided, but why.
Decision drivers are factors that:
| Category | Description | Examples |
|---|---|---|
| Functional | What the system must do | Features, capabilities, integrations |
| Quality Attributes | How well system must perform | Performance, security, reliability |
| Constraints | Fixed limitations | Budget, timeline, technology mandates |
| Business | Organizational factors | Cost, time-to-market, compliance |
| Technical | Engineering considerations | Maintainability, testability, complexity |
| Team | Human factors | Skills, capacity, preferences |
Ask these questions to uncover drivers:
Functional Drivers
Quality Attribute Drivers
Constraint Drivers
Business Drivers
Technical Drivers
Team Drivers
| Attribute | Definition | Measures |
|---|---|---|
| Performance | Response time, throughput | Latency (ms), requests/sec |
| Scalability | Handle increased load | Concurrent users, data volume |
| Availability | System uptime | Percentage uptime, MTBF |
| Reliability | Correct operation | Error rate, MTTR |
| Security | Protection from threats | Vulnerabilities, compliance |
| Maintainability | Ease of changes | Change effort, code complexity |
| Testability | Ease of testing | Test coverage, test time |
| Usability | User experience | Task completion time, errors |
| Attribute | Definition | Measures |
|---|---|---|
| Portability | Run on different platforms | Platform support, migration effort |
| Interoperability | Work with other systems | Integration points, standards |
| Modifiability | Support changes | Change impact, coupling |
| Observability | Monitor system state | Metrics, logs, traces |
| Deployability | Ease of deployment | Deployment frequency, time |
| Recoverability | Recovery from failure | RTO, RPO |
## Decision Drivers
* **{Driver Name}** - {Brief description of the driver and why it matters}
* **{Driver Name}** - {Brief description}
## Decision Drivers
* **High availability required** - System must maintain 99.9% uptime as per SLA
* **Limited budget** - Total solution cost must not exceed $50K/year
* **Team lacks Kubernetes expertise** - Any container orchestration must be learnable quickly
* **Compliance with GDPR** - User data must be stored in EU region
* **Sub-100ms response time** - API latency critical for user experience
## Decision Drivers
* Performance
* Cost
* Easy to use
Problems: Too vague, no specifics, no prioritization
| Priority | Meaning | Treatment |
|---|---|---|
| Must | Non-negotiable | Solution must satisfy |
| Should | Important | Satisfy if possible |
| Could | Nice to have | Include if easy |
| Won't | Out of scope | Explicitly excluded |
List drivers in order of importance:
Assign weights to drivers:
| Driver | Weight (1-5) |
|---|---|
| Availability | 5 |
| Performance | 4 |
| Cost | 3 |
| Maintainability | 2 |
Common quality attribute trade-offs:
| Trade-off | Description |
|---|---|
| Performance vs Maintainability | Optimized code harder to maintain |
| Security vs Usability | More security often means more friction |
| Scalability vs Cost | Scaling often increases infrastructure cost |
| Flexibility vs Simplicity | Configurable systems are more complex |
| Speed vs Quality | Faster delivery may reduce quality |
### Trade-offs Accepted
We accept:
- **Higher infrastructure cost** for improved availability
- **Increased complexity** for better extensibility
- **Longer initial development** for lower maintenance burden
| Option | Driver 1 | Driver 2 | Driver 3 | Score |
|---|---|---|---|---|
| Option A | ++ | + | - | 4 |
| Option B | + | ++ | + | 5 |
| Option C | - | + | ++ | 4 |
Scoring: ++ (2), + (1), 0 (0), - (-1), -- (-2)
For each option, evaluate against each driver:
### Option 1: PostgreSQL
* **High availability**: Good - supports replication, mature tooling
* **Limited budget**: Moderate - open source but requires expertise
* **Team expertise**: Good - team has SQL experience
Gather drivers from:
For comprehensive guidance on specific aspects:
references/quality-attributes.md - Detailed quality attribute definitionsreferences/trade-off-patterns.md - Common trade-off patterns and resolutions