A GitHub Trending Interpreter That Reads READMEs Before You Clone

I often browse GitHub Trending, but the real time sink comes afterward. When a project pops up on the list, I have to click in, flip through the README, find the startup commands, look at the directory, and then finally judge for myself whether it's just short-term hype or something truly worth digging into. With many projects, this process quickly turns into repetitive labor.

So I built a small tool, simply called the GitHub Trending AI Interpreter. It doesn't read the source code for me, nor does it jump to conclusions based on star count; it first gathers materials like the trending list, README, and directory, then provides a collated result with evidence. For the model layer, I connected it to Lanyun Yuanshengdai MaaS, using DeepSeek-V3.2. The workflow is placed in a Dify Chatflow, and GitHub remains the data source.

I first implemented trending queries, then used a real repository to run a specific project analysis. Both paths can be initiated from the same input box, which is closer to my usual habit when checking projects: just ask about a name when I see one, without first thinking about which function to click.

1. Getting Both Trending and Specific Repository Paths Running

This tool doesn't present the entry point as a row of fixed filter boxes but retains natural language input. For example, I can directly ask "What are the popular Python projects on GitHub today?" or combine a repository URL with a question: https://github.com/acowbo/health-reminder Help me analyze this project.

The two inputs seem very similar, but the data paths behind them are different. A trending question needs to request the Trending page and collate the day's candidate projects; repository analysis requires reading repository meta-information, README, and directory structure. By letting the model perform intent recognition first, users don't have to guess which mode they should click.

In the workflow panel, this path is broken down into four steps: intent recognition, real data acquisition, structured cleaning, and generating a technical brief. The "real data" here isn't filled in by the model from memory; it's the Chatflow runtime reading GitHub's public content. The model's task is to summarize, judge, and organize the materials already obtained.

2. Why the Model Was Placed on Lanyun Yuanshengdai This Time

When I choose a model service, I first look at the integration cost, not the number of models on the promotional page. For this project to fit into Dify, it needed to meet at least three conditions: have an OpenAI-compatible interface, the model name must be stably lockable, and the call results must be traceable on the platform side. Lanyun Yuanshengdai's MaaS platform places models like DeepSeek, Tongyi, Zhipu, Kimi, and MiniMax in the same model square, so switching models doesn't require rewriting the business layer.

Lanyun's homepage model cards simultaneously show the model type, context length, provider, and API example entry. For me, this is more practical than just seeing a model dropdown: during selection, I can first look at the capability tags, then decide which model to put into Dify.

On the model details page, you can directly see an OpenAI-compatible request example. The model name used in this article is /maas/deepseek-ai/DeepSeek-V3.2, and the Base URL is https://maas-api.lanyun.net/v1. There's a detail that's easy to get wrong here: the Base URL already includes /v1, so when making a request, you only append /chat/completions; don't mistakenly concatenate it as /v1/v1/chat/completions.

I first used a minimal request for connectivity verification, then handed it over to Dify. The returned content, model name, and usage could all be obtained normally, indicating that the problem hadn't yet entered the Chatflow; the interface layer had already passed through first.

This step also confirmed Lanyun's boundary within the project: it handles model inference, not fetching GitHub data, nor does it replace Dify's branching and code nodes. With this separation, it's relatively easy to locate which layer has a problem.

Call records can also be viewed back in the Lanyun console. A single minimal request leaves behind the model name, call count, and token consumption, which is very helpful for troubleshooting "whether the request actually reached the model."

3. Connecting Lanyun into the Dify Chatflow

In Dify, first add an OpenAI-API-compatible model provider. Use the following set of values during configuration:

Model Name: lanyun-dp3
Model Type: LLM
API Base URL: https://maas-api.lanyun.net/v1
Model Name in API Endpoint: /maas/deepseek-ai/DeepSeek-V3.2
API Key: Key created in the Lanyun MaaS console

After the model is configured, clearly write the purpose of this project in the Chatflow's application information: fetch recent popular open-source projects, or generate architecture reports, startup guides, contribution suggestions, and technical value analysis for a specified GitHub repository. Application information is not decoration; it determines whether someone maintaining this workflow later can quickly understand the entry point and output.

The entire process can be understood in the following order:

1. The Start node receives sys.query.
2. "LLM Intent Recognition" determines whether it's trending or repository.
3. The Input Normalization node sorts out fields like language, time range, and repository URL.
4. A conditional branch selects the trending path or the specific repository path.
5. HTTP request nodes fetch GitHub Trending, repository meta-information, README, and directory content.
6. Code nodes clean the returned data, avoiding stuffing entire pages of HTML raw into the prompt.
7. The Report node outputs structured Markdown.

There are three LLM nodes in the workflow; intent recognition and both report generation paths uniformly select the Lanyun model. It's not that they "appear to use Lanyun"; rather, every position requiring model inference falls onto the same MaaS configuration.

The frontend does not directly place the Lanyun Key or Dify App Key into the browser. Next.js's API routes only read the Dify configuration from server-side environment variables, then forward the request to the Chatflow:

const chatClient = new ChatClient(
  process.env.DIFY_API_KEY,
  (process.env.DIFY_API_URL || '').replace(/\/$/, ''),
);

const response = await chatClient.createChatMessage(
  {},
  query,
  'lanyun-github-insight-web',
  true,
);

return new Response(response.data, {
  headers: { 'Content-Type': 'text/event-stream' },
});

When running locally, .env.local only stores the Dify application address and App Key, while Lanyun's model address is stored in Dify's provider configuration:

