System upgrade

System Upgrade

Meta-work prompts that upgrade the system, not the task. Most prompting improves one piece of output. These improve the thing that produces all future output: the agent's harness, the user's security posture, their strategic focus, and the durability of both. They pay off repeatedly, so they are worth doing well and worth the strongest model you have.

Adapted, with credit, from Daniel Miessler's "Prompts to Run When Fable Comes Back." This skill adds the running layer Miessler's list leaves to the reader: when to run each prompt, how to run it without doing harm, and how to keep it portable across agents. The full prompt set lives in references/prompts.md — load it when a run starts.

Why a running layer matters

The raw prompts are powerful and easy to run badly. Run naively, an agent will dump all of them at once, produce essays instead of changes, give confident strategic advice on half the picture, or "upgrade" a system by piling on more scaffolding. The protocol below is what separates a real upgrade from a wall of text. Follow it.

Before anything: map the config surface

These prompts act on the user's system, so first find what that system actually is for this agent. Do not assume Claude Code. Look for and read whatever applies:

• Claude Code: CLAUDE.md (global ~/.claude/ and project), ~/.claude/settings.json hooks, installed skills, the project memory directory, notes.md.
• Codex / OpenAI agents: AGENTS.md, repo config, tool definitions.
• OpenClaw, Hermes, and others: their equivalent instruction files, memory stores, and tool/permission configs. If you do not know the convention, ask or inspect rather than guess — getting the surface wrong wastes the whole run.
• Cross-agent: the user may run several. Note which configs exist where; prompt 17 reconciles them.

State what you found before running a prompt against it. If you cannot find a config surface, say so and ask where it lives.

The running protocol

The order of a session:

1. Map the config surface (above) and state what you found.
2. Pick the prompt(s) that fit the user's trigger (see cadence); confirm scope before starting.
3. Run one prompt: do the work against the real files, make the reversible edits, show the diff.
4. Stop for the user's decision before moving on; confirm anything irreversible first.
5. Note whether that prompt is worth re-running later and what would trigger that. Then next.

The principles below govern how to do steps 3 and 4.

One prompt at a time. Never batch. Run a single prompt, do the work, show the result, get the user's decision, then move to the next. Batching produces shallow output and overwhelms the user with changes they cannot review.

Apply, do not just analyze. The point is a changed system, not a report. Make the actual edits to the actual files. Show a diff or a clear before/after for each change. A prompt that ends in a tidy summary and zero file changes has failed.

Two safety rails, always on:

• Autonomy rail. Gate on irreversibility, not nervousness. Reversible edits (config, docs, memory, anything you can revert) → make them and show the diff, do not ask permission. Irreversible or outward or costly actions (deleting files you did not create, deploys, pushes to shared branches, sending data anywhere, spending money, enabling automation) → confirm first. A skill that edits a person's setup must not wreck it; a skill that asks permission for every comma is useless.
• Evidence rail. The life and work prompts (9–14) produce confident, wrong advice on partial information — this is their main failure mode. Before concluding anything strategic, gather the user's full context (projects, audience, income, constraints, what they actually do), ask for what you cannot see, and label confidence. A clean narrative that fits half the facts is worse than no narrative.

Bias to the lightest path. This skill can quietly become a scaffolding generator, which is the opposite of an upgrade. For every addition — a rule, a hook, a file, a memory — ask whether it earns its weight, and default to cutting before adding. The strongest models need less scaffolding, not more; instructions that compensate for a weakness the current model no longer has are dead weight that dilutes the rules that still matter. Net-neutral-or-negative is the target for any harness edit.

When to run which (cadence, not calendar)

Run by trigger, not on a schedule. Running these on a timer — especially the strategic ones — becomes busywork that feels productive and changes nothing.

• A new model lands → harness prompts (1, 2, 6). A stronger model rots the scaffolding the weaker one needed; re-audit and cut.
• Before committing real time to a build or bet → 10, 12, 13. Catch a wrong direction before pouring months in, not after.
• After shipping something and getting real feedback → 9, 11. New external evidence is the only thing that makes re-running strategy prompts worthwhile.
• Adding tools, MCP servers, or deployments → 7, 8.
• Running multiple agents that may have drifted → 17.
• Light quarterly pass → re-audit the attack surface, prune dead memory/rules, glance at the ratio of building-for-the-world vs. tinkering-on-the-system.

The gate before re-running any strategic prompt (9–14): is there new external evidence since last time? If no, do not re-run. Re-deriving the same narrative without new data is avoidance dressed as progress — for most people the real constraint is too little contact with the outside world, and another internal audit makes it worse, not better. Send them to get the evidence instead.

The prompts

Full text and per-prompt running notes are in references/prompts.md. Read it when a run begins. The five Miessler categories plus one original:

1. Harness optimization (1–6): goal orientation, Bitter-Lesson trimming, self-model audit, memory that compounds, defining "better", the autonomy ladder.
2. Security (7–8): prompt-injection posture, deployed-infrastructure attack surface.
3. Life & work (9–14): Ikigai / focus, where you're most wrong, what 10×s vs. dies, decisions into policy, the one binding constraint, the bus-factor audit.
4. Development (15): the autonomous maintenance loop — and an honest check of whether it fits, since for solo/no-CI setups it usually does not.
5. Public presence (16): consolidating scattered work into one durable home.
6. Cross-config consistency (17, original): reconcile the configs across the agents the user actually runs, so they do not drift or contradict.

How to use this (for the human)

Tell the agent which area you want to work on, or just say "run the system upgrade" and it will start at prompt 1. Expect it to go one prompt at a time, ask before irreversible changes, and edit your real files (reversibly — you can revert anything). It will tell you which prompts are worth re-running later and which to leave alone until you have new information. You stay the decision-maker on every strategic call; the agent surfaces the options and does the mechanical work.