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. No longer used to change SABLE: since 19 Oct 2026 changes are made in Prompt Control.
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.

A rejection also stays on record. Every new proposal, from chat or from the nightly learning loop, is checked against the rules you rejected as well as the queue and the rules in force. A rule identical to one you rejected is refused outright, and a close rewording comes back to its author marked as something you already turned down.

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.

Where prompt changes are made

Since 19 Oct 2026, prompt changes are made in the app: edit the base prompt in Prompt Control, Test, then Promote (or Submit for review). The comparison with Lindsey's own canonical document was removed from the page, because that document is no longer the source of changes.

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 pointer is part of the prompt but is no longer shown as a panel on Prompt Control (19 Oct 2026): skills are an engineering concern.

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, 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 any promote	Confirm the agent version changed, and watch the next board.