Voice ForgeTHE DOCUMENTATION
v2.9.1
SOURCE REFERENCE Generated from the current pluginskills/voice-forge/references/manage-rules.md

Show and change rules directly

A profile grows two ways: from training (rounds, lessons, promotion) and from rules the user states directly. A stated rule needs no training: the user's word is the evidence. It still gets the full rule format and the user's yes on the exact words.

Show

Run python3 <skill>/scripts/vf.py rules --profile <name> (or --base). It prints the brief, then each section with its status and one line per rule: ID, strength, kind, support, language scope and the instruction. It also lists the base rules that apply in the profile's language. Show it to the user as it is. --full prints the whole file.

Without a shell, read rules.md and give the same summary by hand.

Support tells the user how sure the rule is: trained (3 or more rounds), stated (the user said it), adopted (a field convention the user chose), thin (approved on little evidence), transferred (copied from another language, not yet confirmed) and confirmed (transferred, then confirmed by a round).

Add

The user says what they want, for example "all quotations use «»".

  1. Check what exists. If a rule already covers it, in the profile or in base.md, say so and stop.
  2. Pick the place. If it is true in all the user's writing in one language (for example «» in Spanish), propose base.md with transfer: es-only. Otherwise the profile. Pick the section with schema-nonfiction.md.
  3. Draft the full rule: instruction, strength, kind, applies, except, check, an auto check if one fits (see the table in schema-nonfiction.md; for "never start a paragraph with X" use no-paragraph-start), transfer if it is language specific, evidence: stated <today>, status: approved <today>. Get the ID from vf.py next-id --profile <name> (add --never for a prohibited rule; --base for base).
  4. Show the block and ask yes, no or reword. Write the user's rewording exactly.
  5. Write it: save the block to a temporary file and run vf.py rule add --profile <name> --section <2 to 10> --file <block>. It refuses a reused ID or a change that breaks the file. Then vf.py save -m "add rule <ID> to <name>".

From an analysis

Analyze mode often finds a habit the user recognizes. Three different answers lead to three different results:

  • A fact ("I wrote that chapter alone") changes no rule or lesson.
  • Recognition ("yes, I do that in explanations") is not a rule. Analyze mode offers it as a candidate lesson, which still needs training.
  • A stated rule ("make it a rule: always give an analogy before a new term") follows the steps above. Draft the full contract, show it, and write it only after the user's yes on the whole block, with evidence: stated <today> (analysis:<id>).

Approving a chapter, or saying the analysis is right overall, never approves a rule.

Change

Show the current block and the new one side by side. On yes, run vf.py rule replace <ID> --profile <name> --file <block>. Keep the ID. Add stated <today> to the evidence if the user changed the wording.

Drop

On the user's yes, run vf.py rule drop <ID> --profile <name> --reason "<their reason>". The rule moves to a "Retired" line in Notes, and its ID is never used again. If the section has no rules left, its status becomes unknown.

Rules for the agent

  • Never add, change or drop a rule without the user's yes on the exact words.
  • A rule the user states for one task only ("no bullet points in this email") is an instruction for that task, not a rule. Ask before saving it.
  • Do not use this to skip training: when the user is unsure about a habit, propose a lesson instead, and let rounds decide.

← Back to the reference library

Find your next step