kunchenguid/kun: an agent skill that fetches a principal engineer's notes from GitHub

What /kun actually distributes

The repository is not a program. It is four markdown files (ENTRY.md, TOOLS.md, OPINIONS.md, VOICE.md) plus a skills/ directory, an assets/ directory and a README. The README describes the project as "a near-realtime distillation of my experience, knowledge, tools, workflows and skills" belonging to Kun Chen, who writes that he was an L8 principal engineer at Meta, Microsoft and Atlassian. The stated audience is developers who want their coding agent to answer in that style: the README's own examples are /kun how should I improve my AGENTS.md? and /kun fix this nasty bug!.

The interesting part is the packaging decision. Most prompt collections ship as a static file you copy into your own repository. This one ships as a pointer. The skill file is kept thin on purpose and the substance lives in the repo, so the answer you get depends on what was committed that morning. That is the whole design, and it is also the whole risk.

The fetch path from /kun to raw.githubusercontent.com

The README includes an ASCII diagram of the data flow. A daily automation job runs in Grok Bot and updates the repository on main, in the America/Los_Angeles timezone. OPINIONS.md and VOICE.md are derived from Kun's public X, Substack and YouTube output; the README says new signals are merged into the existing map first and appended only when something is truly new. TOOLS.md is generated from Kun-owned public, non-archived repositories that have what the README calls a meaningful number of stars.

On the query side, the skill fetches ENTRY.md and the other markdown files over public HTTPS from raw.githubusercontent.com, with jsDelivr only as a fallback. ENTRY.md is the dispatcher: it explains how to use the other files to answer a question, and the skill picks files as needed rather than loading everything. No GitHub CLI and no GitHub authentication are required for end users. Fetches are session-cached, so a file already read in the current session is not downloaded again unless you explicitly ask to refresh. That caching is the only thing standing between you and a network round trip on every question.

There is no retrieval model, no embedding index and no ranking step. The agent reads the markdown and reasons over it. If your question is not covered by what is in those four files, /kun has nothing to fall back on except the base model.

Installing the skill and asking a first question

The README's Quick Start gives one install command and marks the global install as recommended. It uses npx, so Node has to be available on the machine where your agent runs.

# install (global recommended)
npx skills add kunchenguid/kun -g

After that, the skill is invoked inside your agent with a leading slash and a question. The README's examples are deliberately broad, from improving an AGENTS.md file to debugging:

/kun how should I improve my AGENTS.md?
/kun fix this nasty bug!
/kun how would you build a product that...

What you should see is an answer written in the voice described by VOICE.md, drawing on the viewpoints in OPINIONS.md and the tool notes in TOOLS.md. The first invocation pays the download cost; later ones in the same session reuse the cached files. The README does not document a way to pin a commit, a way to inspect which revision was fetched, or a rollback procedure if a daily update changes an answer you relied on.

The knowledge base is one person's and it changes daily

Two constraints follow directly from the architecture. First, the content is a single engineer's published opinions, not a consensus document and not a review of your codebase. The README is explicit that OPINIONS.md is "a compact map of durable viewpoints", which is a fair description of what it is: a map, not an argument. If Kun's view on a topic differs from your team's, /kun will state his view with the confidence of a principal engineer and no awareness of your constraints.

Second, the files are regenerated from public posts on a daily schedule. The README says new signals are merged and tightened into the existing map rather than simply appended, which is a sensible way to keep the file small, but it also means an opinion can be reworded or dropped between two of your sessions. Nothing in the README describes a changelog for OPINIONS.md or a diff view. For a personal style guide that is fine. For anything you would cite in a design review, it is not.

The failure mode to watch for is a confidently wrong answer that reads like experience. The skill has no mechanism to say "I do not know" beyond what ENTRY.md instructs, and the base model's own knowledge is still in play underneath the fetched files.

Static prompt files and curated skill marketplaces

The obvious alternative is to keep your own AGENTS.md or equivalent instruction file in the repository, versioned alongside the code. The difference is not the format, both are markdown read by an agent. The difference is where the content comes from and who reviews it. A checked-in file changes only when someone opens a pull request, and every change is visible in git history. /kun changes when a bot commits to main, and the README states that the repository deliberately does not accept PR contributions, so there is no external review path at all. Bug reports and suggestions are accepted as issues.

A second alternative is a curated skill or prompt marketplace where each entry is reviewed before publication. Those give you a stable artifact and a publication gate; /kun gives you freshness and a single author's voice. Pick based on whether you want the file to be stable or current. You cannot get both from this design, because the thin-skill-plus-remote-docs split is exactly what makes the content move.

Maintenance, licence and the upgrade path

The last push to the default branch was on 2026-09-16, one day before this writing, and the repository is not archived. The README attributes the daily updates to automation running in Grok Bot, so the maintenance burden sits with that job rather than with contributors. There are no releases in the repository, which means there is no versioned artifact to upgrade to. Upgrading is whatever the daily commit did, and downgrading means checking out an older commit of the markdown files yourself, a step the README does not describe.

The repository does not state a licence. The README, the badges and the top-level file listing contain no licence identifier, and the README's contribution section discusses pull requests and issues without mentioning terms of use. That matters more here than for a typical library: the files are derived from public X, Substack and YouTube posts, and the README does not say under what terms the derived markdown is redistributed. If you plan to vendor OPINIONS.md or VOICE.md into a commercial product, treat the missing licence as an open question to resolve with the author rather than an implied permission.

Editorial conclusion

Adopt /kun if you want an agent that answers from a specific engineer's published opinions and tool notes, and you accept that the content is one person's and changes daily without review. Do not adopt it if you need a pinned, auditable knowledge base, since the skill deliberately reads whatever is on main. Before installing, open ENTRY.md and OPINIONS.md in the repository and check whether you agree with what is in them, then run npx skills add kunchenguid/kun -g and ask /kun one question you already know the answer to.

Frequently asked questions

Official sources

1. Issues
2. kunchenguid/kun on GitHub
3. README