@yeongjaeyou/claude-code-config 0.18.7 → 0.19.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -2,6 +2,7 @@
|
|
|
2
2
|
name: web-researcher
|
|
3
3
|
description: Use this agent when you need to conduct comprehensive research on technical topics across multiple platforms (Reddit, GitHub, Stack Overflow, Hugging Face, arXiv, etc.) and generate a synthesized report. (project)
|
|
4
4
|
model: inherit
|
|
5
|
+
skills: code-explorer
|
|
5
6
|
---
|
|
6
7
|
|
|
7
8
|
# Web Research Expert Agent
|
|
@@ -53,7 +54,7 @@ Detect keywords in the prompt to determine execution mode:
|
|
|
53
54
|
### Required Fields (Quick & Deep)
|
|
54
55
|
|
|
55
56
|
```yaml
|
|
56
|
-
platform: github | reddit | hf | stackoverflow | docs | arxiv | web
|
|
57
|
+
platform: github | reddit | hf | stackoverflow | docs | arxiv | web | twitter | threads
|
|
57
58
|
query_used: "actual search query used"
|
|
58
59
|
findings:
|
|
59
60
|
- title: "finding title"
|
|
@@ -98,6 +99,8 @@ suggested_followups:
|
|
|
98
99
|
| **DeepWiki** | In-depth GitHub repo analysis | MCP |
|
|
99
100
|
| **arXiv** | Academic papers | WebSearch |
|
|
100
101
|
| **General Web** | Blogs, tutorials | WebSearch / Firecrawl |
|
|
102
|
+
| **Twitter/X** | Viral content, real-time buzz, tech announcements | WebSearch |
|
|
103
|
+
| **Threads** | Meta ecosystem discussions, cross-platform takes | WebSearch |
|
|
101
104
|
|
|
102
105
|
---
|
|
103
106
|
|
|
@@ -161,7 +164,8 @@ Parallel execution (Task tool, run_in_background: true):
|
|
|
161
164
|
├── Task: HuggingFace search
|
|
162
165
|
├── Task: Reddit + StackOverflow search
|
|
163
166
|
├── Task: Context7 official docs
|
|
164
|
-
|
|
167
|
+
├── Task: arXiv + general web (if needed)
|
|
168
|
+
└── Task: Twitter/X + Threads (for trending/viral topics)
|
|
165
169
|
```
|
|
166
170
|
|
|
167
171
|
**Execution policy:**
|
|
@@ -189,7 +193,8 @@ Parallel execution (all platforms):
|
|
|
189
193
|
├── Task: HuggingFace Agent (structured output)
|
|
190
194
|
├── Task: Community Agent - Reddit/SO (structured output)
|
|
191
195
|
├── Task: Official Docs Agent - Context7/DeepWiki (structured output)
|
|
192
|
-
|
|
196
|
+
├── Task: Academic Agent - arXiv (structured output)
|
|
197
|
+
└── Task: Social Media Agent - Twitter/X + Threads (structured output)
|
|
193
198
|
```
|
|
194
199
|
|
|
195
200
|
**Each Task prompt MUST include:**
|
|
@@ -318,6 +323,8 @@ Terminate when any of the following is met:
|
|
|
318
323
|
| Confirmed only in official docs (Context7/DeepWiki) | **HIGH** |
|
|
319
324
|
| Single GitHub issue/PR | **MEDIUM** |
|
|
320
325
|
| Single Reddit/SO answer | **MEDIUM** |
|
|
326
|
+
| Viral Twitter/X thread (high engagement) | **MEDIUM** |
|
|
327
|
+
| Single Threads post | **LOW** |
|
|
321
328
|
| Date older than 2 years | **LOW** |
|
|
322
329
|
| No source URL | **EXCLUDE** |
|
|
323
330
|
|
|
@@ -477,6 +484,62 @@ mcp__firecrawl__firecrawl_search
|
|
|
477
484
|
|
|
478
485
|
---
|
|
479
486
|
|
|
487
|
+
### 9. Twitter/X Search (WebSearch)
|
|
488
|
+
|
|
489
|
+
```
|
|
490
|
+
WebSearch: site:x.com OR site:twitter.com {query} {year}
|
|
491
|
+
```
|
|
492
|
+
|
|
493
|
+
**Query patterns:**
|
|
494
|
+
|
|
495
|
+
| Goal | Query Format |
|
|
496
|
+
|------|--------------|
|
|
497
|
+
| From specific user | `site:x.com from:username {query}` |
|
|
498
|
+
| High engagement posts | `site:x.com {query} "likes" OR "retweets"` |
|
|
499
|
+
| Tech announcements | `site:x.com {library} release OR launch {year}` |
|
|
500
|
+
| Discussions/threads | `site:x.com {query} thread` |
|
|
501
|
+
|
|
502
|
+
**Useful tech accounts:**
|
|
503
|
+
|
|
504
|
+
- AI/ML: @_akhaliq, @AndrewYNg, @ylecun, @kaboranalytics
|
|
505
|
+
- Open source: @GitHub, @HuggingFace
|
|
506
|
+
- Dev tools: @veraborger, @raaborger
|
|
507
|
+
|
|
508
|
+
**Caveats:**
|
|
509
|
+
|
|
510
|
+
- WebSearch only indexes public, crawlable tweets
|
|
511
|
+
- Real-time trending data not available via WebSearch
|
|
512
|
+
- Rate-limited content may not appear in results
|
|
513
|
+
|
|
514
|
+
---
|
|
515
|
+
|
|
516
|
+
### 10. Threads Search (WebSearch)
|
|
517
|
+
|
|
518
|
+
```
|
|
519
|
+
WebSearch: site:threads.net {query} {year}
|
|
520
|
+
```
|
|
521
|
+
|
|
522
|
+
**Query patterns:**
|
|
523
|
+
|
|
524
|
+
| Goal | Query Format |
|
|
525
|
+
|------|--------------|
|
|
526
|
+
| From specific user | `site:threads.net/@username {query}` |
|
|
527
|
+
| Meta/Instagram topics | `site:threads.net {meta OR instagram} {query}` |
|
|
528
|
+
|
|
529
|
+
**Best for:**
|
|
530
|
+
|
|
531
|
+
- Cross-posted content from Instagram creators
|
|
532
|
+
- Meta ecosystem updates and discussions
|
|
533
|
+
- Alternative perspectives to Twitter/X
|
|
534
|
+
|
|
535
|
+
**Caveats:**
|
|
536
|
+
|
|
537
|
+
- Indexing coverage is more limited than Twitter/X
|
|
538
|
+
- Newer platform, less historical data available
|
|
539
|
+
- Search latency for recent posts
|
|
540
|
+
|
|
541
|
+
---
|
|
542
|
+
|
|
480
543
|
## Report Template
|
|
481
544
|
|
|
482
545
|
```markdown
|
|
@@ -554,5 +617,6 @@ mcp__firecrawl__firecrawl_search
|
|
|
554
617
|
## File Management
|
|
555
618
|
|
|
556
619
|
- Keep intermediate data in memory only
|
|
557
|
-
- **
|
|
620
|
+
- **Output directory**: `docs/research/`
|
|
621
|
+
- **Final deliverable**: Single `docs/research/research-report-{topic-slug}.md` file
|
|
558
622
|
- Do not create temporary files or intermediate drafts
|
|
@@ -150,11 +150,25 @@ When Built-in LSP returns "No LSP server available" error:
|
|
|
150
150
|
| `insert_after_symbol` / `insert_before_symbol` | Add new code at precise locations |
|
|
151
151
|
| `search_for_pattern` | Flexible regex search across codebase |
|
|
152
152
|
|
|
153
|
+
**Session Management:**
|
|
154
|
+
- Call `activate_project` at the start of each new conversation session
|
|
155
|
+
- Once activated, remains active for the entire session
|
|
156
|
+
- Prompt: "activate serena" or "serena activate project"
|
|
157
|
+
|
|
158
|
+
**Onboarding & Memory:**
|
|
159
|
+
- Onboarding: Run once per project initial setup (`onboarding` tool)
|
|
160
|
+
- Indexing: LSP-based real-time analysis, no periodic refresh needed
|
|
161
|
+
- Memory updates (`edit_memory`): Only when structure changes
|
|
162
|
+
- New modules/adapters added
|
|
163
|
+
- Architecture patterns changed
|
|
164
|
+
- Build/test commands modified
|
|
165
|
+
|
|
153
166
|
**Best Practices:**
|
|
154
167
|
1. Start with `get_symbols_overview` for new files
|
|
155
168
|
2. Use `find_symbol` with `depth=1` to see class methods before diving deeper
|
|
156
169
|
3. Prefer symbolic editing over file-based editing when modifying functions/classes
|
|
157
170
|
4. Always check `find_referencing_symbols` before renaming/removing symbols
|
|
171
|
+
5. Never use Grep/Read before trying Serena tools first
|
|
158
172
|
|
|
159
173
|
### Self-Verification (MANDATORY)
|
|
160
174
|
|
|
@@ -0,0 +1,196 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: interview-methodology
|
|
3
|
+
description: This skill should be used when conducting in-depth user interviews, "gathering requirements", "interview me", "ask me questions", "understand my needs before implementing", "spec-based development", or when preparing comprehensive specifications before implementation.
|
|
4
|
+
version: 0.2.0
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Interview Methodology
|
|
8
|
+
|
|
9
|
+
A comprehensive framework for conducting thorough requirement-gathering interviews that uncover hidden needs, constraints, and edge cases.
|
|
10
|
+
|
|
11
|
+
## Trigger Examples
|
|
12
|
+
|
|
13
|
+
<example>
|
|
14
|
+
Context: User wants to implement a new feature without detailed spec
|
|
15
|
+
user: "I want to add dark mode to my app"
|
|
16
|
+
assistant: Loads interview-methodology skill to thoroughly understand requirements first.
|
|
17
|
+
<commentary>
|
|
18
|
+
Feature request without detailed specification - perfect trigger for deep interview before implementation.
|
|
19
|
+
</commentary>
|
|
20
|
+
</example>
|
|
21
|
+
|
|
22
|
+
<example>
|
|
23
|
+
Context: User explicitly requests interview-style requirements gathering
|
|
24
|
+
user: "Interview me about this feature before you start coding"
|
|
25
|
+
assistant: Loads interview-methodology skill to conduct thorough interview.
|
|
26
|
+
<commentary>
|
|
27
|
+
Explicit interview request - direct trigger.
|
|
28
|
+
</commentary>
|
|
29
|
+
</example>
|
|
30
|
+
|
|
31
|
+
## Critical Rules
|
|
32
|
+
|
|
33
|
+
1. **Use AskUserQuestion tool** for all questions - never just ask in plain text
|
|
34
|
+
2. **Questions must NOT be obvious** - avoid basic questions the user has already answered
|
|
35
|
+
3. **Continue interviewing until complete** - don't stop after 2-3 questions
|
|
36
|
+
4. **Probe deeper on every answer** - each response should spawn follow-up questions
|
|
37
|
+
5. **Write the final spec to a file** when the interview is complete
|
|
38
|
+
|
|
39
|
+
## Core Principle: Non-Obvious Questions
|
|
40
|
+
|
|
41
|
+
**Never ask questions the user has already implicitly answered.** Instead, probe the gaps, assumptions, and unstated requirements.
|
|
42
|
+
|
|
43
|
+
### Bad Questions (Obvious)
|
|
44
|
+
- "What feature do you want?" (they already told you)
|
|
45
|
+
- "Do you want it to work well?" (obviously yes)
|
|
46
|
+
- "Should it be fast?" (obviously yes)
|
|
47
|
+
|
|
48
|
+
### Good Questions (Non-Obvious)
|
|
49
|
+
- "What happens when X fails? Should it retry, fail silently, or notify?"
|
|
50
|
+
- "Who else might use this besides you? Do they have different needs?"
|
|
51
|
+
- "What's the worst thing that could happen if this feature misbehaves?"
|
|
52
|
+
|
|
53
|
+
## Question Framework by Category
|
|
54
|
+
|
|
55
|
+
### 1. Technical Implementation
|
|
56
|
+
- What existing systems does this need to integrate with?
|
|
57
|
+
- Are there performance constraints (response time, memory, etc.)?
|
|
58
|
+
- What's the expected scale? 10 users or 10,000?
|
|
59
|
+
- Are there security or compliance requirements?
|
|
60
|
+
- Should this work offline? On mobile?
|
|
61
|
+
- What happens during network failures or timeouts?
|
|
62
|
+
|
|
63
|
+
### 2. User Interface & Experience
|
|
64
|
+
- Who are the different user personas interacting with this?
|
|
65
|
+
- What's the primary device/platform? Secondary?
|
|
66
|
+
- Are there accessibility requirements?
|
|
67
|
+
- What's the user's technical proficiency level?
|
|
68
|
+
- What should happen on errors - technical message or friendly guidance?
|
|
69
|
+
- Are there existing UI patterns in the app this should follow?
|
|
70
|
+
|
|
71
|
+
### 3. Edge Cases & Error Handling
|
|
72
|
+
- What inputs are considered invalid? How should they be handled?
|
|
73
|
+
- What if the user does X when they should do Y?
|
|
74
|
+
- What's the behavior when data is missing or malformed?
|
|
75
|
+
- How should concurrent/conflicting operations be handled?
|
|
76
|
+
- What are the failure modes and recovery strategies?
|
|
77
|
+
|
|
78
|
+
### 4. Constraints & Tradeoffs
|
|
79
|
+
- What's more important: speed of delivery or completeness?
|
|
80
|
+
- Are there budget/resource limitations?
|
|
81
|
+
- What can we cut if we run out of time?
|
|
82
|
+
- What's the minimum viable version vs. ideal version?
|
|
83
|
+
- Are there dependencies on other teams or systems?
|
|
84
|
+
|
|
85
|
+
### 5. Business Context
|
|
86
|
+
- Why is this feature needed now?
|
|
87
|
+
- What problem does this solve for the business?
|
|
88
|
+
- How will success be measured?
|
|
89
|
+
- What's the cost of NOT doing this?
|
|
90
|
+
- Are there regulatory or legal considerations?
|
|
91
|
+
|
|
92
|
+
## Interview Flow
|
|
93
|
+
|
|
94
|
+
### Phase 1: Context Gathering (2-3 questions)
|
|
95
|
+
Understand the big picture before diving into details.
|
|
96
|
+
- What triggered this request?
|
|
97
|
+
- What's the current pain point?
|
|
98
|
+
- What does success look like?
|
|
99
|
+
|
|
100
|
+
### Phase 2: Deep Dive (5-10 questions)
|
|
101
|
+
Systematically cover each category above. Use AskUserQuestion with multiple-choice options when possible to make answering easier.
|
|
102
|
+
|
|
103
|
+
### Phase 3: Edge Case Exploration (3-5 questions)
|
|
104
|
+
Focus on "what if" scenarios. These often reveal the most important requirements.
|
|
105
|
+
|
|
106
|
+
### Phase 4: Prioritization (2-3 questions)
|
|
107
|
+
Help the user distinguish must-haves from nice-to-haves.
|
|
108
|
+
|
|
109
|
+
### Phase 5: Validation (1-2 questions)
|
|
110
|
+
Summarize understanding and confirm before finalizing.
|
|
111
|
+
|
|
112
|
+
## AskUserQuestion Best Practices
|
|
113
|
+
|
|
114
|
+
### Structure Questions with Options
|
|
115
|
+
```
|
|
116
|
+
Question: "How should the system handle authentication failures?"
|
|
117
|
+
Options:
|
|
118
|
+
1. Show error and retry (simple)
|
|
119
|
+
2. Lock account after 3 attempts (secure)
|
|
120
|
+
3. Send email notification (audit trail)
|
|
121
|
+
4. Custom handling...
|
|
122
|
+
```
|
|
123
|
+
|
|
124
|
+
### Use multiSelect for Non-Exclusive Choices
|
|
125
|
+
```
|
|
126
|
+
Question: "Which platforms need to be supported?"
|
|
127
|
+
multiSelect: true
|
|
128
|
+
Options:
|
|
129
|
+
1. Web browser
|
|
130
|
+
2. iOS app
|
|
131
|
+
3. Android app
|
|
132
|
+
4. Desktop app
|
|
133
|
+
```
|
|
134
|
+
|
|
135
|
+
### Provide Context in Descriptions
|
|
136
|
+
Each option should explain implications, not just the choice itself.
|
|
137
|
+
|
|
138
|
+
## Interview Completion
|
|
139
|
+
|
|
140
|
+
When you've gathered sufficient information:
|
|
141
|
+
1. Summarize all requirements back to the user
|
|
142
|
+
2. Ask for confirmation using AskUserQuestion
|
|
143
|
+
3. Write the comprehensive spec to `SPEC.md` or a user-specified file
|
|
144
|
+
4. The spec should be detailed enough for implementation without further questions
|
|
145
|
+
|
|
146
|
+
## Spec Output Format
|
|
147
|
+
|
|
148
|
+
After interview completion, write a spec file with:
|
|
149
|
+
|
|
150
|
+
```markdown
|
|
151
|
+
# Feature Specification: [Feature Name]
|
|
152
|
+
|
|
153
|
+
## Overview
|
|
154
|
+
[1-2 sentence summary]
|
|
155
|
+
|
|
156
|
+
## User Stories
|
|
157
|
+
- As a [user type], I want [goal] so that [benefit]
|
|
158
|
+
|
|
159
|
+
## Requirements
|
|
160
|
+
|
|
161
|
+
### Must Have (P0)
|
|
162
|
+
- [ ] Requirement 1
|
|
163
|
+
- [ ] Requirement 2
|
|
164
|
+
|
|
165
|
+
### Should Have (P1)
|
|
166
|
+
- [ ] Requirement 3
|
|
167
|
+
|
|
168
|
+
### Nice to Have (P2)
|
|
169
|
+
- [ ] Requirement 4
|
|
170
|
+
|
|
171
|
+
## Technical Constraints
|
|
172
|
+
- [List technical requirements and limitations]
|
|
173
|
+
|
|
174
|
+
## UI/UX Requirements
|
|
175
|
+
- [List interface requirements]
|
|
176
|
+
|
|
177
|
+
## Edge Cases
|
|
178
|
+
| Scenario | Expected Behavior |
|
|
179
|
+
|----------|------------------|
|
|
180
|
+
| Case 1 | Behavior 1 |
|
|
181
|
+
|
|
182
|
+
## Out of Scope
|
|
183
|
+
- [Explicitly list what this feature does NOT include]
|
|
184
|
+
|
|
185
|
+
## Open Questions
|
|
186
|
+
- [Any unresolved items for future discussion]
|
|
187
|
+
```
|
|
188
|
+
|
|
189
|
+
## Interviewing Anti-Patterns to Avoid
|
|
190
|
+
|
|
191
|
+
1. **Assuming you know best** - Always verify assumptions
|
|
192
|
+
2. **Leading questions** - Don't bias the answer
|
|
193
|
+
3. **Stopping too early** - Keep probing until truly complete
|
|
194
|
+
4. **Ignoring contradictions** - Surface and resolve conflicts
|
|
195
|
+
5. **Forgetting to summarize** - Always validate understanding
|
|
196
|
+
6. **Skipping prioritization** - Everything can't be P0
|