Skip to content

fix: make implement command technology-agnostic #45

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
brennercruvinel wants to merge 1 commit into from
Closed

fix: make implement command technology-agnostic #45

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
300 changes: 180 additions & 120 deletions commands/implement.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Smart Implementation Engine

I'll intelligently implement features from any source - GitHub, CodePen, local folders, or multiple references - adapting them perfectly to your project's architecture.
I'll intelligently implement features from any source - web URLs, local folders, or multiple references - adapting them perfectly to your project's architecture.

Arguments: `$ARGUMENTS` - URLs, paths, or descriptions of what to implement

Expand All @@ -10,8 +10,8 @@ Arguments: `$ARGUMENTS` - URLs, paths, or descriptions of what to implement
Let me analyze what type of implementation this is:

1. **Source Type Detection**
- Is this a GitHub URL? (github.com, raw.githubusercontent.com)
- Is this a CodePen/JSFiddle/CodeSandbox URL?
- Is this a web URL with source code?
- Is this a code sharing platform URL?
- Is this a local path? (starts with ./ or ../ or /)
- Is this a description for me to research?
- Are there multiple sources to combine?
Expand All @@ -34,7 +34,41 @@ Let me analyze what type of implementation this is:
- What to avoid or replace?
</think>

Based on what you've provided, I'll analyze and adapt the implementation:
Based on what you've provided, I'll analyze and adapt the implementation.

## SPECIAL CASE: Implementation Plans in Markdown

When you provide a .md file (like documentation.md), I understand this is an IMPLEMENTATION PLAN:

1. **Read the Plan Document**
- Understand the overall goal
- Identify all tasks/checklist items
- Note any specific requirements

2. **Analyze Current Progress**
- Check each checklist item: Done? Partially done? Not started?
- Use Grep/Read to verify what's already implemented
- Map plan items to actual code/files

3. **Continue Implementation**
- Start from where the plan left off
- NEVER redo completed work
- Check off items as I complete them
- Update progress in the plan

4. **Smart Verification**
- Before implementing: "Does this already exist?"
- After implementing: "Did I complete this correctly?"
- Continuous validation against the plan

## MY COMMITMENT: Complete Professional Analysis

I will:
- Read EVERY code file in EVERY directory
- Never skip files or read partially
- Analyze actual implementation, not assumptions
- Provide detailed technical understanding
- Count and report total files analyzed

## IMPORTANT: Complete File Reading

Expand All @@ -44,37 +78,62 @@ I will ALWAYS read files completely:
- No summarization: Complete code, not snippets
- Full analysis: Every line of every file

## Source Analysis - COMPLETE CODE EXAMINATION

I'll analyze EVERYTHING, not just docs:

**STEP 1: Find ALL Source Files**
Using Glob to locate:
- Common source directories (src/, lib/, app/, core/)
- All code files regardless of language
- Component/module directories
- Service/API directories
- Any custom project structure

**STEP 2: Read ACTUAL Implementation**
For EACH core file found:
- Read with NO LIMIT PARAMETER (gets entire file)
- NEVER use "limit: 100" or any other limit
- Get ALL lines, even if file has 10,000 lines
- Understand HOW it works, not just what docs say
- Analyze actual functions, classes, algorithms
- Map data flow and architecture

**STEP 3: Deep Feature Analysis**
- What does each component/function ACTUALLY do?
- How do they interact with each other?
- What's the real architecture (not what README claims)?
- What patterns and techniques are used?

**STEP 4: Only THEN Check Documentation**
- package.json for dependencies
- README for context
- But REAL understanding comes from CODE
## Source Analysis - EXHAUSTIVE CODE EXAMINATION

I'll analyze EVERY SINGLE FILE in EVERY repository:

**STEP 1: Map ENTIRE Repository Structure**
```
For EACH repository provided:
1. Use Glob "**/*.*" to find EVERY file
2. List ALL directories and subdirectories
3. Count total files to ensure nothing missed
4. Create complete file tree
```

