76 lines
2.1 KiB
Markdown
76 lines
2.1 KiB
Markdown
---
|
|
name: search-first
|
|
description: Research-before-coding workflow. Search web, docs, and codebase before writing code. Use when: unfamiliar tech, library selection, API design, solving errors you haven't seen, architecture decisions.
|
|
---
|
|
|
|
# Search-First Workflow
|
|
|
|
Based on ECC search-first skill. Research BEFORE implementation decisions.
|
|
|
|
## When to Use This Flow
|
|
|
|
Before starting ANY new feature, library integration, or architecture decision, follow this flow.
|
|
|
|
## The Flow
|
|
|
|
### 1. Understand the Problem
|
|
- Read requirements fully
|
|
- Identify unknowns or assumptions
|
|
- List what you NEED to know vs what's nice to know
|
|
|
|
### 2. Search Existing Codebase First
|
|
```bash
|
|
# Search for similar implementations
|
|
grep -rn "pattern" src/
|
|
# Check existing dependencies
|
|
cat package.json | grep "search_term"
|
|
cat pyproject.toml
|
|
cat go.mod
|
|
# Check existing tests for patterns
|
|
grep -rn "describe" **/tests/ # or equivalent
|
|
```
|
|
|
|
### 3. Search Documentation
|
|
- Official docs first
|
|
- API reference
|
|
- Migration guides (if upgrading)
|
|
- GitHub issues (known problems, workarounds)
|
|
|
|
### 4. Search Web
|
|
```
|
|
query examples:
|
|
- "[library] best practices 2024 2025"
|
|
- "[library] equivalent of [other_library] pattern"
|
|
- "[framework] common pitfalls"
|
|
- "[tech] performance optimization patterns"
|
|
```
|
|
|
|
### 5. Synthesize Findings
|
|
- Compare 2-3 approaches
|
|
- Document trade-offs
|
|
- Select the BEST approach with reasoning
|
|
- Note any caveats or gotchas discovered
|
|
|
|
### 6. Design THEN Implement
|
|
- Write brief design doc if complex
|
|
- Get approval if needed
|
|
- THEN start coding
|
|
|
|
## Anti-Patterns to Avoid
|
|
|
|
- Jumping straight into code without research
|
|
- Using outdated patterns (check dates)
|
|
- Choosing first library without comparing alternatives
|
|
- Skipping codebase search (reinventing existing solutions)
|
|
- Ignoring migration notes (breaking changes)
|
|
|
|
## Research Checklist
|
|
|
|
Before coding:
|
|
- [ ] Searched codebase for existing patterns?
|
|
- [ ] Read official docs for version being used?
|
|
- [ ] Compared at least 2 approaches/libraries?
|
|
- [ ] Read recent GitHub issues for known problems?
|
|
- [ ] Verified compatibility with existing dependencies?
|
|
- [ ] Checked performance benchmarks if relevant?
|