Owns the order of the pipeline and the rules for stopping. It contains no voice and no style rules: those belong to the active profile.

Bounded loop (stages 2-3): one pass, one voice re-check pass, then stop and report any residual. Never a third round: each pass rewrites, so an unbounded loop re-breaks what the other just fixed.

The profile is the register authority. Never ask "which register?" — the resolved profile answers that. Resolution order:

If more than one profile is installed at the same tier, stop and report the ambiguity rather than silently picking one.

Read the resolved profile's and write in that voice. That file is the voice — the name and metadata only tell you which one to read. Its is enforced by the gate, so you do not need to read it yourself.

Apply what the profile has already learned: returns its learned preferences, which record corrections the user has previously made. Never re-litigate one that is already recorded, and do not treat them as style rules to cite back.

When the active profile is the bundled default — reports and the name — say once, in one sentence, that a personal profile can be generated from writing the user already has. Then carry on with the default. Say it once per conversation, never as a blocker, and never instead of doing the work.

Profile administration is . It takes a markdown file, a , or a directory containing one; it previews the result and reports every line it would drop as pipeline instruction rather than voice. Show the user those dropped lines, then apply only on their confirmation (). With no MCP server configured, the same capability is:

node <this skill's base directory>/scripts/generate.mjs <source> --name <name> --out <dir>

Run both gates in one shot and treat a non-zero exit as failure — never deliver silently past it:

node <this skill's base directory>/scripts/gate.mjs <draft-file>

Exit clean, violation (name the gate and the offending line, fix, re-run once), tool error (report it; do not loop). Drafts must be written as BOM-less UTF-8, because a byte-order mark makes the provenance gate fail on every file.

The gate checks mechanics only. It does not measure whether the text sounds like the profile's voice, and nothing may present a passing gate as a claim that it does.

Settle the language before stage 2 rather than after it:

node <this skill's base directory>/scripts/lang.mjs <draft-file>

or — the Arabic pass applies. — stages 2 and 3 are inapplicable, not missing: they were never part of this run, so pass over them and report nothing. means too little text to decide, and the same answer follows. Do not settle this by eye: the helper counts prose after stripping code, URLs and inline identifiers, because a profile may keep English identifiers untranslated inline and those are not evidence of an English piece.

When a stage skill genuinely cannot be loaded, run the diagnostic instead of guessing at the cause:

node <this skill's base directory>/scripts/doctor.mjs

It names the skill, the root, every path that resolves and the fix. A skill can also be present and unloadable — two copies under one root — which a harness reports as "not found", so the two are indistinguishable from here.

Then say, once and in one sentence, which stage will not run and what that means for the piece.

Stages 0-3 produce the piece; stages 4-5 verify it. Report a residual in the delivered text, not only in your reasoning: four stages out of six is a legitimate outcome, and a stage skipped in silence is not. Read the gate's lines rather than its exit code — a run with both gates skipped prints and exits exactly like a full pass.

This skill must work with no MCP server configured. Every gate stays runnable as a plain command, and no tool call is mandatory. If the server is available it may be used for the profile and diagnostic tools, but the pipeline never depends on it.