Onboarding: hmjz100/LinkSwift

Generated by RepoPilot · 2026-05-06 · Source

Agent protocol

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/hmjz100/LinkSwift shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

Verdict

WAIT — Single-maintainer risk — review before adopting

• Last commit 3d ago
• 2 active contributors
• AGPL-3.0 licensed
• ⚠ Small team — 2 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 98% of recent commits
• ⚠ AGPL-3.0 is copyleft — check downstream compatibility
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

Verify before trusting

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live hmjz100/LinkSwift repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/hmjz100/LinkSwift.

What it runs against: a local clone of hmjz100/LinkSwift — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in hmjz100/LinkSwift | Confirms the artifact applies here, not a fork | | 2 | License is still AGPL-3.0 | Catches relicense before you depend on it | | 3 | Default branch dev exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 33 days ago | Catches sudden abandonment since generation |

<details> <summary><b>Run all checks</b> — paste this script from inside your clone of <code>hmjz100/LinkSwift</code></summary>

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of hmjz100/LinkSwift. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/hmjz100/LinkSwift.git
#   cd LinkSwift
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of hmjz100/LinkSwift and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "hmjz100/LinkSwift(\\.git)?\\b" \\
  && ok "origin remote is hmjz100/LinkSwift" \\
  || miss "origin remote is not hmjz100/LinkSwift (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(AGPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"AGPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is AGPL-3.0" \\
  || miss "license drift — was AGPL-3.0 at generation time"

# 3. Default branch
git rev-parse --verify dev >/dev/null 2>&1 \\
  && ok "default branch dev exists" \\
  || miss "default branch dev no longer exists"

# 4. Critical files exist
test -f "（改）网盘直链下载助手.user.js" \\
  && ok "（改）网盘直链下载助手.user.js" \\
  || miss "missing critical file: （改）网盘直链下载助手.user.js"
test -f "（改）百度网盘会员青春版.user.js" \\
  && ok "（改）百度网盘会员青春版.user.js" \\
  || miss "missing critical file: （改）百度网盘会员青春版.user.js"
test -f "config/config.json" \\
  && ok "config/config.json" \\
  || miss "missing critical file: config/config.json"
test -f "config/ali.json" \\
  && ok "config/ali.json" \\
  || miss "missing critical file: config/ali.json"
test -f "config/quark.json" \\
  && ok "config/quark.json" \\
  || miss "missing critical file: config/quark.json"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 33 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~3d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/hmjz100/LinkSwift"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

</details>

TL;DR

LinkSwift is a Tampermonkey/Greasemonkey userscript that extracts direct download links from 8 Chinese cloud storage platforms (Baidu, Aliyun, China Mobile, Tianyi, Xunlei, Quark, UC, 123pan). It injects JavaScript into the web pages of these services to bypass their web interfaces and expose downloadable file URLs, enabling users to download files without using the official clients or web UIs. Flat structure: two root-level userscript files (（改）网盘直链下载助手.user.js and （改）百度网盘会员青春版.user.js) contain the main logic, with platform-specific configs in config/ directory (ali.json, quark.json, tianyi.json, xunlei.json, yidong.json). A single CSS file (default.min.css) provides UI styling. No modular library structure—logic is inline in the userscripts.

Who it's for

Chinese users who frequently download files from multiple cloud storage providers and want a unified, browser-integrated tool to get direct download links without installing separate client applications or navigating each platform's web interface.

Maturity & risk

Actively maintained and production-ready with version 1.1.3.1 and recent updates. The repo contains 606KB of JavaScript code spread across 2 main userscript files and config files for each cloud service. However, there is no visible test suite (package.json has no test implementation), no CI/CD pipeline visible (.github has only issue templates and contributing guidelines), and commit recency is unclear from the provided data.

Single-maintainer repo (hmjz100) with minimal dependencies (only dev tools: eslint, @eslint/js). Primary risk is that cloud storage APIs change frequently and each platform's anti-scraping protections can break the extraction logic—requiring rapid maintenance cycles. AGPL-3.0 license means any derivative must remain open-source. No visible issue resolution SLA or community contribution infrastructure.

