Three-day in-person offsite for the Formation team (12 people, distributed across the US). Goal: align on H2 priorities, run a couple of working sessions together, and get the team in the same room after a stretch of fully-remote work. New York City chosen because it's well-connected and easy to plan around.
Three days in mid-October 2026 (exact dates TBD).
A prompt-template for the "process" step of a meeting processor. Give it one meeting and the person's task defaults, and it turns the meeting into a clean, de-duplicated set of proposed tasks — staged for review, never filed silently.
You, the LLM reading this, are helping someone turn a single meeting into tasks. You are given two things: the meeting, and the person's processing defaults. The defaults are the source of truth for every judgment call below — follow them exactly. Where they didn't specify something, do the sensible thing and flag it rather than guess.
You do not file anything and you do not decide where tasks live. Your job is to produce a clean, reviewable plan. A separate step files it into their destination.
A pattern for processing a whole stream of similar things with one skill: a batch of emails, calendar events, product review requests, or Slack messages. You build it once, point it at the stream, and it can run on a schedule.
You, the LLM reading this, are helping someone build a skill that takes a whole stream of similar things and processes them in one sweep. The skill looks at the stream, decides what actually needs handling, does the work on those items, and keeps track of what it has already done. Because it keeps track, it can run on a schedule and pick up only what is new since last time.
The running example is email. The pattern is not. It works on any stream of incoming work: calendar events, form responses, product review requests, Slack messages. Exactly one thing changes between streams, and this doc points at it when we get there.
This doc explains how the whole thing works, start to finish. How you build it is up to the person you
A runbook for an LLM to follow, with a human nearby.
You (the LLM) are helping someone copy their notes folder ("the vault") up to GitHub, so it's backed up and reachable from anywhere. They're not a developer — they don't know what the commands do, but they can paste one into their terminal when you give it to them. Your job is to walk them through it one step at a time, in plain language.
This is a guide you talk the person through — it is NOT something you run. Do not execute any of these commands yourself, do not check your own shell, and do not install anything in your own environment. Whatever environment you happen to be running in is irrelevant and you should never mention it. Every command and instruction below is for the person to run in their own terminal on their own computer. You hand them one step, they run it and report back, you read the result and give the next. That's the whole job.
They'll kick you off with something like: *"Read this gist and pu
A pattern for adopting AI agents deliberately — narrow focus, deep iteration, escalating trust, and a system that stays sharp.
The skill log exists to do two things: measure the lift AI is giving you in your workflow, and systematically increase that lift over time.
1. Measure the lift. Lift is the point. Not "I have AI in my workflow," not "I built a stack of skills" — what matters is a measurable signal that the work is faster, better, or both than it was without AI. Every run gets rated on both axes; every skill earns a clear picture of what it's actually delivering. Without measurement, you're guessing about what's working — and most people guess wrong.
| This is a test gist. |