DEV Community: Sam Novak

Call whoami first: your agent should not trust a cached tool catalog

Sam Novak — Thu, 27 Aug 2026 08:13:54 +0000

There is a failure I have now watched three separate teams hit, and it always looks like a bug in the agent.

An agent connects to a tool server, does useful work for a week, and then one day starts producing confidently wrong actions. It calls a tool that no longer exists. It tries to transition something it is not allowed to transition. It reports success on a mutation that silently did nothing. Everyone goes looking for the regression in the model, or in the prompt, and the actual cause is that the agent was working from a catalog of tools and permissions it had cached at some point in the past.

The fix is one boring call at the start of every session, and it is worth understanding why it is not optional.

A token is a connection, not a role

Here is the thing people get wrong about tokens on a permissioned tool server. The token identifies which named connection is talking. It does not carry the caller's authority.

That sounds like a distinction without a difference until something changes on the other side. The person the connection belongs to gets moved to a different team. Their role changes. An admin turns off tool access at the workspace level. A permission that used to be granted is revoked.

In a system built correctly, the token keeps working as an identifier and the authority is resolved fresh on every call from the person's current membership, roles, and permissions. Which means the answer to "can I do this?" can be yes on Monday and no on Tuesday with nothing about the token having changed. Wagglet's MCP server is explicit about this: a token identifies a named connection, and it never overrides the same person's current membership, roles, or permissions. Team-level access is off by default, and disabling it later rejects every connection request immediately without deleting the connections.

If your agent cached a permission list at connection time, it is now confidently wrong about what it can do, and the only symptom you will see is a failed action it did not expect to fail.

Tool schemas move under you

The second half is the tool catalog. Any actively developed tool server adds tools, renames arguments, tightens validation, and deprecates things. That is normal and healthy.

What is not healthy is an agent whose idea of the available tools came from documentation, a blog post, or a previous session's transcript. A copied old catalog is not a source of truth. The live tools/list response is. This is the same discipline as not hardcoding an API response shape you saw once in a tutorial, except the failure is quieter, because a model will happily improvise a plausible call for a tool that no longer accepts that argument.

So: whoami first, then read, then act

The sequence that holds up:

1. Establish identity and authority. Call the server's whoami (or equivalent) and treat its team, identity, roles, and permissions as the authority for this session. Not your prompt's belief about who you are. Not last week's.

2. Fetch the live tool schemas. Use them, not a remembered list. If a tool you were planning to call is gone, that is information, not an error to work around.

3. Discover ids with bounded search, and page properly. Cursors exist because the population can be bigger than one response. An agent that reads the first page and reports a total is producing a confident number that is wrong.

4. Read the complete authorized record before you change it. Fetch the ticket or document, keep the returned record and its item revisions, and use those in the mutation. This is what makes concurrent edits safe instead of last-write-wins.

5. Use the matching lifecycle command, and give each intended mutation a fresh operation id. Reuse an operation id only when you are deliberately retrying the same intended change. This is the difference between a retry and a duplicate.

The full sequence with the actual tool names is in the Wagglet MCP workspace guide.

Why this is more than hygiene

There is a design point buried in this that is worth pulling out.

A permissioned tool interface is not a database with a chat wrapper. It keeps the product's own language and its own lifecycle rules, and it refuses actions that do not fit them. That refusal is the feature. An agent that could freely write any field would produce records that are structurally valid and semantically nonsense - a task marked delivered with no evidence, a review verdict with no reviewer.

Which is why "read current state, then use the explicit action for what you actually mean" is not ceremony. It is the thing that keeps an agent's output reviewable by a human afterwards. If you want the reasoning behind treating delivery, acceptance, merge, and deploy as four separate facts rather than one status field, that is the argument in the Wagglet workflow.

The one-line version

Do not let an agent start from what it remembers. Make it ask who it is, what it may do, and what tools exist - every session, out loud, before the first action. It costs one call. It saves the class of bug that looks like the model got worse and is actually your permissions changing underneath a cached answer.

Background on the surrounding handoff model: how Wagglet works.

Your coding agent needs a read-only, task-scoped, expiring credential

Sam Novak — Thu, 27 Aug 2026 08:07:58 +0000

Every team that starts handing work to coding agents hits the same wall in about week three. Someone prepares a task, someone else is going to run it, and the agent needs context. Not vague context - the ticket, the acceptance criteria, the linked spec, the three comments that changed the scope. So one of two things happens.

Either the person who prepared the task pastes a wall of text into a chat window and hopes it is still accurate by the time the agent reads it, or somebody shares a credential. A personal access token. An API key with read/write on the whole workspace. In the worst version I have seen, a shared login to the tracker itself.

Both are bad, and they are bad in ways that do not look like security problems at first. They look like reliability problems.

The snapshot goes stale, quietly

A pasted brief is a snapshot. It was true when it was copied. Ten minutes later somebody narrows the scope in a comment, or attaches the design that answers the open question, and the agent has no way to know. It will complete the task it was given, confidently, and you will find out at review that it was the previous version of the task.

The failure mode is not that the agent is wrong. It is that nothing in the system can tell you the agent was reading a stale copy. There is no version, no timestamp, no way to ask "is this still current?".

The credential is too big, always

So the obvious fix is to give the agent live access. And the moment you do that with a normal token, you have handed a process that generates text the ability to change your workspace.

Think about what a standard workspace token can usually do: read any ticket, comment anywhere, transition anything, sometimes delete. You needed exactly one of those powers - read this one task and the things it points at. You granted all of them, for as long as the token lives, which is usually forever.

And you granted them to the wrong identity. A shared token is not "the agent" or "the runner", it is whoever created the token. Every action lands in the audit log under their name. Six weeks later, when you are trying to work out who moved the ticket, the log says a person who was on holiday.

What a bounded credential looks like

The version that actually works is narrower on four separate axes, and it is worth being explicit about all four, because most homegrown solutions get two right and forget the others.

Read-only. Not "read-mostly". The capability the agent starts with should have no ability to deliver, transition, comment, or edit anything. If the agent's report is going to move the task forward, that should be a separate, later, deliberately authorized action - not something the same credential could do at any moment.

Rooted at one resource. Scoped to this claim, on this task. Not to the project, not to the team. If the agent follows a link out of the task to something it was not granted, the answer should be a refusal, not a helpful response. This is the axis people skip, because project-wide scoping is so much easier to build.

