Effect Schema Brainstorming

Make production schemas, generated examples, and functional properties the shared language of the conversation. Iterate on the schemas that the final implementation imports; never create disposable copies merely for brainstorming.

Use this skill for domain discovery that directly shapes implementation. Use executable-interactive-plans after the work expands into agreed Errors, Services, functions, and end-to-end stories.

Ground the workspace

1. Read the effect and effect-arbitrary skills when available.
2. Locate the workspace package that owns the domain and declares Effect v4. Read that installed Effect package's AGENTS.md and relevant source.
3. Locate the existing production schema module, its exports, callsites, and tests. Edit those schemas in place. For a new domain, create the schema in its intended final source module following package conventions.
4. Never place production schemas, competing copies, or wrapper schemas in a scratch directory. Keep test-only scenario schemas in the package's normal test location unless they are real domain concepts that belong in production.
5. Give every named production schema, type alias, interface, class, and named nested data structure its own JSDoc comment that states its domain role and includes a realistic @example usage. Document exported decoded types separately from their schema values. Name meaningful nested structures instead of hiding them in anonymous Schema.Struct declarations; inline primitive composition does not need JSDoc.
6. Generate examples directly from the production schema symbols. Keep permanent tests in the package's normal test location. Use a one-off runner for sample printing unless the package already has a samples convention, then delete that runner after capturing its output.

Keep one production working set throughout the conversation. Every accepted answer updates the same schema symbols that the final implementation uses.

Run the brainstorming loop