Canonical identity

A tool is identified by the lowercase owner/repository derived from an HTTPS GitHub repository root. A repository name by itself is not enough. URLs with credentials, custom ports, query strings, fragments, or paths such as tree, blob, and issues are rejected rather than guessed.

People and organizations are represented by their GitHub identity. The owner relationship remains a separate source-backed record instead of being inferred from similar names.

Sources and verification

Canonical repository and maker metadata comes from the official GitHub REST API. Each published snapshot records source identifiers, URLs, and a UTC collection time. GitHub stars and forks are immutable metric snapshots tied to that time.

GeekNews, Hacker News, Product Hunt, and Oh My Feed editorial discovery can provide evidence that something was noticed. A mention cannot replace official GitHub confirmation or become a popularity metric from another source. Product-family labels remain human organization. The web and CLI apply the same automatic classification to all tools using versioned rules over official GitHub topics, descriptions, and repository names. Capability signals come first; weaker signals that only name a host agent such as Claude Code or Codex, an agent-skill or agent-memory convention, or an mcp segment of the repository name apply only when no capability rule matched. Classification updates with published metadata, and filters include only categories with tools. Detail pages show the matching evidence and policy version. These are derived labels, not categories supplied by GitHub or human review; unmatched tools remain unclassified. The canonical download retains the original editorial fields.

Sorting—not a hidden recommendation score

Popular orders tools by the displayed GitHub star snapshot. Recently created orders by repository creation date. Canonical repository identity breaks ties deterministically. Oh My Feed does not currently publish a “Hot” score; the star-growth lists on Updates use the published formulas below. Product-event collection is off by default unless local analytics consent is granted; consent-gated event aggregates are not ranking input.

These controls help scan the catalog; they do not measure quality, safety, momentum, or fit. A star count can be useful context but is not a substitute for evaluating documentation, maintenance, licensing, and security.

Star growth on Updates

Updates shows two separate star-growth lists. Neither is a recommendation score, and the two are never combined into one.

Rising fastest compares the two latest official GitHub star snapshots of a cataloged tool: stars per day = (newer stars − older stars) ÷ days between the two snapshots. A tool is compared only when the change is positive, the snapshots are at least 1 day and at most 14 days apart, and the newer snapshot is no more than 7 days old. A shorter interval turns one burst into an inflated rate; a longer one averages the change away. Tools are ordered by that rate, highest first, and equal rates by canonical repository identity. Each row shows the rate, the change, and the interval, for example “≈383/day” beside “+2,248 stars in 5.9 days”, with both snapshot times. The rate describes the measured interval only; it is not projected beyond it.

New and fast covers repositories whose GitHub creation date is within the last 14 days, including repositories just found by recent-repository discovery that have a single snapshot: stars per day = current stars ÷ days from creation to the star snapshot, where an age under 1 day counts as 1 day. The snapshot must be no more than 7 days old. This is an average over the repository's whole life, not a recent change, so it is labeled “stars since creation” and kept as its own list.

Each list shows its top 10 and how many tools qualified. Stars are re-measured only when a collection source observes a repository again, so intervals differ from tool to tool; on 2026-10-09 the median gap between a tool's two latest snapshots was about 7 days. That is why the rate, not the raw change, is compared. Stars show interest; they do not measure quality, safety, or fit.

How the local recommendation scores a match

The local CLI compares technology names read from a project, and any task you type, against the catalog. Where a word matches changes what it is worth. A word in the name a tool publishes under, or in the tags its owner chose, is a claim about what that tool is. The same word in a description is prose, and prose is where a match is most often accidental, so name and tag matches count for more.

The same word is also worth less when the catalog is full of it. This is a catalog of AI tools, so words like llm and mcp sit on a large share of every entry and say almost nothing about which one you want. A word carried by more than a tenth of the catalog counts least; one carried by a hundredth or less counts most. Where a matched word is common, the reason line prints how many entries carry it, so the figure is visible rather than implied.

A few dependency names also say what a project is for: a repository that declares @playwright/test runs end-to-end tests. Those names are mapped to the tags the catalog files that subject under. The mapping is a curated table rather than something the project stated, so it counts for half of what a declared name does, and the reason line names the dependency that implied it so the inference can be checked.

