Naming policy v6 — family brand + product brand + category + suffix

Repos: oriz-<product>-<category>-<suffix>. Forks exempt

Naming policy v6

Decision

Repo slugs follow:

<family-brand>-<product-brand>-<category>-<suffix>

• family brand = oriz (always on family repos)
• product brand = a unique short word per product (e.g. paisa for finance, slice for PDF, pixie for image)
• category = the function (e.g. finance-tools, pdf-tools)
• suffix = the runtime/role (-app, -game, -api, etc.)

Examples:

Google-style branding: the family brand carries recognition; the product brand provides per-product identity (cf. “Google Maps”, “Google Pixel”, “Google Workspace”).

Special cases (category IS the brand)

Where the category word already IS the brand, format collapses to oriz-<category>-<suffix> (no separate product brand):

Games where game-name IS the brand

oriz-<game-name>-game (no separate product brand). Game name carries identity.

Suffix matrix

Suffixes name the runtime/role of the repo:

-app, -game, -kids-game, -api, -npm-pkg, -py-pkg, -rs-crate, -go-mod, -npm-cli, -py-cli, -rs-cli, -browser-ext, -vsc-ext, -mcp-server, -worker, -fn, -data, -skill, -rules, -dotfiles, -gh-action.

Live repo slugs

App repos

Tool-app repos

API repos

Why single family brand

• Google-style branding wins recognition. A user who knows “Oriz” recognises every Oriz product on sight.
• Cross-product link-building is stronger with one family brand. oriz.in linking to every oriz-*-app repo accumulates domain authority faster.
• Recruiter scanning still works — the suffix tells the type, the category tells the function, the oriz- prefix tells the family.
• No brand-naming bikeshedding per new repo. New tool ships? oriz-<product-brand>-<category>-<suffix>. Quick decisions.

Exceptions

Three classes of repos escape the oriz- prefix:

1. Apex umbrella keeps bare name

chirag127/workspace stays as workspace (no oriz- prefix, no suffix). It’s the meta umbrella holding everything; adding a brand prefix would be circular.

2. Existing astro-*-npm-pkg packages keep current names

The 8 shipped Astro packages keep their astro-<role>-npm-pkg form:

Rationale: astro- is a meaningful brand prefix on its own (Astro framework family). New npm packages going forward DO get the oriz- prefix unless they are specifically Astro framework adapters; those keep the astro- prefix to read as part of the Astro ecosystem.

3. Forks always keep upstream slug

Forks of upstream repos keep their original GitHub name. No -fork suffix. No oriz- prefix.

Per-category nuance

The category portion behaves differently per repo type:

Tool apps — keep category in slug for SEO

Tool apps benefit from the category word being searchable. Google ranks oriz-pdf-tools for “pdf tools” the way it ranks “Google Images” for “images.” Pattern: oriz-<product-brand>-<category>-<suffix>.

Games — game-name + suffix (no category word)

Games don’t benefit from a generic category word — the GAME NAME itself is what users search for. Pattern: oriz-<game-name>-game.

Content apps — product-brand + function + suffix

Content apps where the function name carries the brand:

Decision tree for new repos

Is the repo a tool app where users search for "X tools"?
  YES ? oriz-<product-brand>-<category>-tools-app
  NO  ? Is it a game (named entity is the product)?
        YES ? oriz-<game-name>-game (or -kids-game)
        NO  ? oriz-<product-brand>-<role-or-function>-<suffix>

API + website combo repos

Some repos ship BOTH a server-side API (Cloudflare Worker / Function / scheduled job) AND a public-facing website (examples: tickertape-mmi, fii-dii-tracker — both scrape Indian financial data, expose a REST endpoint, AND host a small dashboard site showing the same data).

Pattern: primary = the artifact that drives revenue / users.

• If the API is what gets consumed (other services call it): primary is -worker.
• If the dashboard is what users see (humans visit it): primary is -app.
• Both shipped from one repo.

Final pattern for API+site combos:

• One artifact only: pick the dominant role’s suffix.
• Dataset shipped to oriz-*-data repo if the data is also reused elsewhere (separate repo).

Vendor-convention exceptions

Some repo names match a vendor or community convention better than oriz-* would. These keep their bare slugs:

For envpact specifically, the 7 repos keep their envpact-* prefix but add the v5 role suffix to each:

• envpact (umbrella) ? keep
• envpact-cli ? envpact-npm-cli
• envpact-registry-publisher ? envpact-registry-publisher-npm-cli
• envpact-python ? envpact-py-pkg
• envpact-dashboard ? envpact-dashboard-app
• envpact-vscode ? envpact-vscode-vsc-ext
• envpact-action ? envpact-gh-action

Cross-refs

• — predecessor (status: superseded by v6)
• multi-target-build — release cadence, deploy gating, sentry, sitemap, dashboard locks
• per-runtime-framework — framework matrix per runtime
• keep-knowledge-fresh — meta-rule

Edit on GitHub · Back to index