CODEZ / ABOUT & DATA METHODS
About CODEZ: Skill sources, repository stars and data methods
CODEZ.WIN is a traceable Agent Skill discovery directory. It helps you find candidates for a task, then check the original repository for instructions, dependencies and licensing. This page explains how our numbers and labels are produced and what they cannot establish.
Methods reviewed:
Catalog snapshot:
This page describes our actual collection and display rules. Third-party descriptions belong to their authors; method explanations and selection advice are CODEZ editorial work. Inclusion does not mean a project has been tested in use, audited for security or certified for compatibility.
Which sources are currently included?
This snapshot contains 11 repositories and 611 skills; the source list configures 11 repositories. This collection recorded 0 repository errors, and 0 repositories retain older data.
The table follows source-list order, not popularity. “Not marked stale” means no repository-level failure flag is present, not that every file was read. A partial refresh may retain older data for other repositories, so the batch timestamp is not each source’s collection time.
Original repositories and the published snapshot:
| Source repository | Repository stars | Included skills | Collection status |
|---|---|---|---|
| anthropics/skills | 183,533 | 20 | Not marked stale |
| openai/skills | 28,289 | 44 | Not marked stale |
| vercel-labs/agent-skills | 32,960 | 9 | Not marked stale |
| obra/superpowers | 304,663 | 15 | Not marked stale |
| microsoft/skills | 3,145 | 209 | Not marked stale |
| vercel-labs/open-agents | 5,862 | 13 | Not marked stale |
| anthropics/knowledge-work-plugins | 32,664 | 252 | Not marked stale |
| huggingface/skills | 11,209 | 26 | Not marked stale |
| cloudflare/skills | 3,166 | 19 | Not marked stale |
| supabase/agent-skills | 2,923 | 2 | Not marked stale |
| duixcom/duix-skills | 12 | 2 | Not marked stale |
Why might a skill be missing?
Collection scans only public, enabled repositories on the source list, using their default-branch file trees. The current limit is 300 candidate SKILL.md files per repository. An exceeded limit or truncated tree fails repository collection rather than publishing a truncated result as complete.
Paths containing these directory fragments are currently excluded: /test/, /tests/, /fixtures/, /node_modules/, /examples/. Filenames must end in SKILL.md, with nonempty string name and description fields in YAML frontmatter. Third-party scripts are not executed.
These are our parseability requirements, not validation of every Agent Skills specification rule. Unreadable files, missing metadata or parse failures may cause individual files to be skipped. Projects outside the source list are not discovered automatically.
Why do different skills display the same Star count?
Stars belong to GitHub repositories. Skills within one repository display the same repository Star count. These are not counts of people starring individual skills and should not be added across skills. GitHub uses stars for bookmarking and appreciation, so we treat them as discovery signals.
The homepage repository ranking sorts by descending stars, then repository ID for ties. The complete skill catalog sorts by source repository stars, then skill name and ID for stable ordering. Card numbers are directory positions, not performance scores. The homepage also offers alternative sorts, including names.
| Field | What it represents | What it cannot establish |
|---|---|---|
| Repository stars | Repository attention returned by GitHub at collection time | An individual skill’s success rate or security |
| Included skill count | Parseable entries retained in this snapshot | All repository capabilities, quality or compatibility |
| Repository update date | The latest repository push time reported by GitHub | Which changes fixed the particular skill you need |
Are categories author claims or CODEZ judgments?
Each skill receives one category inferred by our rules. Manual overrides take priority, followed by cloud-service and Agent-workflow rules on names and paths. Remaining entries use keyword hit counts across the name, description and skill path; no match produces “Other.” Ties follow rule order.
A skill may span development, data and research tasks, while the directory assigns a single main category. Misclassification is possible. A category does not prove client compatibility; read SKILL.md, README and dependency instructions after filtering. A correction needs the repository, exact SKILL.md path and source text supporting the proposed category.
These are CODEZ editorial category reviews for specific files; previous labels came from the public catalog at review time. The evidence is the original text at the linked fixed commit. Only directory categories were changed; these third-party skills were not executed and their effectiveness across clients is not established.
| Skill | Previous category | Current category | CODEZ reasoning | Sources checked |
|---|---|---|---|---|
| obra/superpowers / brainstorming | Design | Agent workflows | Organize collaboration before implementation to confirm intent, requirements and design. The main outputs are collaborative decisions and specifications. | 2026-10-07 |
| obra/superpowers / verification-before-completion | Other | Agent workflows | Identify the verification command and inspect its complete output before claiming completion. The main output is evidence for acceptance and delivery. | 2026-10-07 |
| obra/superpowers / writing-skills | Documents | Agent workflows | This skill focuses on creating and editing skills and checking agent behavior under pressure scenarios. Its main purpose is the process of authoring and verifying reusable agent capabilities. | 2026-10-07 |
| anthropics/skills / pdf | Design | Documents | This document explains how to extract, merge, split, generate, and OCR scanned PDF documents; the main input and output are documents, and the Python examples illustrate the implementation methods. | 2026-10-08 |
| openai/skills / pdf | Development | Documents | This skill focuses on reading and creating PDFs and checking rendered pages before delivery. Its main outputs are documents and layout verification, rather than software-development work. | 2026-10-08 |
| vercel-labs/open-agents / frontend-design | Agent workflows | Design | Guides frontend interface implementation through typography, color, layout and motion; the main deliverables are interface design and code. | 2026-10-11 |
| cloudflare/skills / cf-cli | Development | Cloud | Focuses on Cloudflare API operations, Workers deployment and management of DNS, D1, KV and R2 resources; cloud service operations are the primary task, and the source marks the CLI as beta. | 2026-10-13 |
| cloudflare/skills / gateway-workers | Development | Cloud | Focuses on the Forward action in Cloudflare Gateway HTTP policies, Workers and the GatewayMiddleware entrypoint; cloud services are its main scope. Only the source text was reviewed; the Skill was not run. | 2026-10-19 |
CODEZ: choosing workflow skills by task stage ↗
CODEZ: two PDF skills compared with acceptance checks ↗
obra/superpowers / skills/brainstorming/SKILL.md ↗
obra/superpowers / skills/verification-before-completion/SKILL.md ↗
obra/superpowers / skills/writing-skills/SKILL.md ↗
anthropics/skills / skills/pdf/SKILL.md ↗
openai/skills / skills/.curated/pdf/SKILL.md ↗
vercel-labs/open-agents / .agents/skills/frontend-design/SKILL.md ↗
Can every public repository be used in your own project?
Public visibility on GitHub and licensing are separate facts. CODEZ keeps licensing uncertainty explicit and does not infer permission from a project name, promotional README text or download availability.
| Label | Our evidence | Check before use |
|---|---|---|
| SPDX identifiers such as MIT or Apache-2.0 | Use the repository license identified by GitHub when no independent license file is nearer to the skill in the directory hierarchy | Original license text, scope and licenses for additional content |
| License file needs review | An independent license file in the skill directory or an ancestor, or an unrecognized root license | That file’s text; the root license is not automatically inherited |
| Unspecified | No identifiable licensing evidence was found | Ask the source project for permission; readability is not a license |
Where do Chinese and English descriptions come from?
The interface and first-party explanations are maintained in thirteen languages. Third-party summaries currently identify Chinese and English README files beside SKILL.md, preferring explicitly named language files; plain README.md is classified from its text. Chinese and English interfaces prefer a short original summary in that language. Other interfaces retain the original SKILL.md description. Available Chinese and English README links are preserved.
If a matching language or usable excerpt is unavailable, the card falls back to the original SKILL.md description. We do not substitute a repository-wide README for an individual skill or present machine translations as author text. An English interface can therefore contain Chinese source text, and vice versa.
What happens when collection fails?
The server starts collection daily at 10:37 Beijing time (UTC+08:00), then generates static pages from MySQL. The snapshot timestamp marks generation of that batch, not simultaneous reads from every source or each project’s own update time.
A repository-level request failure retains its last successful data, marked as older data in the ranking and this page. If all sources fail, the previous snapshot remains and collection reports failure. Repository errors are recorded in the public catalog JSON. Individual file failures may only be logged and skipped, without marking the entire repository stale, so a successful run still has coverage limits.
Source links point to the default branch used at collection; upstream files may later change. To reproduce a finding, record the exact GitHub commit and file path rather than just a CODEZ number.
How should you use this information to choose a skill?
Narrow candidates by task, input and output, then check requirements, operation scope and licensing. Run a small trial on the same input and record results. Repository stars, inferred categories and author descriptions help you find candidates; they do not perform that trial for you.
Our selection guide offers a repeatable checklist and illustrative scenarios. Examples are not measured results for a particular project. Future project analysis will also distinguish public-source judgments from actual tests.