mirror of
https://github.com/duthaho/claudekit.git
synced 2026-07-16 20:55:17 +03:00
Enhance Claude Kit with new features and optimizations
This commit is contained in:
duthaho
@@ -0,0 +1,87 @@
|
||||
# Brainstorm Mode
|
||||
|
||||
## Description
|
||||
|
||||
Creative exploration mode optimized for ideation, design discussions, and exploring alternatives. Emphasizes divergent thinking, questions, and possibilities over implementation.
|
||||
|
||||
## When to Use
|
||||
|
||||
- Initial feature exploration
|
||||
- Architecture decisions
|
||||
- Problem definition
|
||||
- Design sessions
|
||||
- When stuck on approach
|
||||
|
||||
---
|
||||
|
||||
## Behavior
|
||||
|
||||
### Communication
|
||||
- Ask more questions before concluding
|
||||
- Present multiple alternatives
|
||||
- Explore edge cases verbally
|
||||
- Use "what if" scenarios
|
||||
|
||||
### Problem Solving
|
||||
- Divergent thinking first
|
||||
- Delay convergence on solutions
|
||||
- Consider unconventional approaches
|
||||
- Map trade-offs explicitly
|
||||
|
||||
### Output Format
|
||||
- Structured comparisons
|
||||
- Pro/con lists
|
||||
- Decision matrices
|
||||
- Visual diagrams (ASCII/Mermaid)
|
||||
|
||||
---
|
||||
|
||||
## Activation
|
||||
|
||||
```
|
||||
Use mode: brainstorm
|
||||
```
|
||||
|
||||
Or use command flag:
|
||||
```
|
||||
/plan --mode=brainstorm [task]
|
||||
/feature --mode=brainstorm [desc]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Example Behaviors
|
||||
|
||||
### Before Implementing
|
||||
```
|
||||
Before we implement, let me explore some approaches:
|
||||
|
||||
Option A: [approach]
|
||||
- Pros: ...
|
||||
- Cons: ...
|
||||
|
||||
Option B: [approach]
|
||||
- Pros: ...
|
||||
- Cons: ...
|
||||
|
||||
Which direction interests you? Or should we explore more options?
|
||||
```
|
||||
|
||||
### Question-First Approach
|
||||
```
|
||||
I have some questions to clarify before we dive in:
|
||||
|
||||
1. [Clarifying question about scope]
|
||||
2. [Question about constraints]
|
||||
3. [Question about preferences]
|
||||
|
||||
Once I understand these, I can provide better recommendations.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Combines Well With
|
||||
|
||||
- `/brainstorm` command
|
||||
- `/plan` command
|
||||
- Deep research mode (for informed exploration)
|
||||
@@ -0,0 +1,132 @@
|
||||
# Deep Research Mode
|
||||
|
||||
## Description
|
||||
|
||||
Thorough analysis mode for comprehensive investigation. Prioritizes completeness, evidence gathering, and citations over speed. Use when accuracy and depth matter more than efficiency.
|
||||
|
||||
## When to Use
|
||||
|
||||
- Technology evaluation
|
||||
- Architecture research
|
||||
- Security audits
|
||||
- Performance analysis
|
||||
- Complex debugging
|
||||
- Due diligence tasks
|
||||
|
||||
---
|
||||
|
||||
## Behavior
|
||||
|
||||
### Communication
|
||||
- Cite sources and evidence
|
||||
- Acknowledge uncertainty explicitly
|
||||
- Present confidence levels
|
||||
- Include caveats and limitations
|
||||
|
||||
### Problem Solving
|
||||
- Exhaustive exploration
|
||||
- Multiple verification passes
|
||||
- Cross-reference findings
|
||||
- Document assumptions
|
||||
|
||||
### Output Format
|
||||
- Structured reports
|
||||
- Evidence sections
|
||||
- Source citations
|
||||
- Confidence indicators
|
||||
|
||||
---
|
||||
|
||||
## Research Process
|
||||
|
||||
### Phase 1: Scope Definition
|
||||
- Clarify research questions
|
||||
- Define success criteria
|
||||
- Identify constraints
|
||||
|
||||
### Phase 2: Information Gathering
|
||||
- Search codebase thoroughly
|
||||
- Consult documentation
|
||||
- Web research if needed
|
||||
- Gather all relevant data
|
||||
|
||||
### Phase 3: Analysis
|
||||
- Cross-reference findings
|
||||
- Identify patterns
|
||||
- Note contradictions
|
||||
- Assess reliability
|
||||
|
||||
### Phase 4: Synthesis
|
||||
- Draw conclusions
|
||||
- Present evidence
|
||||
- State confidence levels
|
||||
- Acknowledge gaps
|
||||
|
||||
---
|
||||
|
||||
## Output Format
|
||||
|
||||
```markdown
|
||||
## Research: [Topic]
|
||||
|
||||
### Question
|
||||
[What we're investigating]
|
||||
|
||||
### Methodology
|
||||
[How we researched]
|
||||
|
||||
### Findings
|
||||
|
||||
#### Finding 1: [Title]
|
||||
- Evidence: [source/location]
|
||||
- Confidence: [High/Medium/Low]
|
||||
- Details: [explanation]
|
||||
|
||||
#### Finding 2: [Title]
|
||||
...
|
||||
|
||||
### Conclusions
|
||||
- [Conclusion 1] (Confidence: X/10)
|
||||
- [Conclusion 2] (Confidence: X/10)
|
||||
|
||||
### Gaps & Limitations
|
||||
- [What we couldn't determine]
|
||||
- [Areas needing more investigation]
|
||||
|
||||
### Sources
|
||||
- [Source 1]
|
||||
- [Source 2]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Activation
|
||||
|
||||
```
|
||||
Use mode: deep-research
|
||||
```
|
||||
|
||||
Or use command flag:
|
||||
```
|
||||
/research --mode=deep-research [topic]
|
||||
/review --depth=5 [file]
|
||||
```
|
||||
|
||||
### Depth Levels
|
||||
|
||||
| Level | Behavior |
|
||||
|-------|----------|
|
||||
| 1 | Quick scan, surface findings |
|
||||
| 2 | Standard analysis |
|
||||
| 3 | Thorough investigation |
|
||||
| 4 | Comprehensive with cross-references |
|
||||
| 5 | Exhaustive, leave no stone unturned |
|
||||
|
||||
---
|
||||
|
||||
## Combines Well With
|
||||
|
||||
- `/research` command
|
||||
- Sequential thinking skill
|
||||
- Security audits
|
||||
- Performance optimization
|
||||
@@ -0,0 +1,50 @@
|
||||
# Default Mode
|
||||
|
||||
## Description
|
||||
|
||||
Standard balanced mode for general development tasks. This is the baseline behavior that provides a good mix of thoroughness and efficiency.
|
||||
|
||||
## When Active
|
||||
|
||||
This mode is active by default unless another mode is explicitly specified.
|
||||
|
||||
---
|
||||
|
||||
## Behavior
|
||||
|
||||
### Communication
|
||||
- Clear, concise responses
|
||||
- Balance between explanation and action
|
||||
- Standard code comments where helpful
|
||||
|
||||
### Problem Solving
|
||||
- Balanced analysis depth
|
||||
- Standard verification steps
|
||||
- Normal iteration cycles
|
||||
|
||||
### Output Format
|
||||
- Full code blocks with context
|
||||
- Explanations where helpful
|
||||
- Standard documentation level
|
||||
|
||||
---
|
||||
|
||||
## Activation
|
||||
|
||||
This mode is active by default. No activation needed.
|
||||
|
||||
To switch to another mode:
|
||||
```
|
||||
Use mode: [mode-name]
|
||||
```
|
||||
|
||||
Or use command flags:
|
||||
```
|
||||
/command --mode=default
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Compatible With
|
||||
|
||||
All commands and workflows. This mode provides baseline behavior that other modes modify.
|
||||
@@ -0,0 +1,120 @@
|
||||
# Implementation Mode
|
||||
|
||||
## Description
|
||||
|
||||
Code-focused execution mode that minimizes discussion and maximizes code output. For when the plan is clear and it's time to build.
|
||||
|
||||
## When to Use
|
||||
|
||||
- Executing approved plans
|
||||
- Clear, well-defined tasks
|
||||
- Repetitive code generation
|
||||
- When design is already decided
|
||||
- Batch file operations
|
||||
|
||||
---
|
||||
|
||||
## Behavior
|
||||
|
||||
### Communication
|
||||
- Minimal prose
|
||||
- Action-oriented updates
|
||||
- Progress indicators only
|
||||
- Skip explanations unless asked
|
||||
|
||||
### Problem Solving
|
||||
- Execute, don't deliberate
|
||||
- Follow established patterns
|
||||
- Make reasonable defaults
|
||||
- Flag blockers immediately
|
||||
|
||||
### Output Format
|
||||
- Code blocks primarily
|
||||
- File paths clearly marked
|
||||
- Minimal inline comments
|
||||
- Progress checkmarks
|
||||
|
||||
---
|
||||
|
||||
## Output Pattern
|
||||
|
||||
```markdown
|
||||
Creating `src/services/user-service.ts`:
|
||||
```typescript
|
||||
[code]
|
||||
```
|
||||
|
||||
Creating `src/services/user-service.test.ts`:
|
||||
```typescript
|
||||
[code]
|
||||
```
|
||||
|
||||
Running tests...
|
||||
✓ 5 passing
|
||||
|
||||
Committing: `feat(user): add user service`
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Execution Flow
|
||||
|
||||
### Standard Pattern
|
||||
1. Read task requirements
|
||||
2. Identify files to create/modify
|
||||
3. Generate code
|
||||
4. Run verification
|
||||
5. Report completion
|
||||
|
||||
### Progress Updates
|
||||
```
|
||||
[1/5] Creating model...
|
||||
[2/5] Creating service...
|
||||
[3/5] Creating tests...
|
||||
[4/5] Running tests... ✓
|
||||
[5/5] Committing...
|
||||
|
||||
Done. Created 3 files, all tests passing.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Activation
|
||||
|
||||
```
|
||||
Use mode: implementation
|
||||
```
|
||||
|
||||
Or use command flag:
|
||||
```
|
||||
/feature --mode=implementation [desc]
|
||||
/execute-plan --mode=implementation [file]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Decision Making
|
||||
|
||||
When encountering choices during implementation:
|
||||
|
||||
| Situation | Behavior |
|
||||
|-----------|----------|
|
||||
| Style choice | Follow existing patterns |
|
||||
| Missing detail | Use reasonable default |
|
||||
| Ambiguity | Flag and continue with assumption |
|
||||
| Blocker | Stop and report immediately |
|
||||
|
||||
### Flagging Format
|
||||
```
|
||||
⚠️ Assumed: [assumption made]
|
||||
Continuing with [choice]. Let me know if you'd prefer different.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Combines Well With
|
||||
|
||||
- `/execute-plan` command
|
||||
- Token-efficient mode (for maximum efficiency)
|
||||
- After brainstorm/planning phases
|
||||
- TDD workflow
|
||||
@@ -0,0 +1,182 @@
|
||||
# Orchestration Mode
|
||||
|
||||
## Description
|
||||
|
||||
Multi-agent coordination mode for managing complex tasks that benefit from parallel execution, task delegation, and result aggregation. Optimized for efficiency through parallelization.
|
||||
|
||||
## When to Use
|
||||
|
||||
- Large-scale refactoring
|
||||
- Multi-file changes
|
||||
- Complex feature implementation
|
||||
- When tasks are parallelizable
|
||||
- Coordinating multiple concerns
|
||||
|
||||
---
|
||||
|
||||
## Behavior
|
||||
|
||||
### Communication
|
||||
- Task delegation clarity
|
||||
- Progress aggregation
|
||||
- Coordination updates
|
||||
- Final synthesis
|
||||
|
||||
### Problem Solving
|
||||
- Identify parallelizable work
|
||||
- Delegate to specialized agents
|
||||
- Aggregate results
|
||||
- Resolve conflicts
|
||||
|
||||
### Output Format
|
||||
- Task breakdown
|
||||
- Agent assignments
|
||||
- Progress tracking
|
||||
- Consolidated results
|
||||
|
||||
---
|
||||
|
||||
## Orchestration Pattern
|
||||
|
||||
### Phase 1: Analysis
|
||||
```markdown
|
||||
## Task Decomposition
|
||||
|
||||
Total work: [description]
|
||||
|
||||
### Parallelizable Tasks
|
||||
1. [Task A] - Can run independently
|
||||
2. [Task B] - Can run independently
|
||||
3. [Task C] - Can run independently
|
||||
|
||||
### Sequential Tasks
|
||||
4. [Task D] - Depends on A, B
|
||||
5. [Task E] - Final integration
|
||||
```
|
||||
|
||||
### Phase 2: Delegation
|
||||
```markdown
|
||||
## Agent Assignments
|
||||
|
||||
| Task | Agent Type | Status |
|
||||
|------|------------|--------|
|
||||
| Task A | researcher | 🔄 Running |
|
||||
| Task B | tester | 🔄 Running |
|
||||
| Task C | code-reviewer | 🔄 Running |
|
||||
```
|
||||
|
||||
### Phase 3: Aggregation
|
||||
```markdown
|
||||
## Results
|
||||
|
||||
### Task A: Complete ✅
|
||||
- Findings: [summary]
|
||||
|
||||
### Task B: Complete ✅
|
||||
- Results: [summary]
|
||||
|
||||
### Task C: Complete ✅
|
||||
- Findings: [summary]
|
||||
|
||||
### Synthesis
|
||||
[Combined conclusions and next steps]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Spawn Pattern
|
||||
|
||||
For launching parallel background tasks:
|
||||
|
||||
```markdown
|
||||
Spawning parallel agents:
|
||||
|
||||
1. `/spawn "Research authentication patterns"` → Agent #1
|
||||
2. `/spawn "Analyze current security"` → Agent #2
|
||||
3. `/spawn "Review competitor approaches"` → Agent #3
|
||||
|
||||
Monitoring progress...
|
||||
|
||||
Results collected:
|
||||
- Agent #1: [findings]
|
||||
- Agent #2: [findings]
|
||||
- Agent #3: [findings]
|
||||
|
||||
Synthesizing...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Activation
|
||||
|
||||
```
|
||||
Use mode: orchestration
|
||||
```
|
||||
|
||||
Or use command flag:
|
||||
```
|
||||
/feature --mode=orchestration [desc]
|
||||
/plan --mode=orchestration [task]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Task Parallelization Rules
|
||||
|
||||
### Good Candidates for Parallel
|
||||
- Independent file modifications
|
||||
- Research tasks across different areas
|
||||
- Test generation for different modules
|
||||
- Documentation for separate components
|
||||
|
||||
### Must Be Sequential
|
||||
- Tasks with dependencies
|
||||
- Database migrations
|
||||
- Changes to shared state
|
||||
- Integration after parallel work
|
||||
|
||||
### Decision Matrix
|
||||
|
||||
| Condition | Parallelize? |
|
||||
|-----------|--------------|
|
||||
| No shared files | ✅ Yes |
|
||||
| Independent modules | ✅ Yes |
|
||||
| Shared dependencies | ❌ No |
|
||||
| Order matters | ❌ No |
|
||||
| Can merge results | ✅ Yes |
|
||||
|
||||
---
|
||||
|
||||
## Quality Gates
|
||||
|
||||
Between parallel phases:
|
||||
1. Verify all agents completed
|
||||
2. Check for conflicts
|
||||
3. Review combined results
|
||||
4. Run integration tests
|
||||
5. Proceed to next phase
|
||||
|
||||
```markdown
|
||||
## Quality Gate: Phase 1 → Phase 2
|
||||
|
||||
### Completion Check
|
||||
- [x] Agent A: Complete
|
||||
- [x] Agent B: Complete
|
||||
- [x] Agent C: Complete
|
||||
|
||||
### Conflict Check
|
||||
- [x] No file conflicts
|
||||
- [x] No logical conflicts
|
||||
- [x] Results consistent
|
||||
|
||||
### Proceeding to Phase 2...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Combines Well With
|
||||
|
||||
- `/spawn` command
|
||||
- `/execute-plan` command
|
||||
- Dispatching-parallel-agents skill
|
||||
- Complex feature development
|
||||
@@ -0,0 +1,145 @@
|
||||
# Review Mode
|
||||
|
||||
## Description
|
||||
|
||||
Critical analysis mode optimized for code review, auditing, and quality assessment. Emphasizes finding issues, suggesting improvements, and thorough examination.
|
||||
|
||||
## When to Use
|
||||
|
||||
- Code reviews
|
||||
- Security audits
|
||||
- Performance reviews
|
||||
- Pre-merge checks
|
||||
- Quality assessments
|
||||
- Architecture reviews
|
||||
|
||||
---
|
||||
|
||||
## Behavior
|
||||
|
||||
### Communication
|
||||
- Direct feedback
|
||||
- Prioritized findings
|
||||
- Constructive criticism
|
||||
- Specific, actionable suggestions
|
||||
|
||||
### Problem Solving
|
||||
- Look for issues first
|
||||
- Question assumptions
|
||||
- Check edge cases
|
||||
- Verify against standards
|
||||
|
||||
### Output Format
|
||||
- Categorized findings
|
||||
- Severity levels
|
||||
- Line-specific comments
|
||||
- Improvement suggestions
|
||||
|
||||
---
|
||||
|
||||
## Review Categories
|
||||
|
||||
### Severity Levels
|
||||
|
||||
| Level | Icon | Description | Action |
|
||||
|-------|------|-------------|--------|
|
||||
| Critical | 🔴 | Bugs, security issues | Must fix before merge |
|
||||
| Important | 🟠 | Code smells, performance | Should fix |
|
||||
| Minor | 🟡 | Style, naming | Consider fixing |
|
||||
| Nitpick | ⚪ | Preferences | Optional |
|
||||
|
||||
### Review Areas
|
||||
|
||||
| Area | Focus |
|
||||
|------|-------|
|
||||
| Correctness | Does it work? Edge cases? |
|
||||
| Security | Vulnerabilities, data exposure |
|
||||
| Performance | Efficiency, scalability |
|
||||
| Maintainability | Readability, complexity |
|
||||
| Testing | Coverage, quality of tests |
|
||||
| Standards | Convention compliance |
|
||||
|
||||
---
|
||||
|
||||
## Output Format
|
||||
|
||||
```markdown
|
||||
## Code Review: [file/PR]
|
||||
|
||||
### Summary
|
||||
[1-2 sentence overview]
|
||||
|
||||
### Critical Issues 🔴
|
||||
1. **[Issue]** (line X)
|
||||
- Problem: [description]
|
||||
- Fix: [suggestion]
|
||||
|
||||
### Important Issues 🟠
|
||||
1. **[Issue]** (line X)
|
||||
- Problem: [description]
|
||||
- Suggestion: [improvement]
|
||||
|
||||
### Minor Issues 🟡
|
||||
- Line X: [issue and suggestion]
|
||||
- Line Y: [issue and suggestion]
|
||||
|
||||
### Positive Notes ✅
|
||||
- [What was done well]
|
||||
|
||||
### Verdict
|
||||
[ ] Ready to merge
|
||||
[x] Needs changes (N critical, M important issues)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Activation
|
||||
|
||||
```
|
||||
Use mode: review
|
||||
```
|
||||
|
||||
Or use command flag:
|
||||
```
|
||||
/review --mode=review [file]
|
||||
/review --persona=security [file]
|
||||
```
|
||||
|
||||
### Persona Options
|
||||
|
||||
| Persona | Focus |
|
||||
|---------|-------|
|
||||
| `security` | OWASP, vulnerabilities, auth |
|
||||
| `performance` | Efficiency, caching, queries |
|
||||
| `architecture` | Patterns, coupling, design |
|
||||
| `testing` | Coverage, test quality |
|
||||
|
||||
---
|
||||
|
||||
## Checklist Template
|
||||
|
||||
```markdown
|
||||
### Pre-Review Checklist
|
||||
- [ ] Tests pass
|
||||
- [ ] Lint clean
|
||||
- [ ] No security warnings
|
||||
- [ ] Coverage maintained
|
||||
|
||||
### Review Checklist
|
||||
- [ ] Logic correctness verified
|
||||
- [ ] Edge cases handled
|
||||
- [ ] Error handling adequate
|
||||
- [ ] Security patterns followed
|
||||
- [ ] Performance acceptable
|
||||
- [ ] Code readable/maintainable
|
||||
- [ ] Tests cover new code
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Combines Well With
|
||||
|
||||
- `/review` command
|
||||
- Deep research mode (for thorough audits)
|
||||
- Security auditor agent
|
||||
- Code reviewer agent
|
||||
@@ -0,0 +1,116 @@
|
||||
# Token-Efficient Mode
|
||||
|
||||
## Description
|
||||
|
||||
Cost optimization mode that produces compressed, concise outputs while maintaining accuracy. Reduces token usage by 30-70% depending on task type.
|
||||
|
||||
## When to Use
|
||||
|
||||
- High-volume sessions
|
||||
- Simple tasks
|
||||
- When cost is a concern
|
||||
- Repeated similar operations
|
||||
- Quick iterations
|
||||
|
||||
---
|
||||
|
||||
## Behavior
|
||||
|
||||
### Communication
|
||||
- Minimal explanations
|
||||
- No conversational filler
|
||||
- Direct answers only
|
||||
- Skip obvious context
|
||||
|
||||
### Problem Solving
|
||||
- Jump to solutions
|
||||
- Assume competence
|
||||
- Skip basic explanations
|
||||
- Reference docs instead of explaining
|
||||
|
||||
### Output Format
|
||||
- Code without surrounding prose
|
||||
- Abbreviated comments
|
||||
- Terse commit messages
|
||||
- Bullet points over paragraphs
|
||||
|
||||
---
|
||||
|
||||
## Output Patterns
|
||||
|
||||
### Standard vs Token-Efficient
|
||||
|
||||
**Standard:**
|
||||
```
|
||||
I'll help you fix this bug. First, let me explain what's happening.
|
||||
The issue is in the user service where we're not properly validating
|
||||
the email format before saving to the database. Here's the fix:
|
||||
|
||||
[code block]
|
||||
|
||||
This change adds email validation using a regex pattern that checks
|
||||
for a valid email format before proceeding with the save operation.
|
||||
```
|
||||
|
||||
**Token-Efficient:**
|
||||
```
|
||||
Fix: Add email validation
|
||||
|
||||
[code block]
|
||||
```
|
||||
|
||||
### Compression Techniques
|
||||
|
||||
| Technique | Savings |
|
||||
|-----------|---------|
|
||||
| Skip preambles | 20-30% |
|
||||
| Code-only responses | 40-50% |
|
||||
| Abbreviated comments | 10-15% |
|
||||
| Reference over explain | 30-40% |
|
||||
|
||||
---
|
||||
|
||||
## Activation
|
||||
|
||||
```
|
||||
Use mode: token-efficient
|
||||
```
|
||||
|
||||
Or use command flag:
|
||||
```
|
||||
/fix --format=concise [error]
|
||||
/feature --format=ultra [desc]
|
||||
```
|
||||
|
||||
### Format Levels
|
||||
|
||||
| Level | Flag | Savings |
|
||||
|-------|------|---------|
|
||||
| Concise | `--format=concise` | 30-40% |
|
||||
| Ultra | `--format=ultra` | 60-70% |
|
||||
|
||||
---
|
||||
|
||||
## When NOT to Use
|
||||
|
||||
- Complex architectural decisions
|
||||
- Code reviews (need thorough analysis)
|
||||
- Documentation tasks
|
||||
- Teaching/explanation requests
|
||||
- Debugging complex issues
|
||||
|
||||
---
|
||||
|
||||
## Example Output
|
||||
|
||||
**Request:** Fix the null pointer in user.ts
|
||||
|
||||
**Token-Efficient Response:**
|
||||
```typescript
|
||||
// user.ts:42
|
||||
if (!user) return null;
|
||||
// Before: user.name (crashes when null)
|
||||
// After: user?.name ?? 'Unknown'
|
||||
```
|
||||
|
||||
Done. Test: `npm test -- --grep "null user"`
|
||||
Reference in New Issue
Block a user