标签：#devto

Sometimes an email shouldn't go out the instant your code runs. A human needs to review it first, or the user wants to compose now and hit send later, or an AI agent proposes a reply that a person approves before it ships. The mechanism for all three is the same: a draft. Build that against providers directly and you're juggling Gmail's draft resource, Microsoft Graph's, and an IMAP APPEND to the Drafts folder, each with its own shape and quirks. The Nylas Email API collapses that into one draft resource. You create a draft on the user's account, it lands in their real Drafts folder, and you send it later with a single request, the same way across Gmail, Microsoft 365, Yahoo, iCloud, IMAP, and Exchange. This post walks the full draft lifecycle from two angles: the HTTP API for your backend, and the nylas CLI for the terminal. I work on the CLI, so the terminal commands below are the ones I reach for. One draft resource across every provider A draft in the Nylas model is a real object in the user's mailbox, not a staging area on the side. When you create one, it saves to the user's own Drafts folder on their provider, so it shows up in their normal mail client exactly like a draft they started themselves. That's the property that makes drafts useful for review workflows: a person can open the mailbox and see the pending message before it sends. Because drafts are real provider objects, edits flow both ways. A draft you create through the API appears in the user's mail client within the provider's sync window, and a change the user makes there alters the same draft you'd fetch back through the API. The operations split across two paths: create and list live on /v3/grants/{grant_id}/drafts , while fetch, update, send, and delete act on a specific draft at /v3/grants/{grant_id}/drafts/{draft_id} . They behave the same across all six providers, so you write the integration once. Create a draft Creating a draft is a POST /v3/grants/{grant_id}/drafts with the same message

An AI agent that can email but can't hold a calendar slot is only half useful. The moment a conversation turns into "let's meet Thursday at 2," the agent needs a real calendar — one that sends invitations people accept in Google Calendar or Outlook, receives invites at its own address, and RSVPs back so the organizer sees a real response next to everyone else's. Bolting a scheduling library onto a shared mailbox doesn't get you there; the agent needs a calendar identity of its own. An Agent Account ships with exactly that. Every account gets a primary calendar that hosts events, accepts invitations over standard iCalendar, and RSVPs with yes, no, or maybe. To a participant, the agent is just another attendee on the invite. This post walks through using that calendar from two angles: the HTTP API for your backend, and the Nylas CLI for the terminal. I work on the CLI, so the terminal commands below are the ones I reach for. The calendar an Agent Account comes with When Nylas provisions an Agent Account, it creates a primary calendar that belongs to the account. You reach it through the same Calendars and Events endpoints at /v3/grants/{grant_id}/... that any other grant uses, so calendar code you've written for a connected Google or Microsoft account works here unchanged. Each account gets: A primary calendar , provisioned automatically. It can't be deleted while other calendars exist on the account. Additional calendars , up to your plan's cap, for separating concerns — a sales-calls calendar and an internal one on the same agent. Free/busy queries , so the agent can check its own availability before proposing a time. Event webhooks — event.created , event.updated , and event.deleted fire on every change, whether it came from the agent or from someone responding to an invitation. List the calendars from the terminal with nylas calendar list , or over the API with GET /v3/grants/{grant_id}/calendars . Both return the primary calendar plus any you've added. List what'

