git:20260919.5c92926 to git:20260921.fb24f6e

8 added, 6 removed. Audit A to A.

---

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.

- 4. Never edit a contributor's wording purely for style; do fix inaccurate claims.

- 5. 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.

- 6. 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.

- 7. 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.

- 8. 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.

+ 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"

- "定期维护这个仓库"