Jesse is a mature, full-stack algorithmic trading framework designed for cryptocurrency backtesting, live/paper trading, hyperparameter optimization, Monte Carlo simulation, and rule significance testing. It combines a Python library with a FastAPI web server and a Nuxt.js dashboard, offering a comprehensive environment for developing and validating trading strategies. The repository also includes an MCP (Model Context Protocol) server for AI-assistant integration, over 180 technical indicators (many with Rust-accelerated backends), and a research API for programmatic strategy analysis. Architecture is modular with distinct layers: CLI entrypoint → web controllers / MCP tools → service layer → simulation engine (backtest/optimize/live) → exchange adapters. State management uses global singletons for in-memory simulation state, while persistent data is stored via Peewee ORM (PostgreSQL, optional TimescaleDB). The indicator library showcases a clean pattern with sequential/non-sequential modes and Rust fallback. However, the codebase shows signs of organic growth with some tightly coupled modules (global config, store singletons) and a large static frontend bundle that is opaque to analysis. Key strengths include the breadth of supported exchanges (10+), robust backtesting with realistic fee/margin/leverage modeling, and a well-designed MCP tool layer for AI-assisted development. Weaknesses include exchange driver duplication, a complex Rust subprocess for coordination, and dependency on many external APIs that require ongoing maintenance.
This repository is a Node.js GitHub Bot that automates tasks in response to GitHub and Jenkins webhooks. It uses an Express.js server to receive webhooks, validates GitHub signatures, and emits normalized events via a central event emitter. Scripts in the `scripts` directory listen for these events to perform actions such as commenting on pull requests, updating GitHub status checks based on Jenkins builds, and enforcing CODEOWNERS reviews. The architecture separates webhook reception from processing, allowing for extensibility through additional scripts.
This is a WhatsApp messaging API built with Node.js, TypeScript, and Express. The system provides REST endpoints for user authentication, WhatsApp number registration (via QR code), message sending (with scheduling and media support), and user/token management. Architecture follows a layered approach: API controllers delegate to service classes, which use TypeORM repositories for data access. A separate worker process continuously polls the database for pending messages and sends them via WhatsApp using a sophisticated custom client manager that handles multiple WhatsApp sessions, QR code authentication, session persistence, and connection recovery. The WhatsApp client implementation (src/whatsapp/client/index.ts) demonstrates significant skill in managing the complexities of the whatsapp-web.js library, including proper resource cleanup, timeout handling, and state management across multiple concurrent connections.
OsEngine is a comprehensive, multi-exchange algorithmic trading platform for desktop (WPF/WinForms hybrid). It provides data downloading (OsData), backtesting (OsTester), walk-forward optimization (OsOptimizer), and live trading (OsTrader) with support for 30+ exchange connectors (MOEX, Binance, Bybit, OKX, Interactive Brokers, etc.). The platform includes a built-in technical indicator library (100+ indicators), a trading robot framework with attribute-based registration, and an MCP (Model Context Protocol) API for external AI/automation control. The architecture is modular: separate executables for different modes, a common server abstraction layer, and a consistent parameter system for bots and indicators. While the codebase is large and well-organized, it suffers from significant duplication across exchange connector entity classes and some copy-paste logic in trading robots. The UI mixes WPF and Windows Forms, and some patterns are legacy. Overall, it is a production-grade algorithmic trading platform with strong engineering practices and a rich feature set.
esmBot is a feature-rich Discord bot focused on image manipulation, music playback, and server management. It leverages Oceanic.js for Discord API interaction, native C++ addons built on libvips for high-performance image processing, and Lavalink for music streaming. The bot supports both classic prefix commands and Discord slash commands, with a modular command class hierarchy that simplifies adding new features. It includes a database abstraction layer (SQLite or PostgreSQL), a localization system supporting 20+ languages, and a pagination utility for interactive embeds. The bot can run in a clustered PM2 environment and optionally operate a separate media API server for distributed processing. While the codebase demonstrates good engineering practices with clean abstractions, it has some security concerns (an eval/exec command), incomplete translations, and a complex native build process that may introduce maintenance overhead.
AzurLaneAutoScript (ALAS) is a Python-based game automation bot for the mobile game Azur Lane. It uses computer vision (OpenCV, template matching, OCR via cnocr/mxnet) and Android Debug Bridge (ADB) to control an emulator, automating nearly all gameplay loops: campaign sorties, daily missions, research, dormitory, guild operations, Operation Siren, and event-specific maps. The architecture is modular, with a core framework providing device abstraction (module/device), image recognition (module/ocr, module/map_detection), configuration management (module/config), and a web UI (module/webui) built on PyWebIO with an Electron wrapper. Campaign logic is organized into hundreds of per-event map scripts under campaign/, each defining map grids, enemy spawns, and battle strategies via a consistent CampaignBase subclass pattern. The system runs as a daemon, continuously executing scheduled tasks with configurable priorities and notifications (onepush, Discord). External dependencies include uiautomator2, adbutils, OpenCV, cnocr, mxnet, pywebio, and zerorpc, with pinned versions targeting Python 3.7. The codebase is actively maintained with frequent updates for new game events, but suffers from significant duplication across campaign files and reliance on outdated library versions.
Trainbot (Onlytrains) is a computer vision application that automatically detects trains passing a fixed camera, stitches the train's frames into a single composite image, and logs sightings to a SQLite database. It is designed to run on a Raspberry Pi with a camera (USB, Pi Cam 3, or video file) and can optionally upload results via FTP to a web server. The project is unmaintained as stated in the README. Architecturally, it is a monolith Go backend with three CLI binaries: `trainbot` (main detection loop), `confighelper` (interactive crop selection), and `cleanup` (orphaned blob removal). The backend captures frames using `pkg/vid` (abstraction over V4L2, libcamera-vid, ffmpeg), processes them through a stitch pipeline that detects motion, computes frame offsets via patch matching, fits a constant-acceleration model using RANSAC, and then blends frames into a single JPEG and an animated GIF. Results are stored in a SQLite database and served by a built-in HTTP server. The frontend is a Vue 3 static SPA that loads the SQLite database client-side to display train sightings, stats, and images with no server-side rendering. Key highlights include highly optimized image processing: the `pkg/pmatch` package offers four implementations of cosine-similarity patch search (slow Go, optimized Go, Cgo, Vulkan compute), and the `pkg/ransac` package provides a generic RANSAC fitter for the speed model. The codebase demonstrates strong engineering craftsmanship with a clear package structure, extensive tests, test data sets, and a CI pipeline. However, heavy reliance on Cgo and Vulkan, plus the explicit unmaintained status, introduce cross-compilation complexity and potential drift from modern tooling.
This is the umbrella monorepo for Evo CRM Community, an open-source AI-powered customer support platform. The repository itself does not contain application source code; it orchestrates seven independent microservices (auth, CRM, frontend, AI processor, core service, bot runtime, and event flow) via Git submodules and Docker Compose/Swarm configurations. The primary function of this repo is to provide a single entry point for cloning, building, seeding, and deploying the full stack. It includes a nginx API gateway for path-based routing to backend services, CI/CD workflows for building and publishing Docker images, migration version collision guards, and extensive release documentation. The actual business logic, AI agent execution, conversation management, and user interface reside in the submodules.
Botdarr is a Java-based chat bot application that integrates with Radarr, Sonarr, and Lidarr media management services, allowing users to search, add, and monitor movies, TV shows, and music via chat platforms (Discord, Slack, Telegram, Matrix). The system uses a monolithic architecture with modular packages: API clients for each media service, command processing, chat platform adapters, and a SQLite database for persistence (e.g., user request limits, callback data). The main entry point is `BotdarrApplication`, which initializes the configured chat client and starts listening for commands. Data flows: user messages are received by the chat client, parsed by `CommandProcessor`, which executes commands that call the media service APIs (via `RadarrApi`, `SonarrApi`, `LidarrApi`), and responses are formatted by platform-specific `ChatClientResponseBuilder` implementations before being sent back. External dependencies include Apache HttpClient, Jackson, JDA (Discord), Slack SDK, Telegram Bot API, Matrix client-server API, and Flyway for database migrations. The codebase demonstrates solid engineering with strategy patterns for lookup/add/downloads, a command pattern for user interactions, and a clean abstraction for chat client response formatting. However, it suffers from technical drift due to reliance on Java 8, outdated libraries (JMockit 1.40, Jackson 2.13.4.1), and manual versioning. The Matrix client support appears incomplete, and response formatting logic is duplicated across platforms, increasing maintenance burden.
This repository contains Toxic-MD, a WhatsApp multi-device bot built on Node.js using the Baileys library (reverse-engineered WhatsApp Web API). It is a plugin-based application that handles incoming WhatsApp messages, processes commands from over 200 plugins organized by category (General, Groups, Owner, AI, Downloads, Editing, Settings, etc.), and executes actions such as group administration (anti-link, anti-badword, welcome messages, warn/kick), media downloads (YouTube, TikTok, Instagram), AI chat (via Groq/Llama), image/sticker editing, and privacy toggles. The bot maintains persistent settings in a PostgreSQL database (with a JSON file fallback), including global and per-group configurations, warn limits, banned users, and conversation history for AI context. It runs as a long-lived process with auto-reconnection, an Express health server, and supports deployment on Heroku, Railway, and traditional Node.js hosts. Architecturally, the bot is a monolith with a central message router in `src/toxic.js`, a dynamic plugin loader in `handlers/commandHandler.js`, and a set of background features (`features/`) that listen to events like group joins, sticker sends, and anti-spam triggers. The codebase is moderately complex, using global state objects (e.g., `_toxicMsgCounts`, `lidPhoneCache`) and patching the Baileys library at startup to adjust timeouts and event buffering. External dependencies include Express, Groq API, various download services (Nexray, qu.ax, uguu.se), and media utilities (ffmpeg, sharp, wa-sticker-formatter). The bot's command structure is consistent: each plugin exports `name`, `aliases`, `description`, and a `run(context)` function, enabling extensibility. However, the code exhibits several quality issues: no test suite, heavy use of global variables, hardcoded developer phone numbers, repetitive toggle commands, and obfuscated API keys in `keys.js`. Despite these shortcomings, the bot is functional and widely forked (1587 forks), indicating practical utility in the WhatsApp bot community.
Instabot is a Python library and CLI tool for automating Instagram actions such as liking, commenting, following, unfollowing, uploading photos/videos, and direct messaging. It operates by reverse-engineering Instagram's private API, simulating an Android client with device fingerprints, session cookies, and request signing. The architecture consists of a low-level API wrapper (`instabot.api.API`) that handles HTTP requests and login flow, and a high-level Bot class (`instabot.bot.Bot`) that orchestrates actions with built-in rate limiting, filtering, and checkpointing. The repository includes over 30 example scripts for common automation tasks, a multi-script CLI menu, and a scheduled 24/7 bot. External dependencies include `requests`, `Pillow`, `moviepy`, and `pycryptodome`. The project is no longer actively maintained and carries high risk of Instagram account bans due to ToS violations. The README now promotes paid private API services, indicating the open-source codebase is effectively deprecated.
This repository claims to be a Solana trading bot hub but contains ZERO actual trading bot code. The entire codebase consists of only 3 files: .gitignore, README.md, and one image asset. The README is purely a marketing landing page with affiliate/referral links to external trading platforms (Axiom, Odin Bot, Bloom, Trojan, GMGN, Padre, etc.). There are no Python, TypeScript, Rust, or any other programming language source files. No package manifests, no configuration files, no actual bot implementations. This is effectively a placeholder repository designed to drive traffic to affiliate partners, not a functional software project. The repository structure suggests it was created solely for SEO/marketing purposes with no intention of providing reusable code or actual trading bot implementations.
This repository contains no application source code. The only substantive file is a GitHub Actions workflow (clawsweeper-dispatch.yml) that acts as a dispatch router for the ClawSweeper bot, forwarding GitHub events (issues, issue comments, pull requests) to the openclaw/clawsweeper repository. The workflow uses a GitHub App token for authentication and includes debouncing, comment filtering, and acknowledgment logic. The repository itself is essentially a configuration stub—there are no scripts, binaries, or libraries. The bot's actual logic resides elsewhere. The repo appears to be a placeholder or thin integration layer, with no functional code to evaluate for craftsmanship or reusability.