An AI agent sends an email, a reply lands three hours later, and the agent has to answer two questions before it can do anything useful: which conversation is this, and what did I last say? Get the first one wrong and the agent's reply shows up in the recipient's inbox as a brand-new message instead of slotting into the existing thread. To the person on the other end, that looks broken — like the agent forgot the conversation it started. Threading is the part of agent email that's easy to get almost right and quietly wrong. The fix lives in a few email headers most developers never touch, and in the Threads API that groups messages into conversations for you. This post walks through both, from two angles: the HTTP API for your backend, and the Nylas CLI for the terminal. I work on the CLI, so the terminal commands below are the ones I reach for when I'm testing a reply loop. The three headers that make threading work Threading runs on three email headers, not on subject lines. Every message carries a Message-ID — a globally unique identifier the sending server stamps on it. When someone replies, their mail client adds In-Reply-To (the Message-ID of the message being answered) and References (the full chain of Message-ID values, oldest to newest). Those two headers are how every mail client decides which messages belong together. Here's what the chain looks like across one exchange. The agent's first message gets a Message-ID ; the reply points back at it; the agent's follow-up references both: # The agent's outbound message Message-ID : <abc123@agents.yourcompany.com> Subject : Following up on your demo request # The recipient's reply Message-ID: <def456@gmail.com> In-Reply-To: <abc123@agents.yourcompany.com> References: <abc123@agents.yourcompany.com> Subject: Re: Following up on your demo request # The agent's follow-up Message-ID: <ghi789@agents.yourcompany.com> In-Reply-To: <def456@gmail.com> References: <abc123@agents.yourcompany.com> <def456@gmail.com> The Ref

Most "AI agent that emails for you" demos point a language model at a human's Gmail inbox over OAuth. That works until the agent needs its own identity: an address people reply to, a calendar that accepts invites, a mailbox your application owns end to end. Borrowing a human's inbox means inheriting their OAuth scopes, their rate limits, and the awkwardness of an agent sending mail as a person who didn't write it. A Nylas Agent Account flips that around. It's a real name@yourcompany.com mailbox that you create and control entirely through the API — it sends, receives, hosts calendar events, and RSVPs, and it's indistinguishable from a human-operated account to anyone on the other end. Under the hood it's just a grant , so the grant_id you get back works with the same grant-scoped endpoints — Messages, Threads, Folders, Drafts, Attachments, Contacts, Calendars, and Events — you've already used for connected accounts, plus the standard webhook triggers. This post is a working tour of provisioning one, from two angles: the HTTP API for your backend, and the Nylas CLI for the terminal and quick experiments. I work on the CLI, so the terminal commands below are the exact ones I reach for. Why an Agent Account beats borrowing a human inbox An Agent Account is a first-class sender, not a delegated one. When the agent owns support@yourcompany.com , people reply to it directly, calendars invite it as a normal participant, and its mail authenticates as coming from you. A few concrete differences from pointing an agent at someone's existing mailbox: No OAuth flow to babysit. Creation needs only an email address on a domain you've registered — there's no refresh token to store or rotate, and the grant rarely expires because there's no OAuth token to refresh. Its own reputation. The account sends on your domain, and a new domain establishes its sender reputation over roughly four weeks of gradual sending. That reputation is yours to protect, not a shared corporate inbox's. Per-t

Developers inheriting sprawling SQL codebases or revisiting queries from weeks earlier know the frustration: a dense, unformatted block that obscures joins, filters, and logical flow. Readable SQL isn’t cosmetic — it directly affects debugging speed, peer review accuracy, and long-term maintainability. What it is SQL Formatter restructures raw SQL into clear, conventionally formatted code, running entirely in the browser. It applies consistent indentation, capitalisation of keywords, and logical line breaks — all without altering the query’s semantics. The formatter understands the syntax of all major database engines, including PostgreSQL, MySQL, SQL Server, and Oracle, so it preserves dialect-specific functions and operators rather than flattening them into a generic style. The tool is one of 200+ free browser utilities on DevTools. It processes all input entirely on your machine — no data ever leaves the browser, no account is required, and no analytics track your usage. That privacy-first design means you can safely format queries that contain proprietary business logic embedded in production SQL. The engine handles the full spectrum of SQL complexity: basic SELECT statements, multi-table joins, Common Table Expressions (CTEs), correlated subqueries, window functions, and DML operations like INSERT or UPDATE . Because it parses the input rather than applying regular expressions, deeply nested constructs retain their hierarchy, with each subquery or CTE level indented to show ownership. How to use it Paste any SQL fragment into the left-hand editor and the formatted result appears instantly in the output panel. A live preview updates as you switch formatting options, so you can tune the output without re-pasting. The primary configuration controls help you match your team’s conventions or personal preference: Dialect : selecting a specific database ensures that functions such as PostgreSQL’s STRING_AGG or MySQL’s GROUP_CONCAT are not inadvertently mangled, and th

