Pocock's handoff skill for AI sessions

Matt Pocock has a small handoff skill for compacting an AI coding session so another agent can pick it up later.

The useful bit is that the handoff is not just “summarize the chat”. It asks the agent to write a temporary handoff document for a fresh agent, suggest relevant skills for the next session, and avoid duplicating details already captured in durable artifacts such as plans, PRDs, issues, commits, and diffs.

That framing makes the handoff more operational: point at durable state, capture only the missing context, and tailor the note to what the next session is supposed to do.

Adversarial evaluation for long-running agents

In Build Agents That Run for Hours (Without Losing the Plot), Ash Prabaker and Andrew Wilson described a practical pattern for long-running coding agents: split planning, building, and evaluation into separate roles, and make the evaluator adversarial.

Takeaways:

• Self-evaluation is a trap. Use an adversarial evaluator.
• Compaction doesn’t cure coherence drift. Structured handoffs do.
• Make subjective quality gradable with rubrics the model can apply.
• Read the traces. They’re your primary debugging loop.
• Delete scaffolding when the model catches up. The frontier moves.

Analyzing a nullability example

Cezary Piątek posted a good overview of the C# nullable reference types feature. It includes a critique of a code snippet. Examining that snippet is a good way to understand some of the C# LDM’s decisions. In the following, Cezary expects a warning on a seemingly unreachable branch and no warning on the dereference.

#nullable enable

public class User 
{
    public static void Method(User userEntity)
    {
        if (userEntity == null) // Actual: no warning for seemingly unreachable branch. 
        {
        }
        
        var s = userEntity.ToString(); // Actual: warning CS8602: Dereference of a possibly null reference.
    }
}

sharplab

Why is there no warning on the seemingly unnecessary null test if (userEntity == null) ... or the apparently unreachable branch?

It’s because such tests are useful and encouraged in public APIs. Users should check inputs and the compiler should not get in the way of good practices. The branch of the if is therefore reachable.

Then, what is the state of userEntity within the if block?

We take the user’s null test seriously by considering userEntity to be maybe-null within the if block. So if the user did userEntity.ToString() inside the if, the compiler would rightly warn. This protects the user against a null reference exception that could realistically happen.

Given those, what should be the state of the userEntity at the exit of the if?

Because we’re merging branches where userEntity is maybe-null (when the condition of the if is true) and not-null (in the alternative), the state of userEntity is maybe-null. Therefore we warn on dereference on userEntity after the if. Note that if the if block contained a throw, the userEntity would be considered not-null after the if. This is a common patter: if (userEntity is null) throw new ArgumentNullException(nameof(userEntity));.