Expiring. Days, not months. The task will be done or abandoned long before then. A credential that outlives the work it was minted for is just a key under the doormat.

Revocable independently. Turning off agent access for the team should reject connections immediately, without deleting them and without anybody having to hunt down individual tokens.

Wagglet's handoff is built on exactly this shape: when a teammate claims a task, the copied prompt carries a read-only, claim-rooted context capability plus a fallback snapshot. The agent can refresh the permitted current context - so the staleness problem goes away - but that starting capability cannot deliver or change anything. The details are in the MCP workspace guide, and the surrounding flow is on how it works.

Identity stays with the person

The other half of this, which is easy to miss: the runner uses their own agent subscription. Their own Claude Code or Codex account, their own token balance. Nobody shares an agent login to move a task, which is the practice this whole pattern exists to kill.

That matters for a boring reason and an interesting one. The boring reason is terms of service. The interesting one is that "who ran this" and "who prepared this" are genuinely different facts, and a shared login collapses them into one name. Once collapsed, you cannot answer basic questions about your own process.

The cheap version, if you are not adopting anything

You do not need a product to get most of this. If you are rolling your own handoff today:

Mint a token per task, not per person, and give it read scope only.
Set an expiry you would be comfortable defending, then halve it.
Put the resource id in the token's scope and enforce it server-side, not in the prompt. A prompt instruction to "only read ticket 412" is a suggestion.
Log the human runner as the actor for anything the agent causes, and keep the agent's own report as evidence rather than as a state change.
Make the delivery step a separate call with a separate authorization, so "the agent said it is done" and "the task is done" stay different facts.

The pattern is not complicated. It is just narrower than the credential you already have lying around, which is why almost everybody reaches for the wrong one first.

More on the task-design side of this: the dual prompt.

Delivered, accepted, merged, deployed: four facts your tracker calls Done

Sam Novak — Wed, 26 Aug 2026 06:40:23 +0000

Most issue trackers have a column called "Done." It is doing far too much work.

"Done" is quietly standing in for at least four separate facts, each with a different owner, a different moment, and a different failure mode:

The person who did the work says it is finished.
Someone responsible for the outcome accepts that claim.
The change is merged into the branch that matters.
The change is deployed where users can reach it.

When a workflow collapses these into one status, it doesn't make the process simpler. It makes the process unable to describe what actually happened. And you notice the missing vocabulary at the worst possible moment, usually in an incident channel at 6pm.

Why the collapse hurts

Each of the four facts can be true while the others are false. All of these are real states:

Reported but not accepted. The runner believes the task is complete. The reviewer hasn't looked yet, or looked and disagreed. The work may be genuinely wrong.
Accepted but not merged. A reviewer signed off on a branch that then sat for nine days behind a conflict nobody owned.
Merged but not deployed. The code is in main. main last shipped on Thursday. It is Tuesday.
Deployed but not accepted. The riskiest one. Something reached production without anyone qualified confirming it does the right thing.

A single "Done" column cannot express any of these. So teams invent shadow vocabulary to compensate - "done done", "really done", "done but not shipped", a comment thread, a Slack message that scrolls away. That shadow vocabulary is a symptom. The status model is missing states the work actually has.

This gets worse when an agent did the work

Everything above predates AI tooling. But handing work to a coding agent sharpens it considerably, for one specific reason: an agent will always produce a confident report.

A human who half-finished a task tends to leak signal. They hedge. They say "I think it works but I couldn't test the mobile case." An agent, asked to summarize what it did, generally returns a clean, plausible, well-structured account of having succeeded. That report is a genuinely useful artifact - but it is evidence, not a verdict.

If your workflow treats "the agent reported completion" as equivalent to "the task is complete," you have wired a system where the party doing the work also certifies the work, and the certifying party is the one component in the loop that is structurally incapable of expressing doubt about its own output.

That is not an argument against agent-run tasks. It is an argument for keeping delivery and acceptance as two separate events with two different owners.

What separating them looks like

The practical version is not heavy. It's mostly about naming the transitions honestly:

Delivery is a report, not a verdict. Whoever performed the work - human, agent, or the pair - reports what happened, what evidence exists, and what they could not verify. Ideally the "what I could not verify" section is mandatory, because it is the section that actually carries information.

Acceptance is a decision by someone accountable for the outcome. They can accept, send it back to the runner, or reopen it. Crucially they must be able to judge the work. If nobody in the loop can distinguish correct output from confidently wrong output, acceptance is theater, and you've distributed risk rather than work.

Merge and deploy stay their own facts. They're usually visible in tooling already; the mistake is letting either one imply acceptance. A revert is a normal event, and a status model where "deployed" is terminal makes reverting feel like failure rather than routine.

Stop conditions are defined up front. The task should say what to do when authority or evidence is missing. Both a human and an agent should be able to stop and escalate rather than guess. An agent that hits an ambiguous requirement and picks an interpretation has made a product decision nobody delegated to it.

The cheap version

You don't need new tooling to get most of the value. Try this on your next handed-off task:

Write down what "accepted" means before the work starts. If you can't, the task isn't ready to hand to anyone, agent or human.
Name the reviewer by name, not by role.
Require the delivery report to include an explicit "not verified" list.
Never let the person or process that performed the work also mark it accepted.

That last one is the whole thing, really. Everything else is elaboration.

I work on Wagglet, where this separation is built into the task lifecycle - the participant who ran the task reports it, which moves the task to Delivered, and an authorized reviewer separately accepts it, sends it back, or reopens it. The full five-stage model is written up at how it works, and the handoff mechanics are in the task handoff docs.

Curious how others handle this: does your tracker distinguish delivered from accepted, or did your team also end up inventing "done done"?

The skill gap blocking a task is usually about twenty minutes wide

Sam Novak — Wed, 26 Aug 2026 06:37:32 +0000

The most expensive sentence in a small company is some version of this:

"She would be perfect for this, if only she knew how to set up the project."

I have watched this block real work more times than I can count. An office manager who had the context and the patience to reproduce a nasty intermittent bug - but not the local toolchain to reach it. An artist whose eye was exactly what a feature needed - who could not run npm install against a private registry. A teammate who could tell you in ten seconds whether a workflow made sense, but who had never written a prompt that a coding agent could act on.

None of that is a story about talent. It is a story about where the gap sits.

The gap is at the entrance, so the whole task waits

Here is the structural problem. The missing knowledge is usually small - twenty minutes of tooling trivia. Which command starts the app. Where the staging test account lives. What a good delivery report looks like.

