DEV Community: An Nguyễn Hoàng

Your coding agent can read a GitHub repo's vibe, not just its README

An Nguyễn Hoàng — Thu, 05 Nov 2026 19:20:39 +0000

Ask Claude or Cursor "is this GitHub repo still maintained?" and it does the only thing it can from a chat box: fetch the README and guess. The README is marketing. It won't tell you that one file has been rewritten nine times in the last twenty commits, that CI is mostly green-by-skip, or that three of the top five contributors stopped pushing a year ago.

That gap — the repo's behaviour versus the repo's description — is exactly the kind of thing an MCP tool can close, because it needs live API calls the model can't make on its own. So I built a small remote MCP server that does six read-only things against any public repo and hands the agent back clean structured JSON.

The six tools

get_repo_overview — stars, forks, language, license, topics, last push
list_recent_prs — recent PRs with author, state, merge dates
get_contributors — who actually commits, and how much
get_hot_files — the files churning hardest right now
get_ci_status — sampled check-run health on the default branch
get_dependencies — declared deps

No local install. It's a hosted Standby Actor on Apify speaking Streamable-HTTP MCP, so you point your client at one URL and it's there.

What the output actually looks like

get_hot_files on cli/cli, last 20 commits:

{
  "branch": "trunk",
  "commits_scanned": 20,
  "top_files": [
    { "path": "go.mod", "changes": 9 },
    { "path": "go.sum", "changes": 9 },
    { "path": "git/client_test.go", "changes": 4 },
    { "path": "pkg/cmd/api/api.go", "changes": 3 }
  ]
}

An agent can now say "dependency churn is high, the API command and the git client are the active surfaces" instead of paraphrasing the README.

get_ci_status is the one I was most careful with, because a naive version lies. It paginates, so I return what was actually sampled, not a total dressed up as a verdict:

{
  "ref": "trunk",
  "total": 784,
  "sampled_count": 100,
  "totals_sampled": { "success": 46, "skipped": 54 }
}

sampled_count and totals_sampled are deliberate field names — if the tool only looked at the first 100 of 784 checks, it says so, and the model doesn't get to tell you "CI is 46% passing" as if it counted all of them.

Wiring it into a client

It's a remote Streamable-HTTP server, so in a client that supports remote MCP you give it the URL and an Authorization: Bearer <apify-token> header:

{
  "mcpServers": {
    "github-repo-intel": {
      "url": "https://cg-nguyen--github-repo-intel-mcp.apify.actor/mcp",
      "headers": { "Authorization": "Bearer apify_api_..." }
    }
  }
}

Then tools/list returns all six and the agent self-discovers them.

Two things I'd flag if you build one of these

Pass a GitHub token. Unauthenticated GitHub is 60 requests/hour shared across everyone hitting the same IP. Every tool takes an optional github_token and with one you get your own 5,000/hr. The fan-out tools (get_hot_files, get_contributors) read per-commit, so without a token you'll rate-limit yourself in under ten calls. Read-only public_repo scope is enough.

Charge on success, never on entry. The server bills per tool call, and the charge fires after the upstream GitHub call succeeds, right before the result is returned. If GitHub 404s or rate-limits, no charge. Charging at handler entry would bill people for failures, which is both wrong and a fast way to get delisted.

It's live here if you want to point an agent at it: https://apify.com/cg_nguyen/github-repo-intel-mcp. First calls are cheap; the whole point is that your agent spends a fraction of a cent to stop guessing about a repo and actually look.

I measured link rot on 2012 Hacker News and resurrected 84% of it (Kiroween 2026)

An Nguyễn Hoàng — Thu, 05 Nov 2026 17:03:57 +0000

This post was written as part of the **Kiroween 2026 hackathon* (Resurrection category).*

The dead tech I wanted to resurrect: the hyperlink

Open any Hacker News front page from 2012 and start clicking. A lot of it is gone. I wanted a number instead of a feeling, so I built Necrolink: it measures link rot on a cohort of links and brings the dead ones back from the Wayback Machine.

The current result, generated from committed data (never hand-typed):

