jev-curation git:20260919.5c92926A

Immutable. This exact content is served forever at /api/v1/blob/54f420a62a662774.

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

## 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"
- "定期维护这个仓库"