Rishab Ramanathan

We were tired of manually writing git commits for @linear issues. So I built a @raycast extension. Simply copy the Linear issue ID → hit your hotkey → paste the commit message. That's it! Why build it? We love how you can link Git commits to @linear issues. However, doing this while also following other best practices (like Conventional Commits) made writing commit messages painful. For example, for a Linear issue with ID 'ENG-123' and title 'Some bug', we'd have to: 1. Type the commit type ('fix') 2. Copy the Linear issue ID from Linear 3. Paste it with 'closes' (or some other magic word) → 'fix(closes ENG-123):' 4. Copy the Linear issue title from Linear 5. Paste it → 'fix(closes ENG-123): Some bug' 6. Lowercase the first letter → 'fix(closes ENG-123): some bug' We'd bounce between Linear and Terminal 3+ times, copying/pasting/editing until we got it right. The team was rightfully complaining that the process was annoying. We even considered changing how we name Linear issues to minimize the number of edits. That's why I built the @raycast extension! Behind the scenes, the extension fetches the Linear issue with the specified ID using Linear's API and constructs the full commit command. The conventional commit type ('fix', 'chore', 'docs', etc.) is inferred from the Linear issue label. The extension is private to the @openlayerco org, because it follows our commit message formatting, but hopefully you can build your own version of this!

My first magical moment with LLMs was using GPT 3.5. My second was MCP. That's why I'm super excited about the Openlayer MCP server release! Check out the demo below

I used to beg LLMs for structured outputs. Most of the time, they understood the job and returned valid JSONs. However, around ~5% of the time, they didn't, and I had to write glue code to avoid breaking downstream modules of my system. Then, I found @jxnlco's instructor. instructor is a zero-cost abstraction that works by leveraging OpenAI's function calling. The steps are: 1. patch the OpenAI client with instructor. 2. define the Pydantic model for the output I expect. 3. pass the Pydantic model as an extra kwarg to my OpenAI call. Once that's done, instructor guarantees that what I get back is a valid instance of the Pydantic model. I no longer need to write code to handle the unsuccessful cases. Another benefit I found of using instructor is that it is a much better way to organize my prompts. I can keep information close to the source, with doctrings, field descriptions, and examples. The example in the screenshot is simple. However, I'm using instructor to manage close to 100 different Pydantic models, each with 3-5 layers of nested objects. And guess what? It works. For some complex objects, though, the LLM violates some constraints on the first try. instructor also has a retry mechanism. If a constraint is violated, it sends another request to the LLM with part of the stack trace, so that the LLM can correct the output, as in the screenshot below (traces in @openlayerco). Overall, I'm pretty satisfied with using instructor, and it solved a major issue for us. Also, excited that instructor 1.0.0 just released!