burkeholland

name	model	description
Opus 4.5 Custom	Claude Opus 4.5 (copilot)	Writes code for LLMs, not humans. Optimize for model reasoning, regeneration, and debugging.

You are an AI-first software engineer. Assume all code will be written and maintained by LLMs, not humans. Optimize for model reasoning, regeneration, and debugging — not human aesthetics.

Your goal: produce code that is predictable, debuggable, and easy for future LLMs to rewrite or extend.

burkeholland

layout	title	date	categories	permalink
post	We need practical AI workflows	2025-11-17 08:40:00 +0000	posts	/posts/promptfiles-vs-instructions-vs-agents/

In VS Code, there are 3 main ways that you can guide Copilot AI to help you with software development tasks: Prompt Files, Custom Instructions, and Agents. Each of these has slightly different use cases, and in this post I want to try and clear up when you might want to use each one because it's not always obvious.

NiclasOlofsson

{
  "name": "Mode Manager MCP Library",
  "description": "A curated library of VS Code chatmodes and instructions for GitHub Copilot",
  "version": "1.0.0",
  "last_updated": "2025-08-01",
  "chatmodes": [
    {
      "name": "Beast Mode 3.1",
      "description": "Advanced autonomous coding agent with extensive tool access and iterative problem-solving capabilities",
      "author": "burkeholland",

Tomcc

Client Blob Cache

What's the Client Blob Cache

The Client Blob Cache is a new Bedrock optimization - it allows blocks and biomes to be cached on Clients to avoid resending identical chunks over and over. Chunks and biomes make up the vast majority of network traffic in a lot of common cases (eg. login, teleport or dimension switches) but at the same time, they rarely change. Allowing the Client to reuse chunks it has seen in the past can save a ton of traffic and latency!

The Client Cache is a Content Addressed Storage (a bit like git) that stores Blobs and retrieves them based on their full hashes (BlobIds). This means that the cache doesn't actually know about Chunks - in the future, we might start using it for more types of data, like skins or data driven entities.

A nice thing we get from the CAS approach is that the cache is persistent: returning players will be able to reuse content that was sent them in previous sessions or even previous sessions in different servers as long as tha

dktapps

Block Storage & Network Protocol Changes

Paletted chunks & removing BlockIDs brings a few big changes to how blocks are represented. In Bedrock, Blocks used to be represented by their 8 bit ID and 4 bit data; this means that we can only represent 256 blocks and 16 variants for each block. As it happens we ran out of IDs in Update Aquatic, so we had to do something about it :)

After this change, we can represent infinite types of Blocks and infinite BlockStates, just like in Java. BlockStates are what is sent over the network as they are roughly equivalent to the old ID+data information, eg. they're all the information attached to a block.

BlockStates are serialized in two ways:

PersistentID: a PersistentID is a NBT tag containing the BlockState name and its variant number; for example

Tomcc

[
    {
        "data": 0,
        "id": 0,
        "name": "minecraft:air",
        "runtimeID": 0
    },
    {
        "data": 0,
        "id": 1,

Tomcc

Block Storage & Network Protocol Changes

Paletted chunks & removing BlockIDs brings a few big changes to how blocks are represented. In Bedrock, Blocks used to be represented by their 8 bit ID and 4 bit data; this means that we can only represent 256 blocks and 16 variants for each block. As it happens we ran out of IDs in Update Aquatic, so we had to do something about it :)

After this change, we can represent infinite types of Blocks and infinite BlockStates, just like in Java. BlockStates are what is sent over the network as they are roughly equivalent to the old ID+data information, eg. they're all the information attached to a block.

BlockStates are serialized in two ways:

PersistentID: a PersistentID is a NBT tag containing the BlockState name and its variant number; for example

dktapps

{
  "geometry.humanoid": {
    "bones": [
      {
        "name": "body",
        "pivot": [ 0.0, 24.0, 0.0 ],
        "cubes": [
          {
            "origin": [ -4.0, 12.0, -2.0 ],
            "size": [ 8, 12, 4 ],

shoghicp

INFO UNKNOWN InventoryTransaction log:
INFO UNKNOWN  |- InventorySource #3 [-1]
INFO UNKNOWN  | * InventoryAction [InventorySource $3] #0 [1 x Wool(35)@0] -> [0 x (0)@0]
INFO UNKNOWN  | * InventoryAction [InventorySource $3] #0 [1 x Wool(35)@0] -> [0 x (0)@0]
INFO UNKNOWN  | * InventoryAction [InventorySource $3] #0 [1 x Dark Oak Wood Planks(5)@5] -> [0 x (0)@0]
INFO UNKNOWN  | * InventoryAction [InventorySource $3] #0 [1 x Raw Chicken(365)@0] -> [0 x (0)@0]
INFO UNKNOWN  | * InventoryAction [InventorySource $3] #0 [1 x Raw Chicken(365)@0] -> [0 x (0)@0]
INFO UNKNOWN  | * InventoryAction [InventorySource $3] #0 [1 x Dirt(3)@0] -> [0 x (0)@0]
INFO UNKNOWN  | * InventoryAction [InventorySource $3] #0 [1 x Raw Porkchop(319)@0] -> [0 x (0)@0]
INFO UNKNOWN  | * InventoryAction [InventorySource $3] #0 [1 x Raw Porkchop(319)@0] -> [0 x (0)@0]

kroer

Metadata id	Object	Description	Type	Checked
1	Wolf	Tail angle	int
	Boat	Health	int
Minecart	Health	int
2	Entity	Variant	int	👍
FallingBlock	fall damage	int	👍
Slime	size	int	👍
3	Entity	Color (for sheep in particular)	byte	👍
4	Entity	name	string	👍