But that small gap sits at the entrance to the task. And a gap at the entrance doesn't cost you twenty minutes; it costs you the entire task, because the task now has to wait for one of the three people who can cross the threshold unaided. Those three people are, of course, the people who are already the bottleneck for everything else.

So the work queues behind them. Not because it is hard. Because it is unenterable.

"Can this person do engineering?" is the wrong question

We ask it constantly, and it's malformed. "Engineering" isn't one act. Shipping a change involves at least: understanding a requirement, locating the relevant code, changing it, running it, noticing a visual defect, checking permissions, testing an edge case, and deciding whether the result is acceptable.

Those are genuinely different skills, and almost nobody is uniformly strong across all of them.

A teammate unqualified to design an authorization system may still be the best person on the team at noticing that a customer flow feels broken.
An artist who doesn't know your build tool is very likely your strongest judge of whether a transition regressed.
An ops teammate who will never write the fix often knows the only reliable sequence that reproduces the bug.

Once you stop treating "engineering" as a single competency, a task stops being all-or-nothing and starts being decomposable.

Decompose the task into four parts, not two

The instinct is to split work into "the technical part" and "the rest." That's too coarse. In practice a bounded task becomes transferable when you separate four distinct things:

1. The domain brief. Somebody who actually understands the problem writes down the outcome, the constraints, and the boundaries. What "done" means. What is explicitly out of scope.

2. The agent guidance. The coding agent gets technical context, setup instructions, the work request, and - critically - stop conditions. When should it refuse to continue and ask?

3. The human runbook. The person running the task gets a short, concrete list: which access to use, what to observe, what judgment only they can supply, what to QA, and when to escalate.

4. The acceptance step. Evidence goes back to a qualified reviewer who decides whether the thing is actually complete. This is a separate decision from "the work was performed."

domain expert's brief + technical context
                |
                v
   human runner  <-->  coding agent
   access, eyes         setup, implementation,
   judgment             explanation
                |
                v
     evidence + recorded delivery
                |
                v
     qualified review and acceptance

Notice what this is not. It is not "give the task to somebody cheaper and hope the model covers the difference." The expert's knowledge stays in the system in two places: once in the brief, and again at review. The runner's role is real rather than ceremonial, because the task explicitly names a check they are equipped to perform.

The research warning is also the argument

The strongest caution about this idea is also the clearest case for it.

In a preregistered experiment, BCG gave consultants access to and training on GPT-4 for tasks outside their existing skill sets. On tasks that sat inside the model's competence, assisted consultants performed substantially better than unassisted ones. On tasks positioned just outside it - where the model was confidently wrong - assisted consultants did worse, because they accepted plausible output they lacked the expertise to challenge.

Read that carefully, because both halves matter:

Capability genuinely transfers. A non-specialist with a good agent and a good brief can complete real work.
Capability transfers only up to the boundary of verification. The moment nobody in the loop can tell good output from confidently wrong output, you have not distributed the work. You have distributed the risk.

That is exactly why the fourth part - acceptance by a qualified reviewer - isn't bureaucratic overhead. It's the thing that makes the other three safe. Assisted performance is not the same as expertise, and a handoff design that forgets this converts a skill gap into a silent defect.

What this means practically

If you want a task to be transferable, the work is mostly front-loaded and mostly writing:

Write the brief before you offer the task, not after someone claims it.
Give the agent and the human different instructions. One generic paragraph asks both of them to improvise.
Name the specific human check the runner is qualified to perform. If you can't name one, the task probably shouldn't be handed off.
Keep delivery and acceptance as two separate events. "The runner reported it" and "the reviewer accepted it" are different facts.
Be honest about the verification boundary. Some work should not be handed off at all, and a better prompt cannot repair a missing qualified reviewer.

The payoff isn't that job titles stop mattering. It's that a narrow twenty-minute gap stops being able to hold an entire task hostage.

I work on Wagglet, which is built around this pattern - an author prepares a task for two audiences, a teammate claims and runs it on their own agent subscription, and acceptance stays a separate decision. If you want the longer version of the argument above, it's written up as a field note: How AI task handoffs help more teammates complete technical work. The five-stage lifecycle is documented at how it works.

How does your team handle this? I'm curious whether anyone has found a good way to decide in advance which tasks are safe to hand off.

Move the task, not the AI account

Sam Novak — Tue, 25 Aug 2026 09:19:04 +0000

Sharing AI work across a team gets messy fast.

One person writes a good prompt, gathers the context, gets partway through. Then someone else needs to continue. So fragments get pasted into Slack, screenshots get sent, a conversation gets exported, or an account is left signed in for the next person.

The collaboration isn't the problem. The handoff is. Most AI tools assume one person, one account, one session. The moment work crosses that boundary, you have to decide what moves and what stays.

Wagglet's rule is simple: move the prepared task, not the AI account.

That doesn't mean nothing is shared. An agent can't work on context it never receives. It means the disclosure can be about the job rather than somebody's identity.

What moves

A real AI task is more than a one-line prompt. It usually includes the intended result, background and prior decisions, constraints and acceptance criteria, project or repository context, chosen attachments, discussion and rework feedback, and the evidence expected at delivery.

That's the material that moves. One person prepares the task; another claims it and runs it with their own authenticated coding agent.

What stays

Keeping each AI account with its owner preserves three boundaries worth having:

Identity. Provider activity stays attached to the person who owns the account. A shared login can show that an account acted, but not which teammate.

Permissions. The runner works with the repository, files, and provider access already in their own environment. Claiming a task doesn't silently grant them the author's local permissions.

Usage and billing. The subscription, quota, and billing relationship stay with the person running the work.

It's a policy boundary too. A handoff doesn't make provider-prohibited account sharing acceptable, and the runner still needs legitimate access to every system the task touches.

A handoff is still a disclosure

This is the part worth stating plainly, because "move the task, not the account" is easy to over-read.

If someone copies a task into Claude Code, Codex, or another agent, that task context is disclosed to that agent and processed under the provider's terms. Attachments and instructions deserve the same review as anything else you send to an AI provider.

So before a handoff: strip unnecessary secrets and personal data, check every attachment belongs, and confirm the chosen agent may receive the material. When the answer is no, keep the task human-only or narrow it first.

Wagglet reduces the need to share identity. It doesn't turn sensitive content into non-sensitive content.

What a handoff does not transfer