Everyone is asking whether AI can write code. That question is already answered. The more important question is: Can AI understand the system it is changing? The biggest limitation of AI coding tools isn't code generation. It's system understanding. That is no longer the interesting question. AI can already generate APIs, tests, database migrations, infrastructure files, and entire services. The better question is: Does your AI understand the system it is changing? For most engineering teams, the answer is no. And that is where many AI-assisted workflows quietly fail. The illusion of understanding Ask an AI assistant to: create a new endpoint add a background worker generate a service layer write a migration Most models will produce something that looks correct. The code compiles. The tests may even pass. But production systems are not collections of files. They are collections of relationships. The real questions are: Which service owns this capability? Which projects depend on it? Which runtime executes it? Which release gates are affected? Which verification steps must pass? What breaks if this change is wrong? These questions are rarely visible in source code. They exist in architecture, operational knowledge, deployment rules, contracts, and team conventions. That is why an AI agent can generate valid code and still make the wrong change. Bigger context windows won't solve this The common response is: Give the model more context. But more context is not the same as better context. A million tokens of source code still do not explicitly answer: What projects exist? Which commands are safe? What evidence is trusted? What is currently blocked? What is ready for release? The issue is not missing tokens. The issue is missing structure. The missing layer Most AI tools understand: files functions repositories Production systems require understanding: ownership architecture dependencies operational boundaries verification requirements change impact This is the gap betw

A stat from 2026 that should stop you cold: 88% of organizations reported a confirmed or suspected AI agent security incident in the past year (92.7% in healthcare). And more than half of all agents run with no security oversight and no logging — naked. The problem isn't that the AI isn't smart enough. It's that almost nobody welded boundaries around it. And boundaries are exactly where rigor lives. The incident list: speed flooring it, boundaries naked The last couple of weeks of security signals line up scarily well: 88% of orgs reported confirmed/suspected AI agent incidents in the past year; healthcare 92.7% ; over half of agents have no security oversight or logging. Supply chain is the front door. A plugin-ecosystem supply-chain attack harvested agent credentials from 47 enterprise deployments ; attackers used them to reach customer data, financial records, and proprietary code — undetected for six months. A public skills marketplace at one point hosted 824 of 10,700 malicious "skills." Config is an attack surface. Check Point disclosed remote code execution in a popular coding agent via poisoned repository config files ; MCP (Model Context Protocol) is the connective tissue across nearly every incident this year — poisoned configs, malicious marketplace skills, unauthenticated exposed MCP servers. By early 2026, at least ten public incidents across six major AI coding tools were attributed to " agents acting with insufficient boundaries. " The industry's own summary: AI agent security in 2026 is a supply chain problem first, a prompt-injection problem second. And every one of these shares a single root cause — the agent can act, but there's no architectural boundary on what it can touch, change, or call. Why "naked" is inevitable: bolt-on boundaries always leak Why do half the agents run with no oversight? Because in the mainstream approach, boundaries are bolt-ons : an allow-list here, a gateway there, logs you read after the fact. The trouble: The tools an

We just shipped the Forgelab PDF API — a fast, affordable REST API for developers who need to handle PDF files without the hassle. What it does: Merge multiple PDFs into one Split PDFs by page ranges Compress PDFs to reduce file size Convert PDFs to images (PNG/JPEG) Pricing: Starts at $5/month for 100 calls/month. No hidden fees. Quick start: curl -X POST https://www.forgelab.africa/api/pdf/merge \ -H "X-API-Key: your_key" \ -F "files=@doc1.pdf" -F "files=@doc2.pdf" Sign up at forgelab.africa

