yingjie@memoir
Yingjie's Memoir

English

中文

English

中文

Appearance

2026-05-23 ​

Today I wanted to check if anyone had submitted a PR about automatic issue labeling, but I found that my own gitlink-health PR hadn't been merged yet. I went in and saw that the reviewer had made a new request — implement it in Go.

Overall Assessment: Good direction, suggest adjusting the implementation approach ​

First, thank you @yingjie for this contribution! Project health analysis is a very practical scenario, and the selection of the three core metrics — Issue resolution time, PR merge rate, and contributor activity — is very accurate. Testing across multiple Agent platforms including Claude Code, Kilo CLI, Kimi Code, and Hermes also demonstrates the author's deep understanding of the AI Agent ecosystem.

However, I have a significant concern about the architectural choice of placing Python code in the skills directory and recommend replacing it with a pure Go solution.

Core Issue: Python breaks the boundary of the skills directory ​

Currently, all 12 skills under skills/ are pure Markdown documents (totaling about 30KB). The npm package's files field directly bundles the entire skills/ directory. Introducing Python code means:

  1. New runtime dependency — After npm install -g, only Node.js is guaranteed; Python 3.8+ needs to be installed separately
  2. Blurred positioning of skills — If gitlink-health can include Python scripts, could other skills include shell scripts? Node.js scripts? The boundary is unclear
  3. Package bloat — Although fetcher.py only uses stdlib and doesn't depend on pip, the skill files go from pure documentation to "documentation + executable tool + SQL schema"

Suggested Solution: Go-ify the data collection logic ​

What fetcher.py does is essentially:

  1. Paginate calls to pr +list / issue +list to fetch lists
  2. For each record, call pr +view / issue +view to get details
  3. Parse JSON and write to SQLite

All of this can be implemented in Go as a built-in command gitlink-cli health +fetch:

  • Reuse existing capabilities — HTTP client, auth token, JSON parsing, PaginateAll pagination logic are all already available
  • Pure Go SQLite — modernc.org/sqlite without CGO dependency, cross-platform cross-compilation unaffected
  • Concurrent detail fetching — goroutines can fetch details for each PR/Issue in parallel, much faster than Python's sequential approach
  • Zero extra dependencies — binary distribution, users only need gitlink-cli itself

At the Skill level, SKILL.md would be simplified to:

  1. # Collect data

  2. gitlink-cli health +fetch --owner <owner> --repo <repo>

  3. # Execute SQL analysis queries (refer to references/queries.md)

  4. sqlite3 data/gitlink_health.db "SELECT ..."

  5. # Fill in report template

Specific Suggestions ​

  1. collector/fetcher.py + schema.sql → Go code under shortcuts/health/, registered as gitlink-cli health +fetch
  2. SKILL.md, references/queries.md, asset/ remain in skills/gitlink-health/ (pure documentation)
  3. data/ directory and *.db stay in gitignore
  4. Report templates and SQL query analysis are still executed by the AI Agent (that's the Skill's responsibility)

Verdict: 🔄 Changes Required ​

The scenario value and workflow design of this PR are both very good. The main hope is to replace the Python collection script with a Go built-in command, keeping the skills directory purely documentation. If the author is interested in making the changes, I'd be happy to help review the Go code. If time doesn't permit, I can also merge the core ideas first and do the Go migration myself later.

Thank you again for the contribution!

In summary, the reviewer wants me to internalize the data collection code into gitlink-cli.