2026-05-25

GitLink

Yesterday, I had Kilo (DeepSeek V4) check the completeness of gitlink-cli health. It turned out that the PRs in the database don’t have merge times. At first, I thought this was a known issue, but after searching the code, Kilo found several other problems.

DeepSeek uncovered 5 bugs, 2 of which were known (since the platform currently can’t provide the relevant data). The other three might be due to unclear instructions in the prompt: I used "processor" to refer to the user who processes the PR, but the returned data didn’t include that field.

Lessons learned:

• Supplement known issues in the prompt.
• Explain the meaning of custom names and how they map to actual data.

Confusion

I went to the PR list of the gitlink-cli repo and saw that someone had submitted a PR about workflows, which also included health content. The reviewer’s opinion was that it could be merged…

It makes me wonder: if two people are working on the same track, who will ultimately win? I’m not sure if this person also used an Agent, as they submitted multiple features in one go.

A thought of giving up the competition flashed through my mind, but I quickly dismissed it. It’s normal for others to work on the same content. I can’t quit just because there are competitors. Resources have to be fought for — just keep working hard. Even if I don’t win the prize in the end, it’s fine — I’ll have gained experience.

In the afternoon, I saw a new PR, also made with an Agent, which seemed somewhat related to the contributor system I’m planning.

Thoughts on Improving Quality and Efficiency with Agents

This person submitted multiple features in a single PR. If the reviewer also uses an Agent for verification, back and forth, it feels like a huge time sink.

After all, while an Agent can quickly read code and give a conclusion, the reviewer still has to manually confirm everything. Submitting a large amount of code at once risks longer review time and ultimately losing the initiative.

Hand-coded era: $$ T_{\text{PR}} = \sum_{i=1}^{n} \left( T_{\text{reviewer review}} + T_{\text{reviewer-contributor communication}} + T_{\text{contributor revision}} \right)^{(i)} $$

Agent early era: $$ T_{\text{PR}} = \sum_{i=1}^{m} \left(T_{\text{Agent review}} + T_{\text{reviewer confirmation}} + T_{\text{reviewer-contributor communication}} + T_{\text{contributor-agent communication}} + T_{\text{agent revision}} + T_{\text{contributor confirmation}} \right)^{(i)} $$

I believe the hardest part of using Agents to improve quality and efficiency is making the Agent fully understand the user’s requirements.

When communicating with an Agent, I can’t convey all information at once — for example, what external bottlenecks the project faces and how I plan to resolve them.

If the input area for Agent coding in VSCode is a small panel on the right, it might naturally make people want to input less. If it were a large editing area, would people input more?

An Agent can generate large amounts of code, but if my initial prompt is flawed, the subsequent code will be affected as well. A small error can lead to huge deviations. We can keep iterating to approach the target, but it still consumes a lot of mental energy from the user.

Contributor Growth System

I think we can borrow the idea from the health shortcut to build a growth system: first pull the developer’s data, then analyze it, and finally produce rankings and so on.

Step one: determine what data is needed and how to obtain it.

Since this is a personal ranking, we need the number of PRs/Issues submitted by the contributor, the number of PR reviews they’ve participated in, and these PRs/Issues must have detailed categories, which can be done via labels.

So, the first thing is to download all PRs and Issues into the database.

gitlink-cli pr list --owner yingjie --repo growth-system
{
  "ok": true,
  "data": {
    "close_count": 0,
    "disable_pr_vew": false,
    "has_created_pull_requests": true,
    "issues": [
      {
        "assign_user_login": "yingjie",
        "assign_user_name": "yingjie",
        "attached_issues": [],
        "author_login": "tang_dev",
        "author_name": "tang_dev",
        "avatar_url": "system/lets/letter_avatars/2/T/251_195_45/120.png",
        "fork_project_id": 1547054,
        "fork_project_identifier": "growth-system",
        "fork_project_user": "tang_dev",
        "fork_project_user_name": "tang_dev",
        "id": 142615,
        "is_original": true,
        "issue_tags": [
          {
            "color": "#9ed600",
            "id": 323856,
            "name": "文档"
          }
        ],
        "journals_count": 2,
        "name": "更新项目名称",
        "pr_created_unix": 1779362247,
        "pr_full_time": "2026-05-21T19:17:27.000+08:00",
        "pr_time": "4天前",
        "priority": "高",
        "pull_request_base": "master",
        "pull_request_head": "master",
        "pull_request_id": 14937,
        "pull_request_number": 1,
        "pull_request_status": 1,
        "pull_request_staus": "merged",
        "reviewers": [],
        "version": null
      }
    ],
    "limit": null,
    "merged_issues_size": 1,
    "message": "响应成功",
    "open_count": 0,
    "pr_need": false,
    "project_author": "yingjie",
    "project_author_name": "yingjie",
    "project_name": "开源项目贡献者成长体系",
    "search_count": 1,
    "status": 0,
    "user_admin_or_developer": false,
    "user_admin_or_member": false
  }
}