Stats
Actions
Tags
'%20stop-opacity%3D'0.16'%2F%3E%3Cstop%20offset%3D'1'%20stop-color%3D'rgb(200%2C90%2C60)'%20stop-opacity%3D'0.03'%2F%3E%3C%2FlinearGradient%3E%3C%2Fdefs%3E%3Crect%20width%3D'320'%20height%3D'200'%20fill%3D'url(%23g)'%2F%3E%3Ccircle%20cx%3D'250'%20cy%3D'56'%20r%3D'92'%20fill%3D'rgb(200%2C90%2C60)'%20fill-opacity%3D'0.06'%2F%3E%3Ccircle%20cx%3D'64'%20cy%3D'172'%20r%3D'58'%20fill%3D'rgb(200%2C90%2C60)'%20fill-opacity%3D'0.05'%2F%3E%3C%2Fsvg%3E)
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.
How this skill is triggered — by the user, by Claude, or both
Slash command
/adr:adr-decision-driversThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
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 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 resolutionsnpx claudepluginhub zircote-plugins/adrGuides completion of development work by verifying tests, detecting environment, and presenting structured options for merge, PR, or cleanup.
Guides creation and editing of skills using test-driven development with pressure scenarios and subagents to verify agent compliance.
Dispatches multiple subagents concurrently for independent tasks without shared state. Use when facing 2+ unrelated failures or subsystems that can be investigated in parallel.