Draft mode

Write new text in the user's voice. The profile is the specification; the reviewer checks the result against the same profile.

The cycle: profile → plan → draft → mechanical checks → review → targeted revision → final check.

1. Gather

• The task: what the text is, who reads it, how long it should be, where it goes.
• The facts: only what the user gave, what a named source says, or what is common knowledge. If a key fact is missing, ask before writing, or leave a clear [TODO: ...] marker if the user is away.
• The profile: base.md and profiles/<name>/rules.md. Read section 1 (the brief) first. Read "Reading a rule" in schema-nonfiction.md once per session: it says how strength, kind, scope and exceptions work.
• Examples: 2 or 3 short texts from this profile only (its samples/ and the Rewrite section of recent rounds) that match the register and, if possible, the topic. They show rhythm and word choice better than rules do.
• The language file: lang-en.md or lang-es.md.

Do not load more than you need. Three good samples beat ten. Do not load lessons, analyses or old rounds beyond the samples.

2. Pick the rules that apply

For each rule, check applies, except and the task. Keep the ones that apply; ignore the rest. Skip rules marked en-only or es-only when the text is in the other language. An argument rule does not apply to a two line email. Sections marked unknown or not_applicable give no rules: follow the samples and the generic rules there.

3. Plan

Write a short plan for yourself, by section of the profile, only where rules apply:

• Architecture (2): the order of sections or moves; how it opens and how it ends.
• Argument (3): the main claim, its support, the objection to answer.
• Paragraphs (4): one line per paragraph: its claim and its support.
• Evidence (9): which numbers and sources go where, and what each needs (unit, year, comparison).

Each paragraph must add something the reader does not have yet.

4. Write

• Follow the rules for discourse (5), sentences (6), vocabulary (7), voice (8) and constraints (10), and the base rules.
• mandatory and prohibited rules always hold where they apply. preferred rules hold unless the task gives a reason. A tendency is a habit over the whole text, not a limit on each sentence.
• Match the samples' sentence length, openings, connectors and punctuation.
• Avoid the strong patterns in slop.md from the first draft.

5. Mechanical checks

If you can run a shell:

python3 <skill>/scripts/lint.py --lang <en|es> <file>
python3 <skill>/scripts/measure.py check --rules <profile>/rules.md --base <home>/base.md --lang <en|es> <file>

Fix every lint error and every confirmed violation. A result marked lead needs a look: scope or an exception may cover it. A note: line is not a failure: the other checks ran. If it says a file uses the old layout, read that file's rules and judge them yourself, and offer to migrate it once (migrate.md).

6. Review

Follow review.md. Use an independent subagent if your agent can start one.

For short everyday texts (under about 150 words, such as a quick email), a review by yourself is enough, and no written report is needed.

7. Revise, then stop

• Fix each VIOLATION with the reviewer's fix or a smaller one: high severity first, then medium. Leave low severity and UNCERTAIN items unless the fix is small and safe.
• Change only the flagged spots. Never fix a rule by changing meaning.
• Run the mechanical checks again and do the final check in SKILL.md section 6.
• Review a second time only if the first review found a high severity violation. Never more than two reviews. If something still fails, stop and report it.

8. Return

• Return the text only, in Markdown, unless the user asked for notes.
• After the text, add one line per open item: a [TODO] marker, a guess the user must verify, or a violation you could not fix. Say nothing about the review when it passed, unless the user asks.
• If the text goes into a file in a git repo, write it there, then record it as a draft: python3 <skill>/scripts/vf.py mark-draft <file> --profile <name>. It commits only that file, labeled vf-draft, so Learn mode can later compare the user's edits with this exact draft. Tell the user: when they finish editing, vf-learn <profile> <file> learns from their changes.