**STEP 2: Systematic File Reading**
```
For EVERY code file found:
- Read ENTIRE file (no limit parameter)
- Components: Read every component file completely
- Services: Read all service implementations
- Utils: Read every utility function
- Tests: Read test files to understand usage
- Configs: Read all configuration files
- Routes: Read all routing/endpoint files
```

**STEP 3: Deep Component Analysis**
```
For component-based apps:
- Read EVERY component file in components/
- Understand props, state, methods
- Map component relationships
- Analyze data flow between components
- Check how components communicate
```

**STEP 4: Architecture Reconstruction**
```
From actual code reading:
- Entry points (main, index, app files)
- Core business logic location
- Data models and schemas
- API endpoints and handlers
- State management approach
- Dependency injection patterns
- Error handling strategies
```

**STEP 5: Cross-Repository Analysis**
```
When multiple repos provided:
- Compare architectures
- Identify best practices from each
- Find reusable patterns
- Understand different approaches
- Extract most efficient solutions
```

## Project Understanding

Expand Down Expand Up @@ -113,7 +172,7 @@ Critical checks before implementation:
</think>

I'll check your current dependencies and ensure compatibility:
- Read ENTIRE package.json/lock files (no line limits)
- Read ENTIRE dependency files (no line limits)
- Analyze COMPLETE dependency tree
- Check FULL documentation of existing packages
- Read ALL config files completely (no truncation)
Expand All @@ -124,10 +183,10 @@ I'll check your current dependencies and ensure compatibility:
Based on the source and target analysis, I need to:

1. **Smart Dependency Mapping**
- Source uses lodash.debounce → You already have lodash 4.x
- Source uses axios → You have fetch wrapper utilities
- Source uses old React patterns → Convert to your hooks
- Source has X dependency → Check if you have equivalent
- Map source dependencies to your existing ones
- Use your utilities instead of adding new ones
- Convert patterns to match your project
- Check for equivalent functionality

2. **Transform Code**
- Match your established patterns
Expand All @@ -136,7 +195,7 @@ Based on the source and target analysis, I need to:
- Maintain your state management style

3. **Ensure Quality**
- Follow your TypeScript strictness level
- Follow your project's code quality standards
- Match your testing patterns
- Use your linting rules
- Apply your security practices
Expand All @@ -155,7 +214,7 @@ I'll adapt the source code by:
2. **Smart Adaptation**
```
Example transformations:
- Old date library → Your existing date solution
- External date library → Your existing date solution
- Legacy HTTP calls → Your HTTP client
- Outdated patterns → Modern equivalents
- Old module system → Your module system
Expand All @@ -168,7 +227,7 @@ I'll adapt the source code by:
- Apply your code formatting

4. **Best Practices Application**
- Language-appropriate modern syntax
- Modern syntax appropriate for your project
- Proper error handling for your stack
- Accessibility considerations
- Performance optimizations
Expand All @@ -186,50 +245,35 @@ I'll proceed step by step:
## Common Use Cases

### 1. Single Source Implementation
```bash
/implement https://github.com/tanstack/table/tree/main/examples/react/sorting
```
I'll fetch, analyze, and adapt the sorting example to your project.
Provide a URL or path to analyze and adapt the code to your project.

### 2. Multiple Sources Combination
```bash
/implement https://github.com/user/auth https://codepen.io/user/pen/xyz
```
I'll intelligently merge features from multiple sources.

**For Multiple Repositories:**
- Analyze EACH repository's core functionality
- Read main source files, not just README
- Understand how each works internally
- Find best parts of each to combine
- Create unified implementation
Provide multiple URLs or paths to intelligently merge features from different sources.

### 3. Research and Implement
```bash
/implement "infinite scroll with virtual list"
```
I'll research best practices and implement an optimized version.
Describe what you need and I'll research best practices and implement an optimized version.

### 4. Local Folder Integration
```bash
/implement ./examples/payment-flow/
```
I'll analyze and integrate local example code.
Provide local paths to analyze and integrate existing code.

### 5. Library Migration
```bash
/implement migrate-from moment.js migrate-to date-fns
```
I'll help migrate from one library to another.
Specify what you're migrating from and to, and I'll help with the transition.

### 6. Implementation Plan Execution
Provide a .md file with implementation plan/checklist and I'll:
- Analyze what's been done
- Continue from where it stopped
- Never duplicate completed work
- Update progress as I go

## What I Actually Do

1. **CODE FIRST Analysis (Not Just Docs!)**
- Use Glob to find ALL source files
- Read ACTUAL implementation files
- Understand algorithms and logic
- See how features REALLY work
- THEN check package.json/docs
1. **EXHAUSTIVE Code Analysis**
- Use Glob "**/*" to find EVERY file in EVERY directory
- Read EACH file completely (no limits, no skipping)
- Map entire application architecture from code
- Understand every feature implementation
- Count files read to ensure completeness

2. **Intelligent Fetch**
- Use WebFetch for URLs with prompt: "Read ENTIRE file content, ALL lines, no summarization"
Expand Down Expand Up @@ -260,50 +304,66 @@ I'll help migrate from one library to another.

## Example Scenarios

```bash
# Scenario 1: Source uses outdated patterns
/implement https://github.com/old/jquery-plugin
# I'll convert jQuery to vanilla JS using your existing DOM utils