the sender's Google, GitHub, Claude, or OpenAI login
their AI subscription or token balance
their browser session
a team model key or integration credential
access to the sender's computer

A team can separately configure server-side integrations, and an MCP connection can grant an agent the product actions its owner is already authorized to perform. Those are explicit features with their own controls, not hidden extras attached to a single handoff.

Questions worth settling before adopting anything like this

What may people put in it? Decide whether customer data, production logs, or regulated information belong in tasks and attachments.
Who belongs in each workspace? Membership, roles, admins, offboarding.
Which integrations get connected? Treat GitHub, Slack, model keys and MCP connections as separate credentials with different scopes.
What assurance does security require? Wagglet does not currently claim SOC 2 or ISO 27001 certification, and a hosting provider's certifications don't transfer to the product running on it.

Less exciting than asking whether a product "uses encryption", but the answers are more useful.

The point

AI collaboration involves two assets: the work, and the identity used to execute it.

The work often needs to move. The identity usually shouldn't.

Details are on the Wagglet security page and the privacy page.

I work on Wagglet, which is operated by Rockbite Games. This describes the product's current documented behaviour and is not a claim of any security certification.

One task, two readers:the agent, the human

Sam Novak — Mon, 24 Aug 2026 11:54:01 +0000

I spent a long time writing deliberately vague task descriptions, and I could defend it. A complete brief took forty minutes. The teammate picking it up would skim it anyway, miss the one constraint that mattered, and message me a question I had already answered in paragraph three. So I wrote less and kept the rest in my head. Cheaper, given the reader.

Then the reader changed. Half the tickets on our board are now picked up by someone who immediately pastes them into Claude Code or Codex. And an agent is the opposite kind of reader: it will happily consume two thousand words of constraints, and it will not skim. Suddenly the forty-minute brief pays for itself.

Except the person supervising the run still does not want to read it.

One task, two readers

That is the actual problem, and it took me embarrassingly long to name it. A task in an agentic workflow has two participants with completely different needs:

The agent needs the full context. Intended outcome, source material, constraints, edge cases, what evidence to produce at delivery, and the conditions under which it should stop and ask instead of guessing.
The human needs a runbook. Why this matters, how to start the right session, which checks need human eyes, which decisions they are allowed to make alone, and where the agent must escalate.

Writing one document for both produces something that fails both. Trim it for the human and the agent hallucinates the missing constraints. Write it for the agent and the human skims, misses the escalation rule, and rubber-stamps a bad delivery.

What we actually write now

Every work item gets two blocks. Same task, same intended outcome, two audiences.

The agent block is long and boring on purpose:

Outcome: CSV export on the reports page matches the on-screen totals.
Source: apps/reports/, the export path is in exporters/csv.ts
Constraints:
- Do not change the on-screen aggregation. It is correct.
- Currency must stay in minor units end to end.
- Timezone for date bucketing is the workspace timezone, not UTC.
Edge cases: empty result set, >50k rows, refunds (negative amounts).
Evidence at delivery: a diff, the new tests, and one exported CSV
  for the 50k-row fixture.
STOP and ask if: the on-screen totals themselves look wrong.

The human block is five lines:

Why: finance is reconciling by hand every month because of this.
Start: open the repo, run the agent against the task above.
You decide: whether the refund rows belong in the export at all.
Verify: open the CSV in Sheets, check one month against the UI.
Escalate: any change to the on-screen aggregation.

The second block is the one that gets read. That is the point.

The part I got wrong first

My first attempt at this was two separate tickets, one "for the AI" and one "for the human". That was worse than doing nothing. The two drifted within a week: someone updated the constraint in the agent ticket, nobody touched the human one, and the reviewer verified against a rule that no longer existed.

They have to be one work item with two sections, sharing one intended outcome and one definition of done. If you cannot express both from a single outcome statement, that is a signal the task is really two tasks.

Why "stop and ask" earns its place

The line I would keep if I could only keep one is STOP and ask if:. Agents are relentlessly agreeable. Handed an ambiguous task, they will pick an interpretation and build something coherent on top of it, and coherent-but-wrong is far more expensive to unwind than a question asked up front.

Naming the specific conditions under which the work should halt converts that failure mode into a five-minute conversation. It is the single highest-leverage line in the brief and it costs one sentence.

Verification is a human column, not a checkbox

The other thing worth being explicit about: which checks a person actually has to perform with their eyes. "Tests pass" is not verification when the agent wrote the tests. Naming one concrete manual check — open the file, compare one month, click the button — catches the class of failure where everything is internally consistent and collectively wrong.

We formalised this into a pattern we call the Dual Prompt, and there is a longer write-up with the reasoning and a fuller template here: https://wagglet.com/blog/dual-prompt-human-agent-task-design

If you want the mechanical version — a board where each item carries both blocks and the delivery loop enforces the evidence requirement — that is roughly what we built at Wagglet, and the workflow docs are at https://wagglet.com/docs/task-handoff.

Curious whether other people have landed on something similar. The failure mode I still have not solved is keeping the human block genuinely short as the task grows.

Particle effects for Three.js and PixiJS without the reload loop

Sam Novak — Mon, 24 Aug 2026 11:48:23 +0000

Most of the cost of web-game VFX isn't the effect. It's the loop you run to see the effect.

Edit a config object. Rebuild the bundle. Reload the game. Get to the state where the thing actually fires. Squint. Change emitRate from 240 to 180. Do it again. Forty iterations later you have a fire effect that's fine, and you've spent an afternoon.

This post is about the parts of that loop you can cut, for both Three.js and PixiJS.

The eight knobs

Every particle system — Unity's, Unreal's, three.quarks, Pixi's emitter, whatever you hand-roll — exposes roughly the same eight things:

emitter shape and rate — where particles spawn, how many per second
lifetime — how long each one lives; the clock every curve runs against
velocity — initial speed and direction, spread across the emission shape
forces — gravity, drag, noise; what bends the path after spawn
color over life — tint and alpha; the difference between fire and smoke is mostly this
scale over life — grow on birth, shrink on death; most of the readability lives here
texture — soft dot, spark streak, or a flipbook
material / blend mode — additive for energy and light, alpha-blended for smoke and debris

Layered effects add multi-emitter timelines, trails and sub-emitters on top of the same eight. If you understand the list, you can read any effect file in any tool.

Hand-written configs are fine, until curves

Here's a fire burst as a plain object:

{
  emitRate: 240,
  lifetime: [0.25, 0.6],
  speed: [4, 9],
  gravity: -12,
  sizeOverLife: [1, 0.1],
  colorOverLife: ['#fff2b0', '#ff5a1e'],
  blend: 'additive'
}

This is precise, diffable and lives in git. Nothing wrong with it. The problem starts the moment an effect needs a non-linear curve — an alpha that holds then falls off a cliff, a size that pops then eases. You cannot feel a bezier as four numbers. You can only compile it and look.

So: author the curves visually, export JSON, keep the runtime in code. The effect still ends up as a reviewable file in the repo; you just stop guessing at the numbers that go in it.

The Three.js side

The game-side code is three calls. Load, spawn, update.

const fx = await loadEffect('effects/explosion.json');
scene.add(fx.object3D);

function onHit(point) {
  fx.spawnAt(point);
}

renderer.setAnimationLoop(() => {
  fx.update(clock.getDelta());
  renderer.render(scene, camera);
});

Three things worth getting right here:

Clamp your delta. clock.getDelta() after a tab switch can hand you two seconds. Effects then jump forward and look broken. Clamp to something like 1/20s.

Pool, don't allocate. Construct one emitter per effect type at load and reuse it, rather than building a new one per hit. Garbage collection during combat is a visible stutter.

Make sure the preview is the effect. If your editor and your runtime use different simulation code, the preview is an approximation and you're back to reload-and-check. A shared deterministic simulation is what actually kills the loop.

The PixiJS side

Same authoring, different stage. 2D world effects and UI effects use the identical JSON:

const fx = await loadEffect('effects/coin-burst.json');
uiLayer.addChild(fx.container);

button.on('pointertap', () => {
  fx.spawnAt(button.position);
});

app.ticker.add((t) => fx.update(t.deltaMS / 1000));

UI particles are underrated. A button that sparkles on tap, a reward counter that bursts, a progress bar that throws off sparks as it fills — these cost almost nothing and change how finished a game feels.

Six rules for 60 FPS on a phone

The target is a mid-range Android, not your desktop.

Cap particle counts per effect and per scene. Twenty well-timed particles beat two hundred.
Watch overdraw. Large transparent quads stacked on each other are the most common frame killer — not particle count.
Atlas your textures. One atlas, one draw call. Flipbooks belong in the same sheet.
Lower emission, not lifetime. Fewer particles reads better than shorter ones. Keep the silhouette, drop the density.
Clean up finished effects. Return emitters to the pool on completion. Leaked emitters cost frames silently.
Profile the worst case on device. Several effects firing at once, mid-combat, on real hardware.

Letting an agent write effects

"Make me a fire effect" gets you plausible code with invented APIs and parameters nobody validated, and usually an effect you can't open in an editor afterwards.

What works better: give the agent the actual schema and runtime API as a skill, have it write effect JSON rather than bespoke code, validate the export with a CLI, then open the result in the editor and look at it. The agent drafts; you still judge it with your eyes. VFX is one of the few things where a human has to be the acceptance test.

The tool

I've been building NixieFX around this workflow: a browser particle editor with multi-emitter timelines, curves and gradients, forces and noise, flipbooks, trails, sub-emitters and a node-based material workflow. Effects export as JSON into your own project folder, the editor and runtime share one deterministic simulation, and there are open-source runtimes for both Three.js and PixiJS. There are also skills for Claude Code, Codex, Cursor, Gemini and Copilot.

Free, no install, no account: nixiefx.com · runtime on GitHub

Curious what everyone else is using for web-game VFX — three.quarks, hand-rolled shaders, something else?

One task, two readers: briefs for the agent and the human at the same time

Sam Novak — Thu, 20 Aug 2026 07:59:19 +0000

Except the person supervising the run still does not want to read it.

One task, two readers

That is the actual problem, and it took me embarrassingly long to name it. A task in an agentic workflow has two participants with completely different needs:

The agent needs the full context. Intended outcome, source material, constraints, edge cases, what evidence to produce at delivery, and the conditions under which it should stop and ask instead of guessing.
The human needs a runbook. Why this matters, how to start the right session, which checks need human eyes, which decisions they are allowed to make alone, and where the agent must escalate.

What we actually write now

Every work item gets two blocks. Same task, same intended outcome, two audiences.

The agent block is long and boring on purpose:

Outcome: CSV export on the reports page matches the on-screen totals.
Source: apps/reports/, the export path is in exporters/csv.ts
Constraints:
- Do not change the on-screen aggregation. It is correct.
- Currency must stay in minor units end to end.
- Timezone for date bucketing is the workspace timezone, not UTC.
Edge cases: empty result set, >50k rows, refunds (negative amounts).
Evidence at delivery: a diff, the new tests, and one exported CSV
  for the 50k-row fixture.
STOP and ask if: the on-screen totals themselves look wrong.

The human block is five lines:

Why: finance is reconciling by hand every month because of this.
Start: open the repo, run the agent against the task above.
You decide: whether the refund rows belong in the export at all.
Verify: open the CSV in Sheets, check one month against the UI.
Escalate: any change to the on-screen aggregation.

The second block is the one that gets read. That is the point.

The part I got wrong first

Why "stop and ask" earns its place

Verification is a human column, not a checkbox

The other thing worth being explicit about: which checks a person actually has to perform with their eyes. "Tests pass" is not verification when the agent wrote the tests. Naming one concrete manual check, open the file, compare one month, click the button, catches the class of failure where everything is internally consistent and collectively wrong.

We formalised this into a pattern we call the Dual Prompt, and there is a longer write-up with the reasoning and a fuller template here: https://wagglet.com/blog/dual-prompt-human-agent-task-design

If you want the mechanical version, a board where each item carries both blocks and the delivery loop enforces the evidence requirement, that is roughly what we built at Wagglet, and the workflow docs are at https://wagglet.com/docs/task-handoff.

Curious whether other people have landed on something similar. The failure mode I still have not solved is keeping the human block genuinely short as the task grows.

Local vs remote MCP servers: which one you actually want

Sam Novak — Thu, 20 Aug 2026 03:16:36 +0000

There are two kinds of MCP server, they solve different problems, and almost nothing tells you which one you are building until you are deep enough in to have already made the wrong choice.

I worked this out from a submission form. More on that below, because it turns out to be the clearest signal in the whole ecosystem and it is buried in a footnote.

The two shapes