Active areas of work

Cannot determine from provided data. No recent commit history, PR list, or milestones are visible. The README mentions migrating users away from GreasyFork due to maintenance risks, suggesting ongoing deployment/distribution strategy changes rather than feature development.

Get running

Check README for instructions.

Daily commands: Not a traditional Node.js app. After npm install, run npm run check to lint the code. To use: install the .user.js file into Tampermonkey/Greasemonkey extension in your browser, then visit a supported cloud storage website—the script auto-injects buttons/UI to extract direct download links.

Map of the codebase

• （改）网盘直链下载助手.user.js — Main userscript entry point that orchestrates cloud disk detection and direct link extraction across all 8 supported platforms.
• （改）百度网盘会员青春版.user.js — Baidu Netdisk-specific implementation handling member features and session-based authentication for link generation.
• config/config.json — Core configuration file defining API endpoints, headers, and request patterns for all cloud disk services.
• config/ali.json — Alibaba Cloud Disk (阿里云盘) specific configuration with API routes and authentication parameters.
• config/quark.json — Quark Cloud Disk configuration containing API endpoints and encryption/decryption logic for link extraction.
• package.json — Declares project metadata, ESLint tooling, and semantic versioning for the userscript ecosystem.

Components & responsibilities

• Main Userscript Entry (网盘直链下载助手.user.js) (JavaScript, DOM API, fetch/XMLHttpRequest, URL pattern matching) — Detects cloud disk URL, loads appropriate config, dispatches API calls, injects UI, and manages user interactions
  • Failure mode: Script fails silently if URL pattern doesn't match; API errors show no feedback to user; missing config file stops execution
• Baidu-Specific Script (百度网盘会员青春版.user.js) (JavaScript, Baidu API, session token management) — Extracts Baidu session tokens, manages member-only download quotas, and handles Baidu's unique token refresh mechanism
  • Failure mode: If Baidu token format changes, script returns invalid download links; no fallback for member-only files
• Config Loader (JSON parsing, fetch API,) — Fetches and parses JSON configs (ali.json, quark.json, etc.) to determine API endpoints and request formats per platform

How to make changes

Add Support for a New Cloud Disk Platform

1. Create a new JSON config file in config/ directory following the pattern of existing files (e.g., config/newdisk.json) with API endpoints, authentication headers, and request/response structures (config/newdisk.json)
2. Add the new platform's URL pattern matcher and config reference to the main dispatcher in the universal userscript (（改）网盘直链下载助手.user.js)
3. Implement platform-specific API call logic (token exchange, link encryption/decryption) by extending the existing request handler pattern used for Quark/Ali/Xunlei (（改）网盘直链下载助手.user.js)
4. Update README.md to list the new platform in the supported services section and add installation instructions if needed (README.md)

Modify API Endpoint or Authentication for Existing Platform

1. Edit the target platform's JSON config (e.g., config/ali.json) to update API host, authentication endpoint, or request headers (config/ali.json)
2. If authentication flow changed, update the corresponding token exchange or session handling logic in the main userscript (（改）网盘直链下载助手.user.js)
3. Test the changes by running ESLint to catch syntax errors and then manually verify on the cloud disk website (eslint.config.mjs)

Update UI Display or Styling for Download Links

1. Modify the CSS classes and visual layout in the stylesheet to adjust modal appearance, button styles, or text formatting (default.min.css)
2. Update the HTML injection code in the userscript that creates and displays the download link UI modal (（改）网盘直链下载助手.user.js)
3. Test the updated UI by running the script on a cloud disk page and verifying modal rendering and responsiveness (default.min.css)

Why these technologies

