The Construct Graveyard

Most constructs die young.

They are published with good intentions. Someone spends an afternoon writing a construct for code review or debugging or project planning. They add tags, write a description, click publish. It appears in the registry. Maybe it gets a star or two. Then nothing. No forks. No downloads. No second look.

This is not a failing of the registry. It is the natural outcome of a creative ecosystem. Most songs are never heard. Most books are never read. Most open source projects have zero stars. The construct graveyard is not a bug — it is the inevitable consequence of a platform where publishing is free and easy.

But understanding why constructs die can teach us what makes the survivors live.

Cause of Death: Generic

The most common killer. The construct says “review code for quality” or “help with debugging.” It defines no persona, no specific methodology, no prioritization, no boundaries. It is, effectively, a slightly reworded version of what the base model already does.

A construct that does not make the agent meaningfully different from its default behavior has no reason to exist. The bar is not “does this produce an agent that can do the task?” — the base model can do most tasks. The bar is “does this produce an agent that does the task in a way that is noticeably better, different, or more specialized?”

The survivors are specific. Not “code reviewer” but “code reviewer that prioritizes SQL safety and treats every string concatenation near a database query as a P0 finding.” The specificity is the value. Without it, there is no reason to choose this construct over the default.

Cause of Death: Too Long

The second killer. Someone writes a construct that is 5,000 words long, covering every possible scenario. Every edge case. Every exception to every rule. Every caveat to every exception.

Context windows are finite. Every word in a construct competes with the actual task for the agent's attention. A 5,000-word construct leaves less room for the code being reviewed, the bug being debugged, the plan being evaluated. The construct itself becomes noise.

The survivors are concise. They say what matters and stop. A great construct for code review might be 500 words. It defines the persona in two sentences, lists five priorities in order, specifies the output format, and defines three things the agent should never do. Everything else is trust in the model's general capability.

Cause of Death: No Opinion

A construct that lists every possible approach without choosing one is a textbook, not a persona. “You may use either tabs or spaces. Both are valid choices.” An agent that follows this instruction has no opinion. It will do whatever the user seems to prefer. It adds no value.

The survivors are opinionated. “We use tabs. If you see spaces, convert them.” This is a choice that will be wrong for some teams. That is fine. The teams who disagree will fork and change it. The teams who agree will star it and use it as-is. Both outcomes are better than a construct that tries to please everyone and helps no one.

Opinion is what makes a construct worth forking. If there is nothing to disagree with, there is nothing to build on.

Cause of Death: Wrong Level

Some constructs die because they operate at the wrong level of abstraction. A “React Best Practices” construct that includes rules about semicolons is mixing architectural guidance with formatting rules. A “Startup Advisor” construct that includes TypeScript configuration is mixing strategic advice with implementation details.

The survivors stay at one level. A soul construct defines identity. A skill construct defines workflow. A project construct defines conventions. When these concerns are mixed, the result is a document that does not know what it is — and an agent that does not know what it is supposed to be doing.

What Survives

The constructs that live are the ones that make someone say: “That is exactly how I think about this problem, but articulated better than I could.”

They are specific enough to be useful and general enough to be forkable. They are short enough to fit in context and long enough to encode real expertise. They have opinions that provoke forks. They stay at one level of abstraction.

Most importantly, they come from experience. Not from research, not from best-practice lists, not from what sounds impressive. From someone who has done the work, felt the pain of doing it wrong, and developed a method for doing it right.

The graveyard is full of constructs that were written. The registry is alive with constructs that were lived.

Related: The Taste Gap explores what separates great constructs from mediocre ones. The Fork Graph examines which branches survive and why.