Prompt Maintenance

Prompt Control covers how to change the prompt. This page covers how to keep it healthy — the recurring routine, and the panels that support it.

They are different jobs. Changing the prompt is something you do when SABLE needs to behave differently. Maintenance is something you do on a cadence whether or not anything is wrong, because without it the prompt only ever gets longer.

Why this is a standing job

SABLE's prompt is append-only by construction. Every approved rule is folded into the Learned Rules block, and the fold rebuilds that block from every approval still marked approved or executed. Nothing takes a rule out unless a person decides to.

Measured on 2026-09-04:

Base prompt	unchanged across 32 agent versions
Learned Rules block	502 → 6,846 characters, more than doubling in a single approval session
Still pending	49 proposals

Every character is re-sent on every request of every run. A longer prompt is slower and more expensive, but the part that actually matters is dilution: the more rules SABLE carries, the less weight any one of them has.

The Prompt health panel shows this as two numbers side by side — tokens per run today, and tokens per run if the pending queue were approved as-is. The second number is the argument for doing this work.

Terminology

Words that look interchangeable and are not.

Term	What it means
Base prompt	The foundation SABLE runs. The only part written by a person, changed only by a deliberate Promote.
Canonical prompt	The owner's own document, regenerated daily. SABLE does not follow it — the two drift apart until someone brings changes across.
Learned rule	One standing instruction, added by approving a proposal. Rendered as a flat dated bullet with no nesting, so each must stand on its own.
Learned Rules block	The assembled section holding every rule in force. Read-only; you change it by approving, rejecting, and retiring.
The fold	Rebuilding that block. It regenerates from every proposal currently approved rather than appending — which is why a rule leaves only by leaving the approved set.
Skill	Guidance for a recurring situation, held outside the prompt and fetched only when it applies.
Skills pointer	The short block telling SABLE skills exist. Carries the count, never the contents — ten skills cost three more characters than one.
Agent version	A counter that rises on every write to the live prompt: promote, fold, or rollback. A receipt that something changed, not a measure of quality.
Proposal	A suggested change waiting in Proposed rules. Changes nothing until approved.

Adding is immediate; removing is not

Approving a proposal folds the prompt on the click — the rule is live straight away and the agent version goes up. This is why a sitting of approvals produces a run of versions in quick succession.

Retiring does only half of that. It records that the rule should be left out of the next fold, and nothing folds automatically. Retire several rules, close the page, and every one of them is still in force.

Reject and retire are different decisions

Reject is for a proposal that should never have become a rule — it was never in force, so nothing about SABLE changes. Retire is for a rule that is in force, possibly for months, and keeps the record that it was once approved. A rule can only be retired if it was approved first, and only retiring needs a fold afterwards.

The routing rule

Everything below rests on the three-tier test from Section 28 of your own prompt. Every candidate answers exactly one question:

Tier	The question it answers	Where it goes
System prompt	How does SABLE behave?	The prompt
Active Projects file	What is true about a client, project, or person?	The AP file
HQ Log	What changed today?	The log

A rule that names a client almost always belongs in the AP file, not the prompt. That is the most common mistake by a wide margin, and the health check exists mostly to catch it after the fact.

The rare exception is a client behaviour so unusual it changes universal behaviour — the example in your own §28 is "Lindsey does not attend Katerina White CP meetings." If you cannot make that case out loud, it is an AP fact.

Daily — work the queue

This folds into the end-of-day routine you already run.

1. Open Prompt in the navigation.
2. Read Proposed rules. Each is a rule SABLE drew from a recurring correction.
3. For each, run the three-tier test before deciding:

• Universal behaviour → Approve. It folds into the prompt and re-versions the agent.
• Names a client, project, or person → Reject, reason client fact. Add it to the AP file instead. Rejecting is not throwing it away; it is filing it correctly.
• Nearly right → Edit first, then Approve. Your edited wording is what gets folded, not what was proposed. The edited chip on the row records that.
• Already covered by a rule you approved before → Reject, reason duplicate. Approving it is how the ledger ends up holding one fact four times.

