ASu-skills: nine job-hunting skills and the skills-as-content wave
Contents
A skills pack for a non-coding niche — preparing job applications in Chinese — created on August 12, 2026 reached 4,025 stars per the GitHub API on 2026-09-08, under a month. That number tells a story bigger than the repo: skills have become a distributable content format — whoever writes the content well owns the product, and the agent harness is just the runtime that runs it. Hisn00w’s ASu-skills is a sample of this phenomenon done with real engineering discipline: one source of skills, many harnesses, and a catalog reconciled by machine.
TL;DR
- ASu-skills is a Chinese job-hunting workflow plugin with nine independent skills: from making real open-source contributions and building or improving resumes, to interview prep and application tracking.
- Multi-harness distribution: one shared
skills/source, five per-harness manifests (Codex, Claude Code, TraeWork, OpenCode, WorkBuddy);skills.registry.jsonis the single source of truth, with CI running--checkto block catalog drift. - The strongest part lives in the prompt content itself: “fact boundaries” — separating production from prototype, measured from estimated, your own actions from what the AI did — plus a nine-segment evidence chain with a dedicated “missing evidence” segment.
- 4k stars for a non-code skill is a demand signal: agent skills are no longer just a developer-tools story.
Skills are content; the harness is the runtime
How the repo organizes distribution is the operational definition of skills-as-content. All content lives in three shared directories — skills/, assets/, references/ — and each harness only needs a thin manifest pointing at them: .codex-plugin/ for Codex, .claude-plugin/ for Claude Code, .trae-plugin/ for TraeWork, while .opencode-plugin/ and .workbuddy-plugin/ are lighter community bridges. Installing on Claude Code is the familiar two-command marketplace flow: /plugin marketplace add Hisn00w/ASu-skills, then /plugin install asu-skills@asu.
The anti-drift part is the real lesson. The README states it plainly: the catalog of entries takes skills.registry.json at the repo root as the single source of truth, generated and reconciled by npm run sync:skills, with CI re-checking via --check. Add a skill and forget to sync the manifests in five places, and CI goes red before merge. This is not theory: in the very first month, an outside contributor (qiyu-lu) submitted PR #136 “fix/docs-skill-catalog-sync” explicitly to stop the docs catalog from drifting — the mechanism is genuinely being used.
| Component | Role |
|---|---|
skills/ + assets/ + references/ | one content source shared by every harness |
.codex-plugin/ … .workbuddy-plugin/ | five thin manifests, one per harness |
skills.registry.json | single source of truth for the entry catalog |
npm run sync:skills + CI --check | generates and reconciles the registry, blocks drift |
The repo has no releases or tags at all (per the GitHub API on 2026-09-08) — versions live in the plugin manifests and distribution happens through each harness’s marketplace. That is a content distribution model, not a software one: no binaries to install, no update channel of its own, just text that a runtime reads.
Nine skills, one workflow
The nine entries are not nine loose tools; they are an ordered job-hunting pipeline:
| Skill | Role in the pipeline |
|---|---|
/contributor | find open-source issues matching the target role; check maintainer signals and contribution rules before proposing |
/evidence-recap | nine-segment evidence chain from AI-coding records |
/project-guide | a source-reading path with study questions |
/great-resume | reposition the resume for a target role; mark gaps 【待补】 |
/make-resume | export editable HTML resumes from 18 templates (why the repo’s language stat reads HTML) |
/job-match | compare a job description against real evidence |
/job-apply | fill application forms through a browser, stopping before submit for review |
/interview | predict questions and probe evidence gaps |
/offer | track application progress |
— compiled from README.md, Hisn00w/ASu-skills (probed 2026-09-08)
The README chains them into scenarios: no real experience yet? Run /contributor first, then hand the results to /great-resume. Have AI-coding records? /evidence-recap builds the evidence chain before you decide how to tell the story. Each entry also documents when NOT to use it — the responsibility boundaries between skills are declared rather than left for the runtime to guess.
Fact boundaries, written into the prompt
The longest read is the /evidence-recap skill: it turns AI-coding conversations and delivery records into a nine-segment evidence chain, in a fixed order:
1 问题背景 (problem background) 6 效果证据 (effect evidence)
2 方案决策 (solution decision) 7 个人边界 (personal responsibility boundary)
3 个人动作 (personal actions) 8 待补证据 (missing evidence)
4 交付状态 (delivery status) 9 面试追问 (interview follow-up questions)
5 落地范围 (deployment scope)— skills/evidence-recap/SKILL.md, Hisn00w/ASu-skills (probed 2026-09-08)
Several segments deserve to be stolen by every accomplishment-tracking system. Segment four forces an explicit status label: production, internal pilot, prototype, or merely planned. Segment six separates measured results, phase results, technical validation, and estimated gains. And segment eight is a rare design decision: a dedicated slot for “missing evidence,” with inference forbidden as a filler.
The fact boundaries do not stop at one skill. /great-resume is required to mark gaps with 【待补】 (“to be filled”) instead of inventing job titles, companies, or numbers. /contributor may only use strong outcome language when GitHub shows the PR merged — an unmerged PR is “submitted.” And before any output, the skill runs a privacy scrub: project codenames, tokens, emails, client identifiers, and internal paths are generalized or replaced. This is anti-hallucination written as a content process, not a generic reminder to “be honest.”
For Wakii, this is the “done means evidence” philosophy — already running through gates in the story-workflow docs — seen from the content side: a non-code skill pack that makes every number justify itself before it enters a resume. And ASu-skills’ catalog-drift lesson lands exactly where Wakii is exposed: Wakii’s skill catalog, toured in skills-catalog-tour, lives in skills.ts, but hand-written derived numbers elsewhere still drift.
What Wakii learns
- ADOPT — a single-source registry with machine-reconciled derived views:
skills.registry.jsongenerated by a script, CI--checkblocking every catalog drift. Wakii has hit exactly this disease: the README still says “21 skills” while ground truth is 20/13 (at the time of writing), and hand-kept numbers will drift again at the next count. The right-layer fix: generate or lint-check every skills count in README/docs fromskills.ts. - DIRECTION — multi-harness distribution: one skill source, a thin manifest per harness, one reconciled registry. Wakii’s kit currently targets Claude Code; if it ever opens to another harness, this is the layout to copy without rewriting content.
- DIRECTION — the nine-segment evidence chain with its “missing evidence” slot and human-vs-AI responsibility boundary: a sharper shape for Wakii’s story memory and done-means-evidence — recording what you have not yet proven is part of the evidence, not a failure to hide.
- WATCH — 4k stars in under a month (created 2026-08-12) for a non-code skill proves skills-as-content demand beyond dev tools; but the five-harness coverage is young (two “lightweight” bridges), and the security story leans on third-party badges — watch as harness marketplaces standardize.
Wakii is an agentic IDE with a superpowers team built in — 20 skills at the time of writing, split by role, every step through gates. Get Wakii and let the catalog tell its own story.
Follow the blog
New posts land straight in your reader — no inbox required.