DIFY_API_URL=https://api.dify.ai/v1
DIFY_API_KEY=app-xxxxxxxxxxxxxxxx

Don't mix these two addresses up: the former is the address for the application to call Dify, and the latter is the address for Dify to call the Lanyun model.

4. Running the Trending List First, Then Checking if the Report Has Substance

I first used "What are the popular Python projects on GitHub today?" to test the trending path. After submitting the request, the page status changes from "Service Ready" to "Connecting to Workflow," with the four steps on the right progressing in order. This status change is important because GitHub requests and model generation aren't instantaneous; users need to know the request is still working, rather than mistakenly thinking the button is broken.

The final report includes the date, data scope, number of candidate projects, and the nature of the report. One run returned 7 candidate projects, scoped to GitHub Trending Daily, with the report focusing on AI, developer tools, and infrastructure. The model didn't just repeat project descriptions; it first distilled trends, then placed projects into a recommendation table.

The recommendation table is an output form I care about quite a bit. It puts the project, language, today's stars, total stars, core value, suitable audience, and recommendation index into one table. For example, public-apis/public-apis, cordiverse/cordis, and sponsors/unslothai are compared under the same set of fields; readers can look at the table first, then decide whether to click into a repository.

Run records also return to Dify's logs. Both trending queries and repository analysis show as SUCCESS, with the user identifier uniformly set to lanyun-github-insight-web. On the right, you can open the complete conversation to check if the input and generated results correspond.

5. Specific Repository Analysis: From README to Module Inference

The trending list is an entry point for discovery, but the tool's real value is demonstrated in specific repository analysis. I input acowbo/health-reminder, and the page keeps the repository address intact in the input box while still displaying the same four-step processing chain.

The report first gives a project positioning, then lists the tech stack, directory structure, and a maturity assessment. For health-reminder, the output identified technical clues like React 19, TypeScript, Vite, Tauri 2, Rust, Web Notification API, GitHub Actions, and npm, and associated these judgments with the README, src/ files, and workflow files.

This kind of analysis doesn't mean the model "understood all the source code." The report writes out its basis, giving the conclusions a boundary: what the README wrote, whether corresponding files exist in the directory, and whether configuration files are present are all verifiable evidence. For example, the license field in the repository metadata shows as Unknown, but the README's License section states it's MIT; this discrepancy is also preserved, rather than directly giving an overly definitive conclusion.

The module inference section separates "functional description" from "possible implementation path." Modules like status bar countdown, reminder scheduling, activity data, settings persistence, and notification service are all annotated with inference premises and possible directories or files involved. This way, readers can use it as an index for further code reading, rather than treating the inference as verified fact.

6. Actual Problem Encountered: The Report is Markdown, but the Page Didn't Render It Completely at First

When the workflow was first connected, the report content returned by Dify was fine; the problem was on the frontend. The initial page only manually supported titles, simple unordered lists, and tables. When encountering > blockquotes, --- horizontal rules, single-asterisk italics, and code blocks, the page would display the Markdown markup directly. The judgment basis and warning information appearing in the report were therefore very hard to read.

The solution wasn't to keep piling rules into regular expressions, but to hand Markdown parsing over to the GFM parser marked, then use DOMPurify to sanitize the generated HTML. This way, tables, blockquotes, ordered lists, code blocks, and emphasis syntax go through the same set of parsing rules, and occasional HTML fragments output by the model won't execute scripts directly. During streaming output, it still merges and refreshes every 160 milliseconds; the parsing scope just changed from "assembling HTML manually" to full Markdown rendering.

After the report is generated, it can also be copied directly. What's copied isn't the plain text on the screen, but the original Markdown, so pasting it into a document or knowledge base retains the titles, tables, and code blocks.

7. Getting the Project Running

The project is a Next.js application. Dify is accessed through a server-side API proxy, and the frontend touches no keys. After preparing the Dify Chatflow and Lanyun model, execute:

npm install
cp .env.example .env.local

# Edit .env.local, fill in the Dify application API
npm run dev

After opening http://localhost:3000, you can first use "View Demo Report" to check the page and Markdown styles, then submit a real trending question. On the Dify side, you need to confirm that all three LLM nodes in the Chatflow have selected the Lanyun model, the API Base URL remains https://maas-api.lanyun.net/v1, and the model name remains /maas/deepseek-ai/DeepSeek-V3.2.

In this project, Lanyun Yuanshengdai plays a replaceable but clearly defined model service role: it receives context cleaned from GitHub data, completes intent recognition and report generation; Dify retains the process, branching, and logs; GitHub provides project facts; Next.js converges these capabilities into a directly usable entry point. In other words, changing the model won't force the GitHub data layer and frontend page to be rebuilt from scratch.

Conclusion

After running both the trending list and health-reminder inputs, I now treat this report as the first round of screening before opening a repository. It helps me first see the project positioning, tech stack, directory, and risks, but it won't replace source code review for me; the report writes "possible implementation paths," and I will still go back to the repository to verify.

Lanyun's position in this project is also very clear: Dify needs a directly integrable OpenAI-compatible model, and all three LLM nodes uniformly use DeepSeek-V3.2; how GitHub data is fetched, how branches proceed, and how results are displayed are still handled by the Chatflow and Next.js. After separating these layers, debugging doesn't require guessing where the problem lies within a large block of generated text; the model address, data requests, and page rendering can be checked individually.

In the future, when I encounter a repository that suddenly rockets up the trending list, I'll first throw the address into this tool, wait for the report to organize the README and directory, and then decide whether to spend the time pulling the project down.