Code reviews, configuration changes, and debugging sessions demand precise understanding of what changed between two versions of text. Manual comparison of large blocks of code or configuration files is error-prone, and version control diffs don’t always provide a quick, focused view for sharing or verifying changes outside a repository. What it is Diff Checker is a browser-based text comparison tool that performs line-by-line analysis of two text blocks and highlights differences with color-coded visual indicators. It processes text entirely in the browser—part of the 200+ free tools on DevTools—meaning no data is uploaded or stored, a privacy‑first design. The interface uses a split‑pane layout: original text on the left, modified text on the right. As you paste or type, the comparison engine recalculates the diff in real time, marking added, removed, and changed segments so differences are immediately clear. Several configuration options tailor the analysis. Toggling whitespace sensitivity ignores differences in indentation or blank lines, useful when comparing code from teams with different formatting conventions. Case sensitivity can be turned off for text where capitalization inconsistencies are irrelevant. A swap button reverses the comparison direction with a single click, handy when the assignment of “original” and “modified” is accidentally reversed. How to use it Paste the original text into the left panel and the modified version into the right panel. The diff view updates instantly, so you don’t need to press a button to see changes. For code, the process is straightforward. Drop a baseline function on the left: function calculateTotal ( items ) { let total = 0 ; for ( let item of items ) { total += item . price ; } return total ; } And the updated version on the right: function calculateTotal ( items , taxRate = 0 ) { let total = 0 ; for ( let item of items ) { total += item . price * ( 1 + taxRate ); } return Math . round ( total * 100 ) / 100 ; } The

Placeholder text is necessary scaffolding in web development, but ubiquitous Lorem ipsum can lead to design monotony and disconnect from project context. Developers building mockups, prototypes, or content-heavy interfaces often need filler text that matches the tone of the target application without introducing distracting Latin. What it is The Lorem Ipsum Generator is a browser-based tool that produces placeholder text in multiple styles, moving beyond classical Latin pseudo-text. It offers distinct variants: traditional Lorem ipsum, Hipster Ipsum with artisanal terminology, Corporate Speak filled with business jargon, and Pirate Ipsum with nautical themes. Each style maintains readability while providing vocabulary that aligns with the spirit of a given project. The generator is part of DevTools, a privacy-first collection of 200+ free browser tools where all processing happens locally—no signup, no tracking. Developers can configure generation parameters to specify the number of paragraphs, total word count, and whether to start with the familiar “Lorem ipsum dolor sit amet” opening. The output is plain text ready for pasting into HTML, design files, or CMS entries. How to use it The interface is a straightforward form: select a text style from the dropdown, then set the number of paragraphs or words you need. The tool generates the text instantly and provides a one-click copy button. <!-- Example output structure when pasting into HTML --> <div class= "content-area" > <p> Leverage agile frameworks to provide a robust synopsis for high level overviews... </p> <p> Iterative approaches to corporate strategy foster collaborative thinking... </p> </div> For typical workflows, 1–3 paragraphs suffice for article previews or body content. Headlines work well with 5–15 words, while navigation elements often need only 2–5 words. The quick copy functionality streamlines populating multiple content areas. Different styles suit different contexts: Corporate Speak makes busi