Local (stdio). The server runs as a process on the user's own machine. The client — Claude Desktop, Cursor, whatever — spawns it and talks to it over stdin/stdout. It is a package the user installs.

Remote (Streamable HTTP). The server is a service you host. The client connects out to a URL with a token in an Authorization header. Nothing is installed locally.

That is the entire distinction, and it determines everything else.

What actually differs

Who runs the code. Local: the user, on their hardware. Remote: you, on yours. This is the real decision. Everything below follows from it.

Where secrets live. Local servers read credentials from the user's own environment — their shell profile, their config file. You never see them. Remote servers require the user to hold a token you issued, which means you own the entire credential lifecycle: issuing, scoping, rotating, revoking.

What the server can reach. A local server can read the user's filesystem, hit localhost, talk to their Docker daemon. A remote server can see none of that, and should not want to.

Update path. Remote: you deploy, everyone is on the new version immediately. Local: users run whatever version they installed, possibly forever.

Failure surface. A local server fails on one machine. A remote server fails for everyone at once. Pick your poison.

Choosing

Local if you need the user's filesystem, local processes, a local database, or hardware. Or if the data must not leave their machine.

Remote if the server fronts a service you already run. If your MCP server's job is to call your own API, making users install a process that proxies to your HTTP endpoint is pure overhead — you have shipped a local wrapper around a remote call, and now you maintain both.

Rule of thumb: if the data lives on your infrastructure, the server should be remote. If it lives on the user's machine, local.

The part that cost me an hour

Anthropic runs a directory of MCP servers, and there are two separate submission forms — one for local, one for remote. The local one is framed around Desktop Extensions, and its stated requirements are:

Publicly available on GitHub
MIT licensed
Built with Node.js
A valid manifest.json with the author field pointing at your GitHub profile
A .mcpb file, as a required upload

That last one is the tell. A .mcpb is a packaged local extension that Claude Desktop installs and runs. If your server is remote, there is no bundle to produce — and the required-file field is where you discover you are on the wrong page.

The link to the remote form sits in a single line near the top of the local one, easy to skim straight past.

So: read the transport requirements before you fill anything in. If a form asks for a .mcpb, or names Node.js as a hard requirement, it wants a local server. A rejected submission is a worse outcome than a slower correct one.

Auth, if you are going remote

Remote means you own the credentials, so a few things stop being optional.

Scope tokens narrowly. A token that can only read context for a single task is a much smaller problem when it leaks than one that acts as the user's whole account.

Make expiry the default, not revocation. "Revocable" puts the burden on someone remembering. Expiring means neglect is harmless. Design for the person who forgets, because that person is you.

Never let a token land in a committed file. Reference an environment variable in config and export the real value from the shell profile. Once a credential reaches a remote branch, deleting the line does nothing — the value is in the history, and rotating is the only real fix.

Where I landed

I work on Wagglet, which is remote. The server fronts a shared task board, so the data is ours rather than the user's. Going local would have meant shipping a process whose only job was to proxy HTTP calls to our own API, plus a bundle to package it, plus a version-skew problem — in exchange for nothing.

The docs cover the connection and credential model if you want a worked example of the remote side.

Disclosure: I work on Wagglet. The local/remote decision above is the part worth taking regardless of what you are building.

Short version

Data on your infrastructure, go remote. Data on the user's machine, go local.

And before you fill in any directory form, check whether it wants a .mcpb. That is the fastest way to tell which door you are standing at.

You don't need Unity to ship a browser game

Sam Novak — Wed, 19 Aug 2026 08:49:02 +0000

If you are evaluating engines for a web game, the default recommendation you will get is Unity, and the default reason is "it's the industry standard." That is true and mostly irrelevant to the question you are actually asking.

I have shipped web games both ways. This is the comparison I wish someone had given me — including the parts where Unity is genuinely the right answer, because there are several and pretending otherwise would make the rest of this untrustworthy.

The thing that decides it: are you targeting the browser, or exporting to it?
This is the whole argument, so I will put it first.

Unity's WebGL support is an export target. You build in an editor designed for native platforms, then emit a browser build. The web is a destination, not the native habitat. Everything downstream of that decision — bundle size, load time, how you debug — follows from it.

A web-native stack (Three.js, PixiJS, plain TypeScript) treats the browser as the primary platform. The thing you develop in is the thing users run.

If the browser is one of five platforms you ship to, Unity's export model is a reasonable trade. If the browser is where your players actually are — an instant-play game, a playable ad, a web-first F2P title — you are paying the export tax on every single build for a capability you are not using.

Where the web stack measurably wins
Bundle size and time-to-first-frame. A Unity WebGL build ships an engine runtime before it ships your game. Your first-load payload includes a large WASM binary whether your game is a puzzler or an open world. A Three.js/PixiJS build ships roughly what you wrote plus the libraries you imported, and code-splits like any other web app.

This matters disproportionately because web game players do not wait. Every second of load costs you a measurable share of your funnel, and on a mobile connection an engine-runtime-first payload is a real conversion problem. If your acquisition depends on instant play, this alone can decide the stack.

Iteration speed. Web reload is sub-second. No editor domain reload, no build step between "change a number" and "see the number." Over a tuning-heavy day — which is most days on a live game — this compounds into hours.

Live ops without store review. This is the one that surprises people who have not shipped F2P. An engine game ships a balance change through a binary build and store review. A web game pushes JavaScript and assets over the air in minutes. When you need to fix a broken economy on a Saturday, "minutes" and "a week" are different businesses. Wrapping with Capacitor and delivering updates over the air via Capawesome gets you native store presence and keeps the fast path.

Debugging is just the browser. Chrome DevTools, real heap snapshots, a real network panel, real profiling — the same tooling the entire web industry sharpens every year. Nothing engine-specific to learn.

AI agents can actually read your project. This is newer and, I think, the most underrated item. A web game is plain TypeScript in plain files, which is the format LLMs are strongest at and have seen the most of. A Unity project lives in binary scenes, serialized YAML, meta files, and editor state that an agent cannot reliably read or write. If a meaningful share of your output now comes from coding agents, project format stops being a detail and becomes a throughput ceiling. We wrote up the full web-native F2P stack and the iteration-speed argument behind it if you want the long version.

Where Unity genuinely wins — and you should pick it
I would be wasting your time if I did not write this section properly.

Existing team expertise. If your team knows Unity, that beats every architectural argument on this page. Retraining costs more than the export tax. This is the single most common correct reason to choose Unity and it is not a cop-out.

