home / skills / shotaiuchi / dotclaude / design-pragmatist

design-pragmatist skill

safe

This skill helps evaluate design proposals for real-world feasibility, team capability, timelines, maintenance cost, and proven patterns to ensure practical

npx playbooks add skill shotaiuchi/dotclaude --skill design-pragmatist

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

2.0 KB

---
name: design-pragmatist
description: >-
  Practical design analysis. Apply when evaluating design proposals for
  real-world feasibility, team capabilities, implementation timeline,
  maintenance cost, and proven solution patterns.
user-invocable: false
---

# Pragmatist Perspective

Evaluate design proposals from a practical, real-world feasibility standpoint.

## Analysis Checklist

### Feasibility Assessment
- Verify the proposal can be implemented with available tools and frameworks
- Check that assumptions about infrastructure and services are realistic
- Identify any dependencies on unproven or immature technologies
- Assess whether the proposed timeline accounts for integration complexity
- Confirm that prototyping or proof-of-concept has validated risky areas

### Team & Timeline Fit
- Check that required skills exist within the current team
- Assess whether the learning curve is acceptable for the project timeline
- Verify that staffing and resource allocation supports the proposal
- Look for opportunities to parallelize work across team members

### Maintenance Burden
- Evaluate long-term operational complexity of the proposed design
- Check that debugging and troubleshooting paths are straightforward
- Verify that monitoring, logging, and alerting are accounted for
- Assess documentation requirements for knowledge transfer

### Proven Patterns
- Verify the design leverages well-established patterns over novel approaches
- Check for existing internal solutions that could be reused or extended
- Look for unnecessary reinvention where off-the-shelf solutions exist
- Assess whether deviations from standard patterns are justified

## Output Format

Report findings with strength ratings:

| Strength | Description |
|----------|-------------|
| Strong | Highly practical, proven approach with low risk |
| Moderate | Feasible with some concerns or trade-offs to manage |
| Weak | Significant feasibility risks or unrealistic assumptions |
| Neutral | Insufficient information to assess practicality |

Overview

This skill provides practical design analysis focused on real-world feasibility, team fit, timeline realism, maintenance cost, and use of proven solution patterns. It helps decision-makers and engineers surface implementation risks and actionable mitigations. The output grades proposals with clear strength ratings to guide go/no-go and next-step planning.

How this skill works

The skill inspects a design proposal against a checklist: feasibility with available tools, realism of infrastructure assumptions, team capabilities and staffing, timeline and integration complexity, maintenance burden, and adherence to proven patterns. It identifies risky assumptions, dependency concerns, and opportunities to reuse existing solutions, then assigns a strength rating: Strong, Moderate, Weak, or Neutral. Recommendations include concrete mitigation steps, prototyping focuses, and documentation or monitoring needs.

When to use it

Evaluating architecture decisions before committing significant resources
Reviewing vendor solutions or new technologies for production readiness
Assessing proposals that require cross-team coordination or hiring
Prioritizing work that impacts long-term maintenance and operational cost
Deciding between building custom features versus buying or reusing

Best practices

Validate risky areas with a time-boxed prototype or proof-of-concept
Map required skills and confirm team capacity before scheduling work
Prefer well-established patterns unless a clear, documented benefit exists
Factor operational needs (monitoring, debugging, updates) into initial design
Document assumptions, dependencies, and rollback criteria early

Example use cases

Reviewing a microservices split to verify deployment and monitoring readiness
Assessing adoption of a new database or queue technology for production use
Deciding whether to rewrite a legacy module or extend the current system
Estimating realistic timelines when introducing unfamiliar frameworks
Comparing build-vs-buy options for a third-party authentication provider

FAQ

What does each strength rating mean?

Strong means low risk and proven approach; Moderate indicates manageable trade-offs; Weak flags major feasibility risks; Neutral means missing information prevents assessment.

How detailed should the prototype be?

Keep prototypes focused on the riskiest integrations or performance assumptions and limit scope to deliver quick, informative results within a few days to a few weeks.