Let me confess something a little creepy. I have a habit of peeking at other people's dev posts. Not stealing the writing — relax. I run a tiny read-only job that fetches the public pages on dev.to, Zenn, and Qiita and counts only the boring parts: titles, post times, like counts. Who published what, at what hour, and how far it traveled. Then it tallies the lot. The reason is petty: my own posts weren't landing. The content is already in my hands — so I wanted to know how much the rest, the when and how you publish , actually moves the needle. By the numbers, not by gut. So I counted across three platforms. And the conditions that make a post fly turned out to be roughly mirror images between Japan (Zenn / Qiita) and the English-speaking world (dev.to). Here's the story. First, my most important disclaimer This post is full of numbers, so let me put up a guardrail before any of them. This is correlation, not causation . A result like "weekend posts don't do well" could mean the weekend itself is bad — or it could mean people who post on weekends are just dashing something off on the side. The data can't separate those. Please read it that way. Also, I only keep aggregate numbers I computed myself . I don't store or reuse anyone's article body (read-only GET, count the features, throw the page away). I peek, but only at the overall shape . Nobody gets singled out here. With that out of the way — four findings I enjoyed. 1. The best hour to publish is just your readers' time zone This one came out cleanest. On Qiita , posts published in the morning win (+32pt in the GOOD group). Midday is +14pt. Evening is -32pt, late night -14pt. Zenn likes midday too (+27pt). Late night is -15pt. dev.to is the exact opposite. Late night Japan time scores +7pt — Japanese evening is actually weak. The trick is obvious once you see it. dev.to's readers are English-speaking, mostly US. Late night in Japan is the US working day. Zenn and Qiita readers are in Japan, so the Japanese morni

Every developer I know has the same problem: knowledge scattered across five places at once. Browser bookmarks they never re-read. Notion docs that become graveyards. Slack threads with critical context that disappear into the archive. README files that contradict each other. Stack Overflow answers bookmarked with zero recall of why. I tried most of the "second brain" setups and none of them stuck until I figured out why they kept failing: generic productivity systems are not built for how developers actually think and work. A developer's knowledge is fundamentally different from a writer's or a manager's. It is: Code-linked (a note about a library is useless without the actual code it explains) Decision-heavy (architecture decisions need context, rationale, and alternatives considered) Debugging-intensive (solutions to bugs need the exact error message, environment, and what you tried) Time-sensitive (that API migration note is only relevant for a 3-month window) Here is the structure that actually worked. The Core Structure 00-Inbox/ 10-Projects/ 20-Areas/ - Language: Python/ - Stack: AWS/ - Domain: Auth/ 30-Resources/ - Libraries/ - Tools/ - Patterns/ 40-Archive/ The key insight: Resources are evergreen, Projects are temporary, Areas are ongoing responsibilities. A note about how JWT works lives in 30-Resources/Domain-Auth/ . A note about implementing JWT for the current sprint lives in 10-Projects/Sprint-42-Auth-Revamp/ . When the sprint is done, the project gets archived. The JWT fundamentals note stays forever. The Templates That Made It Click Architecture Decision Record (ADR) # ADR-042: Use Postgres over DynamoDB for user sessions Status: Accepted | Date: 2026-06-22 ## Context We need session storage that supports complex queries for the audit log feature. ## Decision Postgres with connection pooling via PgBouncer. ## Alternatives Considered - DynamoDB: rejected (query limitations for audit log requirements) - Redis: rejected (not durable enough for complian

Contacts are messier than they look. A user's real address book is spread across the people they've saved by hand, the people they've emailed often enough that the provider auto-collected them, and the colleagues in their company directory. Google exposes these through the People API; Microsoft through Graph; both model the data differently and split it across sources you have to query separately. The Nylas Contacts API unifies all of that behind one schema and one grant_id . You read saved contacts, auto-collected contacts, and directory contacts through the same endpoint, create and update entries that sync back to the provider, and organize them into groups. This post walks the contact surface from the HTTP API and the Nylas CLI , which mirrors every operation for terminal use. I work on the CLI, so the terminal commands below are the ones I run when I'm exploring an address book. The contact model and its three sources A contact in Nylas carries the fields you'd expect — given_name , surname , emails , phone_numbers , company_name , job_title , notes — plus richer ones like im_addresses , physical_addresses , and web_pages . The schema is the same across providers, so a Google contact and a Microsoft contact deserialize into one struct. The detail that trips people up is source . Every contact has one of three sources, and they mean very different things: address_book — contacts the user saved deliberately. This is the real address book. inbox — contacts the provider auto-collected because the user emailed them. These were never explicitly saved. domain — contacts from the organization's directory (coworkers). Knowing the source matters because "all contacts" usually isn't what you want. If you're building a contact picker, the inbox source can flood it with one-off recipients the user doesn't think of as contacts. Filter by source deliberately. See the Contacts API overview for the full data model. Before you begin You need a Nylas API key and a connected accou