3D-heavy, near-native visual ambition. Advanced lighting, complex physics, large streamed worlds — Unity's renderer and tooling are years ahead, and Three.js will cost you significant custom engineering to approach it.

The asset store and middleware ecosystem. Genuinely enormous. Need an inventory system, a dialogue tree, a specific mobile ad SDK integration? On Unity you buy it this afternoon. On the web you write it.

Real multi-platform reach. Console, XR, native mobile with heavy device integration. This is not the web's fight and web advocates should stop pretending it is.

Complex editor-driven content workflows. Scene composition by level designers who are not engineers is something Unity's editor does well and a code-first stack does badly by default.

The honest summary: Unity is the better engine. The web is the better platform for web games. Those are compatible statements, and confusing them is what makes this debate so tedious.

The gap you will hit, and where it actually is
Assume you pick the web stack. Rendering is solved — Three.js for the world, PixiJS for the UI layer on top, both mature.

The gap is VFX authoring, and it is worth knowing about before you commit rather than discovering it in month three.

In Unity you have a visual particle editor. Your VFX artist opens it, tunes a curve, sees the result, hands over a prefab. On a bare web stack, "authoring particle effects" often means an engineer typing numbers into a config object and reloading — which means every VFX iteration costs engineering time, and your artist is blocked on someone else's calendar. That is an organisational bottleneck disguised as a tooling gap, and it is the one thing I would call a real regression versus Unity.

It is solvable, and closing it is why NixieFX exists: visual particle and material authoring in the browser, projects stored as plain JSON so a VFX change is code-reviewable like anything else, and an export bundle you load into Three.js with npm install nixie-fx three. The artist iterates and commits JSON; no engine build, no programmer in the loop. If you want the argument for why the classic engine era is ending for F2P specifically, we made that case at length.

Disclosure: I work on NixieFX. The Unity-wins section above is not false modesty — if you are building a 3D console title with a Unity-fluent team, use Unity.

How to actually decide
Skip the engine debate and answer three questions:

Is instant play in a browser core to how players reach you? If yes, weight load time heavily, and the web stack wins on that axis alone.
Does your team already know Unity? If yes, that is probably decisive, and that is fine.
How often do you need to change live content? If the answer is "weekly or faster," over-the-air updates are worth more than renderer features.
You do not need Unity to ship a browser game. You might still want it — but it should be because of question 2, not because it is the default answer.

If you have shipped a web game at scale and disagree — particularly on the asset-ecosystem gap, which I think is the strongest remaining argument for Unity — I would genuinely like to hear where this framing breaks down.

AI coding agent usage limits: what actually resets, and when

Sam Novak — Wed, 19 Aug 2026 08:40:05 +0000

AI coding agent usage limits: what actually resets, and when
Most confusion about AI usage limits is not about the numbers. It is about the fact that every vendor meters something different, on more than one clock, and the word "reset" means at least three unrelated things depending on whose product you are using.

I lost an afternoon to this. I hit a wall mid-refactor, assumed I was out until the next billing period, and shelved the work. I was actually only out on the short clock and would have been fine after a coffee.

So: the general mental model that holds across tools, then the practical part — how to scope work so limits stop mattering much. No specific figures anywhere in this post, deliberately, and I will explain why.

First: what is being counted?
Before you can reason about a limit, you have to know its unit. Broadly there are three, and tools mix them:

Tokens. The most common for API-billed usage. Roughly, chunks of text - both what you send and what comes back. Two things people miss: output usually costs more than input, and the entire conversation is re-sent on every turn. Which means turn 40 of a session is dramatically more expensive than turn 4, even if you typed the same number of words. More on why that matters below.

Requests or messages. Some subscription tools count interactions rather than volume, sometimes labelled "premium requests" or similar. Under this model a huge task and a one-line question cost the same, which inverts your strategy completely — batching is free, and asking many small questions is what hurts.

Credits. An abstraction over the other two, usually with different models drawing at different rates.

The single most useful thing you can do is find out which of these your tool uses, because strategies that help under one model actively hurt under another.

Second: there is usually more than one clock
A short rolling window. Covers a few hours of heavy use, then rolls off. Critically it is rolling, not a calendar bucket — usage from early in the window ages out continuously, which is why you can sometimes come back in twenty minutes and have room. This is the limit you hit most and panic about most unnecessarily.

A longer ceiling tied to a week or a billing cycle. This is the one that genuinely ends your week, and the reason a single very heavy day can quietly cost you Thursday.

Per-model sub-limits. The most capable models are almost always metered harder than the cheap ones, whether by a separate cap or a higher credit rate.

"Reset" can therefore mean: a rolling window aging off, a calendar period flipping, or a credit balance refilling on your billing date. Three different behaviours. Worth knowing which one you are waiting for before you decide to wait.

On actual numbers: I am not quoting any. They differ by vendor and plan and they get revised constantly — anything I wrote today would be wrong by the time you found this via search. Check your vendor's own limits page, and treat any blog post quoting hard figures (including ones ranking above this) as possibly stale. The structure above is stable even as the numbers move, and you can plan against structure.

Why "just wait for the reset" is worse than it looks
The cost people underestimate is not the agent's. It is yours.

The context you built over the last hour is perishable. You had three approaches in your head, rejected two for reasons you never wrote down, and had just worked out that the legacy adapter is load-bearing.

Come back five hours later and that is gone. You will re-litigate a decision you already made, and possibly land on the approach you already rejected.

So the real question is not "how do I get more quota." It is "how do I stop accumulating expensive undocumented context that a five-hour gap destroys."

Four strategies, in the order I reach for them

Batch the work, then get out of the loop.

Under token metering this is the big one, because of the re-sending problem. Twenty small conversational nudges each re-send the whole accumulated context — you pay for the same history twenty times. One well-specified task costs a fraction and produces a better audit trail.

Caveat: if your tool counts requests rather than tokens, this is already free and you should ignore it.

Scope tasks to fit one window.

If a task cannot finish inside a single short window, it is usually not one task. "Migrate the auth module" is a programme of work. "Auth should make one network call per session instead of one per request; auth_spec must still pass" is a task, and it fits.

The forcing function: if you cannot state the definition of done as a command and its expected output, the task is not scoped yet. Better to find that out before spending the quota.

Put cheap models on mechanical work.

