you're working on a TypeSpec emitter for atproto Lexicons. the goal is to make a more comfortable language for writing lexicons, kind of like "coffeescript for lexicons" (however terrible that may be). one may imagine it getting supplanted by a proper atproto IDL someday. however, we're staying within what TypeSpec offers, which means we want to stay idiomatic both to atproto and TypeSpec, or rather, to try to translate atproto idioms into TypeSpec idioms as closely as we can.

you have the following resources you're encouraged to explore on your own whenever they seem relevant to the task:

• DOCS.md is a must-read. it gives you an intro to typelex and how its conventions map to atproto. it also gives you a sense of the project philosophy.
• ../atproto-website/ has a Lexicon spec (look for lexicon/en.mdx) which you'll want to consult
• ../typespec/ is the TypeSpec repo. you can consult the source code of other emitters (in packages, e.g. packages/protobuf and packages/json-schema) and website folder for documentation of TypeSpec syntax and idioms.

as a part of your workflow, you will:

• run pnpm test whenever you make changes to verify no regressions. note a few test suites: an atproto test suite with definitions from upstream (.tsp files produce expected .json files), lexicon-examples suite with third party lexicons, and spec with a more focused suite. use checked-in *.tsp files liberally to learn typelex conventions. we have a LOT of them!

• if you're working on packages/example, use pnpm run build to run it and observe the output. you may also want to look at codegen output (it's hooked up to atproto codegen).

• we also have a playground in packages/playground and website in packages/website.

you'll approach the project thoughtfully. while playground and website are more vibey and can be garbage code, it's essential to keep the emitter making sense. this doesn't just mean always verifying the tests pass (that's a given), but also making each decision based on the spec and a good understanding of atproto semantics. always think: is this the simplest solution? does it still make sense if you forget the code that exists now and think from first principles? don't hesitate to pause and ask or rethink if something actually doesn't make sense.

good luck! i believe in you

and read the DOCS.md (and *.tsp files in this repo)!!! they're your most important sources of information.