• Userscript (Tampermonkey/Greasemonkey/ScriptCat) — Enables browser-side injection without modifying cloud disk websites; works transparently in user's browser context with access to page DOM and cookies
• JSON Configuration Files — Decouples API endpoint management from script logic, allowing rapid updates when cloud disk services change APIs without redeploying the entire script
• JavaScript (ES6+) — Native browser language for DOM manipulation, HTTP requests, and session token handling; no build step needed for distribution
• ESLint with @eslint/js — Maintains code quality and consistency across community contributions; catches syntax errors before userscript execution

Trade-offs already made

• Userscript-based approach over browser extension

  • Why: Easier distribution (GreasyFork, ScriptCat); no store approval process; instant deployment via CDN or raw GitHub links
  • Consequence: Limited to same-origin browser APIs; requires users to manually install on supported userscript managers; cannot persist data across browser sessions reliably

• JSON config files instead of hardcoded endpoints

  • Why: Platform changes (API rewrites, endpoint URLs) can be updated without modifying core script logic
  • Consequence: Adds file management overhead; config versioning challenges if APIs diverge significantly; requires config file to be fetched/bundled at runtime

• Support for 8 disparate cloud disk platforms

  • Why: Maximizes utility for users across different regions (Baidu=China, Ali=Enterprise, Quark=New, TC Telecom=Gov, etc.)
  • Consequence: High maintenance burden; each platform has unique auth, encryption, and API changes; no unified interface

• Minified CSS in single file vs. modular styles

  • Why: Reduces bundle size for faster injection and reduces HTTP requests in userscript context
  • Consequence: Harder to maintain and modify styles; no SCSS/PostCSS toolchain; must manually minify on updates