Your local choices also affect the score: a tool marked useful gets 6 extra points, each topic shared with tools marked useful adds 2, and each topic shared with selected tools adds 1. This history stays on your computer; it is not your web account or browser saved list. With a CLI account connection, interests explicitly chosen in the web account add at most 3 points in total, below the minimum 4-point direct project match. A score is the sum of these declared matching, feedback and account-interest rules. It is not a quality, security, license or fitness judgement. The rankingSemantics field in every result states the rule that was in force when it was produced.

When a list cannot be ranked

A broad query does not produce a ranking. A score is a function of which words matched in which field, so a two-word query has at most eight possible values while the number of tools it admits can run into the hundreds. Hundreds of entries then hold one score, and the five places in a shortlist are settled by measured stars rather than by relevance.

No weighting fixes this. Weights relabel those buckets; they cannot split them. So instead of adjusting the score, the result reports that the score did not separate anything.

That is what discrimination carries: how many entries the search admitted, how many held the same score as the last one shown without making the list, and whether what you are reading is a ranking or a sample of a tied group. When the tied group is small enough to read, the candidates left out are named.

A way to narrow comes with it. refinements are the catalog’s own tags, chosen because they are frequent among the candidates competing for a place and rare across the catalog as a whole. Each carries both counts — how many of the current candidates have the tag and how many entries have it overall — so a suggestion can be checked rather than taken on trust.

Catalog exclusions

A repository is removed from the public catalog when its evident purpose is abuse: distributing malware or luring people into downloading it, attacking accounts or servers (for example raid, nuker, selfbot, or token-stealing tools), or fraud and bypassing device or account protections (for example IMEI masking, or FRP and activation-lock bypass). Security research, penetration-testing, malware-analysis, and defensive tools are not excluded because of their subject.

Each exclusion is a manual decision by an Oh My Feed administrator. Keyword signals can bring a repository to a reviewer, but they never exclude anything on their own. The record keeps the GitHub numeric repository ID, a reason category, an evidence note based on the repository's own description and topics, evidence links, and who decided and when. It applies to the numeric ID, so renaming the repository or being found again by another discovery source does not bring it back while the exclusion is active. Official GitHub evidence is kept. The listing disappears at the next hourly publication.

Exclusions are reversible. A revoked exclusion stays in the history, and the repository returns at the next publication if it still meets the normal criteria. An exclusion is a catalog listing decision, not a security verdict on the code, and a repository that is not excluded is not thereby safe. To ask for a review of an exclusion, or to report a repository for review, use Corrections with the repository link and your evidence.

Validation and limits

Before publication, the snapshot is checked for canonical IDs, required relationships, source-specific metrics, safe URLs, valid timestamps, and dangling references. An invalid snapshot fails closed instead of rendering unknown destinations.

Published repositories are rechecked against the GitHub API by numeric repository ID about once a week, separately from discovery. A renamed or transferred repository is updated to its new name. An archived repository, or one below one star, is removed. A repository GitHub reports as not found (deleted or made private) is removed only after two not-found checks at least 24 hours apart; the not-found observations are kept as evidence, and the tool returns automatically if GitHub later serves it again. GitHub errors, timeouts, and rate limits never remove a listing.

Star-growth lists depend on when snapshots were taken: a growing tool that was not re-measured in the last 7 days is not listed, and a newly discovered repository appears only in New and fast until a second snapshot 1–14 days later exists. The current catalog is selective, not comprehensive, and reflects a point in time. Descriptions from the canonical source may remain in English even when the interface is Korean. Corrections create a support case for review; they do not directly alter a source record. See Corrections to identify a record and provide evidence.

정규 식별

도구는 HTTPS GitHub 저장소 루트에서 얻은 소문자 owner/repository로 식별합니다. 저장소 이름만으로는 충분하지 않습니다. 자격 증명, 사용자 포트, 쿼리, 프래그먼트 또는 tree, blob, issues 같은 하위 경로는 추측하지 않고 거부합니다.

