jev-curation · git:20260921.fb24f6e · 2026-09-21 · sha256 81e9c96c2521984d
jev-curation git:20260921.fb24f6eA
Immutable. This exact content is served forever at /api/v1/blob/81e9c96c2521984d.
--- name: jev-curation description: Curate and expand the awesome-jev repository. Use when adding Jev projects or cases, collecting discussion evidence from X/Reddit/HN/blogs, promoting discussion items into main categories, refreshing README counts, or running periodic evidence sweeps. --- # Jev Curation Use this skill to maintain `awesome-jev` as a **strict, high-signal list of projects and practices built on Jev**. ## Goal Keep the repository focused on two questions: 1. Where is Jev actually being used in public? 2. Which decision patterns transfer across domains? This skill is for **curation**, not general AI news collection. Jev is a typed-decision model: `Choice`, `Score`, `Boolean`, each with confidence. Entries that do not involve a Jev decision do not belong here. ## Source of truth Read these files before making changes: - `README.md` - `CONTRIBUTING.md` - every file under `categories/` `README.md` is the homepage aggregate, not the primary editing surface. Update category files first, then refresh `README.md` from the current category files. Always use `scripts/build-readme.py` instead of hand-editing the aggregate. ## Hard inclusion rules Only include items that satisfy at least one of these: - explicitly name `Jev` / `jev` - explicitly cite TypeSafe AI's System One models - clearly implement a typed-decision loop (typed question → typed answer + confidence → accept / reject / escalate) And all of these: - source is public and citable - description is concrete - entry stays **one sentence** - item is **strictly Jev-relevant**, not a generic classifier, router, or LLM judge Reject: - generic classifiers, routers, or decision agents with no Jev involvement - launch-hype commentary with no artifact - private or uncitable claims - things that need a paragraph to justify inclusion ## Category model Use **main category pages** for stronger evidence such as: - public repos - project pages - substantial write-ups - benchmark or evaluation results Use **`categories/related-practices-discussions.md`** for: - X threads - Reddit discussions - Hacker News threads - interviews - blog mentions when they show credible real practice signals but do not yet have a strong standalone repo or case page. Main categories: classification-routing, verification-guardrails, scoring-ranking, agent-decisions, data-labeling-curation, evaluation-benchmarking, calibration-research, infra-sdks-integrations, related-practices-discussions. Open categories still being seeded: content-moderation, compliance-legal, game-simulation, scientific-pipelines. ## Working strategy ### 1. Search broadly, classify narrowly Preferred evidence channels: - GitHub - X / Twitter - Reddit - Hacker News - Vercel AI Gateway / AI SDK ecosystem - independent blogs / write-ups ### 2. Keep queries simple Prefer medium-complexity searches such as: - `jev typesafe` - `typesafe-ai/jev` - `jev Choice Score Boolean` - `Jev System One Model` - `jev classification routing` - `jev verification guardrail` - `Jev Diogo Almeida` Avoid very long advanced-search expressions when the adapter is unstable. ### 3. Chinese + English Search in both languages when useful. Useful Chinese patterns: - `jev 大模型 决策` - `TypeSafe Jev 分类` - `Jev 类型化决策` Keep Chinese queries narrow to avoid noisy generic matches. ## Promotion workflow Use this exact ladder: 1. **Discussion lead found** - Add to `categories/related-practices-discussions.md` if it is credible and directly Jev-related. 2. **Evidence chain search** - Look for repo, project page, case page, or blog post. 3. **Promotion test** - Promote only if public evidence clearly shows a real Jev decision in use. 4. **Promote** - Move it into the best-fit main category. 5. **Deduplicate** - Remove the weaker discussion-only item if the main case now covers it. 6. **Refresh counts** - Run `scripts/build-readme.py` if category totals changed. ## Entry-writing rules ### Main categories Format: ```md - [Name](URL) - Industry: one-sentence description of the Jev use case. ``` Rules: - one sentence only - must mention the decision + the typed shape (`Choice` / `Score` / `Boolean`) + the gate or escalation - prefer concrete verbs like `classifies`, `routes`, `gates`, `scores`, `verifies` - include a number when the source provides one - avoid hype ### Discussions page Format: ```md - [Name or thread title](URL) - Source/platform: one-sentence description of the Jev-related practice or discussion. ``` Rules: - keep it factual - describe the practice signal, not your opinion - if it is mostly about transfer of the pattern, say that clearly ## Periodic maintenance loop When invoked for a recurring sweep: 1. Read the current category files. 2. Search for 3-10 new public leads. 3. Filter aggressively. 4. Add only high-signal entries. 5. Attempt promotion for the strongest discussion leads. 6. Remove duplicates. 7. Recount category totals. 8. Refresh `README.md` so the homepage aggregate matches the current category files and counts. 9. Publish one short X post covering the round, following the 统一格式 in `/skill:tweet-posting-cdp` (same layout for both awesome lists), then summarize what was added, promoted, and rejected. - Verify with `DRY_RUN=1` first; the script prints `内容校验通过：N 字符 / M 段落` and must match before actually posting. ## Suggested commands Count entries: ```bash python3 scripts/build-readme.py && sed -n '/## Current coverage/,/Each entry lives/p' README.md ``` Example searches: ```bash bb-browser site twitter/search 'jev typesafe' --json bb-browser site google/search 'site:github.com "typesafe-ai/jev" OR "jev" typesafe | sed -n "1,120p"' bb-browser site google/search 'site:news.ycombinator.com jev typesafe | sed -n "1,120p"' bb-browser site google/search 'site:reddit.com jev typesafe model | sed -n "1,120p"' opencli gh api repos/typesafe-ai/jev/readme ``` ## Quality bar **Promote slowly. Add discussions faster.** If evidence is good but not strong enough for a main case, keep it in discussions. Precision beats coverage. This model shipped in September 2026, so the corpus is small — resist padding it. Before adding a repository, check depth (see CONTRIBUTING.md, "AI-assisted work, and bulk submissions"): - Does the code actually call the Jev API, or is the claim README-only? - Is there a runnable check (test, example with expected output, public demo)? - Is the repository mostly prompt documents? Then describe it as such, or skip it. - Does a batch of same-day repositories share one scaffold? That is a risk signal, not momentum — review each on its own merits, and cap a single author at three entries per rolling seven days. - Are the numbers in the entry traceable to the linked page? Strip what you cannot verify. ## Handling pull requests When a contributor opens a PR: 1. Verify the repository, do not just read the PR body — file tree, source, tests, CI, commit history, and whether the code really calls the Jev API. 2. If the repository is thinner than the entry implies (README-only claims, no runnable check, docs outweighing code), say so in a review comment and ask for the missing evidence rather than merging or silently rejecting it. 3. When an author already has three entries accepted in a rolling seven-day window, state the rule in the PR comment *before* acting, and queue the extra entries to a later cycle instead of rejecting them. Link the CONTRIBUTING section so the contributor knows it is policy, not a judgement about them. Queue by submission order, never by quality — picking "the best three" turns the rule into a hidden quality verdict, which is exactly what it exists to avoid. If one of the queued entries has more stars than the merged ones, say so explicitly in the comment. 4. **Bulk AI-generated submissions are a rule, not a preference** (CONTRIBUTING → "Rule: do not submit bulk drops of AI-generated projects"). Before merging a cluster of same-author, same-day repositories, check for a shared scaffold (`AGENTS.md` / `CLAUDE.md` / `STATE.md`), a common README template, or single-commit histories — those mark one project family, which counts as **one** submission, so merge at most one and queue the rest. Disclose-or-pause also applies: if a submission was generated and not disclosed, hold the author's whole pending batch until they say so. 5. Never edit a contributor's wording purely for style; do fix inaccurate claims. 6. README.md is generated — when a PR conflicts there, rebase the branch and regenerate it (`python3 scripts/build-readme.py`) rather than hand-resolving. For conflicts in a category file, keep main's version and append the PR's new line. 7. An entry written **only** into `README.md` (no category file) will be silently erased by the next generator run. Move it into the right category file, regenerate, amend the commit, and push back to the contributor's branch — then say so in a comment, including that the mistake is easy to make from the current docs. 8. Use `scripts/maintainer/merge-prs.sh` to process PRs in bulk. It handles the four traps that make manual merging tedious: fork repository names vary (`awesome-jev`, `awesome-jev-yibie`, `yibie_awesome-jev`, `awesome-jev-1`), so it resolves them via `headRepository.nameWithOwner`; it fast-forwards local `main` before rebasing, because rebasing onto a stale base leaves the PR conflicting after the push; it loops over conflict rounds, because a PR with two commits (add the entry, then reword it) conflicts twice; and it appends the PR's entry with `grep -qF --` so an entry starting with `- [` is not parsed as a grep option. 9. A PR that edits only a category file merges cleanly and leaves the README count stale, so `merge-prs.sh` rebuilds the README after every merge and pushes a follow-up commit when it drifted. 10. Every PR touches the adjacent count lines in README.md, so from the second PR onward conflicts are normal, not a sign of a bad contribution. Expect to rebase and force-push to the contributor's branch (most forks have `maintainerCanModify: true`) rather than asking them to resolve it. ## Deliverable checklist Before finishing, verify: - entries are one sentence - no generic classifiers or judges slipped in - promoted items have stronger evidence than discussion-only items - discussions page remains useful as a map of emerging practice - README homepage aggregate matches the current category files ## Recommended invocation phrases This skill should be used for prompts like: - "继续搜集 awesome-jev" - "做一轮 Jev 证据巡检" - "把 discussions 里强条目升格" - "更新 jev awesome list" - "定期维护这个仓库"