Non-goals (don't propose these)

• Does not provide server-side link generation or API backend—runs entirely in the user's browser
• Does not handle login/authentication—relies on user's existing session cookies in the browser
• Does not support batch download automation—extracts links one at a time for manual download
• Does not work on non-Chromium browsers without userscript manager support (Firefox support depends on Tampermonkey availability)
• Does not implement cloud disk file browsing UI—only extracts direct links for files already visible on the cloud disk website

Traps & gotchas

1. Platform API stability: Each of the 8 cloud services can change their internal APIs or authentication flows without notice, breaking the extraction logic. 2. Userscript runtime environment: Code runs under Tampermonkey sandbox with CSP and cross-origin restrictions—direct XHR may be blocked on some domains. 3. No server backend: All logic is client-side; cannot use server-side proxies or session management, limiting ability to bypass certain anti-bot measures. 4. License compliance: AGPL-3.0 requires disclosing source code in any distribution; ensure derivative works link back to this repo. 5. Config JSON format: No visible JSON schema validation—malformed config files will silently fail at runtime.

Architecture

Concepts to learn

• Userscript Content Script Injection — LinkSwift's entire architecture depends on injecting JavaScript into web pages via Tampermonkey—understanding DOM patching, timing, and the userscript lifecycle is fundamental to modifying extraction logic
• HTTP Request/Response Interception (XHR/Fetch Hooks) — The script intercepts cloud service API calls to extract link data; knowing how to hook XMLHttpRequest or Fetch API is critical to adding new platforms or debugging extraction failures
• API Authentication & Session Management — Each cloud service uses different auth schemes (cookies, tokens, signatures); contributors must understand how to preserve user sessions and pass authentication through intercepted requests
• Browser Same-Origin Policy & CORS — Userscripts run under CSP; direct cross-origin requests may be blocked, requiring GM_xmlhttpRequest or other workarounds specific to the Tampermonkey sandbox
• API Endpoint Reverse-Engineering — LinkSwift works by observing cloud service internal APIs (not public); contributors must use browser DevTools to trace requests and update config JSONs when APIs change
• Configuration-Driven Service Abstraction — Platform logic is partially defined in JSON configs (config/*.json) rather than code; understanding this pattern allows adding new services without modifying core scripts
• Anti-Bot & Rate-Limiting Evasion — Cloud services employ anti-scraping measures; LinkSwift must blend in as a real user (headers, delays, session reuse) to avoid being blocked

Related repos

• PanDownload/PanDownload-Python — CLI tool for Baidu cloud downloads; overlaps on the Baidu platform but uses Python backend instead of browser injection
• aliyun/aliyun-oss-js-sdk — Official Aliyun SDK for JavaScript; LinkSwift integrates with Aliyun's internals and could benefit from understanding their public API surface
• hmjz100/123panYouthMember — Companion script by same author targeting 123pan cloud storage membership features; shares architecture and contributes to LinkSwift's broader multi-platform ecosystem
• GreasyFork/greasyfork — Primary distribution platform for userscripts like LinkSwift; understanding GreasyFork's policies and update mechanisms is critical for deployment
• Tampermonkey/tampermonkey — Runtime environment for this userscript; knowledge of Tampermonkey's API (GM_xmlhttpRequest, GM_setClipboard, @match patterns) is essential for development

PR ideas

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add GitHub Actions CI workflow for ESLint validation on pull requests

The repo has ESLint configured (eslint.config.mjs, @eslint/js, eslint in devDependencies) and a 'check' script, but no automated CI pipeline. This means code quality issues can slip into main without automatic validation. A simple GitHub Actions workflow would run eslint on every PR to catch style violations early, consistent with the AGPL-3.0 license requirements for code quality in open source.

• [ ] Create .github/workflows/lint.yml with job to run 'npm run check' on pull_request events
• [ ] Ensure workflow runs on Node.js LTS version
• [ ] Add step to fail workflow if eslint finds issues (already in eslint.config.mjs setup)
• [ ] Test locally with 'npm run check' against the two main script files: '（改）网盘直链下载助手.user.js' and '（改）百度网盘会员青春版.user.js'

Document configuration files with inline comments and separate CONFIG.md

The config/ directory contains 6 JSON files (ali.json, config.json, quark.json, tianyi.json, xunlei.json, yidong.json) for different cloud storage providers, but there is no documentation explaining their structure, purpose, or how contributors should modify them. This creates a barrier for contributors wanting to add new cloud providers or fix existing ones.

• [ ] Create docs/CONFIG.md explaining the structure of each config file and which cloud provider it maps to
• [ ] Add JSDoc-style comments inside config/config.json (and other critical configs) documenting required fields
• [ ] Document which user scripts consume which config files (e.g., which script uses config/ali.json for 阿里云盘)
• [ ] Add a section explaining how to add a new cloud provider config

Add unit test suite for config file validation and user script initialization

The package.json has a placeholder test script ('Error: no test specified'), and there are 8 different cloud storage provider integrations. Without tests, refactoring config structures or script initialization logic risks breaking multiple providers silently. A test suite would ensure config files are valid JSON and required fields exist.

• [ ] Create tests/config.test.js that validates all config/*.json files parse correctly and contain required fields (e.g., API endpoints, authentication parameters)
• [ ] Create tests/provider-mapping.test.js that verifies each user script can load the appropriate config without errors
• [ ] Update package.json test script to run tests (e.g., 'jest' or 'node tests/*.test.js')
• [ ] Add jest or similar test framework to devDependencies (optional: keep minimal, use Node's built-in assert module)

Good first issues

• Add a test suite under test/ directory with Jest or Mocha that validates each platform's config JSON structure (config/*.json) against a schema, and tests the URL extraction regex patterns in isolation
• Create missing platform-specific documentation: add docs/PLATFORMS.md listing each of the 8 supported services with example URLs, known limitations, and last-verified dates
• Extract the inline service detection and API-calling logic from the main .user.js file into modular functions in a new src/ directory (e.g., src/services/ali.js, src/services/baidu.js) and refactor the main scripts to import from there, improving maintainability

Top contributors

• @hmjz100 — 98 commits
• @Night-stars-1 — 2 commits

Recent commits

• 615731f — 移除：123 云盘的 “notoken” 逻辑 (hmjz100)
• 5c867a1 — 适配 - 123 云盘 260427 升级 (hmjz100)
• 72a9230 — 优化：增强下载的逻辑 (hmjz100)
• 91f4be5 — 更新：说明文件 (hmjz100)
• 5b1a03a — 更改：版本号及更新日志 (hmjz100)
• fa66fa1 — 修复：光鸭云盘未点亮时的按钮 (hmjz100)
• f1ce34a — 新增：适配光鸭云盘 (hmjz100)
• e2f7886 — 修复：Aria2 POST 推送类型、ABDM 推送请求头格式化 (hmjz100)
• 6155ad4 — 优化：使用 eslint 处理 (hmjz100)
• 65749fe — 修复：来源请求头 (hmjz100)

Security observations

The LinkSwift userscript project shows moderate security concerns. The primary risks stem from: (1) potential XSS vulnerabilities inherent to userscript DOM manipulation, (2) possible credential exposure in configuration files and API interactions, (3) lack of input validation framework, and (4) absence of security testing infrastructure. The project lacks comprehensive security best practices including automated vulnerability scanning, proper credential management, and

• High · Potential XSS Vulnerability in Userscript — （改）网盘直链下载助手.user.js, （改）百度网盘会员青春版.user.js. The project appears to be a userscript that interacts with web pages and may manipulate DOM elements. Without reviewing the actual script content, the nature of userscripts (which typically inject JavaScript into web pages) poses inherent XSS risks if user input or external data is not properly sanitized before being inserted into the DOM. Fix: Ensure all dynamic content insertion uses safe DOM methods (textContent instead of innerHTML). Validate and sanitize all external data before DOM insertion. Implement Content Security Policy where applicable.
• Medium · Configuration Files May Contain Sensitive Data — config/ali.json, config/config.json, config/quark.json, config/tianyi.json, config/xunlei.json, config/yidong.json. Configuration files in the /config directory (ali.json, config.json, quark.json, tianyi.json, xunlei.json, yidong.json) may contain API endpoints, tokens, or other sensitive information. If these are committed to the repository, they could expose credentials or authentication details. Fix: Move sensitive configuration to environment variables or .env files (add to .gitignore). Use separate configuration files for development and production. Never commit API keys, tokens, or credentials to version control.
• Medium · Missing Input Validation Framework — Entire codebase. The project lacks any visible input validation or sanitization library. Given that it handles file downloads and interacts with cloud storage APIs, there's a risk of injection attacks if user input (file names, paths, etc.) is not properly validated before being sent to API endpoints. Fix: Implement comprehensive input validation for all user-provided data. Add a validation library or framework. Validate file names, paths, and API parameters. Use whitelisting for allowed characters and patterns.
• Medium · No Security Testing Infrastructure — package.json. The package.json shows only linting scripts ('check': eslint). There are no test scripts, security audit commands, or vulnerability scanning in place. This makes it difficult to detect security regressions. Fix: Add 'npm audit' to the build pipeline. Implement unit tests with security-focused test cases. Add pre-commit hooks to check for vulnerabilities. Consider using tools like Snyk or npm audit in CI/CD.
• Medium · Potential Credential Exposure via API Interactions — （改）网盘直链下载助手.user.js, config files. The script interacts with multiple cloud storage providers' APIs. There's a risk that authentication tokens or API credentials used in HTTP requests could be logged, cached, or exposed in error messages if not handled carefully. Fix: Never log authentication tokens or credentials. Implement secure token handling. Use HTTPS for all API requests. Consider using proxy endpoints to avoid exposing tokens in client-side code. Implement token expiration and rotation.
• Low · Missing Security Headers Documentation — Project structure. No documentation or implementation of security headers is visible for any server-side components (if they exist). The default.min.css file suggests there may be a web interface component. Fix: If there are any server-side or web components, implement security headers (CSP, X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security).
• Low · AGPL-3.0 License Compliance Risk — LICENSE, package.json. The project uses AGPL-3.0 license which requires source code disclosure for any networked use. Users embedding this as a userscript may not be aware of these licensing implications. Fix: Add prominent notices in README about AGPL-3.0 requirements. Document what constitutes 'modification' under AGPL-3.0 for userscript context.

LLM-derived; treat as a starting point, not a security audit.

Where to read next

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

---

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.