Meeting notes are the feature everyone wants and nobody wants to build. The hard part isn't the summary — an LLM handles that. The hard part is getting into the meeting: a bot that joins Zoom, Google Meet, and Microsoft Teams, survives each platform's waiting room and admission flow, records cleanly, and produces a transcript you can feed downstream. Each provider has its own join mechanics, and none of them ships a tidy "record this meeting" API. The Nylas Notetaker API is that bot as a service. You point it at a meeting link, it joins on schedule, records, and generates a transcript, and you fetch the recording and transcript through one endpoint. This post walks the Notetaker surface from the HTTP API and the Nylas CLI , which mirrors the whole lifecycle for terminal use and quick testing. I work on the CLI, so the terminal commands below are exactly what I run when I'm testing a notetaker against a live meeting. Two ways to run a notetaker: grant-scoped or standalone Before any code, there's one architectural choice worth understanding, because it changes the endpoint you call. A grant-scoped notetaker is tied to a connected account and lives under /v3/grants/{grant_id}/notetakers . Use it when the bot acts on behalf of a specific user — it can read that user's calendar and join their meetings as them. A standalone notetaker has no grant at all and lives under /v3/notetakers . You hand it a raw meeting link and it joins, no connected account required. This is the one to reach for when you just have a URL and want a recording — a public webinar, a meeting on an account you haven't connected, or a system that deals in links rather than users. Same request body, same lifecycle, same media output; the only difference is whether there's a grant_id in the path. See the Notetaker overview for how both models fit together. Before you begin You need a Nylas API key. If you're using a grant-scoped notetaker you also need a connected account; for standalone, the API key al

If your integration polls Nylas every minute to check for new email, you're doing too much work and still getting stale data. Polling is a tax: you burn rate limit on requests that mostly return nothing, and a message that arrives at 12:00:05 doesn't reach your app until the next poll. Webhooks flip that around. Nylas pushes a notification to your endpoint the moment something happens — a message arrives, an event changes, a contact is created — and your app reacts in real time. This post walks the webhook surface from both sides: the HTTP API that registers and manages webhooks, and the Nylas CLI , which has genuinely useful tooling for the part everyone gets stuck on — verifying signatures and testing webhooks against local code. I work on the CLI, so the terminal commands below are the ones I run when I'm wiring up a webhook receiver. Triggers and destinations A webhook has two halves: the trigger types it listens for and the destination URL it pushes to. Trigger types are dotted event names like message.created , event.updated , and contact.created , grouped into categories — grant, message, thread, event, contact, calendar, folder, and notetaker. You subscribe one destination to as many triggers as you want. The CLI lists every available trigger so you don't have to guess the names: # All trigger types nylas webhook triggers # Only message-related triggers nylas webhook triggers --category message Webhooks are application-scoped, not grant-scoped: one webhook registered on your application receives notifications for every connected account, identified by the grant_id in each payload. See the notifications overview for the full event model. Before you begin You need a Nylas API key — webhook management is admin-level, so it uses the application's API key rather than a grant. You also need an HTTPS endpoint reachable from the public internet to receive the notifications. The CLI gets the key set up: nylas init # create an account, generate an API key For local de