Since top-tier models are metered hardest everywhere, spending them on rote work is the most common way people burn a week. Renames across files, the obvious test, mechanical format translation — none of that needs your most expensive model. Save the tightly-metered capacity for work where reasoning quality changes the outcome.

Biggest difference for me, costs nothing to adopt, works on every vendor.

Hand the task off rather than sit on it.

If a teammate has capacity and the work is genuinely unblocked, the work should move. The trap is how most teams do it: pasting an API key into Slack, or letting someone log into your account. Now you have a shared secret with no scope, no expiry and no audit trail, in a DM that is still searchable in two years.

The principle that fixes it: the unit you share is the task, not the account. Whoever picks it up authenticates as themselves, against their own subscription, with a credential scoped to that one task.

That requires the task to be written down properly — which loops back to strategy 2. A handoff is only as good as its specification.

Reach for this one last. Fix scoping first; it makes everything else smaller.

The part that surprised me
Every strategy here is good practice regardless of limits.

Batching produces better diffs. Tight scoping produces checkable outcomes. Model tiering saves money on any plan. Written-down tasks are easier to resume even if nobody else touches them.

So limits are not really a constraint you work around. They are a forcing function toward habits you should have had anyway. I write better task descriptions now than when I had effectively unlimited quota, purely because sloppiness got expensive.

We build Wagglet around the handoff half of this — documenting a task so someone else can claim it and run it on their own subscription, whichever vendor that is, with per-task scoped credentials instead of a shared account. If that is your bottleneck: using unused agent capacity across a team and writing a task two audiences can both read.

Disclosure: I work on Wagglet. The metering, scoping and model-tiering advice above is vendor-neutral and free.

What does your tool actually count — tokens, requests, or credits? I am increasingly convinced most people do not know, and that it is the root of most bad quota strategy

How to Hand Off AI Agent Work When You Hit Your weekly Usage Limit

Sam Novak — Tue, 18 Aug 2026 19:19:36 +0000

You are forty minutes into a refactor. The agent has read the codebase, you have corrected it twice, it finally understands that the legacy adapter is load-bearing and cannot be deleted. You are close.

Then you hit your usage limit.

Everyone who codes with an AI agent daily has had this moment, and the two obvious responses are both bad.

The two bad options: wait, or share credentials

Wait for the reset. Sometimes correct. But the context you built up is perishable — not the agent's context window, yours. Come back in five hours and you have forgotten which of the three approaches you rejected and why. You will re-litigate a decision you already made.

Hand over your credentials. Someone on your team has quota left. You paste an API key into Slack, or worse, they log into your account. Now you have a shared secret with no audit trail, no scope, and no expiry, sitting in a DM that will still be searchable in two years. Everyone knows this is wrong. Everyone does it anyway, because the alternative is losing the afternoon.

There is a third option, and it is less about tooling than it sounds.

What actually breaks when you hand off AI work

Here is the thing I got wrong for a long time: I assumed handing off AI work was a credentials problem. Solve the auth, and the work flows.

It isn't. I have watched handoffs fail with perfect credentials, and the failure is always the same shape — the person picking it up cannot reconstruct what the task actually is.

The reason is that you never wrote it down. You were talking to an agent conversationally, steering it in small corrections, and the real specification lives in the diff between what you asked for and what you accepted. That is invisible to the next person. They see the prompt and the half-finished branch, and neither one contains the sentence "we decided not to touch the adapter."

So they rediscover it. Usually by breaking it.

The three things every claimable task needs

After watching enough of these go sideways, I have landed on a minimum. If a task description has these three, someone else can pick it up cold. If it is missing any of them, it will bounce back to you with questions.

1. The goal, in outcome terms. Not "refactor the auth module" — that is an activity, not an outcome. "Auth module should stop making a network call per request; target is one call per session." Now there is something to check against.

2. The constraints, especially the non-obvious ones. This is the one everybody skips, and it is where all the pain is. Every "don't touch X," every "we tried Y and it deadlocks," every "the tests in Z are flaky, ignore them." These live in your head and nowhere else. Write them down or watch someone else find them the hard way.

3. The definition of done. What command do I run? What should it output? If you cannot state this, the task is not ready to hand off — and honestly, it might not be ready for you to work on either.

Here is the template I use. It is deliberately short, because a template nobody fills in is worse than no template:

## Goal
<outcome, stated so it can be checked>

## Constraints
- <thing that must not change, and why>
- <approach already tried and rejected, and why>

## Done when
<command to run, and the output you expect>

## Context
<links: the branch, the issue, the failing CI run>

Thirty seconds to fill in. Saves an hour of back-and-forth.

Share the task, not the account

The auth problem is real, it is just easier than the context problem.

The principle worth internalising: the unit you share should be the task, not the account. A teammate picking up your work should authenticate as themselves, against their own subscription, with a credential scoped to that one task and nothing else.

Concretely, that means scoped and revocable tokens rather than a shared key. A read-only token pinned to a single task cannot exfiltrate your other work, and it expires on its own — which matters because revocation is a step everyone forgets.

If you take one operational habit from this post, take this one: never inline a token in a config file that gets committed. Use environment variable indirection, so the config holds a reference like ${YOUR_TOKEN_ENV_VAR} rather than the secret itself, and export the actual value from your shell profile, which is not in the repo.

Once a credential reaches a remote branch, deleting the line does nothing — the value is in the history, and rotating is the only real fix.

Tooling: when a shared markdown file stops scaling

You can do all of the above with a shared markdown file and some discipline. I did for a while. It works until the team is bigger than about four people, at which point "which tasks are unclaimed" becomes its own problem.

If you want something purpose-built, Wagglet is built around exactly this split — one person documents the task, another claims it and runs it on their own Claude Code or Codex subscription, with per-task scoped credentials rather than a shared account. The docs cover the handoff format and the security model. There is also a raw skill file if you want your agent to read the workflow directly rather than you translating it.

Disclosure: I work on Wagglet. The template above is the part I would defend regardless of what you use to track it — the tooling is genuinely the easy half.

The bit that surprised me

Writing tasks this way made me better at working on them alone.

If I cannot state the definition of done, I do not understand the task yet. That is worth knowing before I spend an hour and my whole quota discovering it. The handoff format turned out to be a thinking tool that happens to also be a handoff format.

Which means the discipline is worth adopting even if you never hand anything to anyone.

What is in your handoff template that I have missed? I am especially curious how people handle the "approaches already rejected" part — that is the one I still write badly.