Not yet assessed
Review the original instructions and requested permissions before installing.
No security review is available for this catalog entry yet.
Apply Grida enterprise-edition conventions to commercial and hosted features.
Working pattern for enterprise-edition features in Grida — the commercial/hosted concerns (entitlement, BYOD, billing) on top of the OSS core. Anchor for the `GRIDA-EE: <surface>` grep marker, `(ee)` route group, `*-hosted` package suffix, and namespaced `grida_*` schema. Use when adding or touching an EE-only feature, or deciding whether a feature is EE territory. Surface skills (`ee-billing`) are siblings.
Review the original instructions and requested permissions before installing.
No security review is available for this catalog entry yet.
How clearly the skill guides your agent, how complete its workflow is, and how you can check the outcome.
No quality assessment is available for this catalog entry yet.
Original instructions from the publisher’s SKILL.md
# ee Grida is open source. Some features only exist because Grida is also a hosted commercial product — org-level entitlement, custom domains, billing. Those features are **EE (enterprise edition)**: they ship in the same monorepo as the OSS core, but a self-hoster running the codebase without paid infrastructure should be able to identify and strip them. This skill is the anchor for that boundary. No `GRIDA-EE` marker exists in the repo today; this skill establishes the convention. ## What counts as EE The test: _would this feature still make sense in a single-user, no-billing self-hosted instance?_ If no, it is EE. Three surfaces today: - **Org / entitlement** — the commercial layer on top of multi-tenant routing. Paid plans, member seats, the entitlement check that gates paid features. _The tenant routing substrate itself (`(tenant)` route group, RLS, hostname resolution) is OSS infrastructure — only the commercial layer on top of it is EE._ - **Custom domains (BYOD)** — user-owned apex + subdomain mapping on Vercel. See [multi-tenant-custom-domain-vercel](https://grida.co/docs/wg/platform/multi-tenant-custom-domain-vercel). - **Billing** — subscriptions, AI credit, the entitlement gate primitive. See the `ee-billing` skill (planned) for the workflow. ## The `GRIDA-EE` marker Like `GRIDA-SEC`, the boundary is grep-able. Tag every file that exists _only_ for EE, with the surface as the sub-label: ```ts // GRIDA-EE: entitlement — paid-plan gate // GRIDA-EE: byod — apex domain verification // GRIDA-EE: billing — see ee-billing ``` Sub-labels are surface names (`entitlement` / `byod` / `billing`), not ids — there is no central registry like `SECURITY.md`. The grep is the index: ```sh grep -rn 'GRIDA-EE' editor crates packages ``` Tag the file header when the entire file is EE; tag inline when only a branch is EE. **Known limitation.** The marker captures files that exist _only_ for EE. Shared utilities that EE imports but OSS also uses are not tagged — strip-time discovery has to come from an import audit, not grep. Don't tag OSS modules with EE callers; tag inline at the EE branch instead. ## Physical placement Co-locate by surface so the grep doesn't have to do all the work. - **Next.js routes** — group under `(ee)` only when a cluster of EE-only routes shares chrome/auth distinct from OSS readers (per [`naming`](../naming/SKILL.md), route groups encode the reader on the other side of the screen). For a single EE route inside an OSS reader's surface, tag inline rather than fragmenting the existing group. Tenant _content rendering_ stays in `(tenant)` — that is the OSS routing substrate, not EE. - **Packages and crates** — use the existing `*-hosted` suffix when the whole package is EE-only. `grida_hosted` already lives in the DB schemas as the parallel namespace, and `*-hosted` is in `naming`'s established suffix list. Don't mint a parallel `*-ee` suffix. Mixed packages stay unsuffixed and tag the EE branches inside. - **Database** — namespaced schema. Existing examples: `grida_billing`, `grida_hosted`. Don't bleed EE columns into OSS-relevant tables. Schema-design rules live in the [`database`](../database/SKILL.md) skill / `supabase/AGENTS.md`; consult those. When in doubt, default to the EE-named location. The cost of moving later is the cost of every import. ## Working on EE features 1. Tag every file you create or touch with `GRIDA-EE: <surface>`. 2. Place new code in an EE-named location. If there's no existing EE location for the surface yet, create it — don't dilute an OSS one. 3. **Direction of dependency: EE → OSS, not OSS → EE.** Stripping the `(ee)` group and `*-hosted` packages must not break OSS modules. Where OSS needs to query an EE concept (entitlement, paid plan, member seats), define the interface in OSS and let EE provide the implementation — not a direct import of an EE module from an OSS one. 4. Fail-closed at the EE boundary is [`security`](../security/SKILL.md) discipline — see `GRIDA-SEC-003` (BYOK fail-closed) for the worked example. ## When EE crosses security EE surfaces that also carry a `GRIDA-SEC-<id>` tag — the Stripe and Metronome webhook receivers (`GRIDA-SEC-001`), the BYOK carve-out (`GRIDA-SEC-003`), any path that gates entitlement on a signed payload — run the [`security`](../security/SKILL.md) review first; this pattern is the second pass. Tag the file with both markers. > Precedence is stated here only; if the rule becomes load-bearing, > mirror it into `security/SKILL.md` so a reader entering from that > side doesn't miss it. See also: `ee-billing` (billing workflow — planned), [`security`](../security/SKILL.md) (boundary contracts, fail-closed discipline), [`naming`](../naming/SKILL.md) (the suffix list this inherits), [`oss-standards`](../oss-standards/SKILL.md) (public-by-default discipline), [`database`](../database/SKILL.md) (schema namespacing).