Scheduling features look simple until you build them. Google Calendar speaks its own REST API with events.insert ; Microsoft 365 wants Graph and POST /me/calendar/events ; Apple and a long tail of providers expect CalDAV. The moment your app needs to read a user's events, drop a meeting on their calendar, or check whether three people are free at 2pm, you're staring down three integrations that disagree on field names, time formats, and recurrence rules. The Nylas Calendar API gives you one interface over all of them. Connect a user's account once, get a grant_id , and read calendars, manage events, send RSVPs, and compute free/busy with the same request shape whether the backing provider is Google or Microsoft. This post walks the calendar surface from both sides: the HTTP API your backend calls, and the Nylas CLI for testing the same operations in a terminal. I work on the CLI, so the terminal snippets below are the commands I actually run when I'm poking at a calendar. Calendars, events, and the calendar_id A connected account has one or more calendars , and every event belongs to exactly one of them. Most operations take a calendar_id , and the special value primary resolves to the account's default calendar — so you don't need to look up an ID to act on the main calendar. One exception: iCloud doesn't support primary , so for iCloud accounts you pass a real calendar ID from nylas calendar list . An event carries a title , a when object holding its start and end times, a list of participants , an optional location , and flags like busy . That schema is identical across providers, which is the whole point: you read a Google event and a Microsoft event into the same struct. See the Calendar API overview for how calendars, events, and availability fit together. Before you begin You need a Nylas API key and a connected account with calendar scopes. The CLI gets you there in two commands: nylas init # create an account, generate an API key nylas auth login # connect

Most "AI email" demos point a model at a human's inbox over OAuth. That's fine until you want the agent to be a participant — to have its own address that people reply to, that calendars invite, and that builds its own sender reputation. Pointing at someone's personal inbox doesn't give you that. Nylas Agent Accounts take the other approach: a real name@yourdomain.com mailbox and calendar that the agent owns end to end. It sends, receives, hosts events, and RSVPs — and to anyone on the other side it's indistinguishable from a human-operated account. It went GA in June 2026. The part I like as an SRE: it's not a new API surface. An Agent Account is just another Nylas grant . It gets a grant_id that works with every endpoint you already use — Messages, Drafts, Threads, Folders, Attachments, Calendars, Events, Webhooks. Nothing new to learn on the data plane. This walkthrough provisions one two ways (CLI and raw API), then sends, receives, RSVPs, and adds guardrails. What you get When you create an Agent Account, Nylas provisions a real mailbox on a domain you've registered (or a Nylas *.nylas.email trial domain). Each account comes with: An email address that sends and receives like any other mailbox Six system folders ( inbox , sent , drafts , trash , junk , archive ), plus any custom ones you create A primary calendar that hosts events and RSVPs over standard iCalendar/ICS A grant_id for all the existing Nylas endpoints Before you begin You need two things: A Nylas API key. The fastest path is the CLI — nylas init creates an account and generates a key in one command. A domain. Either a Nylas-provided *.nylas.email trial subdomain (good for testing in minutes) or your own custom domain with MX + TXT records. Register it under Organization Settings → Domains. Why your own domain? It's what makes the agent a real first-class sender instead of a shared relay address — people reply to it, calendars invite it, and its mail authenticates as coming from you. A new domain b

You've probably seen that trending post — "I Asked AI to Write My Commit Messages and It Was Embarrassing." Same. But instead of accepting embarrassing output, I fixed it. Here's the thing: the problem isn't AI writing commit messages. The problem is how you ask it. One clear system prompt + the actual diff = surprisingly good results. The Setup No new packages. No API key. If you have Claude Code , you're already set. #!/usr/bin/env python3 import subprocess SYSTEM = ( " You are a git commit message generator. " " Output ONLY the commit message — no explanation, no markdown, no quotes. " " Follow Conventional Commits: type(scope): subject. " " Types: feat, fix, docs, style, refactor, test, chore. " " Subject: imperative, lowercase, max 72 chars. " ) diff = subprocess . check_output ([ " git " , " diff " , " --staged " ], text = True ) if not diff . strip (): print ( " Nothing staged. Run `git add` first. " ) raise SystemExit ( 1 ) msg = subprocess . check_output ( [ " claude " , " -p " , SYSTEM + " \n\n " + diff ], text = True , ). strip () print ( msg ) That's it. 20 lines. Uses the claude CLI under the hood — no API key, no config, just your existing Claude Code OAuth session. Why It Works The system prompt does the heavy lifting. Three constraints: Output ONLY the commit message — no preamble, no explanation Follow Conventional Commits — feat , fix , chore , etc. max 72 chars — keeps it readable in git log The diff is the context. You're not asking "write a commit message". You're asking "given these exact changes, what happened?" That's a much more answerable question. Usage # No setup needed if you have Claude Code. Just: git add . python /path/to/git_commit.py # → feat(server): add AI commit message generator via Claude CLI Or wire it into a git alias: git config --global alias.ai '!python /path/to/git_commit.py' # git ai The Results Before: update stuff fix bug WIP added the thing After: feat(api): add generate_commit_message tool to MCP server fix(auth): ha