# Scenario 2: Source has security issues
/implement https://github.com/example/auth-system
# I'll fix SQL injection risks and use your auth middleware

# Scenario 3: Source is bloated
/implement "rich text editor"
# I'll find lightweight alternative matching your bundle size goals
```
I'll handle various scenarios:
- Sources with outdated patterns: Convert to modern approaches
- Sources with security issues: Fix vulnerabilities
- Sources that are bloated: Find lightweight alternatives

The key difference: I don't just adapt code - I ensure it fits perfectly with your existing setup, uses what you already have, and follows current best practices.

## CRITICAL: Analyzing Multiple Cloned Repositories

When you provide multiple cloned repos, I will:

1. **Explore Each Repository's CODE**:
```
repo1/
├── src/ Read ALL source files
├── components/ Understand EACH component
└── lib/ Analyze core logic

repo2/
├── src/ Read implementation
├── api/ Understand endpoints
└── utils/ Check utilities
```

2. **Deep Dive into Functionality**:
- NOT just "repo1 has authentication, repo2 has UI"
- BUT: "repo1 implements token-based auth with automatic refresh"
- AND: "repo2 uses performance optimization for large lists"

3. **Extract and Combine Best Parts**:
- Take auth logic from repo1
- Take UI components from repo2
- Merge data handling from repo3
- Create unified, optimized implementation

4. **No Superficial Analysis**:
- Avoid: "This repo seems to handle authentication"
- Instead: "This repo implements secure token-based authentication with automatic session management"
## Implementation Plan Analysis

When working with .md implementation plans, I follow this careful process:

### Understanding Checklist Format
I recognize various checklist formats:
- [ ] Not started task
- [x] Completed task
- [~] Partially completed task
- TODO: Task description
- DONE: Completed task
- WIP: Work in progress

### Verification Process
Before implementing any task:
1. Check if files/functions mentioned already exist
2. Use Grep to search for implementations
3. Read existing code to understand current state
4. Only implement what's actually missing

### Progress Tracking
As I work:
- Update checklist items from [ ] to [x]
- Add notes about what was implemented
- Document any deviations from the plan
- Create clear commit messages referencing plan items

## CRITICAL: Complete Repository Analysis Strategy

When analyzing multiple repositories, I follow this EXHAUSTIVE approach:

### 1. **Complete File Discovery**
Use Glob patterns to find all files in all directories.
Read every file found, regardless of type or location.

### 2. **Systematic Component Reading**
Read every single file found in every directory.
No exceptions, no skipping, complete analysis.

### 3. **Implementation Detail Extraction**
Extract specific implementation details, not generic descriptions.
Understand exact patterns, algorithms, and approaches used.

### 4. **Professional Analysis Output**
Report complete analysis with:
- Total files analyzed
- Core features identified
- Architectural patterns found
- Key implementations to extract

### 5. **Nothing Gets Missed**
- Config files: Read ALL
- Test files: Read to understand usage
- Documentation: Read AFTER code
- Hidden files: Check environment examples, ignore files
- Build files: Understand project setup
Loading