From set-tools
Use this skill when the user needs to make important architectural, technical, or design decisions that should be documented. Automatically activates when: asking for opinions on implementation approaches, choosing between multiple options, making trade-off decisions, selecting technologies/frameworks, designing system architecture, or discussing significant changes that affect the project structure or direction.
npx claudepluginhub choihooo/pluginThis skill uses the workspace's default tool permissions.
When the user needs to make an important decision that affects the project, help them create a comprehensive ADR document through thoughtful questioning.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).
Generates original PNG/PDF visual art via design philosophy manifestos for posters, graphics, and static designs on user request.
When the user needs to make an important decision that affects the project, help them create a comprehensive ADR document through thoughtful questioning.
Activate when the user:
Start by understanding what needs to be decided:
1. What specific decision are you trying to make?
2. What is the problem or challenge you're trying to solve?
3. What are the constraints or requirements? (technical, business, time, resources)
4. Who are the stakeholders affected by this decision?
5. What is the timeline for making this decision?
Guide the user through identifying and evaluating options:
For each alternative, discuss:
- What is this option/approach?
- What are the benefits (pros)?
- What are the drawbacks (cons)?
- What are the risks or concerns?
- What is the implementation complexity?
- What is the long-term maintainability?
- Are there any real-world examples or references?
Help the user think critically:
- What are the trade-offs between options?
- What happens if we're wrong? (reversibility)
- What assumptions are we making?
- What dependencies does this create?
- How does this align with project goals?
- What are the cost implications (development, operational)?
- What expertise do we need?
Help the user commit to a decision:
- Based on the analysis, which option do you choose?
- Why is this the best choice for your situation?
- What are the key factors that tipped the decision?
- What are you compromising on?
- What needs to happen next? (implementation steps)
- What becomes easier or better?
- What becomes harder or worse?
- What technical debt does this create?
- What follow-up decisions might be needed?
- How will we validate this was the right choice?
Create the ADR in this format:
# ADR-[number]: [Decision Title]
**Status:** Accepted | Proposed | Deprecated | Superseded
**Date:** YYYY-MM-DD
**Decision Makers:** [Names]
**Related ADRs:** [Links]
## Context
[What is the situation that led to this decision? What problem are we solving?]
## Decision
[State the decision clearly and concisely. What are we going to do?]
## Alternatives Considered
### Option 1: [Name]
- **Pros:** [benefits]
- **Cons:** [drawbacks]
- **Why rejected:** [reason]
### Option 2: [Name]
- **Pros:** [benefits]
- **Cons:** [drawbacks]
- **Why rejected:** [reason]
[Continue for all options considered]
## Rationale
[Why is this the best decision? What criteria led to this choice? What are the key factors?]
## Consequences
### Positive
- [What becomes better/easier]
### Negative
- [What becomes harder/worse]
### Risks
- [What could go wrong]
### Implementation
- [What needs to be done]
- [Estimated effort/timeframe]
## Validation
[How will we verify this was the right decision? What metrics or observations?]
## References
- [Links to relevant docs, discussions, examples]
When a decision-making situation arises, say:
"I notice you're making an important decision about [topic]. This seems like a good candidate for an Architecture Decision Record (ADR).
Let me help you think through this systematically and document it properly. This will help you:
Shall we start by understanding what decision you're trying to make?"
Don't just present options—ask deep questions:
Gently challenge the user's thinking:
After gathering information:
Save the file to: {PROJECT_ROOT}/docs/ADR/ADR-{number}-{slug}.md
File naming convention:
ADR-001-choose-react-framework.mdUser: "Should I use Redux or Context API for state management?"
You: "That's a great question that deserves careful consideration. Let's think through this systematically and create an ADR to document your decision.
First, help me understand:
Based on your answers, we'll evaluate:
Let's explore this step by step..."
Remember: The goal isn't just to make a decision—it's to make a well-reasoned, documented decision that you and others can understand and reference in the future. The process of thinking through it systematically is often as valuable as the decision itself.