사람과 조직은 GitHub 식별자로 표현합니다. 소유 관계는 비슷한 이름에서 추정하지 않고 별도 출처 기반 기록으로 유지합니다.

출처와 검증

정규 저장소와 제작자 메타데이터는 공식 GitHub REST API에서 옵니다. 발행 스냅샷은 출처 식별자, URL, UTC 수집 시각을 기록합니다. 스타와 포크는 그 시점에 묶인 변경 불가 수치 스냅샷입니다.

GeekNews, Hacker News, Product Hunt, Oh My Feed 편집 발견은 발견됐다는 근거를 제공할 수 있지만 공식 GitHub 확인을 대신하거나 다른 출처의 인기 수치로 바뀔 수 없습니다. 제품군은 사람이 정리한 정보입니다. 웹과 CLI의 모든 도구를 공식 GitHub 토픽·설명·저장소 이름에 같은 버전된 규칙을 적용해 자동 분류합니다. 기능을 직접 밝힌 신호를 먼저 적용하고, Claude Code·Codex 같은 호스트 에이전트 이름, 에이전트 스킬·메모리 관례, 저장소 이름의 mcp 구간처럼 약한 신호는 기능 규칙이 맞지 않을 때만 적용합니다. 메타데이터 발행 때 분류를 갱신하고 도구가 있는 카테고리만 필터에 표시합니다. 상세에는 일치한 근거와 정책 버전을 제공합니다. 이는 GitHub가 제공한 카테고리나 사람이 검토한 결과가 아니며, 근거가 없는 항목은 미분류로 유지합니다. 정규 다운로드 원본에는 기존 편집 필드를 보존합니다.

숨은 추천 점수가 아닌 정렬

인기순은 표시된 GitHub 스타 스냅샷, 저장소 생성일순은 저장소 생성일을 사용합니다. 동률은 정규 저장소 식별자로 일관되게 정리합니다. 현재 “Hot” 점수를 발행하지 않으며, 업데이트의 스타 증가 목록은 아래에 공개한 산식을 씁니다. 제품 이벤트 수집은 로컬 분석 동의가 없으면 기본적으로 전송되지 않으며, 동의 기반 이벤트 집계도 정렬 입력이 아닙니다.

이 정렬은 품질, 안전성, 성장세, 적합성을 측정하지 않습니다. 스타 수는 맥락일 수 있지만 문서, 유지보수, 라이선스, 보안 평가를 대신하지 않습니다.

업데이트의 스타 증가

업데이트에는 스타 증가 목록이 두 개 따로 있습니다. 둘 다 추천 점수가 아니며 하나의 값으로 합치지 않습니다.

빠르게 상승은 등재 도구의 최근 두 공식 GitHub 스타 스냅샷을 비교합니다. 하루당 스타 = (나중 스타 − 이전 스타) ÷ 두 스냅샷 사이 일수입니다. 증가가 양수이고 두 스냅샷 간격이 1일 이상 14일 이하이며 나중 스냅샷이 7일 이내일 때만 비교합니다. 간격이 더 짧으면 한 번의 급증이 부풀려지고, 더 길면 변화가 평균에 묻힙니다. 하루당 값이 큰 순으로 정렬하고 같으면 정규 저장소 식별자로 정합니다. 각 항목은 하루당 값, 증가량, 간격을 “하루 약 383”과 “5.9일 동안 스타 +2,248”처럼 두 스냅샷 시각과 함께 보여 줍니다. 이 값은 측정한 간격만 설명하며 그 밖으로 늘려 추정하지 않습니다.

신규 저장소 중 빠른 곳은 GitHub 생성일이 최근 14일 이내인 저장소이며, 최근 생성 저장소 발견으로 막 들어와 스냅샷이 하나뿐인 저장소도 포함합니다. 하루당 스타 = 현재 스타 ÷ 생성부터 스타 스냅샷까지 일수이고, 1일 미만은 1일로 계산합니다. 스냅샷은 7일 이내여야 합니다. 이 값은 최근 변화가 아니라 저장소 전체 기간의 평균이므로 “생성 후 스타”로 표시하고 별도 목록으로 둡니다.

