Code Porter

🚚 Core Principle: I'm a Code Porter, who prefers adopting excellent open-source projects into my own projects. Avoid reinventing the wheel unless absolutely necessary.

🔴 First Rule: Adopt First, Modify Later

❌ Wrong mindset: "This is core logic, I need to write it myself"
✅ Correct mindset: "This is core logic, so I should look for mature solutions first—adopt then modify"

❌ Wrong mindset: "Security code is too important, I must implement it myself"  
✅ Correct mindset: "Security code is too important, writing it myself is riskier—use time-tested open-source libraries"

When to Use This Skill

• Implement a new feature or module
• Select technical solutions or libraries
• Evaluate whether you need to write code from scratch
• Look for existing solutions
• Integrate third-party services or APIs

Not For / Boundaries

• Projects with clear existing technical selections (follow the existing architecture)
• Pure learning practice projects (except deliberate practice)

⚠️ Common Misconceptions Corrected

• Trading systems? Check ccxt, hummingbot first
• Risk control engines? Check riskfolio-lib first
• Recommendation systems? Check surprise first

• Authentication? Use passport, next-auth
• Encryption? Use crypto-js, bcrypt
• JWT? Use jose, jsonwebtoken

Quick Reference

🎯 Adoption Decision Process

Requirement → Search for open-source solutions → Evaluate adaptability → Adopt/Integrate → Adapt and adjust
         ↓
    No suitable solution found → Minimal self-implementation

📋 Pre-Adoption Checklist

🔍 Search Strategies

# 1. Package manager search
npm search <keyword>
pip search <keyword>  # Or pip index versions <package>

# 2. GitHub search
# Sort by stars: stars:>1000 <keyword>
# Filter by language: language:typescript <keyword>
# Filter by recent updates: pushed:>2024-01-01 <keyword>

# 3. Awesome lists
# Search for "awesome-<domain>" repositories

✅ Open-Source Project Evaluation Criteria

🚫 Wheel-Reinvention Prohibited List

🔧 Adoption & Integration Patterns

npm install <package>
# Or
pnpm add <package>

// Source: https://github.com/xxx/yyy
// License: MIT
// Original Author: @author
// Modification Notes: Adapted for TypeScript types in this project

// ... Code ...

# 1. Fork the repository
# 2. Modify and adapt
# 3. Import as a git submodule or private package

// Reference: https://github.com/xxx/yyy/blob/main/src/utils.ts
// Rewritten based on the original implementation to adapt to this project's architecture

Examples

Example 1: Need to Implement WebSocket Real-Time Communication

1. Search for existing solutions:

   npm search websocket react

2. Found candidates:

   socket.io-client

   ,

   @tanstack/react-query

   + WebSocket,

   use-websocket

3. Evaluate

   use-websocket

   :
   • Stars: 1.8k ✅
   • Recent Update: 2024 ✅
   • TypeScript Support: Complete ✅
   • Documentation: Clear ✅
4. Decision: Use

   use-websocket

pnpm add react-use-websocket

import useWebSocket from 'react-use-websocket';

function MyComponent() {
  const { sendMessage, lastMessage } = useWebSocket('wss://api.example.com');
  // ...
}

Example 2: Need to Implement Markdown Rendering

1. Search:

   npm search markdown react

2. Candidates:

   react-markdown

   ,

   marked

   ,

   markdown-it

3. Evaluate

   react-markdown

   :
   • Stars: 12k+ ✅
   • Ecosystem: Supports remark/rehype plugins ✅
   • Code Highlighting: Works with

     react-syntax-highlighter

     ✅
4. Decision: Use

   react-markdown

   +

   react-syntax-highlighter

pnpm add react-markdown react-syntax-highlighter @types/react-syntax-highlighter

Example 3: Need to Implement Drag-and-Drop Sorting

1. Search:

   npm search drag drop react

2. Candidates:

   @dnd-kit/core

   ,

   react-beautiful-dnd

   ,

   react-dnd

3. Evaluate

   @dnd-kit

   :
   • Stars: 11k+ ✅
   • Maintenance: Active ✅
   • Performance: Excellent ✅
   • Accessibility: Supported ✅
4. Decision: Use

   @dnd-kit

pnpm add @dnd-kit/core @dnd-kit/sortable @dnd-kit/utilities

Adoption Workflow

Phase 1: Requirement Analysis

1. Clarify functional requirements
2. Determine technical constraints (language, framework, performance requirements)
3. Evaluate complexity

Phase 2: Solution Search

1. Package manager search
2. GitHub search (stars:>500)
3. Look for Awesome lists
4. Official documentation recommendations
5. Community discussions (Reddit, HN, Twitter)

Phase 3: Solution Evaluation

1. Activity check (recent commits, issue responses)
2. Quality check (tests, documentation, TypeScript support)
3. Compatibility check (dependency conflicts, version requirements)
4. License check (prefer MIT/Apache)
5. Security check (npm audit, snyk)

Phase 4: Integration Implementation

1. Install dependencies
2. Read documentation/examples
3. Write adaptation code
4. Test and verify
5. Document records (source, version, modifications)

References

• references/index.md

  : Navigation index

• references/awesome-lists.md

  : Summary of commonly used Awesome lists

• references/license-guide.md

  : Open-source license selection guide

Maintenance

• Sources: vibe-coding-cn methodology, open-source community best practices
• Last Updated: 2025-12-30
• Known Limits:
  • Evaluation criteria are empirical values and need to be adjusted according to specific scenarios
  • Mature open-source solutions may be lacking in certain fields