Of 299 links on Hacker News front-page stories from 2012, 55.2% are dead or moved today; Necrolink resurrects 84.2% of those from the Wayback Machine. Control: of 300 links from 2025, 10% are dead.

Repo (MIT, .kiro/ committed): https://github.com/luongs3/necrolink
Live graveyard: https://luongs3.github.io/necrolink/web/
Offline judge demo: make judge-demo (under 1 second, no keys)

Why a control cohort

A claim like "55% of old links are dead" is useless if your checker calls everything dead. So the spec requires a second cohort: 300 links from 2025 HN. If the tool says those are dead too, the tool is broken. They come out 10% dead and 76.7% alive, so the checker isn't just a pessimism machine.

How Kiro shaped the build

Spec first, not vibes. I wrote .kiro/specs/necrolink/requirements.md in EARS form ("WHEN the user runs scan THEN the system SHALL…"), then design.md and tasks.md, and had Kiro CLI implement every task from the spec. The difference from vibe coding showed up the first time a real scan went wrong. I didn't patch the code by hand. I amended the spec and let Kiro re-implement against it:

Wayback 429s. archive.org's availability API rate-limits under concurrency. The spec now says lookups run serially with a 1.2s gap, exponential backoff that honors Retry-After, and a separate ERROR state that is distinct from UNRECOVERABLE. "We couldn't ask" is not the same as "no snapshot exists".
Bot walls are not death. 401/403/405/429/436 now map to a BLOCKED class that is reported in its own column and kept out of the dead%. Without this rule the 2012 number would be inflated by Cloudflare.

Both fixes live in the requirements doc, so the reason for each behavior is written down next to it.

Steering. product.md holds the one rule that matters: every headline number must be falsifiable and must have a control. tech.md keeps it zero-dependency (Node built-ins only). That stopped Kiro from pulling in an HTTP library or a test framework.

Hooks. test-on-save runs the suite whenever lib/ changes. claim-sync regenerates the README headline whenever data/ changes, so the number in the README can't drift away from the data.

Property-based tests. The URL normalizer gets randomized never-throw and idempotence tests. They caught a float-formatting bug (39.7 + 15.7 = 55.400000000000006) that would have ended up in the headline.

82 tests, all passing.

What I'd tell someone starting with Kiro

The spec is not paperwork. It's where bug fixes go. When reality disagrees with your code, change the requirement first, and the fix plus the reason for it stay in one place.

Kiro #KiroweenHackathon26

A stale skill is worse than no skill

An Nguyễn Hoàng — Thu, 04 Jun 2026 07:26:21 +0000

While building a skill index I almost recommended a repo with sixteen thousand stars. Looked great. Then I checked when it was last touched: January 2023. Three years dead. If an agent had loaded its instructions it would have followed them confidently, and they're wrong now. That's the whole problem nobody talks about with these skill libraries.

If you've used Claude Code or any agent setup recently, you've seen the pattern. There's a folder of SKILL.md files, or an MCP registry, or some awesome-agent-skills repo, and the agent reaches into it when it needs to do a thing. Everyone is building the library. The library is easy. It's a folder of markdown.

The part nobody builds is the part that actually matters: how does the agent know which skill in the pile won't lie to it?

A skill is instructions an AI follows. Confidently. That's different from code. When code is wrong it crashes, loud, you notice. When a skill is wrong the agent just does the wrong thing and tells you it went great. So a stale or subtly-broken skill isn't neutral. It's negative. It produces a confident wrong answer instead of making the agent stop and think. No skill at all would have been safer.

I went looking for the existing solution and what I found was a hundred link lists. They tell you a skill exists. They do not tell you the one thing you need before you load it: can I trust this, and is it still true.

