PCH-Optimizer Is an Operating System for Prompts

Reading the PCH-Optimizer prompt catalog again, I no longer see it as simply a prompt that improves prompts. It behaves more like a small operating system: it receives a prompt, classifies it, unfolds only the relevant layers, diagnoses it, assembles an upgrade, verifies the result, and hands it off.

This note covers 45 of the 115 catalog items. I am not publishing the original prompt as a public prompt dump. The public work here is to read the structure and extract blog-worthy ideas from it.

Bundle	Items	Reading lens
Meta-System Prompt	4	The upgrader’s identity and mission
Operating Principle	8	The constitution behind every decision
Input Metadata	7	The input contract before the prompt
Target Type Classifier	7	The T1-T7 classifier
Layer Scope Rule	4	The switch that decides which layers open
Pipeline Stage	9	The execution path from CLASSIFY to HANDOFF
Output Contract	6	The section contract for final answers
Total	45	The operating layer

Why an Operating System?

A common failure in prompt upgrading is to edit the sentence immediately: make it clearer, more detailed, more structured. PCH-Optimizer pauses before that. It first asks what kind of work this prompt is.

Is it a one-shot instruction? A few-shot extraction task? A grounded generation task? An agent prompt with tools? A subagent? A long-running harness? A creative persona prompt?

That question changes the whole upgrade. T1 prompts mostly need the Prompt layer. T3 prompts need Context and citation policy. T4 and T6 prompts may fail because of tools, state, termination criteria, or verification loops rather than wording.

An operating system’s first job is to place work into the right process. PCH-Optimizer does the same for prompts.

The Eight Principles Are the Kernel

The eight Operating Principle items come before technique. The goal is not to apply as many techniques as possible. The goal is to apply only what is needed without violating the deeper principles.

Four principles keep pulling me back.

Principle	Meaning in prompt design
Context is finite and decays	Keep high-signal tokens instead of adding more
Right altitude	Avoid both brittle hardcoding and vague direction
Model does not equal harness	Separate wording failures from runtime failures
Verification over trust	Add pass/fail criteria instead of vibe checks

Without principles, prompt improvement becomes decoration: XML, examples, checklists, bans, and extra sections. The answer may look more engineered while nobody knows which layer improved.

Principles ask not “how much can we add?” but “why exactly this much?”

Input Metadata Is the API in Front of the Prompt

PCH-Optimizer does not stop at the raw prompt. It asks for metadata such as target model, deployment surface, available tools, constraints, known failures, and success criteria.

That feels like API design. When a function lacks arguments, it starts guessing internally. Prompts do the same. Without the model type, it is hard to decide how much reasoning scaffold to include. Without the deployment surface, we do not know whether this is a one-shot reply, a RAG pipeline, or an agent loop.

A strong prompt upgrade begins with these questions.

Where will this prompt run?
What can the model see?
Are there tools or state?
How will success be judged?
What has already failed?

Those five questions make a prompt much steadier.

T1-T7 Is a Blog Idea Generator

The Target Type Classifier is already a set of blog topics.

Type	Blog question it opens
T1 one-shot instruction	How much structure does a one-line request need?
T2 few-shot extraction/classification	How many examples are enough?
T3 grounded generation	Are citation and hallucination control prompt work or context work?
T4 agent system prompt	Why does a tool-using model need a harness?
T5 subagent	Why can a narrower role be stronger?
T6 long-running harness	How does work survive beyond one context window?
T7 creative/persona prompt	How do voice and world become a contract?

The type gives the angle. A T3 article naturally talks about grounding, retrieval, and citations. A T6 article talks about state artifacts and compaction. A T7 article talks about voice, world, and emotional pressure.

The Six Stages Also Write the Article

The PCH-Optimizer pipeline is CLASSIFY, DIAGNOSE, ENGINEER, ASSEMBLE, VERIFY, HANDOFF. That sequence works for prompt upgrading, but it also works for writing the blog series itself.

Stage	Prompt upgrade	Blog writing equivalent
CLASSIFY	Identify type and scope	Decide the reader and problem type
DIAGNOSE	Find defects and risks	Show why the topic is hard
ENGINEER	Select techniques	Choose explanation devices and examples
ASSEMBLE	Produce a copyable artifact	Assemble a readable article
VERIFY	Attach tests and rubrics	Check claims, numbers, links, and images
HANDOFF	Log changes and next iteration	Leave the reader with the next question

Turning the prompt catalog into blog posts followed the same pipeline. I classified the whole catalog, diagnosed which existing posts covered which parts, split the 115 items into three bundles, and assembled each bundle into an article.

Output Contracts Are Promises to the Reader

The six Output Contract items fix the answer order: classification, diagnosis, technique design, upgraded artifact, verification, and handoff. With that order, a model answer becomes a report instead of a blob.

Blog series need the same kind of promise.

• What part of the catalog this article covers
• Why this bundle matters
• What the PCH lens reveals
• Which prompt ideas can be reused
• What question the next post should answer

Repeat that structure and the series starts behaving like a harness. Each article is new, but the way of reading becomes familiar.

Prompt Idea from This Bundle

You are a prompt operating-system designer.
Do not rewrite my raw prompt immediately.
First classify it by T1-T7 type, required P/C/H layers, success criteria, and deployment surface.
Then unfold only the necessary layers, upgrade the prompt, and end with an output contract and verification criteria for repeated use.

The point is sequence, not speed. Instead of rushing to the answer, the operating layer first decides where the work belongs. This is where prompt engineering starts moving from sentence craft into system design.

The next note looks at what this operating system diagnoses and how it earns the right to say an upgrade is actually better.