각 목록은 상위 10개와 조건을 만족한 도구 수를 보여 줍니다. 스타는 수집 경로가 저장소를 다시 관측할 때만 다시 측정되므로 도구마다 간격이 다릅니다. 2026-10-09 기준 도구별 최근 두 스냅샷 간격의 중앙값은 약 7일이었습니다. 그래서 증가량 자체가 아니라 하루당 값을 비교합니다. 스타는 관심의 표시이며 품질·안전성·적합성을 측정하지 않습니다.

로컬 추천이 점수를 매기는 방식

로컬 CLI는 프로젝트에서 읽은 기술 이름과 사용자가 입력한 과제를 카탈로그와 맞춰 봅니다. 어디서 맞았는지에 따라 값이 다릅니다. 도구가 스스로 내건 이름이나 소유자가 붙인 태그에서 맞으면 그 도구가 무엇인지에 대한 주장이고, 설명문에서만 맞으면 문장이 우연히 겹친 경우가 많습니다. 그래서 이름·태그 일치를 설명문 일치보다 높게 칩니다.

같은 단어라도 카탈로그에 흔할수록 값이 낮아집니다. 이곳은 AI 도구 모음이라 llm·mcp 같은 말은 상당수 항목이 달고 있어 어느 것을 원하는지 거의 알려 주지 않습니다. 열에 하나 넘게 가진 단어는 가장 낮게, 백에 하나 이하인 단어는 가장 높게 칩니다. 흔한 단어가 맞았을 때는 근거 문장에 몇 개가 그 단어를 갖는지 함께 적어, 짐작이 아니라 수로 보이게 합니다.

의존성 이름 중 일부는 그 프로젝트가 무엇을 하는지도 알려 줍니다. @playwright/test를 선언한 저장소는 end-to-end 테스트를 합니다. 이런 이름은 카탈로그가 그 주제를 분류할 때 쓰는 태그로 이어 두었습니다. 다만 이건 정리해 둔 표에서 읽은 추론이지 프로젝트가 직접 말한 것이 아니므로, 선언된 이름의 절반만 칩니다. 어느 의존성이 그 주제를 가리켰는지 근거 문장에 함께 적어 확인할 수 있게 했습니다.

이 컴퓨터에서 남긴 선택과 피드백도 반영합니다. 유용하다고 평가한 도구에는 6점, 유용하다고 평가한 도구와 공통인 태그마다 2점, 선택한 도구와 공통인 태그마다 1점을 더합니다. 이 기록은 컴퓨터에 보관되며 웹 계정이나 브라우저 저장 목록과는 별개입니다. CLI 계정을 연결했다면 웹 계정에서 직접 선택한 관심 주제는 합계 최대 3점의 보조 신호이며 프로젝트 직접 일치의 최소 4점보다 낮습니다. 점수는 이렇게 공개한 일치·피드백·계정 관심 주제 규칙을 합한 값입니다. 품질·보안·라이선스·적합성 판단이 아닙니다. 결과의 rankingSemantics에 그때 적용된 규칙이 문장으로 들어 있습니다.

순위를 매길 수 없을 때

넓은 검색어는 순위가 나오지 않습니다. 점수는 "어느 단어가 어느 자리에서 맞았나"로만 정해지므로 단어 두 개짜리 검색어가 낼 수 있는 값은 많아야 여덟 가지인데, 그 검색어를 통과하는 도구는 수백 개일 수 있습니다. 그러면 수백 개가 같은 점수를 갖고, 목록의 다섯 자리는 관련성이 아니라 측정된 별 수가 정하게 됩니다.

이건 가중치로 고칠 수 있는 문제가 아닙니다. 가중치는 같은 통에 다른 이름표를 붙일 뿐 통을 쪼개지 못합니다. 그래서 점수를 손보는 대신 갈라내지 못했다는 사실을 결과에 싣습니다.