So I built the missing layer. It's called Skill Atlas. It's a public index of skills, but organized by job (the thing you're about to do, like "work on Upwork" or "build an MCP server" or "write Go" or "set up CI"), and every single entry carries three things a link list skips:

where it came from, and is that source reputable
a trust tier, A through D
a last_validated date, that an actual check happened, not the publish date

The tiers are simple. A is canonical, the official source, you trust it because the vendor wrote it. B is community-proven, high reputation and still maintained. C is useful but verify before you lean on it. D is caution, it's stale or unmaintained, listed on purpose so you don't waste an afternoon rediscovering it's dead.

The freshness part isn't optional, and the English repo is why.

That English repo from the top? Sixteen thousand stars makes it an easy B by the usual logic, maybe higher. The January 2023 last-push makes it a D. Stars said trust it. The date said run.

Same story with a famous interview-prep repo, around three hundred fifty thousand stars, hasn't been touched since last August, so it drops to C. Stars are a lagging signal. People star a thing once and never unstar it when it rots. Stars plus last-push tell the truth that stars alone hide.

That's the actual product. Not the list, the judgment about the list.

To keep it from rotting itself, there's a script that re-checks every source, liveness plus live star counts plus last-push, and a GitHub Action runs it monthly and opens an issue the moment a link dies. An entry that hasn't been re-validated in six months gets treated as "verify before trusting" no matter what tier it claims. The atlas has to hold itself to the same bar it holds everything else, or it becomes the exact thing it warns about.

One more thing that surprised me while building it. For some jobs there is no good public skill, and the honest move is to say so. "How to win on Upwork" doesn't have a trustworthy public skill, because the real one is bespoke, it lives in your own head and your own win/loss history. So the atlas says that out loud instead of padding the slot with generic junk. The whole model is: find the good public starting point, then fork it private and make it yours. The public layer is the floor, not the ceiling.

It's 34 jobs right now. Backend stuff mostly, because that's what I do (Go, Postgres, docker, observability, API design, auth, the usual), plus the agent-specific ones (MCP, prompt engineering) and a few soft ones (interviews, careers). MIT, and it installs as a skill itself so your agent routes to the right vetted entry at the start of a task.

Repo's here if you want to poke at it: https://github.com/luongs3/skill-atlas

The question I actually can't answer yet, and the reason I'm posting this: what other signal would make you trust a skill before loading it? Stars and last-push are what I have. They're not enough. Install counts maybe, but those lie too. If you've got a better trust signal I want to hear it.

I gave my coding agent root on my VPS so it would stop making me deploy by hand

An Nguyễn Hoàng — Tue, 02 Jun 2026 03:38:43 +0000

Last week I built a little dashboard with Claude. Took maybe ten minutes. Then I spent the next hour trying to get it online.

ssh in, install docker, write a Dockerfile, set up nginx, run certbot, certbot fails, read the log, oh the DNS hasn't propagated, wait, run it again, open port 443, realize ufw was blocking it the whole time. By the time it was live I'd forgotten what the app even did.

I've done that maybe a few hundred times by now. I'm a backend guy, I'm fast at it. But fast at something boring still means doing the boring thing.

So at some point I just thought: the AI already wrote the app. Why does it stop right when the annoying part starts? Why doesn't it just deploy the thing itself?

The reason is it has no hands. The model can write you a perfect docker-compose file. It can't ssh into your box and run it. No connection to your server, nowhere to hold your key.

So I gave it hands. It's an MCP server, vibe-deploy. You hook it up once to a VPS you own, and then you just say "deploy this to notes.mydomain.com" and the agent containerizes it, ships it over ssh, sets up nginx, gets a real Let's Encrypt cert. Node, Python, Go, plain static. It figures out the stack and writes the Dockerfile.

No PaaS, no per-seat pricing, no free tier you'll outgrow. A $5 box runs a dozen of my projects and I own the whole thing.

The "you gave an AI root on your server??" reaction is fair, so: it runs locally, your key never leaves your laptop. I used a separate ssh key scoped to deploys, not my real one, and you should too. It checks the server host key before connecting and validates everything you pass it, because a deploy tool that pastes your input straight into a shell is a horror story waiting to happen. I had someone audit the security before I put it out. They found two real bugs. I fixed them.

It's free and MIT, on GitHub and npm as @cgnguyen/vibe-deploy. I built it because I wanted it. If you live in the same gap between "it works on localhost" and "it's online", try it and tell me where it breaks. The stacks it supports right now are the ones I needed. Next ones are whatever you ask for.