feat: reorganize learning commands under /learn namespace
- Move quiz.md → learn/quiz.md (/learn:quiz) - Add learn/teach.md (/learn:teach) for step-by-step concept explanations - Add learn/alternatives.md (/learn:alternatives) for approach comparisons - Update all references in guide, README, and reference.yaml Follows Claude Code namespaced commands convention: /namespace:command → .claude/commands/namespace/command.md Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
Florian BRUNIAUX
parent
e7e1de7ad5
commit
dab11d260c
7 changed files with 400 additions and 19 deletions
192
examples/commands/learn/alternatives.md
Normal file
192
examples/commands/learn/alternatives.md
Normal file
|
|
@ -0,0 +1,192 @@
|
|||
# Show Alternatives
|
||||
|
||||
Compare different approaches to solve the same problem.
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/learn:alternatives # Compare approaches for current code
|
||||
/learn:alternatives auth # Compare authentication methods
|
||||
/learn:alternatives state # Compare state management options
|
||||
/learn:alternatives --detailed # Include code examples for each
|
||||
```
|
||||
|
||||
## Instructions
|
||||
|
||||
1. Identify the **problem being solved** (from context or argument)
|
||||
2. Present **3-5 alternative approaches**
|
||||
3. For each approach, explain:
|
||||
- What it is (one sentence)
|
||||
- When to use it
|
||||
- Trade-offs (pros/cons)
|
||||
4. Provide a **recommendation** based on context
|
||||
5. Optionally show code examples for top choices
|
||||
|
||||
## Response Format
|
||||
|
||||
```markdown
|
||||
## Problem: [What we're trying to solve]
|
||||
|
||||
### Approach 1: [Name]
|
||||
|
||||
**What**: [One-sentence description]
|
||||
|
||||
**When to use**:
|
||||
- [Scenario 1]
|
||||
- [Scenario 2]
|
||||
|
||||
**Pros**: [List]
|
||||
**Cons**: [List]
|
||||
|
||||
---
|
||||
|
||||
### Approach 2: [Name]
|
||||
...
|
||||
|
||||
---
|
||||
|
||||
## Comparison Table
|
||||
|
||||
| Criteria | Approach 1 | Approach 2 | Approach 3 |
|
||||
|----------|------------|------------|------------|
|
||||
| Complexity | Low | Medium | High |
|
||||
| Performance | ★★☆ | ★★★ | ★★☆ |
|
||||
| Bundle size | Small | Medium | Large |
|
||||
| Learning curve | Easy | Medium | Steep |
|
||||
|
||||
## Recommendation
|
||||
|
||||
**For your case**: [Recommended approach] because [reason based on context]
|
||||
|
||||
**Consider instead if**: [Alternative scenarios]
|
||||
```
|
||||
|
||||
## Comparison Criteria
|
||||
|
||||
Standard criteria to evaluate (adjust based on problem):
|
||||
|
||||
| Criteria | Description |
|
||||
|----------|-------------|
|
||||
| **Complexity** | How hard to implement and maintain |
|
||||
| **Performance** | Runtime speed, memory usage |
|
||||
| **Bundle size** | Impact on frontend bundle |
|
||||
| **Learning curve** | Time to understand and use correctly |
|
||||
| **Flexibility** | Ease of extending or modifying |
|
||||
| **Community** | Documentation, ecosystem, support |
|
||||
| **Testing** | How easy to test |
|
||||
| **Type safety** | TypeScript support quality |
|
||||
|
||||
## Depth Modes
|
||||
|
||||
### Default
|
||||
- 3-4 alternatives
|
||||
- Brief description each
|
||||
- Comparison table
|
||||
- Recommendation
|
||||
|
||||
### `--detailed`
|
||||
- 4-5 alternatives
|
||||
- Code example for each
|
||||
- Detailed trade-offs
|
||||
- Migration considerations
|
||||
- Real-world case studies
|
||||
|
||||
### `--quick`
|
||||
- 2-3 alternatives
|
||||
- One-line each
|
||||
- Quick recommendation
|
||||
|
||||
## Example Session
|
||||
|
||||
```
|
||||
User: I'm using useState for form state. /learn:alternatives
|
||||
|
||||
Claude: ## Problem: Managing Form State in React
|
||||
|
||||
### Approach 1: Multiple useState
|
||||
|
||||
**What**: Separate useState for each field
|
||||
|
||||
**When to use**:
|
||||
- Simple forms (< 5 fields)
|
||||
- No complex validation
|
||||
- No cross-field dependencies
|
||||
|
||||
**Pros**: Simple, no dependencies, easy to understand
|
||||
**Cons**: Verbose with many fields, scattered state
|
||||
|
||||
---
|
||||
|
||||
### Approach 2: Single useState with Object
|
||||
|
||||
**What**: One useState holding all fields as object
|
||||
|
||||
**When to use**:
|
||||
- Medium forms (5-10 fields)
|
||||
- Need to reset entire form
|
||||
- Want cleaner code
|
||||
|
||||
**Pros**: Grouped state, easy reset, cleaner
|
||||
**Cons**: Need spread operator, can cause unnecessary re-renders
|
||||
|
||||
---
|
||||
|
||||
### Approach 3: useReducer
|
||||
|
||||
**What**: Reducer pattern for complex state transitions
|
||||
|
||||
**When to use**:
|
||||
- Complex validation logic
|
||||
- Multi-step forms
|
||||
- Undo/redo functionality
|
||||
|
||||
**Pros**: Predictable updates, handles complex logic, testable
|
||||
**Cons**: More boilerplate, learning curve
|
||||
|
||||
---
|
||||
|
||||
### Approach 4: Form Library (React Hook Form, Formik)
|
||||
|
||||
**What**: Dedicated form state management library
|
||||
|
||||
**When to use**:
|
||||
- Large forms (10+ fields)
|
||||
- Complex validation (async, cross-field)
|
||||
- Performance critical (many fields)
|
||||
|
||||
**Pros**: Optimized re-renders, validation built-in, less code
|
||||
**Cons**: Dependency, learning curve, bundle size
|
||||
|
||||
---
|
||||
|
||||
## Comparison Table
|
||||
|
||||
| Criteria | useState | useReducer | React Hook Form |
|
||||
|----------|----------|------------|-----------------|
|
||||
| Complexity | Low | Medium | Medium |
|
||||
| Performance | ★★☆ | ★★☆ | ★★★ |
|
||||
| Bundle size | 0kb | 0kb | ~8kb |
|
||||
| Validation | Manual | Manual | Built-in |
|
||||
| Best for | Simple | Complex logic | Large forms |
|
||||
|
||||
## Recommendation
|
||||
|
||||
**For your case**: If this is a simple login/contact form, stick with **useState**. If you're building a multi-step checkout or admin form, consider **React Hook Form** for the validation and performance benefits.
|
||||
|
||||
**Consider useReducer if**: You need undo/redo, complex state machines, or want reducer-style testing.
|
||||
```
|
||||
|
||||
## Common Alternative Comparisons
|
||||
|
||||
| Topic | Typical Alternatives |
|
||||
|-------|---------------------|
|
||||
| **State** | useState, useReducer, Zustand, Redux, Jotai |
|
||||
| **Styling** | CSS Modules, Tailwind, styled-components, CSS-in-JS |
|
||||
| **Data fetching** | fetch, axios, React Query, SWR |
|
||||
| **Forms** | useState, React Hook Form, Formik |
|
||||
| **Auth** | JWT, sessions, OAuth, magic links |
|
||||
| **API design** | REST, GraphQL, tRPC, gRPC |
|
||||
| **Testing** | Jest, Vitest, Testing Library, Cypress |
|
||||
| **Databases** | PostgreSQL, MySQL, MongoDB, SQLite |
|
||||
|
||||
$ARGUMENTS
|
||||
144
examples/commands/learn/quiz.md
Normal file
144
examples/commands/learn/quiz.md
Normal file
|
|
@ -0,0 +1,144 @@
|
|||
# Quiz Me
|
||||
|
||||
Test understanding of recently written or accepted code.
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/learn:quiz # Quiz on last code worked with
|
||||
/learn:quiz error handling # Focus on specific aspect
|
||||
/learn:quiz --hard # More challenging questions
|
||||
```
|
||||
|
||||
## Instructions
|
||||
|
||||
1. Identify the last code I worked with (wrote, edited, or accepted from AI)
|
||||
2. Generate 3-5 questions that test understanding at different levels:
|
||||
- **Recall**: What does this code do?
|
||||
- **Understanding**: Why was this approach chosen?
|
||||
- **Application**: What would happen if X changed?
|
||||
- **Analysis**: What are the trade-offs of this approach?
|
||||
- **Synthesis**: How would you extend this?
|
||||
3. Present questions one at a time
|
||||
4. Wait for my answer before revealing the correct response
|
||||
5. Provide explanations with each answer, not just "correct/incorrect"
|
||||
|
||||
## Question Types
|
||||
|
||||
### Level 1: Recall
|
||||
- "What does the function X return?"
|
||||
- "What parameters does Y accept?"
|
||||
- "What happens when Z is called?"
|
||||
|
||||
### Level 2: Understanding
|
||||
- "Why do we use X instead of Y here?"
|
||||
- "What problem does this pattern solve?"
|
||||
- "Why is this line necessary?"
|
||||
|
||||
### Level 3: Application
|
||||
- "What would happen if we removed line X?"
|
||||
- "How would you add feature Y to this code?"
|
||||
- "What would break if input Z was provided?"
|
||||
|
||||
### Level 4: Analysis
|
||||
- "What are the performance implications of this approach?"
|
||||
- "What edge cases might cause issues?"
|
||||
- "How does this compare to alternative X?"
|
||||
|
||||
### Level 5: Synthesis
|
||||
- "How would you refactor this for better testability?"
|
||||
- "What would need to change to support X?"
|
||||
- "Design an extension that adds Y"
|
||||
|
||||
## Focus Areas
|
||||
|
||||
When focus is specified (e.g., `/learn:quiz error handling`), prioritize questions about:
|
||||
|
||||
| Focus | Question Themes |
|
||||
|-------|-----------------|
|
||||
| `error handling` | Try/catch, error types, recovery strategies |
|
||||
| `performance` | Big-O, optimization, bottlenecks |
|
||||
| `security` | Input validation, XSS, injection |
|
||||
| `testing` | Test cases, edge cases, mocking |
|
||||
| `architecture` | Patterns, separation of concerns, SOLID |
|
||||
| `types` | TypeScript types, inference, generics |
|
||||
|
||||
## Difficulty Modes
|
||||
|
||||
### Default
|
||||
- 3 questions
|
||||
- Mix of Level 1-3
|
||||
- Focus on understanding current code
|
||||
|
||||
### `--hard`
|
||||
- 5 questions
|
||||
- Levels 3-5
|
||||
- Include hypothetical modifications
|
||||
- Ask about trade-offs and alternatives
|
||||
|
||||
## Response Format
|
||||
|
||||
For each question:
|
||||
|
||||
```
|
||||
## Question 1 of 3
|
||||
|
||||
[Question text]
|
||||
|
||||
What's your answer?
|
||||
|
||||
---
|
||||
(After user responds)
|
||||
|
||||
### Feedback
|
||||
|
||||
[Whether correct and why]
|
||||
|
||||
**Key insight**: [The concept this tests]
|
||||
|
||||
**Related concept**: [Something to explore further]
|
||||
|
||||
Ready for the next question?
|
||||
```
|
||||
|
||||
## After Quiz Complete
|
||||
|
||||
Summarize:
|
||||
- Score: X/Y correct
|
||||
- Strengths: [Topics understood well]
|
||||
- Review needed: [Topics to revisit]
|
||||
- Suggested practice: [Specific exercise]
|
||||
|
||||
## Example Session
|
||||
|
||||
```
|
||||
User: /learn:quiz
|
||||
|
||||
Claude: Looking at your last code - the useEffect hook for data fetching.
|
||||
|
||||
## Question 1 of 3
|
||||
|
||||
In your useEffect, you have an empty dependency array [].
|
||||
What does this mean for when the effect runs?
|
||||
|
||||
User: It runs only once when the component mounts
|
||||
|
||||
Claude: ### Feedback
|
||||
Correct! An empty dependency array means the effect runs only on mount
|
||||
(and cleanup on unmount).
|
||||
|
||||
**Key insight**: The dependency array controls WHEN effects re-run.
|
||||
|
||||
**Related concept**: What happens with no array vs. [someValue]?
|
||||
|
||||
Ready for Question 2?
|
||||
```
|
||||
|
||||
## Tips for Users
|
||||
|
||||
1. **Be honest** — Wrong answers are learning opportunities
|
||||
2. **Explain your reasoning** — Helps identify gaps even in correct answers
|
||||
3. **Ask follow-ups** — If feedback is unclear, dig deeper
|
||||
4. **Track weak areas** — Note topics that need more practice
|
||||
|
||||
$ARGUMENTS
|
||||
178
examples/commands/learn/teach.md
Normal file
178
examples/commands/learn/teach.md
Normal file
|
|
@ -0,0 +1,178 @@
|
|||
# Teach Me
|
||||
|
||||
Step-by-step explanation of a concept with progressive depth.
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/learn:teach React hooks # Learn about React hooks
|
||||
/learn:teach async/await # Understand async patterns
|
||||
/learn:teach SOLID principles # Learn design principles
|
||||
/learn:teach --deep SQL joins # In-depth explanation
|
||||
```
|
||||
|
||||
## Instructions
|
||||
|
||||
1. Start with a **one-sentence definition** of the concept
|
||||
2. Explain **why it matters** (real-world problem it solves)
|
||||
3. Show a **minimal example** (simplest possible code)
|
||||
4. Break down **each part** of the example with comments
|
||||
5. Show a **practical example** (real-world use case)
|
||||
6. Highlight **common mistakes** beginners make
|
||||
7. Suggest **next concepts** to learn
|
||||
|
||||
## Response Format
|
||||
|
||||
```markdown
|
||||
## [Concept Name]
|
||||
|
||||
**In one sentence**: [Clear, simple definition]
|
||||
|
||||
### Why It Matters
|
||||
|
||||
[1-2 sentences on the problem this solves]
|
||||
|
||||
### Minimal Example
|
||||
|
||||
\`\`\`[language]
|
||||
// Simplest possible demonstration
|
||||
[code]
|
||||
\`\`\`
|
||||
|
||||
**Line by line**:
|
||||
- Line 1: [explanation]
|
||||
- Line 2: [explanation]
|
||||
...
|
||||
|
||||
### Practical Example
|
||||
|
||||
\`\`\`[language]
|
||||
// Real-world scenario
|
||||
[code]
|
||||
\`\`\`
|
||||
|
||||
### Common Mistakes
|
||||
|
||||
1. **[Mistake]**: [Why it's wrong and what to do instead]
|
||||
2. **[Mistake]**: [Why it's wrong and what to do instead]
|
||||
|
||||
### Key Takeaways
|
||||
|
||||
- [Bullet point 1]
|
||||
- [Bullet point 2]
|
||||
- [Bullet point 3]
|
||||
|
||||
### Learn Next
|
||||
|
||||
- [Related concept 1] — [why it connects]
|
||||
- [Related concept 2] — [why it connects]
|
||||
|
||||
---
|
||||
|
||||
**Practice challenge**: [Small exercise to reinforce the concept]
|
||||
```
|
||||
|
||||
## Depth Modes
|
||||
|
||||
### Default
|
||||
- One-sentence definition
|
||||
- One minimal example
|
||||
- One practical example
|
||||
- 2-3 common mistakes
|
||||
|
||||
### `--deep`
|
||||
- Extended explanation with history/context
|
||||
- Multiple examples of increasing complexity
|
||||
- Edge cases and gotchas
|
||||
- Performance considerations
|
||||
- Comparison with alternatives
|
||||
- Interview-relevant details
|
||||
|
||||
### `--quick`
|
||||
- Definition only
|
||||
- Single example
|
||||
- No extras
|
||||
|
||||
## Adaptation Rules
|
||||
|
||||
### For Beginners
|
||||
- Use analogies from everyday life
|
||||
- Avoid jargon (or explain it immediately)
|
||||
- More comments in code
|
||||
- Smaller code examples
|
||||
|
||||
### For Intermediates
|
||||
- Assume basic syntax knowledge
|
||||
- Focus on "why" over "what"
|
||||
- Include trade-offs
|
||||
- Show idiomatic patterns
|
||||
|
||||
### For Advanced Topics
|
||||
- Reference official documentation
|
||||
- Discuss internal implementation when relevant
|
||||
- Include performance implications
|
||||
- Mention related patterns
|
||||
|
||||
## Example Session
|
||||
|
||||
```
|
||||
User: /learn:teach useEffect
|
||||
|
||||
Claude: ## useEffect
|
||||
|
||||
**In one sentence**: useEffect lets you run side effects (data fetching, subscriptions, DOM changes) after React renders a component.
|
||||
|
||||
### Why It Matters
|
||||
|
||||
React components are pure functions that render UI. But real apps need to interact with the outside world—APIs, browser events, timers. useEffect is the bridge between React's declarative world and imperative side effects.
|
||||
|
||||
### Minimal Example
|
||||
|
||||
\`\`\`jsx
|
||||
import { useEffect, useState } from 'react';
|
||||
|
||||
function Timer() {
|
||||
const [seconds, setSeconds] = useState(0);
|
||||
|
||||
useEffect(() => {
|
||||
const id = setInterval(() => {
|
||||
setSeconds(s => s + 1);
|
||||
}, 1000);
|
||||
|
||||
return () => clearInterval(id); // Cleanup
|
||||
}, []); // Empty array = run once
|
||||
|
||||
return <div>{seconds}s</div>;
|
||||
}
|
||||
\`\`\`
|
||||
|
||||
**Line by line**:
|
||||
- `useEffect(() => {...}, [])`: Run this function after first render
|
||||
- `setInterval(...)`: Start a timer (side effect)
|
||||
- `return () => clearInterval(id)`: Cleanup when component unmounts
|
||||
- `[]`: Empty dependency array = only run on mount
|
||||
|
||||
### Common Mistakes
|
||||
|
||||
1. **Missing dependency array**: Without `[]`, effect runs on EVERY render
|
||||
2. **Forgetting cleanup**: Intervals/subscriptions leak without return function
|
||||
3. **Stale closures**: Using old state values instead of functional updates
|
||||
|
||||
---
|
||||
|
||||
**Practice challenge**: Add a pause button that stops and resumes the timer.
|
||||
```
|
||||
|
||||
## Topics Well-Suited for /learn:teach
|
||||
|
||||
| Category | Examples |
|
||||
|----------|----------|
|
||||
| **React** | hooks, context, suspense, server components |
|
||||
| **JavaScript** | closures, promises, event loop, prototypes |
|
||||
| **TypeScript** | generics, mapped types, utility types |
|
||||
| **Patterns** | SOLID, DI, composition, factories |
|
||||
| **Backend** | REST, GraphQL, authentication, caching |
|
||||
| **Database** | indexes, joins, transactions, normalization |
|
||||
| **DevOps** | containers, CI/CD, infrastructure as code |
|
||||
|
||||
$ARGUMENTS
|
||||
Loading…
Add table
Add a link
Reference in a new issue