A rule must stand on its own. The fold produces flat, dated bullets with no nesting, so a rule that depends on the one above it will not work once folded, and a section layout cannot be expressed as a rule at all. Those belong in the base prompt.

Weekly — run the health check

Open Prompt health, below the editor. It is read-only: it names what should leave, and you decide.

1. Duplicates. Rules stating the same fact more than once. The fullest is tagged keep; the rest get a Retire button. The heading shows the characters you would reclaim.

2. Names a client, person or project. Rules that failed the three-tier test at approval time. Each gets a Retire button with the reason pre-filled. Before retiring one, make sure the fact is written into the AP file — retiring removes it from the prompt and puts it nowhere else.

3. Fold. This is the step it is easy to miss:

Retiring does not change the running prompt. It changes what the next fold emits.

After retiring anything, a banner appears saying so, with a Fold now button. Click it. The rules block is rebuilt from what is currently approved, the agent is re-versioned, and the retired rules are genuinely gone. Until then the live prompt still contains every one of them.

When you regenerate your canonical prompt

Your §27 routine regenerates your prompt every day. The copy SABLE runs does not update itself — it is pinned to whichever version was last promoted here.

Use Compare against Lindsey's canonical prompt: paste your current version and click Compare. Rather than a diff of 42,000 characters, every changed line is sorted into:

• Universal — how SABLE behaves. These are the real import candidates.
• Client facts — lines naming a client, person, or project. Under the three-tier test these belong in the AP file. Importing them would add to exactly the problem the health check reports.
• Already covered — a folded rule already says this. Importing would duplicate it.
• Removed — you dropped it. A question about whether SABLE should too, not an import.

Both regeneration dates are shown, so you can see at a glance how far apart the two copies are.

Comparing changes nothing. To act on it, edit the base prompt, Test, then Promote.

Skills — guidance that does not live in the prompt

Some guidance is only needed in specific moments. Carrying it in the prompt means paying for it on every run regardless.

Skills are fetched when they apply. SABLE calls list_skills to see what exists, and read_skill to read one. The prompt holds only a short pointer carrying the count — so adding a skill does not make the prompt longer.

The Skills pointer panel shows that block when skills are registered.

Fixing a skill

There is no skill editor, and deliberately so — noticing a skill is wrong happens while using SABLE, and the person who notices is rarely the person who may change it.

Say what is wrong in chat. SABLE reads the current skill and queues a proposed rewrite, which lands in Proposed rules in Prompt Control next to the prompt rules. The row names the skill and shows how many lines the change adds and removes.

Approving it is yours alone, the same as a prompt rule — a skill is prompt content, so leaving it open would make the skills table a way around the single-owner control rather than an extension of it. You can Edit the text before approving, and your version is what gets written.

The previous text is kept on the approval. A change that reads badly is undone by proposing the old text back, not by retiring the approval — retiring the record would close it while the skill went on serving the new text.

What only you can do

SABLE_PROMPT_OWNER restricts these to you, so the application never runs two competing prompts:

• Promote a base prompt, and Rollback
• Approve, Edit, or Retire a prompt rule
• Fold now

Any admin or lead can read the prompt, run Test, use Compare, and read the health report. When someone else edits the base prompt their button says Submit for review, and it becomes a proposal you approve.

If a change reads badly

Roll back. Do not write a second rule to correct the first.

Every promotion is versioned. History → Rollback restores a prior base and re-versions the agent; the bad version stays in the audit trail. A corrective rule leaves both the mistake and the correction in the prompt permanently, and the next reader cannot tell which one is live.

A reasonable cadence

When	What
End of day	Work the proposed-rules queue. Route client facts to the AP file rather than approving them.
Weekly	Run the health check. Retire duplicates and misroutes, then Fold now.
After regenerating your prompt	Compare, and import only what the universal bucket contains.
After any promote	Confirm the agent version changed, and watch the next board.