The Problem Most AI assistants give you one model's answer. If it's wrong, you catch it or you don't. If you use a cheap model, quality drops. If you use a frontier model, you pay frontier prices for everything — even a simple file rename. What is Agentic Fusion? When you run /fusion , a panel of models collaborates on your task: Planners (up to 5): Read-only models that research and propose routes in parallel. They figure out the best approach but can't touch your files or run commands. Main model : Your chosen model does the actual work — full tool access, fully visible. You watch every step. Not a black box. Reviewers (up to 5): Read-only models that critique the draft. They can see images the main model generated. They check for errors, suggest fixes, flag issues. Verdict loop : The draft is revised until reviewers approve. The answer you get has already passed independent review. Fusion : Everything combines into one reviewed, approved answer. The quality comes from synthesis — not from running the same job 5 times. Cheap open models combine into something that rivals a frontier model at a fraction of the cost. Safety by Construction Planners and reviewers are read-only at the schema level. They can research and critique, but they can never touch your files or execute commands. Only your main model has tool access, and you watch it work live. Beyond Fusion Clioloop is also: Self-improving : Keeps MEMORY.md and USER.md , updated automatically Autonomous : Set a standing goal with /goal and it loops until done Everywhere : Terminal, desktop app, web dashboard, Telegram, Slack, Discord, WhatsApp Multi-agent Kanban : Break big work into tasks with worker agents Tools : File editing, shell, web search, browser, image/video gen, TTS, MCP Scheduled jobs : Run on cron for automated workflows Open-source : Self-host everything, own your data The Omni Loop Portal One OAuth login gives you access to 300+ models. No API keys. An OpenAI-compatible proxy means any tool works

This week's tooling news clusters around a recurring theme: removing dependencies that were never really necessary. Biome ditches the TypeScript compiler for type-aware linting. Swift developers stop caring which editor they're in. And the most interesting finding of the week is that a 1990s text-retrieval algorithm outperforms GPT-4 at catching lying agents. Here's what's worth your attention. Swift Extension Lands on Open VSX Registry The official Swift extension is now published to the Open VSX Registry, which means Cursor, VSCodium, AWS Kiro, and any other LSP-compatible editor that doesn't use the proprietary VS Code Marketplace can now auto-install it without you doing anything. Code completion, debugging, and the test explorer just work. This matters because the Swift toolchain has always been Xcode-or-fight. Any serious cross-platform Swift work meant manually tracking down extensions, pinning versions, and hoping nothing broke when someone cloned the repo on a different machine. Agentic IDEs that provision their own extensions automatically—like Cursor and Kiro—now get Swift support without intervention. Verdict: Ship. If you're already in an Open VSX-compatible editor, there's nothing to configure. Zero blocking concerns; this is a pure reduction in setup friction. Biome v2 Adds Type Inference Without TypeScript Biome v2 ships its own type inference engine, decoupling type-aware linting rules from the TypeScript compiler entirely. The headline number is 75% detection parity on floating promise rules compared to typescript-eslint—lower recall, but at meaningfully lower install weight and CI overhead. Multi-file analysis also lands in v2, unlocking rules that require cross-module context that were structurally impossible in v1. The real value proposition isn't feature parity—it's dependency elimination. Pulling TypeScript out of your lint pipeline reduces cold-start times in CI and removes a whole class of version-mismatch bugs between typescript , @typescri