discrimination이 그 사실입니다. 이 조건이 몇 개를 통과시켰는지, 마지막 순위와 같은 점수인데 목록에 못 든 후보가 몇인지, 그래서 지금 보는 것이 순위인지 동점 그룹에서 뽑은 표본인지. 동점 그룹이 읽을 만큼 작으면 빠진 후보의 이름도 함께 알려 줍니다.

좁힐 방법도 같이 옵니다. refinements는 카탈로그 자신의 태그이며, 자리를 다투는 후보들 사이에서는 자주 나오고 카탈로그 전체에서는 드문 것을 고릅니다. 각 태그에 두 수 — 지금 후보 중 몇 개가 갖는지, 전체에서는 몇 개인지 — 를 함께 실어, 지어낸 제안이 아님을 확인할 수 있게 했습니다.

카탈로그 제외

목적이 악용임이 드러난 저장소는 공개 카탈로그에서 제외합니다. 악성코드를 배포하거나 내려받도록 유인하는 저장소, 계정·서버를 공격하는 도구(예: raid, nuker, selfbot, 토큰 탈취 도구), 사기 또는 기기·계정 보호 우회(예: IMEI 위장, FRP·활성화 잠금 우회)가 대상입니다. 보안 연구, 침투 테스트, 악성코드 분석, 방어 도구는 주제만으로 제외하지 않습니다.

제외는 Oh My Feed 관리자가 직접 내리는 결정입니다. 키워드 신호는 검토 대상을 찾는 데만 쓰며 그것만으로 제외하지 않습니다. 기록에는 GitHub 숫자 저장소 ID, 사유 분류, 저장소가 스스로 공개한 설명·topics에 근거한 메모, 근거 링크, 결정한 사람과 시각이 남습니다. 숫자 ID에 적용하므로 제외가 유효한 동안에는 저장소 이름을 바꾸거나 다른 발견 경로로 다시 발견돼도 다시 표시되지 않습니다. 공식 GitHub 근거는 보존합니다. 제외는 다음 정시 발행에서 반영됩니다.

제외는 되돌릴 수 있습니다. 해제한 제외도 이력으로 남고, 저장소가 일반 기준을 계속 만족하면 다음 발행에서 다시 표시됩니다. 제외는 카탈로그 등재 결정이며 코드의 보안 판정이 아닙니다. 제외되지 않았다고 해서 안전하다는 뜻도 아닙니다. 제외 재검토나 검토가 필요한 저장소 신고는 정정에서 저장소 링크와 근거를 함께 보내 주세요.

검증과 한계

발행 전에 정규 ID, 필수 관계, 출처별 수치, 안전한 URL, 유효한 시각, 끊어진 참조를 검사합니다. 유효하지 않은 스냅샷은 알 수 없는 목적지를 표시하지 않고 닫힌 상태로 실패합니다.

공개된 저장소는 발견 경로와 별도로 약 일주일마다 숫자 저장소 ID로 GitHub API에서 다시 확인합니다. 이름이 바뀌거나 이전된 저장소는 새 이름으로 갱신합니다. 보관(archived)됐거나 스타가 1개 미만이면 제외합니다. GitHub가 찾을 수 없다고 응답한(삭제 또는 비공개 전환) 저장소는 24시간 이상 간격을 둔 두 번의 확인에서 모두 찾을 수 없을 때만 제외합니다. 이 관측은 근거로 보존하며, 이후 GitHub가 다시 응답하면 자동으로 다시 표시합니다. GitHub 오류, 시간 초과, 요청 한도 초과로는 제외하지 않습니다.

스타 증가 목록은 스냅샷 시점에 좌우됩니다. 최근 7일 안에 다시 측정되지 않은 도구는 늘고 있어도 나오지 않고, 새로 발견된 저장소는 1~14일 뒤 두 번째 스냅샷이 생길 때까지 신규 저장소 중 빠른 곳에만 나옵니다. 현재 카탈로그는 선별 목록이며 전체 목록이 아니고 특정 시점의 상태입니다. 한국어 UI에서도 원출처 설명은 영어로 남을 수 있습니다. 정정 요청은 검토용 케이스를 만들 뿐 원출처를 직접 바꾸지 않습니다. 정정에서 기록과 근거를 알려 주세요.